How to Build a Bug Triage Agent With Linear and GitHub

A bug triage agent starts from a clear trigger and ends with a handoff a person can check. The steps below cover that path, and the code shape after them lists the fields one run needs.

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";
};

Decide allowedTools first. While you build, broad access is tempting, because narrowing it is fiddly and everything works when you are watching. An agent that runs unattended with write access to the whole repo and a shell is a different kind of risk from one that can edit three paths and run a single command. You find out which one you built on the run where something goes wrong.

handoff decides whether people will trust the agent. For an agent that changes code, returning a diff keeps a person in front of every change before it lands, which is the right default while you learn how the agent behaves on your codebase. A pull request keeps the same gate with less friction once you have more confidence in the agent.

A comment is the lightest handoff and suits agents that only diagnose. Whichever you choose, don't let the agent merge until the commands in checks are ones you would have run yourself.

Most failures here are ordinary. The agent gets too much room, or someone trusts a "done" that no test proved.

Scope problems show up first. Give an agent a vague task and it will find related work to do, which looks like initiative until you face a diff across twenty files and can't tell which changes were the point. Narrow the task instead: name the files, name the behavior that should change and say what is out of bounds. A stronger model won't solve a scope problem.

Weak checks show up last and do the most damage. An agent reports success from its own reading of its own work, and nothing outside it says otherwise. If the agent's summary is the only thing between its work and your main branch, you have no review step. Give it a command whose exit code you trust, and fail the run when that command fails.

Write it as the agent's brief, because a detailed Linear or GitHub ticket now does that job as well as recording the bug for people. The ticket sets the quality of the agent's output. Describe the what: the user story, requirements, data model and expected UI. Leave out the implementation steps, and let the agent reason about how.

The board-column trigger

Add a dedicated column, such as In Progress Cursor next to In Progress Human, so agent work is visible. Dragging a ticket into that column then starts a cloud agent that reads the ticket, implements it and returns a pull request with artifacts. In Linear, an automation's Status changed trigger can run when an issue moves into a status you pick, which covers this without custom code. For other trackers, send the column change to a webhook trigger. Free and Plus plans include neither cloud agents nor Automations.

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. server. An MCP server lets a Cursor agent work with an outside system, and Linear's lets it read tickets, comment on them and create tickets and projects. PMs use Cursor as a front end for Linear and hand it bulk triage that nobody would finish by hand.

At the time of the talk, Cursor's own team ran an internal auto-run feature that started a background agent on incoming bug reports above a confidence bar. The agent worked on its own, and a person then merged a high-confidence fix or iterated on it. The feature was built around Linear's schema, with Jira and other connectors said to follow. Cursor's docs now describe starting cloud agents from both: delegate a Linear issue to Cursor or mention @Cursor in a comment, or assign a Jira work item to Cursor.

Yes, and you don't need to know the codebase. A finance teammate flagged a self-serve team with 10 unpaid invoices stacked up, when the product should have blocked it after the first. The presenter opened a new agent, pasted the raw Slack thread and started the run without adding anything else.

The agent was connected to the GitHub repo, to Databricks through 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 to Slack and Notion, and Cursor reasoned across all of them. It built its own to-do list, found the function causing the bug and checked it against that customer. It then summarized every affected team, with open invoice counts, total exposure and the top 10 customers by open value, and proposed both a fix and a Linear bug report. The agent found the relevant files on its own, without anyone pointing it at them.