An incident triage agent for engineering teams

When something breaks, the first fifteen minutes go to gathering: which errors spiked, what was deployed, who touched that service, whether anyone has already said something in chat. An agent can do that gathering for the engineer on call. Here is the shape of one.

What the agent answers

• What is failing, since when, and how often?
• What changed recently in the affected code?
• Is there an open issue or ticket about it?
• What has the team already said?

The services

From the developer tools category of the catalog:

• Errors and metrics: Sentry or Datadog.
• Code and changes: GitHub, GitLab or Bitbucket.
• Tickets: Jira or Linear.
• Conversation: the team’s chat.

Each is reached through a connector, on the engineer’s own authorized account.

Read-only, on purpose

A triage agent needs to look, not to act. Enable only read endpoints: search issues, list recent commits, read errors, search messages. Nothing that merges, closes or deploys becomes a tool. When the engineer decides what to do, they do it.

Code host       ✓ list commits   ✓ read pull requests   ✗ merge
Tickets         ✓ search         ✓ read                 ✗ close
Errors          ✓ read issues    ✓ read events          ✗ resolve

The request

Conceptual example.

const triage = await agent200
  .user(engineer.id)
  .run({
    model: "openai/gpt-5.6-sol",
    instructions: `
      You help an on-call engineer triage an incident.
      Gather facts first. Report: what is failing, likely related changes,
      related tickets, and what the team has said. Link every source.
      Do not guess a root cause without evidence.
    `,
    input: alert.summary,
    tools: ["errors_search", "recent_changes", "ticket_search", "chat_search"],
  });

Make the answer usable at 3 a.m.

• Facts before theories. Ask for evidence first and a hypothesis last, clearly labelled.
• Links everywhere. Every claim should take one click to verify.
• Short. A list of findings beats paragraphs.

Turn repeat steps into a workflow

If every triage starts by pulling the same error details and the same recent changes, configure that as one capability. The model makes one call for the routine part and saves its decisions for the unusual part.

Trigger it from your alerts

Your alerting already knows when something breaks. Have it call your app, and your app call Agent200, so the summary is waiting in the incident channel when the engineer opens it.

See more examples on the Use Cases page.