Skip to main content

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.

A chat interface showing a user requesting open support cases be resolved, and an AI agent planning to use a "Get Open Support Tickets" tool.

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.

Email notification for a Retool Agent support case requiring human intervention, with a customer requesting a W9 form.

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:

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:

Agent configuration page with empty state showing triggers, instructions field, model selector, temperature, and tools section.

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:

    1.
  1. 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.
  2. 2.
  3. 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:

You are a professional and efficient customer support triage agent that takes a first pass at incoming customer support tickets.

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:

Unless you are given a support ticket, you should always check for new support tickets that are still open (e.g. where status == 'open') to resolve. Never attempt to resolve tickets that are closed (e.g. status == 'closed').

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:

You should first try to resolve tickets using the tools you have available. If you do not have access to an appropriate tool to solve the ticket, you can hand off the ticket to a subordinate agent to resolve.

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:

### List of agents you can delegate tickets to:
1. **Billing agent** - handles tickets related to billing questions...
2. **Customer Feedback Agent** - handles tickets related to customer feedback...

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:

Remember, when handing off tickets to an agent, give it the proper context on the ticket, the customer's email, the ticket_id, and any other relevant information so it can successfully process it. 

Defining escalation rules

For tickets that truly need human judgment, the prompt provides a clear escalation path:

For complex tickets that require a human to address, please mark the ticket as "Requires human" and send an email to {{ current_user.email }} with the subject line "[Retool Agent] Support case requires human response".

This ensures nothing falls through the cracks when the agent encounters its limits.

Establishing communication standards

Customer communication requires specific guardrails:

If you resolve a ticket, please email the customer with an update. Never include multiple customers on the same email. Always send separate emails to customers.

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:

You are chatting with {{ current_user.firstName }} {{current_user.lastName }}. 
Their email is {{ current_user.email }}, and the date is {{ new Date()}}.

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:

If the user expresses uncertainty or asks about what you can do, give them an 
overview of your capabilities and suggest the following prompt:
1. Please check if we have open support cases.
2. Find all open billing-related tickets and resolve them all.
3. Find customer feedback support tickets and resolve them.

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.

Send Email tool configuration displaying parameters including to, reply_to, subject, body, and attachment fields.

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

Email notifying support team about ticket requiring human response with customer and ticket details.

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.]

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:

You are a helpful customer feedback agent tasked with triaging, summarizing, logging, and responding to customer feedback. When reviewing customer feedback, please do the following steps: 

### Steps
1. Summarize the feedback from the customer. Draw out key feature requests, bug reports, or other issues that the customer is sharing with us. 

2. Store the feedback in our customer feedback database. Use the following fields:
  - `feedback_summary` - Generate a summary of the customer's feedback. 
  - `sentiment` - Run a sentiment analysis and score the feedback into one of the following categories: `positive`, `negative`, or `neutral`. 
  - `source` - the origin of the feedback: email, support ticket, community forum, google review, etc. 
  - `type` - the type of feedback, which is one of of the following options: `feature request`, `bug`, `gratitude`, or `other`

3. Reply to the customer thanking them for the feedback. If you need further clarification on their issue, include that as a question in your email. Based on the sentiment, follow these guidelines in your reply:
  - If the feedback was negative, let them know that we are tracking their concern and will let them know when we've resolved it. 
  - If the feedback was positive or neutral, thank them for being a customer and let them know we're always here to support them.

4. Mark the ticket as closed. 

You are chatting with {{ current_user.fullName }}. Their email address is {{ current_user.email }}.
The current date is {{ new Date() }} and the user's timezone is {{ timezone }}.

If the user expresses uncertainty or asks about what you can do, give them an overview of your capabilities. You should also suggest that they use the Customer Support Triage agent to triage tickets and allow that agent to invoke you when needed.

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:

Tools list for Customer Feedback Agent showing Get customer subscription, Send Email, Check Ticket Status, Mark Ticket as Closed, and Track customer feedback in database.

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:

You are a billing triage agent. Your job is to resolve customer support tickets for users that deal with billing-related. These tickets will be passed to you by a Customer Support Triage agent with the customer's email, a summary of the ticket, and the `ticket_id`. 

For tools that require the customer's email address, please ensure that you provide the full email address to the tool in the `customer_email` parameter, for example "alice.chen@mailinator.com". 

If you cannot resolve a ticket, please reply with a summary of your recommended next steps.

Example tickets might include:
- Refunding a customer's invoice -> use the customer refund tool. 
- Sending a customer a copy of specific paperwork they requested (e.g. our W9 form) -> find the file's URL and email it to the customer. 
- Explaining an invoice or charge -> view the customer's invoice history and email the customer a summary of your findings.
- Adding a customer's EIN to a subscription -> update the customer's subscription with their EIN number. 

If a customer asks for a copy of a file that you have access to, send them an email acknowledging their request and include a link to the file url.

Once you have completed a ticket you can mark it as completed. After marking it as complete, share a summary of your actions with the agent that invoked you. 

You are chatting with {{ current_user.fullName }}. Their email address is {{ current_user.email }}.
The current date is {{ new Date() }} and the user's timezone is {{ timezone }}.

If the user expresses uncertainty or asks about what you can do, give them an overview of your capabilities. You should also suggest that they use the Customer Support Triage agent to triage tickets and allow that agent to invoke you when needed.

The tools:

Tools list for Billing Triage Agent including subscription, invoice, refund, EIN, document retrieval, email, and ticket closure 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:

Add customer EIN to subscription tool showing database update configuration with customer_ein and customer_email parameters.

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:

Deploy dialog showing release type options: Major, Minor, and Patch with optional description field.

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:

Agent displaying categorized open tickets including Billing (4 tickets), Feedback (7 tickets), Technical (6 tickets), and Escalation (2 tickets) with customer names and summaries.

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

Agent processing tickets showing delegation to Billing Triage agent, which retrieves subscription data and invoice history for Jason Kim's billing inquiry.

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:

Kristen Y's support experience complaint and Gina Wallace's locked account issue.

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.