Tier2How it works
From a support signal to cited evidence
Five stages, in order, with the boundary between model judgement and code enforcement drawn explicitly at each one.
Stage 01 · Intake
A signal arrives, untrusted
A ticket, a Slack thread, an email, or a widget message lands in the tenant inbox. A small, fast model classifies it and extracts the claim under test.
- Ticket content is input, never instruction. The runbook is the only privileged channel into the agent.
- Anything the agent learns from a ticket body is written to a quarantine directory with provenance, and needs a human to promote it.
- A fact sourced from a stranger never outranks an annotation from your engineer.
Why quarantine matters
An agent that writes its own memory is one prompt-injection away from learning something false and repeating it with confidence. Separating proposed memory from promoted memory is the only defence that survives a hostile ticket.
Stage 02 · Answer, or differential diagnosis
Knowledge base first. Code decides when that's not enough.
Most tickets, for most products, are answerable from a knowledge base article — the agent checks yours first and cites the article if it settles the question. When the question is actually about your systems, each runbook is versioned YAML describing differential tests and their branch predicates; the agent chooses which test is worth running, and the predicate runs in TypeScript against the probe result.
- A knowledge base hit ends the investigation right there — no probe needed, no guessing either.
- Probes, when they run, are GET or handshake only, against validated public DNS names — never an IP, never a
.internalhost. - Database reads are named queries on a read replica with a statement timeout and no parallel workers.
Stage 03 · Verification
Five verdicts, two destinations
An adversarial pass reviews the diagnosis before anything is rendered — a separate step, because an agent asked to check its own work over-verifies and still misses the same things.
| Verdict | Route | What the customer gets |
|---|---|---|
| Already fixed | Draft | The behaviour changed in a deploy after the ticket was filed. The reply names the deploy and the probe that confirms current behaviour. |
| Not reproducible | Draft | Probes cannot reproduce the report from outside. The reply says what was checked and asks for the one detail that would change the answer. |
| Environment-specific | Draft | The failure is in the caller’s environment — DNS, TLS, a proxy, a client version. The reply shows the probe that succeeded from ours. |
| Needs info | Draft | The differential cannot be narrowed without one specific fact. The reply asks for exactly that, not a generic questionnaire. |
| Reproduced | Escalate | A defect confirmed by probe evidence. This is the only verdict that reaches an engineer, and it arrives as a packet with the trail attached. |
Stage 04 · Delivery
Customer replies wait. Engineering pages do not.
The draft gate exists to protect your customers, not to slow your engineers down. A customer-facing reply always waits for a human; an internal escalation posts itself.
Thanks for flagging this — we reproduced it. The slowdown started at 14:02 UTC with our v419 deploy, which reduced the connection pool from 64 to 16. Saturation reached 94% within twenty minutes. A fix is rolling out; no action is needed on your side.
deploy.diff · pr_9f2ac2replica.query · pr_9f2ac3- Severity
- P1 · customer-facing latency
- Root cause
pool_max64 → 16 in v419- Owner
- #platform-oncall · @data-infra
- Evidence
- 3 probes · 3 citations · 0 uncited claims
Stage 05 · Correction
Being wrong is an input, not a failure
When an engineer corrects a diagnosis in the thread, that correction is proposed as a runbook diff and reviewed the way a pull request is. Nothing takes effect until it has been scored against the labelled eval set.
- Correction
An engineer replies in the thread
“The pool size is not the cause — the control-plane field is stale, check the replica.”
- Proposal
The runbook change is drafted as a diff
The field trust map marks the control-plane column stale, and the test order changes so the replica read runs first.
- Gate
The replay harness scores it
The change is replayed against every labelled escalation. A runbook edit that cannot be scored does not merge.
- Effect
Next month’s ticket is answered by it
Diagnosis quality compounds with your team’s attention instead of decaying with your documentation.
Ready when you are
Replay one of your escalations.
Pick a ticket your team already resolved. We show you the probes it would have fired and what it would have drafted.
Draft-only by defaultRead + probe access only