TEARDOWN 001 // REFERENCE ARCHITECTURE
A six-agent support fleet for an e-commerce brand
PUBLISHED 2026-08-13 // ~8 MIN READ
What this is: a reference architecture, not a client story. We publish full teardowns instead of logo walls so you can judge the engineering before you ever talk to us. Your volumes and systems will change the shapes — that's exactly what the free audit maps.
The scenario
A direct-to-consumer brand doing roughly 900 tickets a week across email and chat. Five support people. The mix, typical for e-commerce: ~40% order status ("where is my order"), ~25% returns and refunds, ~20% product questions, ~10% shipping exceptions, ~5% everything else. Helpdesk is Zendesk; commerce runs on Shopify; shipping via a 3PL with its own tracking API.
The goal is not deflection — canned macros and "did this answer your question?" widgets. The goal is resolution: the ticket is actually closed, correctly, with the action taken.
The fleet roster
| AGENT | ROLE | WHAT IT DOES |
|---|---|---|
| SENTRY | Triage | Classifies every inbound ticket: intent, sentiment, priority, language. Detects VIP customers and legal/safety keywords that must route straight to humans. Nothing skips triage. |
| RESOLVER | Tier-1/2 resolution | Drafts the actual answer, grounded on the policy corpus, product catalog, and live order data. Retrieval-augmented; it cites the policy line it relied on so QA can check it. |
| LEDGER | Order operations | The only agent allowed to touch systems of record. Executes order lookups, refund initiation, address changes — through a hard allowlist of API actions with per-action limits. |
| ARBITER | QA / critic | Adversarially reviews every outbound draft against policy before it ships: correct action, correct amount, correct tone, no invented promises. Blocks or rewrites failures. Reviews 100% at launch, tapering as measured accuracy allows. |
| SCRIBE | Knowledge mining | Works the queue's exhaust: mines resolved tickets for missing KB articles, drifting policy answers, and emerging issue clusters. Files drafts for human approval. |
| WARDEN | Escalation | When confidence is low or the topic is out of bounds, packages the full context — history, order state, what was tried, why it escalated — into a one-screen brief so the human starts warm, not cold. |
Underneath sits the orchestrator: a state machine that owns every ticket's lifecycle — dispatch, retries, timeouts, reconciliation — and writes every agent action to an append-only audit log.
Message flow: one refund ticket
T+0s inbound email — "item arrived damaged, want my money back" T+2s SENTRY intent=refund_damaged priority=P2 sentiment=neg → route RESOLVER T+4s RESOLVER pulls order #48213 (delivered 2d ago), damage policy §4.2 draft: apologize, full refund, no return required < $40 T+5s LEDGER action=refund amount=$34.99 ✓ within cap ($100) → executed, logged T+6s ARBITER checks draft vs policy §4.2 + refund record → PASS T+7s outbound reply sent — ticket closed, CSAT survey queued · SCRIBE (async) tags SKU #A-115 — 3rd damage report this week → flags ops
Seven seconds, resolved — not deflected. And the interesting part is the last line: the fleet doesn't just answer tickets, it notices why tickets exist.
Guardrails — what makes it safe to ship
- Action allowlist. LEDGER can call exactly the API operations we've enumerated, nothing else. Refunds above a cap, order cancellations after fulfillment, anything irreversible → human approval queue.
- PII redaction at ingress. Payment details and identity documents are stripped before any model sees the ticket.
- Grounding or silence. RESOLVER must cite the policy passage behind every substantive claim. No citation, no send — it escalates instead of improvising.
- Hard out-of-bounds list. Legal threats, safety issues, chargebacks, press — SENTRY routes these to humans unconditionally.
- Kill switch. One toggle halts all outbound actions fleet-wide while inbound triage keeps queuing.
Eval gates — measured, not promised
Before cutover, the fleet must pass a golden set: several hundred historical tickets with known-correct resolutions, replayed through the pipeline. We gate on resolution accuracy, action correctness (right refund, right amount), policy-citation validity, and escalation recall — the fleet must catch ≥98% of tickets a human would have escalated. Miss the bar, no launch. The same suite runs continuously in production against sampled traffic, so drift shows up in a dashboard, not in a customer complaint.
Rollout: shadow first
- Weeks 1–2 — shadow mode. The fleet processes live tickets in parallel but sends nothing. Your team grades its drafts in the command deck.
- Weeks 3–4 — gated live. Lowest-risk intents (order status) go live with ARBITER reviewing 100% of outbound. Coverage expands intent by intent as accuracy holds.
- Weeks 5–10 — production. Refunds and exchanges under caps, exception handling, SLA alerting. Humans work escalations and approvals only.
Typical steady state for this shape of queue: 80–85% of volume absorbed, first-response time from hours to seconds, and the five-person team redeployed onto escalations, VIPs, and the product-feedback loop SCRIBE keeps surfacing.
What it runs on
Frontier LLMs for resolution and critique (typically Anthropic or OpenAI models, selected per task), smaller fast models for triage classification, retrieval over your policy corpus, and native integrations with the helpdesk and commerce APIs. Deployed in your cloud or a dedicated single-tenant environment — security posture here.
Want this mapped to your queue? The free automation audit takes your real ticket mix and volumes and returns this same blueprint, scoped to your business — yours to keep either way.