The problem
A mid-market SaaS company was running a support queue of roughly 1,200 tickets a week across five agents. Most tickets were not hard — "how do I export", "why did my invoice change", "reset my SSO" — but every one still cost a context switch, a search through the help centre, and a few minutes to write. First response averaged about four hours, and it got worse every time someone was on holiday.
The design principle
The agent drafts, a person sends. We did not try to build a bot that answers customers. We built one that does the reading and the first draft for every ticket, and hands a human something to approve or fix. A narrow set of responses — ones with a single correct answer and no judgement — are allowed to send themselves. Everything else waits.
Architecture
The system runs in TaskBreaker's infrastructure. The client gets a queue that stays in sync with their help desk and an SLA; we own upgrades, tracing, and on-call.
- A Claude Agent SDK runtime handles each ticket: classify, retrieve, draft, decide whether it may auto-send.
- MCP servers are the only way the agent touches the client's systems — one for the help desk (read tickets, write drafts and internal notes), one for the docs store, and one for a read replica of the app's billing and account tables.
- Retrieval runs over the published help centre plus two years of resolved tickets, so the draft sounds like the team, not like a manual.
- A work queue does enrichment — pulling the customer's plan, recent errors, and open tickets — before the model sees the case.
- OpenTelemetry tracing captures every ticket: inputs, retrieved passages, tool calls, tokens, latency, cost. One searchable trace per ticket.
Triage and routing
Each ticket is classified by topic, severity, and whether it needs account data to answer. Billing disputes, security reports, and anything mentioning churn or legal go straight to a senior agent with a flag and no auto-send, regardless of how confident the model is. Everything else gets a draft and a suggested assignee. Misroutes ran under 3% against a labelled test set and are one of the numbers we alert on.
Drafting, grounded
The draft cites the passages it used — a help-centre section, a past ticket, a billing record — and those citations render inline for the agent reviewing it. If retrieval comes back thin, the model is instructed to say so and propose a question rather than guess. After a few weeks of prompt and retrieval tuning, agents were accepting about 72% of drafts with no edit and lightly editing most of the rest.
The auto-send allowlist
A response may send itself only if it is on an explicit list: SSO/password reset links, status-page pointers during a known incident, and "here is your invoice" with a deep link. Each was added one at a time, after its draft-acceptance rate sat above 95% for two weeks. Auto-send covers about 15% of volume. Nothing that changes an account, issues a credit, or makes a promise is eligible, and it never will be.
Guardrails
The agent has read-only access to billing and account data and can only write drafts and internal notes — it cannot send on any channel outside the allowlist, and it cannot modify a customer record. Every draft, every auto-send, and every routing decision is logged with the retrieved context attached. An operator can disable auto-send for any response type, or all of them, from a dashboard without a deploy.
What it costs to run
Roughly two to five cents per ticket in model and infrastructure cost, plus the managed fee. At this volume that is a small fraction of the time it gives back — first response on drafted tickets dropped from about four hours to about three minutes.
How we rolled it out
Shadow mode first: for three weeks the agent drafted every ticket and we scored its draft against what the human actually sent, with no agent seeing the output. Then drafts went live in the queue, draft-only, for everyone. Then the auto-send allowlist, one response type at a time, each gated on its own acceptance rate. The eval suite of golden tickets runs on every change.
This is the kind of system we build
If your support team is re-answering the same questions every day, we can put a draft in front of every one of them. Book a call, or read how we built a bookkeeping agent.
Publishing note: a representative composite of support-automation work, not a single named client. Volumes and rates are illustrative of the range we see. Verify any platform specifics before building against them.