LEVEL 1
Shadow
Drafts on live tickets, visible to nobody but you. Its accuracy is measured against what your team actually sent.
Risk: none
Reads an inbound ticket, gathers the account context a human would have gathered, and drafts a reply with every claim traced to its source. Your team reviews and sends.
A ticket triage agent classifies an incoming support ticket, retrieves the customer's record and history from connected systems, checks the relevant policy, and produces a draft reply with citations — all before a human opens it. It does not replace the support agent; it removes the research that precedes the reply.
In measured deployments the research portion is where most handling time goes. Writing a reply takes around ninety seconds. Finding out who the customer is, what they bought, what happened last time and what the policy permits takes several minutes more — every single time, on every single ticket.
The agent has no capability outside this list. Anything not enumerated here would be a change request, not a configuration toggle.
| Operation | System | Access | Human gate |
|---|---|---|---|
| Read ticket and thread | Helpdesk | READ | — |
| Classify intent and urgency | Internal | COMPUTE | — |
| Fetch customer record | CRM | READ | — |
| Fetch order or subscription history | ERP / billing | READ | — |
| Search prior resolved tickets | Helpdesk | READ | — |
| Retrieve applicable policy clause | Docs / help centre | READ | — |
| Write internal note with findings | Helpdesk | WRITE | Not customer-visible |
| Draft customer reply | Helpdesk | DRAFT | Review required |
| Set tags, priority, queue | Helpdesk | WRITE | Reversible, logged |
| Escalate to named human | Helpdesk | WRITE | — |
| Send to customer | Helpdesk | DISABLED | Off unless enabled |
| Issue refund or credit | Billing | NEVER | Not built |
Table 1 — Permitted operations, default configuration
Billing questions can sit at level 3 while complaints stay at level 1. The level is a property of the category, and it moves in both directions.
Swipe →
Drafts on live tickets, visible to nobody but you. Its accuracy is measured against what your team actually sent.
Drafts appear in the agent console. Your team edits and sends. Every correction is captured as signal.
On categories with a proven record, review collapses to a single confirmation. Everything else stays at level 2.
A narrow set of unambiguous categories sends without review, continuously sampled. Categories drop back a level automatically when accuracy slips.
Any helpdesk with a documented API. These are the ones we've already built against, so integration time is known rather than estimated.
| Helpdesk | Drafts in native UI | Integration effort |
|---|---|---|
| Zendesk | Yes | Known — 3 days |
| Freshdesk | Yes | Known — 3 days |
| Intercom | Yes | Known — 4 days |
| HubSpot Service Hub | Yes | Known — 4 days |
| Jira Service Management | Yes | Known — 5 days |
| Salesforce Service Cloud | Yes | Known — 6 days |
| ServiceNow | Yes | Known — 6 days |
| Shared mailbox only | Via drafts folder | Known — 2 days |
| In-house or legacy | Depends on API | Scoped in the Sprint |
Table 2 — Integration effort is a subset of total deployment, not the whole of it
Four situations where this agent will disappoint you. We'd rather you knew now.
If policy lives in the heads of three long-serving people, the agent has nothing to ground on and will either abstain constantly or invent. Documenting first is cheaper than automating around the gap.
Integration effort is largely fixed regardless of volume. Below this threshold the arithmetic rarely closes, and we'll say so in the Sprint rather than after the invoice.
Consultative or bespoke technical support has no repeating shape to learn. The research step is different every time, which is precisely the part this agent optimises.
If most tickets trace to one confusing flow or one unreliable feature, automating the replies makes the symptom cheaper and the cause permanent. Fix the flow. Then talk to us.
You choose, and the choice is reversible. The reasoning layer is model-agnostic: we run it against major commercial providers under zero-retention terms, or against open-weight models inside your own network where policy requires it. Swapping the model is a configuration change, not a rebuild — which matters more than which model you pick today.
During shadow mode, every draft is compared against what your team actually sent, and the edit distance is recorded per category. That gives you a per-category accuracy figure derived from your own tickets rather than a vendor benchmark. Categories only advance an autonomy level when their number justifies it.
The agent detects the language and, unless you've enabled that language explicitly, routes the ticket to a human with a summary in your working language. It won't quietly reply in a language nobody on your team can review.
Your engineers can — the source is in your repository and documented for that purpose. Most clients keep a light retainer instead, because the ongoing work is tuning categories and knowledge rather than fixing code. Both are legitimate; we don't structure the build to make the first option impractical.
Yes, and they solve different problems. A front-of-queue bot deflects simple questions before a ticket exists. This agent sits behind the queue and does the research on tickets that got through. Clients running both usually find the deflection rate matters less once handling time drops.
Supplies mailbox context when tickets arrive by email rather than through a portal.
Reads attachments — invoices, screenshots, forms — so the draft accounts for what the customer sent.
Shares the same grounded knowledge base, so internal and customer answers can't contradict each other.
Inside the five-day Sprint we classify your real tickets, identify which ones this agent could safely draft, and show you the drafts. No cost, and the analysis is yours regardless.