The need

A classic chatbot recites the FAQ. A support agent looks up the customer's account, checks the real status of their order, triggers a refund within the rules, and hands over to an advisor when the situation is beyond it. The difference between the two is access to your systems and the ability to act, and that is where everything plays out: an agent that acts can also make mistakes while acting.

The architecture

  • A stateful orchestrator (LangGraph or equivalent) drives the conversation: understand the request, call the right tools, decide whether to answer, act or escalate. Every step is bounded: limited retries, no infinite loops.
  • Tools connected to your systems through an MCP server: CRM reads, order status, ticket creation, refunds. Each tool exposes one precise action with validated parameters, never generic database access.
  • Write guardrails: consequential actions (refunding, changing an order) go through business rules written in plain code: caps, eligibility conditions, logging. The LLM proposes, the rule disposes.
  • Human escalation as a first-class citizen: when confidence is low, the customer is getting angry, or the request is out of scope, the agent transfers with the full context of the conversation. Above all, a good agent knows when to stop.
  • Conversation memory: the customer's history and previous exchanges, so nobody repeats themselves, without ever leaking one customer's data to another.

The traps we know

  • The over-autonomous agent. Granting write access on day one is a mistake. Start read-only plus escalation, measure, then open actions one by one, capped.
  • The blurry scope. An agent that tries to handle everything handles everything badly. Define the covered intents, escalate the rest cleanly, and widen coverage version by version.
  • The off-brand tone. Replies speak for your brand. Style is tuned with real examples validated by your support teams, and tested like everything else.
  • Latency that kills usage. Three tool calls in a row keep the customer waiting. Parallelise what can be, show progress for the rest, or the customer hangs up before the answer.

How we measure that it works

  • Resolution rate without a human, measured on real conversations, not declared.
  • Action correctness: every executed action is logged and auditable; refunds reconcile with accounting.
  • Escalation quality: how many conversations transferred too late, or not soon enough? It is the first metric support teams look at.
  • Cost per conversation and per-step latency, traced request by request.

A test set of conversations, replayed on every change, keeps an improvement on one side from breaking the other.

What you keep at the end

The agent in your repository, MCP tools reusable for your next agents, the evaluation set wired into your CI, and support teams trained to supervise and enrich the system.