Build AI Agents for Support

TL;DR

• AI support agents are software systems that handle customer inquiries end-to-end: intake, resolution, escalation, and handoff — without requiring a human to touch every ticket.
• They work best when your support team is drowning in repetitive, predictable requests: order status, password resets, billing questions, basic troubleshooting.
• The business case isn’t about replacing your team — it’s about redirecting them. Agents absorb the routine volume so humans focus on complex cases and relationship-building.
• Real implementation takes 2–6 weeks depending on integration depth. The failure modes are almost always about poor scoping, not weak technology.
• If your team handles fewer than 30–40 tickets a week and most require genuine expertise, you don’t need an agent yet. Start somewhere else.

---

What “AI Support Agent” Actually Means

The term gets used loosely, so it’s worth being precise.

An AI support agent is a software system that can interpret incoming customer requests in natural language, retrieve relevant information from connected data sources, take action in external systems (update a record, trigger a refund, create a ticket), and either resolve the issue or hand it off to a human with full context intact.

That’s meaningfully different from a traditional chatbot, which follows a decision tree. A decision tree breaks the moment a customer asks something outside the script. An agent built on a modern language model can handle variation, follow-up questions, and ambiguous phrasing — the kind of language real customers actually use.

It’s also different from a simple auto-responder or a help center search widget. Those surface content. An agent acts.

Under the hood, a production support agent typically involves a language model (accessed via an API like Anthropic’s Claude), a set of tool definitions that tell the model what actions it can take, retrieval from a knowledge base or documentation set, and integration with your existing systems via APIs or workflow automation tools. At Basalt, we typically wire these together using n8n for orchestration and TypeScript for custom logic, connecting to whatever CRM, helpdesk, or billing system the client already runs.

---

The Problem Worth Solving

Most founder-led support teams have the same structural problem: a small group of capable people spending the majority of their time on low-complexity, high-volume requests.

A recruitment agency gets the same five questions from candidates every week. A real estate brokerage fields identical inquiries about listing status or document requirements. An accounting firm answers the same questions about deadlines and portal access in January and April without fail. An HVAC contractor’s admin team spends hours confirming appointment windows and sending technician ETAs.

None of these require deep expertise. They require consistency, availability, and access to the right data. That’s exactly what a well-scoped AI agent delivers.

McKinsey research on service operations suggests that a substantial share of support interactions in most businesses involve routine, structured requests that could be handled without human judgment. The productivity opportunity isn’t theoretical — it’s sitting in your ticket backlog right now.

The more interesting question isn’t whether the technology works. It does, for the right use cases. The question is how to scope it correctly so you’re not six weeks into a deployment that turns out to be solving the wrong problem.

---

How a Support Agent Actually Handles a Request

Walk through a concrete example. A customer emails a legal services firm asking about the status of their document review, whether their intake form was received, and what happens next.

A human handling this opens the CRM, finds the contact record, checks the intake form status in a separate system, pulls up the workflow tracker, and writes a reply. Call it 6–10 minutes, assuming nothing is hard to find.

An agent with the same integrations does this in seconds. It parses the email, identifies the customer from their email address, queries the CRM, checks the intake system, retrieves the current workflow stage, and generates a reply that reflects the actual status of their matter — personalized, accurate, sent immediately.

If the customer follows up with something the agent can’t resolve — say, a question about legal strategy or a complaint about a billing error that needs a human decision — the agent flags it, routes it to the right person, and passes along the full conversation thread and relevant account context. The human doesn’t start from zero.

This pattern — handle what’s routine, escalate what isn’t, never lose context — is what makes agents actually useful in a support workflow.

---

Where Agents Work Well (and Where They Don’t)

Not every support scenario is a good candidate for automation. Getting this wrong is the most common implementation mistake.

Good candidates:

• High-frequency, low-variation requests (order status, appointment confirmation, basic account queries)
• Requests that require pulling from multiple systems but follow a predictable logic
• After-hours coverage where customers currently get nothing until the next business day
• Multilingual support needs that would otherwise require additional headcount
• First-pass triage and routing, even if a human handles resolution

Poor candidates:

• Requests that require genuine judgment, nuance, or legal/professional accountability
• Sensitive escalations where tone and human presence matter (complaints, disputes, distressed customers)
• Highly irregular workflows where every case is meaningfully different
• Businesses with fewer than 30–40 tickets per week — the setup cost won’t be justified

In our work helping founder-led professional services firms deploy support agents, the most common breakdown is scoping too broadly from the start. Teams try to automate everything at once, including the cases where automation genuinely shouldn’t be the answer. Starting narrow — one or two high-volume request types — and expanding from there consistently produces better outcomes than ambitious full-coverage deployments.

---

What a Real Implementation Looks Like

There’s a gap between how AI support agents get described in marketing and what it actually takes to deploy one that works reliably in production. Here’s what the process looks like in practice.

Audit and scoping (week 1) Before anything gets built, you need a clear picture of your current support volume, request categories, resolution patterns, and where your team’s time actually goes. This means pulling ticket data, talking to the people who handle support, and identifying the two or three request types that are both high-volume and well-defined enough to automate confidently.

Agent configuration and integration (weeks 1–3) The agent needs to know what it’s allowed to do, what data it can access, and how to behave when it hits the edge of its capability. This involves writing tool definitions, connecting APIs, building or importing a knowledge base, and setting escalation rules. The knowledge base is often the most underestimated piece — if your documentation is scattered or outdated, the agent will reflect that.

Pilot and calibration (weeks 3–4) Deploy to a subset of traffic or request types. Monitor responses carefully. The goal here isn’t perfection — it’s learning where the agent fails so you can fix it before it’s handling your full volume. Common issues at this stage: edge cases the knowledge base doesn’t cover, tone mismatches, ambiguous escalation thresholds.

Full deployment and team handoff (weeks 4–6) Roll out to full volume. Train your team on how to review escalations, provide feedback, and update the knowledge base as your products or processes change. An agent that nobody on your team knows how to maintain will degrade over time.

The realistic timeline for a focused implementation — two or three request types, integrating with one or two existing systems — is four to six weeks. Broader scope takes longer. Anyone promising a fully capable, multi-channel, production-ready support agent in a week is selling you something that will require extensive cleanup later.

---

Key Technical Concepts (Plain Language)

If you’re evaluating vendors or having technical conversations with your team, these terms come up often.

Tool use / function calling: The mechanism by which a language model takes actions in external systems rather than just generating text. The model is given a list of available tools (e.g., “look up order status”, “create support ticket”) and decides which ones to invoke based on the customer’s request.

RAG (Retrieval-Augmented Generation): A technique where the agent retrieves relevant content from a knowledge base before generating a response. This is how agents stay accurate about your specific products, policies, and processes rather than hallucinating.

Orchestration layer: The middleware that coordinates the agent’s workflow — receiving inputs, deciding which tools to call, handling errors, and routing escalations. Tools like n8n handle this without requiring custom backend development for each integration.

Escalation threshold: The rules that determine when the agent hands off to a human. These should be explicit and conservative at first. Better to escalate something the agent could have handled than to have it attempt something it shouldn’t.

Context window: The amount of conversation history and retrieved information the model can consider at once. For support use cases, this is rarely a constraint — but it matters for very long conversations or agents that need to process large documents.

---

Metrics That Actually Tell You if It’s Working

Resist the urge to judge a support agent on response time alone. Fast wrong answers are worse than slower correct ones.

The metrics worth tracking:

• Containment rate: The percentage of requests the agent resolves without human involvement. For a well-scoped deployment, this should be measurable within the first two weeks.
• Escalation accuracy: Are the escalations the agent sends to humans actually cases that needed human attention? A high false-escalation rate means the agent is being too conservative. Low escalation volume with frustrated customers in the escalated cases means the thresholds are too loose.
• Resolution accuracy: Sample agent responses regularly and check them against what a human would have said. Especially in the first month.
• Time-to-resolution for escalated cases: If the agent is passing context correctly, your human agents should be resolving escalated cases faster than they did before — because they’re not starting from scratch.
• Customer satisfaction on agent-handled threads: If you run CSAT surveys, segment results by whether the interaction was handled by the agent or a human. You want these to be comparable, not dramatically worse on the agent side.

Gartner has noted in its customer service research that businesses measuring containment rate and resolution accuracy together get a more honest picture of automation value than those focused on cost metrics alone. That aligns with what we see in practice.

---

Common Pitfalls

Treating the knowledge base as a one-time task. Your products change, your policies change, your processes change. If nobody owns keeping the knowledge base current, the agent will confidently give customers outdated information.

No human review loop in the first month. Agents need calibration. Shipping and walking away is how you end up with a support channel customers learn to avoid.

Automating emotionally sensitive interactions too early. Billing disputes, complaints, cancellation requests — these need human judgment. Save the agent for transactional, informational requests first.

Underestimating integration complexity. If your CRM data is messy, your ticketing system has custom fields nobody documented, or your APIs aren’t well-maintained, the agent will expose those problems quickly. Budget time for data cleanup.

Overpromising to customers. If customers are told they’re talking to an AI and it handles their request well, that’s a positive experience. If they think they’re talking to a human and the interaction breaks down, that’s a trust problem.

---

Getting Started

The honest starting point is an audit of your current support load. Pull three months of ticket data. Categorize requests by type. Identify the top three categories by volume. Ask whether those categories are well-defined enough that a clear answer exists for each one. If yes, you have a workable starting scope for an agent.

If you’re not sure where the boundaries should be, or how to connect an agent to your existing systems, that’s a scoping conversation worth having before any technology decisions get made.

If you want to talk through what this looks like for your specific business, you can book a short strategy call here: https://cal.com/eliott-ardisson-kzq7zs/ai-strategy-call