Is there AI for incident investigation and alert triage that knows our code, past incidents and postmortems?
Yes, from two kinds of tool. AI SRE agents in PagerDuty, Datadog and incident.io start from the alert and telemetry, and learn from the incidents and docs that pass through their platform. A context engine starts from your code, PRs, Slack threads and the postmortems in your wiki, so it knows the history nobody linked to the incident tool. The two fit together.
Yes, from two kinds of tool that know different things. AI incident investigation is software that takes an alert or a declared incident, gathers evidence, and proposes a likely cause and fix. The AI SRE agents built into PagerDuty, Datadog and incident.io work from the alert side: telemetry, change events, runbooks and their own memory of incidents they have handled. A context engine works from the team side: the code, the pull requests, the Slack threads and the postmortems in Confluence or Google Docs. If "knows our past incidents" means last year's, written up in a wiki, the agent has them only if someone linked or uploaded them.
Teams are early here. The 2026 Stack Overflow survey found 61 percent of developers use AI for debugging, but only 20 percent use it for "deploying, operating, or troubleshooting production systems" (Stack Overflow). The same survey found 93 percent need source attribution to trust AI output.
What do the AI SRE agents in incident tools know?#
These agents start fast because they sit where the alert lands. PagerDuty's SRE Agent works by "ingesting event data, runbooks, and logs" to find the incident's scope and likely cause. It can "search code, pull requests, and commits in connected GitHub repositories" and pull runbooks "from sources such as Confluence and GitHub" (PagerDuty docs). incident.io's Investigations "reasons across telemetry, deployments, code, and incident history." The only change it makes is "a pull request you review and merge yourself" (incident.io).
Datadog's Bits Investigation "iteratively forms hypotheses, gathers relevant telemetry, and uses data-based reasoning" (Datadog docs). Its knowledge comes from runbooks linked in the monitor message, a bits.md file about your environment, and memories built from your feedback (Datadog knowledge sources).
PagerDuty and incident.io say they read code and recent changes. We read each vendor's docs on 2026-11-08. PagerDuty and Datadog take Confluence pages as runbooks you upload or link. None of the pages names postmortems kept in a wiki as a source.
| AI SRE agent (PagerDuty, Datadog, incident.io) | Context engine (Unblocked) | |
|---|---|---|
| Starts from | The alert, telemetry, change events | A question from Slack or a coding agent |
| Code and PRs | Connected repos and recent changes (PagerDuty, incident.io) | Code, PR history and review threads |
| Past incidents | Incidents, feedback and docs in its own platform | Synced Datadog incidents and Sentry issues, plus the chat, PR and wiki history around them |
| Wiki postmortems | Only if uploaded or linked as docs or runbooks | Indexed with the rest of the docs |
| Scope | Their own platform's telemetry; PagerDuty memory is per service | Across repos, teams and tools |
| Acts on systems | Proposes fixes; some open PRs | Answers with citations; does not page or route |
What does "knows our past incidents and postmortems" require?#
Look at how these agents learn. PagerDuty says "every incident Paige participates in contributes to its memory." That memory is "scoped to a given PagerDuty service," and an incident must be resolved before Paige saves anything. Datadog's memories come from feedback you give after an investigation. That is real learning, built from what passes through the tool. PagerDuty's stays inside one service.
Most of what an on-call engineer means by "past incidents" lives somewhere else. For example, take a made-up case. The payments queue backs up at 2 a.m., and the same thing happened fourteen months ago. The postmortem is a Confluence page and the root cause was a connection-pool change in a PR. The engineer who fixed it explained the trade-off in a Slack thread, then left. Nobody linked any of it to the incident tool, so a tool that reads only telemetry and its own records starts from scratch.
That history is worth having. A July 2026 paper indexed 1,172 resolved issues as symptom, root cause and resolution, and had an LLM diagnose failures from the closest past case. It reached 93.1 percent diagnosis accuracy, 77 percent better than a documentation-anchored concept graph (Guan et al., 2026).
The second gap is scope. Real incidents cross services, and a per-service memory does not connect them. Our post on mapping blast radius during an incident shows which tool holds each piece: dependencies, recent changes, ownership and history.
Where does a context engine fit?#
A context engine is a service that indexes code, PRs, issues, docs and chat together, settles conflicts between them, and returns one cited answer filtered to what the asker may see. For incidents, the old postmortem, the fixing PR and the Slack thread come back together. How it ranks sources is in inside the Unblocked context engine.
Unblocked is one, and reads incident data too. It "syncs incidents from Datadog every 15 minutes" and queries logs, metrics and monitors live when you ask (Unblocked Datadog docs). It syncs Sentry issues on the same 15-minute cycle (Unblocked Sentry docs). Its context_research tool runs "a multi-source research query across code, pull requests, documentation, issues, and messaging" and returns cited results (Unblocked docs). Engineers ask it from Slack, or their agent calls it over MCP from Claude Code, Cursor, GitHub Copilot, VS Code or JetBrains. With Data Shield on, answers include only sources the asker can see in the original system.
Nazmus Sakib, a software engineer at Workday, describes the on-call version: "When I'm on call and we hit a data discrepancy, that investigation used to take a full day. Now the agent calls Unblocked to pattern match against past Slack conversations and Confluence pages — and I have an answer in 30 minutes. Teammates without Unblocked licenses have told me the results are more useful and easier to work with than what they're using instead."
A context engine is not a pager. It does not route alerts or run the incident channel. So the two fit together. The incident agent catches the alert and reads telemetry, and the context engine answers whether you have seen this before and what you decided. Our PagerDuty MCP guide puts the live incident and the diff in one Claude Code session, then shows where the history comes in. For how a context engine weighs a recent Slack message against an old wiki page, see this answer.
How do you test either one on your own incidents?#
Demos use clean incidents, so replay real ones.
- Pick three resolved incidents, older than six months, each with a postmortem and a fix in a PR.
- Replay the opening alert and ask each tool what is wrong and whether it has happened before.
- Check that the answer finds the old postmortem, names the fixing PR, and links both.
- Ask one question that crosses two services, and see whether the tool connects them.
- Ask as an engineer who should not see a restricted doc, and confirm the answer leaves it out.
If the incident agent finds the history on its own, you may need nothing else. If it starts from zero each time, the history is in your wiki, PRs and chat, and you need a tool that reads them.
