Devin auto-triage and the always-on oncall

The broadest listener surface on a coding agent

The signal surface is what caught my attention first. Auto-triage connects to Slack, Linear, GitHub, Sentry, Datadog, PagerDuty, and custom webhooks. When a bug report lands in a Slack channel, or a Sentry alert fires, or a Linear ticket transitions to a "Bug" label, auto-triage picks it up and starts investigating.

That's seven input sources, each with its own payload format, its own authentication model, its own delivery semantics. We wrote about the webhook tax earlier in this series: adding one webhook provider to a proactive agent takes roughly a sprint. Four providers takes most of a quarter. Seven is a serious infrastructure investment, and it explains why most agent products settle for one or two integrations at launch.

The investigation flow, based on Cognition's documentation, works something like this: a bug report comes in ("Pro users seeing 'undefined' on the billing page since Friday's deploy"), and auto-triage pulls error logs from Datadog, queries the read replica to verify data state, traces the breaking commit in git history, writes a fix with a regression test, and opens a PR. When the fix isn't obvious, it posts an investigation summary instead.

The listener here is genuinely always-on, not scheduled. Cognition explicitly contrasts this with webhook-triggered automation (an implicit comparison to Cursor's recently launched automations), positioning auto-triage as a persistent agent that maintains context rather than a stateless function that fires and forgets.

The manager and the fleet

The architecture underneath auto-triage uses what Cognition calls a manager-agent pattern. One agent maintains long-running context across all investigations: what incidents have been seen before, which ones are related, how the team typically handles certain categories of bugs, who owns which services. When a new signal arrives, the manager agent can spin up sub-Devins to investigate in parallel, each working in its own sandboxed environment.

This is a different model from a single-agent loop. A single agent handling triage would have to serialize investigations, context-switching between incidents and holding everything in one increasingly long conversation. The manager pattern separates coordination from execution. The manager remembers; the sub-agents do the digging.

The long-term memory is the piece that interests me most. Auto-triage remembers prior findings, recurring issues, and how your team handled specific bug categories. When the same class of error appears again, the agent already knows where to look and who to assign. Over time, the routing should get better as the system learns team preferences.

This memory architecture addresses something I wrote about in what makes proactive agents hard: the cold-start problem across runs. Most agents forget everything between sessions. They wake up, do their work, and lose all context. An agent that accumulates institutional knowledge about your incidents, your codebase, and your team's preferences is qualitatively different from one that cold-starts every time a Sentry alert fires.

Whether the memory actually works well at scale is a different question. The gap between "remembers prior findings" in a product description and "reliably correlates a Tuesday Slack thread with a Thursday Sentry alert about the same root cause" in production is wide. But the architectural commitment is right.

Playbooks as a judgment mechanism

The detail that surprised me is how teams teach auto-triage what to do. In the Linear integration, you don't just point the agent at a bug label and say "fix it." You write a triage playbook: a concrete sequence of investigation steps that describes how a human engineer would approach the problem. Search the codebase for relevant files, check git history for recent changes, look at error patterns in the monitoring tool, verify the data state, and so on.

The playbook isn't a system prompt. It's an operational runbook, the kind of document that experienced oncall engineers keep in their heads or buried in a Confluence page. By making it explicit and machine-readable, teams are encoding their institutional triage knowledge into a format the agent can follow.

From the documentation, the workflow uses edge detection on Linear label transitions, so it only fires on newly triaged tickets rather than retroactively processing the entire backlog. Playbooks can be chained: a "Clear Fix" label can trigger a separate fix playbook. The investigation results sync back to the Linear ticket as structured output.

The playbook pattern also explains why Cognition positions auto-triage as learning over time. The playbooks are a starting point, but the memory layer accumulates which steps actually led to successful resolutions and which were dead ends. In theory, the investigation gets sharper with each incident.