How to build a customer support agent
Overview
Build a customer support agent that handles ticket triage autonomously—resolving simple cases directly, routing specialized issues to sub-agents, and escalating complex situations to humans. This tutorial walks you through creating the agent, configuring its tools and instructions, and deploying it to process support tickets automatically.
Customer support is a balancing act for AI.
On one hand, much of it can already be automated—AI can handle increasingly complex queries, reduce response times, and lower operational costs. On the other, great support requires a human touch. Some issues demand empathy, nuance, and the judgment that only a human can offer.
Agentic AI lets you balance these two forces. By building out a customer support agent that knows when to act independently and when to defer to a human, you get the benefits of automation without sacrificing quality.
In this build, we’ll create an agent that triages customer support tickets and, depending on the ticket details, either:
- Resolves the ticket
- Hands off to a 'Customer Feedback' agent
- Hands off to a 'Billing agent'
- Escalates complex cases to a human
Let’s build.
How the customer support agent works
A support triage agent may seem straightforward, but AI needs to understand ticket categories, determine resolution paths, decide when to delegate versus resolve directly, and communicate with customers appropriately. Then, it can update ticket statuses, route to specialized agents, and escalate to humans when needed, taking on all the complexity of first-line support.
You start by typing in a question:
Please check if we have any open support cases and resolve them.
The agent uses this as the starting point for a thinking-action loop using the LLM and the tools it has at its disposal. It checks your support database for open tickets, then analyzes each one to determine the best path forward.

To build this agent, you’ll need the following tools:
- Get Open Support Tickets to query your support database for open cases
- Check Ticket Status to verify whether a subordinate agent has resolved a ticket
- Mark Ticket as Closed to update the ticket status in the database when it is resolved
- Send Email to communicate the resolutions back to customers
The agent can also delegate tickets to specialized sub-agents:
- Billing Triage Agent to handle billing-related questions like invoices, refunds, W-2 requests, and EIN additions
- Customer Feedback Agent to review customer feedback from support tickets, community forums, and Google/Yelp/Social reviews, escalating negative posts that require human intervention
The tools are pre-built (some custom, others integrated into Retool), but the agent will decide how to use them. For simple cases like password resets or account access, the agent resolves them directly. For billing questions, it delegates to the specialized Billing Agent. For complex issues requiring nuanced judgment, it escalates to a human and sends you a notification email.
Once the agent processes all open tickets, it provides you with a summary showing which tickets were resolved, which were delegated, and which need human attention.

The agent can continue to work autonomously for several minutes, triaging support cases and routing them to the appropriate destination.
Set up your agent workspace
Before building your agent, make sure you have a few key pieces in place. Think of this as your agent’s operating environment—it needs access to data, a way to communicate, and a workspace to run in.
- Access to Agents. If you already use Retool, you can launch Agents directly from your dashboard. If not, you can sign up here.
- Email. Retool's built-in email functionality handles all customer communications with no configuration required.
- Support ticket database. Your agent will need to query and modify support cases, so connect a database that stores ticket information, including IDs, customer emails, statuses, categories, and descriptions. Don't have this set up yet? Here are your options:
- Build a Retool database table with sample tickets
- Set up a Google Sheet with mock support data
- Integrate your existing ticketing system, like Zendesk or Intercom
Here’s an example of the data we’re working with. Once these pieces are in place, you're ready to start building.
Setting up your agent
Start by heading to your Agents dashboard and selecting New Agent. You can start from the Customer Support Agent template—great if you want to explore a working version quickly—but in this post, we’ll walk you through how to build it from scratch to understand how each piece fits together. To start from scratch and give it a name and a description. For example, Customer Support Agent: A customer support agent that triages open tickets and either resolves them, delegates to sub-agents, or escalates to a human.” .
You’ll initially be shown the blank slate for the agent configuration:

We’ll keep this triggered by chat and use a GPT-4.1 model, along with the default temperature (which controls the agent's creativity) and iterations (the number of times the agent tries a specific step before moving on).
The two essential parts we need to change for our agent are:
- Instructions: The instructions are the prompt you give to the agent that tell it what it can do, how it can behave, and how it can use data and resources to achieve that aim.
- Tools: The tools agents use to perform actions and interact with data.
Creating your agent instructions
Prompts are the instructions you provide to an LLM. For an agent to handle complex, multi-step workflows reliably, you'll need to give it detailed, structured guidance.
The support triage agent uses a comprehensive prompt that covers every decision point the agent might encounter. The prompt begins by establishing the agent's identity and core responsibility:
This opening line sets the agent's persona and frames its primary function. It's not trying to replace human support entirely; it's just trying to handle initial triage efficiently.
Defining the core workflow
The prompt then establishes the fundamental rules for how the agent should operate:
This section prevents the agent from wasting time on already-resolved issues and ensures it proactively looks for work when not given a specific task. The explicit mention of database field values (status == 'open') helps the agent construct accurate queries.
Setting the resolution hierarchy
Next, the prompt defines a clear decision tree for ticket handling:
This establishes a "try first, delegate second" approach that maximizes direct resolution while maintaining flexibility to route specialized issues appropriately.
Mapping delegation paths
The agent needs explicit instructions on when to delegate and to whom:
Each sub-agent gets a clear description of its domain, including specific examples of ticket types it should handle. Without this mapping, the agent might guess incorrectly or fail to delegate when it should.
The prompt also specifies what information to pass during handoffs:
Defining escalation rules
For tickets that truly need human judgment, the prompt provides a clear escalation path:
This ensures nothing falls through the cracks when the agent encounters its limits.
Establishing communication standards
Customer communication requires specific guardrails:
These rules prevent privacy issues and ensure personalized responses. The prompt also includes logic to avoid duplicate emails when sub-agents have already communicated with customers.
Adding context variables
Dynamic variables make the agent's responses more natural and accurate:
These variables inject real-time information so the agent knows who it's helping and can reason about time-sensitive issues correctly.
Providing guidance prompts
Finally, the prompt includes suggestions for users who aren't sure what to ask:
This helps users discover the agent's capabilities through concrete examples rather than abstract descriptions.
The complete prompt serves as the agent's operating manual, encoding your support workflow into rules the AI can follow autonomously and consistently.
Connecting your tools
The agent will take the prompt and the user's request (to check and resolve open support tickets), and use the available tools to complete the task. You're building three types of tools for this customer support agent:
Core tools
These are native Retool capabilities that work immediately without configuration. We’re using the Send Email tool to handle customer communication.

This lets the agent send ticket updates with all the information a customer or admin needs, with formatted text, links, and proper structure:

Custom tools
These tools connect to your specific support infrastructure and contain the business logic unique to your workflow:
- The Get Open Support Tickets tool queries your support database to retrieve all tickets with
status == 'open'. It returns ticket ID, customer email, category, description, and creation date, giving the agent everything it needs to assess each case. - The Check Ticket Status tool verifies whether a ticket has been resolved, particularly useful after delegating to a sub-agent. Rather than assuming success, the agent can confirm completion before moving on.
- The Mark Ticket as Closed tool updates the database when the agent successfully resolves an issue. It takes the ticket ID and changes the status field to
'closed', ensuring your support metrics stay accurate.
To create these, select Add Tool, then Create new custom tool. Give your new tool a name (e.g., Get Open Support Tickets) and a description (“Gets a list of open customer support tickets. If you don't have a ticket to work on, check here for an open one.”)
The core of these is within the Function Logic. This is where you’ll create a function or workflow for the tool to follow:
![Get Open Support Tickets tool with SQL query selecting open tickets ordered by submission date.]](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fbclf52sw%2Fproduction%2F8d183a83c27346bfc53440100e1cf92ed20475b9-1999x679.png%3Fw%3D1200%26q%3D80%26fit%3Dmax%26auto%3Dformat&w=3840&q=75)
In this example, the Get Open Support Tickets tool uses a simple SQL query to retrieve open tickets from the database. The query selects all fields from the mock_support_tickets table where status = 'open' and orders results by submission date, ensuring the agent processes the oldest tickets first.
You can write similar queries or workflows for each custom tool, connecting them to your specific database schema and business logic. You can also connect directly to your CRM and customer support tools.
Sub-agents
Like turtles, its agents all the way down. Agents handle a specific action you need to perform. They then call on more specialized agents to handle more complex workflows. Our customer support agents call on:
- A Billing Triage Agent to handle all billing-related inquiries, from invoice requests to refund processing to tax documentation. When the main agent encounters a ticket categorized as billing or containing keywords like "invoice," "refund," or "W-2," it hands off the entire context to this specialist.
- A Customer Feedback Agent that processes feedback from multiple channels, including support tickets, community forums, and review platforms like Google and Yelp. It can respond to positive feedback, log feature requests, and escalate negative reviews that need human attention.
When delegating to a sub-agent, the main agent passes context (ticket ID, customer email, ticket description) and any relevant history. This ensures the sub-agent has everything needed to resolve the issue without having to ask the customer to repeat information.
To create a sub-agent, you can either create another agent from scratch as we’re doing here, or select Add Tool, then Use agent. This will allow you to select an existing agent or create a new agent.
From there, you head back to the Setting up your agent section of this build, only with different instructions and tools.
For instance, say we’re building the customer feedback sub-agent. Here’s the instruction prompt:
This prompt follows a similar structure to the main agent but focuses on a single, well-defined workflow. The numbered steps create a precise sequence that the agent must follow, from summarization to storage to customer communication. By specifying exact database fields and their allowed values (positive, negative, neutral), we get a consistent data structure across all feedback entries.
The conditional email logic based on sentiment ensures customers receive appropriate responses. Negative feedback gets acknowledgment and commitment to resolution, while positive feedback gets appreciation without over-promising. This maintains customer relationships while setting realistic expectations.
The tools are also similar, or in some cases, the same:

We have the same Send Email, Check Ticket Status, and Mark Ticket as Closed tools from the main agent. These are shared across agents because customer communication and ticket management are fundamental to any support workflow.
The Get customer subscription tool is specific to this sub-agent's needs. When processing feedback, understanding a customer's subscription level can inform the response. A feature request from an enterprise customer might warrant a different level of prioritization than one from a free-tier user.
The Track customer feedback in database tool handles the structured storage of feedback entries. It takes the agent's analysis (summary, sentiment, type, source) and writes it to the feedback database, creating a searchable record for your product team to review later.
The billing triage agent is a bit more complicated because it performs a more sophisticated task.
The instructions:
The tools:

The billing agent's prompt indicates that it handles only billing-related tickets passed from the Customer Support Triage agent. It must receive the customer's email, ticket summary, and ticket ID to function.
The prompt provides concrete examples of standard billing tickets: refunding invoices, sending tax documents such as W-9 forms, explaining invoice history, and adding EINs to subscriptions. When the agent can't resolve a ticket with available tools, it provides recommended next steps and marks the ticket for human review.
The tools list reflects these billing-specific needs:
- Get customer subscription and Get customer invoices retrieve account data
- Refund invoice processes refunds
- Add customer EIN to subscription updates tax information
- Get Billing Document Files retrieves tax forms and invoices
- Send Email handles customer communication
- Mark ticket as closed completes the workflow.
Let’s look deeper into one of these, the Add customer EIN to subscription tool:

What’s this doing? This updates the mock_subscriptions database with a customer's EIN (Employer Identification Number) for tax purposes. It takes two parameters, customer_ein and customer_email, and uses a database update to locate the correct subscription record by email and add the EIN.
This structure ensures the agent updates the correct customer record safely. The declarative approach (table, action type, filter, and changeset) makes the tool's behavior predictable and auditable, which is essential for billing operations where mistakes can have financial and legal consequences.
Deploying your agent
The final step is to deploy the agent. You do this from the deploy button in the top-right corner of the Agent dashboard:

You can deploy as either a:
- Patch release for small fixes, such as correcting typos in prompts, adjusting temperature settings, or fixing minor bugs in tool logic. Use this when the agent's core functionality remains unchanged.
- Minor release for adding new capabilities like additional tools, expanding the agent's scope to handle new ticket types, or refining prompts to improve accuracy. Use this when you're enhancing the agent without changing its fundamental purpose.
- Major release for significant changes like restructuring the entire workflow, adding multiple sub-agents, or fundamentally changing how the agent processes tickets. Use this when you're making breaking changes that substantially alter the agent's behavior.
If we deploy our agent, we can then start using it to answer our (mock) support tickets. For instance, we can see what open tickets we have:

Then we can ask the agent to go through each one to resolve, delegate, or escalate:

Here, the agent checked for open support tickets and found a billing case from Jason Kim about charges after subscription cancellation. It was delegated to the Billing Triage agent, which retrieved subscription and invoice data, identified that one invoice had already been refunded while another was legitimate, then sent Jason an email explaining the billing situation before closing the ticket.
After that, it continued through everything else on the list, sending an email for anything that required escalation to a human:

All 20 open tickets were processed automatically by our agents in a few minutes, allowing the human to focus on the most important ones.
What to build next
Congratulations! You've built a customer support agent that autonomously triages tickets, delegates to specialized sub-agents, and escalates complex cases to humans. This agent handles routine support work while preserving human judgment for situations that require it.
The same architecture can extend to other support workflows. You could build agents that handle returns and exchanges, manage account changes, process technical troubleshooting, or coordinate shipping. Each specialized agent can focus on its domain while the main triage agent orchestrates the entire support operation.
This modular approach lets you gradually automate your support stack without sacrificing quality. Start with the workflows that consume the most time, prove the value, then expand. You can sign up to start using Agents and check out more agent examples here.


