Incident Responder agent
The Incident Responder agent sets the timeline, scope and impact of an incident and lists the immediate triage actions. It opens the Incident Response workflow.
The Incident Responder agent handles the first minutes of an incident. It establishes the timeline, the scope and the impact, and lists the immediate triage actions.
Where it runs
| Workflow | Step |
|---|---|
| Incident Response | Triage |
Incident Response runs five steps in order: triage by the Incident Responder, root cause by the Architect, a mitigation from the Builder, verification planned by the Tester, and a postmortem by the Site Reliability agent.
Inputs
- The session task. This is where you describe what is happening: symptoms, error messages, when it started, and anything you have already tried. The better the task, the better the triage.
- A read-only snapshot of relevant files from the project's repository.
- Tools from connected MCP servers, if your workspace policy allows them.
Outputs
A written triage:
- Timeline: what happened and when, from the facts given.
- Scope: which services, endpoints or customers are affected.
- Impact: what users cannot do, and how severe that is.
- Immediate actions: what to do now to limit damage, such as disabling a feature or rolling back a deploy, before the root cause is known.
The root-cause step starts from this triage. When the session finishes, its mitigation is a diff like any other session's, which must pass the release gate before it can ship.
Example run
Illustrative example, not a recorded session. Matt starts Incident Response with: "Since 14:05 UTC about 30% of checkout requests fail with 500. Deploy 412 went out at 14:00. Error: cannot read property code of null in payment adapter." The Incident Responder sets the timeline around the deploy, scopes the impact to checkout for one payment provider, rates it high because customers cannot pay, and recommends rolling back deploy 412 now while the fix is prepared. The Architect then traces the null currency code in the snapshot.
Limits
- It knows only what the task, the code and any connected MCP tools tell it. It cannot see dashboards, logs or alerts by itself.
- It cannot roll back, restart or scale anything. Use your deploy tooling, or the console's deploy and rollback records.
- A model's severity call is a suggestion. The people on call decide.
Frequently asked questions
Can the Incident Responder agent read my logs and metrics?
Only what you put in the task, or what an MCP tool your workspace has connected and allowed can fetch. It has no direct access to your monitoring.
Does it page anyone or change production?
No. It writes a triage. Any fix comes out of the session as a diff that goes through the release gate and approval.