The AI support stack: triage, auto-resolve, sidekick
Three AI layers, three jobs. Here's exactly how we architected each one — and what we learned about keeping AI honest.
Most "AI support" tools today do one of three things: tag tickets, draft replies, or try to close them end-to-end. All three are useful. Almost no one does all three, and none do them with a unified model of trust.
Protodesk has three AI layers, each doing a different job:
- Triage — fires on every inbound ticket, labels and routes it.
- Auto-resolve — attempts to close routine tickets using your knowledge base.
- Sidekick — runs inside a thread to summarize, draft, and suggest.
Each layer is independent. You can turn any of them off per workspace, per team, or per label. Each uses credits from the same monthly pool so billing stays predictable.
Here's what we learned building each one.
Triage — fast, fire-and-forget, never blocks
Triage runs the moment a ticket arrives. Its job: assign a label, set a priority, pick a team. It uses seven signals:
- Subject line
- First message body
- Channel (email/WhatsApp/Slack/Discord)
- Customer metadata (is this a VIP? new vs returning?)
- Recent ticket history for this customer
- Time of day + business hours
- Workspace-specific signals (custom labels, industry)
We fire it async — it never blocks ticket creation. If it fails, the ticket still arrives, uncategorized. That's a deliberate choice: the support inbox is mission-critical infrastructure, and an AI timeout shouldn't cost you a customer email.
The output lands as a reasoning trace in the ticket timeline. You can see exactly which label it picked, why, and with what confidence. Override in one click.
Auto-resolve — the 7-layer guardrail
This is where most AI support tools go wrong. The naive version — "read the knowledge base, write a reply, send it" — hallucinates policies, invents refund terms, and quotes pricing that changed six months ago.
We built a 7-layer guardrail:
- Escalation rules — skip if the customer is VIP, angry, or asking about billing disputes
- KB retrieval gate — skip if we can't find a relevant article with high-enough similarity
- Disambiguation — if the question has two possible meanings, ask back instead of guessing
- Grounded generation — the model is only allowed to cite the retrieved articles, not make things up
- Verification — a second model checks the draft against the source and the policy
- Source citation — every AI reply ends with "Sources: [article title]" linking to the KB article
- Outcome tracking — we log whether the customer replied satisfied or escalated, and feed that back
Only tickets that pass all seven layers get an auto-reply. The rest route to a human with the AI's draft already prepared in the sidekick.
Sidekick — in-thread, human-in-control
Sidekick is the opposite of auto-resolve. It never sends anything on its own. Its job is to make a human agent faster.
In every ticket, sidekick surfaces:
- A summary of the conversation so far (useful for long threads)
- A drafted reply in the workspace's brand voice
- Related knowledge-base articles inline
- A suggested next action (close, escalate, wait)
The agent reads, edits if needed, and sends. The AI helps. The human ships.
Under the hood
- Inference: OpenRouter, so you can choose Claude, GPT-4, Gemini, or any compatible model. Defaults to Claude Sonnet for the balance of quality and cost.
- Embeddings: Local ONNX (pplx-embed). Your knowledge base content never leaves our infrastructure for embedding.
- Retrieval: Upstash Vector for serverless vector search. Graceful fallback if not configured — the system still works, just slower.
- Orchestration: Our own pipeline. No LangChain, no CrewAI. The support domain is narrow enough that purpose-built logic beats general-purpose agent frameworks on both latency and reliability.
The philosophy
AI should be obvious, auditable, and overridable. Every action leaves a trace. Every reply cites its sources. Every human can override in one click.
If you can't trust the AI in your inbox, you shouldn't be running it there.