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.
Engagement
Anonymized — Fortune 500 pharmaceutical enterprise
~50%
reduction in mean-time-to-acknowledge
The problem
What this replaced
The manual process, before
- 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.
Why it costs money
Every one of those steps happens before a single corrective action is taken. Manual context-gathering is pure added latency on MTTA, 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
- Ticket ingestion on creation event
- Resolution procedure retrieval
- Targeted log retrieval
- Prior-case similarity search
- Grounded recommendation, written back to the ticket
How it runs
The workflow
Trigger
A new incident ticket is raised in the ITSM platform.
- 01Ticket creation triggers the agent
- 02Retrieve the relevant resolution procedure
- 03Pull relevant logs, where they add signal
- 04Search resolution history for comparable prior cases
- 05Synthesize a recommendation grounded in all three
Output
A recommended solution posted directly onto the ticket, citing the resolution procedure, the relevant logs and the comparable prior cases it drew from.
Architecture
How it fits together
Components
- ITSM platform (trigger + write-back surface)
- Incident triage agent — Claude Sonnet 4.5 via AWS
- Procedure library
- Log store
- Resolution history store
Data flow
01
Ticket created → agent triggered
02
Fetch resolution procedure → fetch logs → search comparable prior cases
03
Synthesize grounded recommendation
04
Post back to the originating ticket
The guardrail
What it is not allowed to do
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
- ITSM platform 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
~50%
MTTA reduction
Mean-time-to-acknowledge fell by roughly half.
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 client's identity, resolution procedure contents, ticket details and internal resolution history are not disclosed. What is described here is the architecture pattern and the measured outcome — nothing proprietary to the environment it runs in.
Limited availability
Tell me the problem.
I’ll tell you if an agent is the answer.
A 30-minute call, no pitch. Describe the manual loop that hurts and I’ll give you a straight read on whether this is worth building — including when the honest answer is a script, not an agent.
30 minutes · video call · no pitch