FirstResponder: An AI Agent for Incident Investigation

An on-call engineer’s first hour on an incident is rarely spent fixing anything. It’s spent finding out what happened: pulling logs, cross-referencing alerts, tracing a stack trace back to the commit that caused it.

That hour is the bottleneck. Station70 built FirstResponder to close it.

An agent, not a chatbot

FirstResponder is a Claude agent that investigates incidents across both production and development, because we treat dev as a high-availability environment, not a lower tier that can wait.

When an alert lands in Slack or PagerDuty, FirstResponder starts investigating. It pulls AWS logs and our internal Bunker service, builds a hypothesis about root cause, and traces that hypothesis into the codebase, down to the specific commit or function responsible. It posts a report to Slack with the evidence behind it.

Connected is what makes it useful

The industry has largely treated LLMs as isolated reasoning engines: a prompt in, an answer out. That framing undersells what they can do.

An LLM becomes more useful as it connects to more of your infrastructure, not just more data. FirstResponder reaches Slack, PagerDuty, AWS, Bunker, and GitHub through Gatekeeper, our connection layer. Each connection compounds the others. An agent that receives PagerDuty alerts is useful. One that triangulates an API gateway request against a database entry, finds the issue in code, and reports it to Slack is a different order of useful.

That compounding is why a ten-minute investigation covers ground that takes an on-call engineer an hour or more. Claude handles the tedious part: bespoke API calls, unfamiliar log formats buried in the AWS console.

Proof, not a demo

FirstResponder has reproduced intermittent incidents that resisted manual repro attempts, and it has run down root causes on live production incidents. Engineers start their investigation with a hypothesis and linked evidence already in hand. If the theory is wrong, they redirect the agent and it digs in a different direction.

Where this is going

FirstResponder currently runs as a Claude skill invoked manually. We’re moving it toward autonomous triggering, so an investigation starts the moment an alarm or page fires, with a summary and a candidate fix waiting before the engineer opens their laptop.

We’re also testing automated severity triage, so pages get reserved for what needs an immediate response, and automated team routing, since a web console error is sometimes a backend defect and a backend error is sometimes a client-side one.

Speed you can trust is worth more than speed alone. That’s the only kind worth building.