How to Build a Bug Triage Agent With Linear and GitHub

Building bug triage agent starts with a clear trigger and ends with a handoff a person can check. The steps below define that path, and the code shape under them shows how one run holds together.

1. 1Define the trigger: issue, PR, failed CI job, docs change or support ticket.
2. 2Limit tool access to the files and systems the agent needs.
3. 3Add a plan step before writes.
4. 4Run checks and produce a short reviewer handoff.
5. 5Log the prompt, changed files, commands and result.

type AgentJob = {
  task: string;
  context: string[];
  allowedTools: string[];
  checks: string[];
  handoff: "diff" | "comment" | "pull_request";
};

Start with allowedTools. I'd say it's the field people end up regretting, though I'll admit that's a guess from a small sample. The pull is to grant broad access while you're building, because narrowing it is fiddly and everything works either way when you're sitting there watching. An agent running unattended with repo-wide write and a shell is a genuinely different risk than one that can edit three paths and run a single command, and you find out which one you built on the run where something goes wrong.

handoff is what decides whether anyone trusts the thing. Returning a diff keeps a person in front of it before anything lands, which is the right default while you're still learning how the agent behaves on your codebase. Opening a pull request is that same gate with better ergonomics, once you've earned the confidence. A comment is the lightest option and suits agents that only diagnose. What none of them should do is merge — not until the commands in checks are ones you'd have run yourself anyway.

Most failures here are not exotic. They come from giving the agent too much room, or trusting a "done" that no test ever proved.

Scope bites earliest. Give an agent a vague task and it will go and find related work to do, which reads as initiative right up until you're staring at a diff across twenty files with no idea which changes were the point. A better model doesn't fix this. A narrower task does: name the files, name the behaviour that should change, say what's out of bounds.

Weak checks bite latest, and hardest. An agent reports success from its own reading of its own work, and it isn't lying when it does that — it just has nothing external telling it otherwise. Maybe the better way to put it is that if the only thing between the agent and your main branch is its own summary, you don't have a review step at all, you have a formality with a nice interface. Give it a command whose exit code you trust, and let the run fail when that command fails.

A detailed Linear or GitHub ticket is no longer just a record for a human - it is the agent's brief. The quality of the agent's output is set by the ticket, so write the ticket as the what, not the how: user story, requirements, data model, expected UI. Leave the implementation steps out and let the agent reason about how.

The board-column trigger

Add a dedicated column - e.g. an In Progress Cursor column split from In Progress Human so agent work is visible. Wire it via webhook so dragging a ticket into the column triggers a cloud agent that extracts the ticket, implements it, and returns a PR plus artifacts.

Through the Linear MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition.. An MCP lets a Cursor agent talk to an external system; the Linear one lets it read tickets, comment on them, and create tickets and projects. PMs use Cursor as a Linear front-end and let it do bulk triage a human would never finish by hand.

Cursor's own team runs an unreleased auto-run feature internally: it automatically fires a background agent on incoming bug reports that meet a confidence bar. The agent works autonomously, then a human reviews and merges a high-confidence fix or iterates if not. It is oriented around Linear's schema today, with Jira and more connectors expanding externally in the coming months.

Yes, and you don't need to know the codebase. A finance teammate flagged a self-serve team with 10 stacked unpaid invoices the product should have blocked after the first. The presenter opened a new agent, pasted the raw Slack thread, and hit go. Nothing else.

With the agent connected to the GitHub repo, Databricks via MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition., and Slack and Notion, Cursor reasoned across every system. It built its own to-do list, located the exact function causing the bug, validated against that specific customer, summarized all impacted teams (open invoice counts, total exposure, top 10 customers by open value), and proposed both a fix and a Linear bug report. The agent discovers the files live - you don't point it at them.