Triage First, Reply Only After a Human Says Yes

Illustrative session. This walkthrough shows the documented triage workflow and its approval gates. It is not a production recording and claims no production metrics, and it names no customers. For a real, fully public session transcript see the x402 payment session; for a customer deployment with published figures see the case studies.

Request

A team member drops a message into the swarm's internal channel:

"A report just came in that the login flow hangs after the redirect. Triage it before anyone replies — I want to know what we're dealing with in ten minutes."

The request is deliberately scoped: investigate and prepare, do not communicate. The swarm's job is to turn a vague report into a classified, evidenced triage note a human can act on.

Starting context

The inbound report is thin — one sentence and a screenshot. But the swarm is connected to the systems where the truth lives: the Slack integration for the internal thread, the GitHub integration for recent changes, the Linear integration for known issues, and error monitoring for the stack traces. Swarm memory holds every past incident the team has triaged before.

Sources and tools

• Context gathering across integrations — the full list is documented under integrations; this run uses Slack, GitHub, and Linear.
• The investigate-sentry-issue skill — a built-in skill for turning a raw error report into a structured triage; its source is public in plugin/commands.
• Shared memory — searched first, because the fastest triage is recognizing an incident you have already solved; see the memory docs.
• Approval gates — the human-in-the-loop gates pattern governs every outward action.

Task breakdown

1. Intake. The lead reads the report, extracts the symptom (hang after login redirect), and assigns a triage task with one constraint: prepare, don't post.
2. Recall. The worker searches swarm memory. A similar redirect hang was triaged two months ago after an auth-library upgrade — the memory names the culprit file and the fix.
3. Correlate. The worker checks recent GitHub merges: an auth-library bump landed yesterday. It checks Linear: no open ticket for this symptom. It pulls the matching stack traces from error monitoring and confirms the signature matches the earlier incident.
4. Classify. Severity assessment: login is a core flow, the blast radius is every user on the latest deploy, and a known fix exists. The worker drafts a triage note: probable cause, evidence links, affected versions, and the recommended action — roll back or cherry-pick the previous fix.
5. Prepare. The worker also drafts the two outward artifacts: a Linear ticket and a holding reply for the reporter. Both stay as drafts.
6. Hand back. The triage note lands in the internal thread with everything a human needs to decide.

Worker roles and handoffs

The lead scopes the task and enforces the prepare-don't-post constraint. One triage worker holds the whole investigation in a single session, so the memory hit, the merge history, and the stack traces are all in the same context when it writes the classification — no telephone game between agents. The handoff back to the human is the triage note itself: short, evidenced, and actionable. This mirrors the structure of the proactive customer support playbook, where agents assemble context and humans decide what leaves the building.

Approval points

Every outward action waits behind a human. The Linear ticket is filed only after a human approves the draft. The reply to the reporter is sent only after a human edits and approves it. The recommended fix — a rollback or cherry-pick — is executed by engineers, not the swarm. Inside the investigation the worker is autonomous; at the boundary where anything is posted or changed, the gate is absolute.

Output

One triage note in the internal thread: symptom, probable cause with evidence links, severity assessment, and recommended action. Plus two drafts awaiting approval — the Linear ticket and the reporter reply.

Measurable result

Verifiable artifacts, not vanity numbers: one triage note with linked evidence, one classified severity, and two approval-gated drafts. The requester asked for "what we're dealing with" and got a decision-ready answer in a single pass. This illustrative session claims no production metrics such as response-time improvements.

What stayed human-owned

The severity call that pages people, the customer-facing words, the code change, and the decision to roll back. The swarm compressed the investigation; the humans kept every irreversible decision — which is exactly the division of labor the approval-gate pattern exists to protect.

Browse more sessions on the examples index. The integrations, memory, and approval primitives behind this page are open source in desplega-ai/agent-swarm.