Multi-agent support triage
An ensemble classifier routes tickets across 18 intents. Three specialist agents answer in parallel, and low-confidence answers go to a human.
- Seconds
- first response, down from 1–2 days
- 0
- wrong price or lead-time quotes in 1,000+ audited tickets
- 4 → 1
- LLM calls on the fast path
Context
Support tickets waited one to two days for a first response, and answers about prices and lead times have to be exactly right.
I built a triage agent and orchestrated specialist agents that answer in seconds, with guardrails that hand uncertain cases to people.
How it works
- 1
Triage
An ensemble of an LLM, embeddings, and rules sorts each ticket into one of 18 intents. The fast path needs one LLM call instead of four.
- 2
Specialists
Three specialist agents run in parallel with asyncio and call the analytics agent over A2A when they need data.
- 3
Ground
Intent-gated corrective RAG retrieves and checks supporting documents before a draft is written.
- 4
Guard and escalate
A rule-based answer policy checks every draft, and low-confidence answers escalate to a human.
Key decisions
Blend cheap signals with the LLM
Combining an LLM with embeddings and rules made classification faster and cheaper: the fast path needs one LLM call instead of four.
Reuse agents, don't rebuild them
The specialists call the analytics agent over A2A instead of duplicating its data access.
Escalate instead of guessing
A rule-based policy guard plus confidence-gated escalation: no incorrect price or lead-time quotes were observed across 1,000+ audited tickets.
How it shipped
- 600+ tests across both agent systems, run in a 3-stage GitHub Actions pipeline
- Redis-backed circuit breakers shared across services
- OpenTelemetry tracing with Grafana dashboards
- An LLM-as-judge regression harness that runs on every change
Stack
- Python
- asyncio
- A2A
- Corrective RAG
- Embeddings
- Redis
- OpenTelemetry
- Grafana