Incident Copilot
A ticket-triggered triage agent that pulls the right resolution procedure, the relevant logs and comparable prior cases the moment a ticket is created — then posts a recommended fix onto the ticket before an engineer has opened it.
- Trigger
- Agent
- Tool / data
- Guardrail
- Human
⊘ It recommends. The engineer decides.
The problem
What this replaced
- 01An incident ticket lands and the clock starts.
- 02The on-call engineer searches documentation for the right resolution procedure.
- 03Then digs through logs to work out what is actually happening.
- 04Then searches resolution history for anything that looks similar.
- 05Only now does resolution work begin.
Who has this problem
SREs and on-call engineers working enterprise incident queues.
What it costs
Every one of those steps happens before a single corrective action is taken. Manual context-gathering is pure added latency on acknowledgement, repeated on every ticket, at every hour of the night.
The build
What I built
The agent fires on ticket creation. It retrieves the relevant resolution procedure, pulls logs where they add signal, searches comparable prior cases for near-matches, and synthesizes a grounded recommendation that it writes back onto the ticket.
Collapse the context-gathering phase to zero, so the engineer's first action is judgement rather than search.
Capabilities
- 01Ticket ingestion on creation event
- 02Resolution procedure retrieval
- 03Targeted log retrieval
- 04Prior-case similarity search
- 05Grounded recommendation, written back to the ticket
How it runs
The workflow
- in
Trigger
A new incident ticket is raised in the ticket system.
- 01
Ticket creation triggers the agent
- 02
Retrieve the relevant resolution procedure
- 03
Pull relevant logs, where they add signal
- 04
Search resolution history for comparable prior cases
- 05
Synthesize a recommendation grounded in all three
- out
Output
A recommended solution posted directly onto the ticket, citing the resolution procedure, the relevant logs and the comparable prior cases it drew from.
Components
- Ticket system (trigger + write-back surface)
- Incident triage agent — Claude Sonnet 4.5 via AWS
- Procedure library
- Log store
- Resolution history store
The guardrail
What it is not allowed to do
⊘ Boundary
It recommends. The engineer decides.
The agent never resolves or closes a ticket. Its output is a recommendation an SRE reviews and acts on. Because that recommendation feeds straight into live incident resolution, every claim it makes has to be traceable to an actual resolution procedure, an actual log line, or an actual prior case — grounding here is not a quality nicety, it is the safety requirement.
Stack
What it is built on
- Model
- Claude Sonnet 4.5 (via AWS)
- Backend
- PythonFastAPI
- Retrieval
- RAG over procedure library + resolution history
- Integrations
- Ticket system APILog management backend
- Cloud
- AWS
Hard parts
What made it difficult
- 01
Retrieving the genuinely relevant resolution procedure when the ticket is written ambiguously — which, under incident pressure, is most of them.
- 02
Matching comparable prior cases closely enough to be useful without surfacing superficially similar history that sends the engineer down the wrong path.
- 03
Keeping every recommendation anchored to real procedure text and real log lines, because the output feeds directly into resolution.
Outcome
What changed
Manual procedure lookup, log gathering and prior-case search were eliminated as a per-ticket cost.
Every new incident ticket now arrives with its context already assembled.
Written as a de-identified case study. The employer's identity, resolution procedure contents, ticket details, internal resolution history and performance figures are not disclosed. What is described here is the architecture pattern — nothing proprietary to the environment it runs in.
Get in touch
Building an agent that has to survive production?
I write about MCP design, evals and guardrails on LinkedIn most days. If you're working on something similar, I'm happy to talk shop.