Build your bug-report triage agents

Why this matters

Most bug-report backlogs are not a backlog of bugs. They’re a backlog of unsorted reports: half of them missing repro steps, a quarter of them duplicates of something already filed, and the rest pointing at three different teams who all assume someone else owns it. Engineers spend the first hour of Monday triaging instead of fixing. The actual bugs sit longer than they should because the sorting problem is upstream of the fixing problem.

The fix isn’t a single smarter triage rule. Instead, three agents do the work, each handling the part that suits them. Triage scores severity, classifies the area, and checks for duplicates. Repro Followup chases down missing reproduction info from the reporter without your engineer having to ping back and forth. Routing decides which team owns it and writes the one-line “this is yours because…” note. Today, you build all three. By next week, the queue your engineers see is already sorted, deduped, and reproducible: which is the whole job everyone’s been pretending isn’t a job.

Quick start

1. Sign in: open Auxot in your browser and log in.

2. Open chat with the Admin Agent: click Chat in the left menu, make sure the agent picker reads “Admin Agent.”

3. Build the three agents in one shot: paste this:

   I want to build three bug-report triage agents that work together. The first ("Triage") reads incoming bug reports, scores severity 1-5, classifies the area (auth, billing, UI, performance, etc.), checks for duplicates against recent and open issues, and decides whether the report is reproducible-as-filed or needs more info. The second ("Repro Followup") takes reports flagged as needing more info and asks the reporter the right follow-up questions to make the bug reproducible. The third ("Routing") takes triaged-and-reproducible bugs, names the specific team or person who owns the area, and writes a one-line note explaining the routing. Build all three. Make them ready to use.
   

4. Answer the Admin Agent’s questions: it’ll ask about your severity definitions, your area ownership map, and what kinds of reports come in most often. Two or three exchanges.

5. Test on a real recent bug report: pick something filed in the last week. Paste it into chat with Triage. Watch the handoffs between agents.

Done? All three agents are in Settings → Agents and selectable from the agent picker. Optional next step: wire Triage to your issue tracker via an MCP server (Add an MCP server) so it picks up new reports automatically and writes back its decisions.

The agent can do that?

Three triage agents only earn their keep if the three jobs are sharp and the handoffs between them are clean. These three prompts are the difference between “another bot in the queue” and a set of agents your team actually trusts.

1. Have Triage check duplicates against recent reports, not just open issues

Open chat with Triage and ask:

When you classify a new report, check for duplicates against (a) currently open issues and (b) anything filed in the last 30 days even if it's been closed. If a closed issue matches, treat it as a regression candidate, not a fresh dupe — flag it that way explicitly so the engineer knows it came back. If you're not sure whether something's a dupe, surface both reports side by side and let me decide. Never auto-close a report as a dupe — only flag it for review.

Why it’s non-obvious: Most dedup checks only look at open issues, which means closed-then-regressed bugs get filed as fresh tickets and the engineer has to discover the prior history themselves. Treating “closed in the last 30 days” as a regression candidate catches this, and the regression flag is its own signal worth knowing about, separate from the bug itself. The “never auto-close” rule is what makes engineers actually trust the dedup output instead of second-guessing it.

2. Give Repro Followup area-specific question lists, not a generic checklist

Once the agents have been running for a week, head back to the Admin Agent:

Update Repro Followup. Instead of one generic list of repro questions, give it area-specific question sets. For auth bugs, it asks about session state, browser, SSO provider, and whether the user was on a fresh login. For performance bugs, it asks about data volume, browser, network conditions, and whether other users in the same org are affected. For UI bugs, it asks about browser, viewport size, and whether they can attach a screenshot. For billing bugs, it asks about plan tier, recent plan changes, and the exact action that triggered the issue. The classifier from Triage tells Repro Followup which question set to use. If a report doesn't match any area cleanly, fall back to the generic checklist.

Why it’s non-obvious: Generic repro checklists annoy reporters and miss the questions that actually matter for that bug class. A performance bug doesn’t need “what browser are you using?” as the third question: it needs “how much data are you working with?” Area-specific question sets cut the back-and-forth from three rounds to one. Pairs with the next power move: a clean repro on the first ask is what makes the routing agent’s job easy.

3. Wire the routing agent to your tracker so it opens the ticket itself

Inverted-usage move. Open chat with the Admin Agent:

Wire Routing to my issue tracker via MCP (Add an MCP server in the Auxot tutorials). When Routing decides a report is triaged, reproducible, and routed, it should: (1) open a ticket in the right project, (2) set the severity from Triage, (3) tag the area from Triage, (4) assign to the named owner, (5) include the original report plus the repro info Repro Followup gathered plus Triage's reasoning in the ticket body, and (6) reply back in the original Slack thread or report channel with the ticket link so the reporter can follow it. If Routing isn't confident enough to auto-open — for example, severity 1 or anything flagged as a regression — it should post the ticket draft to a "#triage-review" channel for a human to confirm before opening.

Why it’s non-obvious: Most setups stop at “the bug is now well-described and routed,” leaving a human to copy-paste the result into the tracker. That’s where reports go to die on Friday afternoons. Auto-opening closes the loop, and the “high-severity goes to review first” rule is what keeps you from auto-filing a P1 with the wrong team. The reply-back-to-the-reporter part is the bit your support team will love most: closes the loop with the customer without anyone having to remember to do it.

Go deeper

Why three agents, not one mega-agent

You could ask one agent to do triage and repro and routing. It would work in a demo and degrade in production. The constraints fight each other: “score severity in seconds” (triage) and “have a patient back-and-forth with the reporter” (repro) and “know who owns what across the org” (routing) all want different shapes. Splitting the work into three agents lets each one’s description be tight. The handoff between them is what makes the setup work, not the size of any one agent.

The handoff problem

Two patterns work in Auxot for these handoffs:

• Workflow-driven (Run a workflow): a workflow runs Triage → conditional → Repro Followup (if repro missing) → Routing → output. Best when reports come from a structured source (an issue tracker webhook, a Slack channel, a form).
• Chat-driven: you’re the dispatcher. Paste a report into chat with Triage, switch agents based on what it returned. Slower, but lets you stay in the loop while the agents are new and your engineers don’t fully trust them yet.

Run chat-driven for the first week. Move to workflow-driven once the dedup detection has earned trust: that’s the call your team is most likely to push back on, and you want a week of evidence before you let it run unattended.

Severity belongs to Triage, ownership belongs to the routing agent

Don’t put your area-ownership map on Triage: Triage shouldn’t be deciding who fixes the bug. Its job is to score severity, classify the area, and check for dupes. Routing to a team is the routing agent’s job, with full knowledge of who’s on call, who’s on PTO, and what team owns what. Mixing ownership into Triage bloats it and means you have to update both agents whenever a team reorganizes. Keep Triage focused on the report; keep the routing agent focused on the org.

Where reports come from determines the wiring

Pick the source that matches where bugs actually arrive:

• Issue tracker (Linear, Jira, or GitHub Issues): wire via MCP (Add an MCP server). Highest-leverage source; this is where most teams should start.
• Slack channel: #bugs or similar. Wire via Connect Slack to your agents. Catches the “hey, is anyone else seeing this?” reports that never make it to the tracker.
• Support inbox: bugs forwarded from customer support. Wire via an email-reading MCP. Lower volume usually but high-signal.
• All three at once? Don’t. Pick the one your team currently trusts most as the canonical source and wire that first. Add the second after a week.

Troubleshooting

• Triage scores everything as P1. Its severity definitions are too loose, or its examples skew high. Edit the description to include explicit examples of low severity: “a typo on a settings page is P4; a UI glitch in a non-critical flow is P3; a workflow that produces wrong output for some users is P2; data loss or auth breach is P1.”
• Repro Followup is annoying reporters with too many questions. Its question lists are too long. Cap each area at three questions max. The rest can be follow-up if needed; better to ask three good questions and ask again than ask twelve and lose the reporter.
• The routing agent routes everything to the platform team. Its area ownership map is missing or outdated. Edit the context file (or update its description directly) with explicit ownership: “auth → identity team, billing → payments team, and anything in the dashboard UI → frontend team.”
• Bugs keep getting reopened because triage missed they were dupes. Either the dedup window is too narrow (extend the 30 days to 60), or the agent doesn’t have enough recent-issues context. Refresh the context file Triage uses for dedup at least weekly: manually or via a workflow (Run a workflow).
• The agents are producing good triage but engineers ignore it. This is a trust problem, not a quality problem. Run chat-driven for two more weeks. Have your most skeptical engineer audit ten reports with you. The agents earn the right to run unattended; they don’t get it by default.

Variations and edge cases

• Business-to-business vs business-to-consumer reports. Consumer-product reports have high volume and tons of dupes: bias toward aggressive dedup, faster auto-routing. Business-to-business has lower volume per ticket but each one matters more: bias toward more human-review checkpoints, especially for severity 1.
• Internal-only reports (reports from your own team). The repro questions are different: your engineers know the system; ask less. Their reports are also higher-trust on severity self-assessments. Consider a separate Triage agent tuned for internal reports if you have meaningful internal volume.
• Security-sensitive reports. Carve these out of the three-agent flow entirely. Add a rule to Triage: “if a report mentions auth bypass, data leak, account takeover, or any CVE-style language, route immediately to the security channel without going through Repro Followup.” Don’t have these agents ask follow-up questions on a possible security incident: that’s a human conversation.
• Don’t merge Triage and the routing agent. They feel similar (both classify), but Triage scores what kind of bug and the routing agent decides who fixes it. Different jobs, different descriptions. If you find yourself wanting to merge them, the fix is usually that the routing agent’s ownership map needs more detail, not that the agents need to combine.
• Free tier: all three agents work at all tiers. Multi-team routing (the routing agent sending to a different team’s tracker or Slack channel) needs Business+ if those teams are separate in Auxot (Set up multi-team isolation). Issue-tracker MCP works at all tiers.

Walkthrough

Step 1: Open chat with the Admin Agent

Click Chat in the left menu. Make sure the agent picker at the top reads “Admin Agent.”

Step 2: Build the three agents

Paste this:

Build me three bug-report triage agents:

1. "Triage" — reads incoming bug reports. Scores severity 1-5 with a one-line reason. Classifies area (auth, billing, UI, performance, infrastructure, etc.) using the area list I'll give you. Checks for duplicates against open issues and anything filed in the last 30 days; flags closed-and-recently-filed matches as regression candidates separately from fresh dupes. Decides whether the report is reproducible-as-filed or needs more repro info before routing.

2. "Repro Followup" — picks up reports Triage flagged as needing more info. Asks the reporter follow-up questions tailored to the area Triage classified. When the report has enough info to reproduce, marks it ready and hands off to Routing.

3. "Routing" — picks up triaged + reproducible reports. Names the specific team or person who owns the area, writes a one-line "this is yours because..." note, and produces a clean ticket draft (severity, area, repro steps, and context).

Give each one a clear job description, ask me what context files to attach (severity definitions, area ownership map, and recent-issues data), and make all three ready to use.

The Admin Agent will ask follow-up questions: what your severity definitions are, what your area list is, who owns each area, and what counts as enough repro info. Be concrete: “P1 = data loss, auth bypass, or any production outage; P2 = wrong output for some users; P3 = degraded UX; P4 = cosmetic” beats “important vs less important.”

Step 3: Confirm and create

The Admin Agent proposes the configuration for all three agents. Read it. If a description sounds vague, push back: “Make Triage more specific about what counts as a ‘regression candidate’ versus a fresh dupe.” If it looks right, say “yes, create them.” All three agents appear in Settings → Agents.

Step 4: Attach the right context files

Three context files do the bulk of the work:

• Severity definitions: explicit examples of P1 through P5, with one-line reasons for each. The agent uses this to score consistently.
• Area ownership map: which team or named person owns each area of the product. The routing agent consults this directly. Update it whenever the org reshuffles.
• Recent issues: a snapshot of the last 30 to 60 days of bugs (open and closed). Triage consults this for dedup. Refresh it weekly via a workflow (Run a workflow) or manually.

Add your first context file covers context-file mechanics. The recent-issues file is the one most teams skip and most regret skipping: without it, dedup is guesswork.

Step 5: Test on a real recent bug report

Pick a real bug filed in the last week. Paste it into chat with Triage. Verify, in order:

• Did Triage score severity at the level you’d score it?
• Did it pick the right area?
• Did it correctly catch (or correctly clear) the dedup against your real backlog?
• If it flagged “needs more repro info”: were the questions the right ones?
• If the routing agent got involved: did it pick the right team?

Adjust the agents’ descriptions or context files based on what’s off. “Triage scored this P3 but it should have been P2 because some users were getting wrong output, not just degraded UX — tighten the P3 vs P2 boundary in the severity definitions.”

Step 6: Wire it to a real source

Once the agents are producing usable triage on real reports, connect it to an actual source:

• Issue tracker (Add an MCP server): wire your tracker via MCP. The agent picks up new reports as they come in and can write back its triage decisions to the ticket.
• Slack (Connect Slack to your agents): Triage watches a #bugs channel; new posts get triaged inline.
• Workflow (Run a workflow): runs the agents on a schedule against a queue of unsorted reports. Useful for nightly batch triage if your reports come in faster than real-time triage can handle.

Start with the source your team trusts most as canonical. Add the second only after the first has been running cleanly for a week.

Step 7: (Optional) Wire the routing agent to auto-open tickets

Once the routing agent has been running for two weeks and you trust its routing, use power move 3 to wire it to your tracker: the routing agent opens the ticket itself, fills in severity and area, assigns to the named owner, and replies back to the reporter with the ticket link. Keep severity 1 and regression candidates routed through a #triage-review channel for a human confirm before they auto-open. The “everything else auto-opens” rule is where these three agents start saving real engineer-hours.

What’s next

• → Add your first context file. Severity definitions, area ownership, and recent-issues data all live as context files.
• → Run a workflow. Once the agents are trusted, wire them into a workflow for nightly batch triage or refresh the recent-issues context file on a schedule.
• → Connect Slack to your agents. Triage watching a #bugs channel is a common starting point.
• → Add an MCP server. Wire the agents into your issue tracker so they read reports and write back triage decisions.
• → Triage pull requests before humans review them. Same triage instinct applied to code-review queues: paste mode or GitHub MCP instead of bug intake.
• → Build your customer support agents. Same multi-agent pattern, different end of the inbound pipeline.
• → Set up a content review pipeline. Adjacent multi-agent pattern with explicit human-in-the-loop checkpoints.
• → Replace an agent currently in use. Agent rosters grow cruft; replacing bad agents is part of healthy ops once triage is trustworthy.

Reference

• Three roles, three agents: Triage (score + classify + dedup), Repro Followup (chase missing repro info), and Routing (decide ownership and route).
• Why split: each agent’s description stays tight; constraints don’t fight each other.
• Dedup is where these agents pay for themselves: 30 to 50 percent of most backlogs are duplicates; catching them at intake is the biggest win.
• Severity lives on Triage, ownership lives on the routing agent: don’t smear either across both.
• Never auto-close a dedup: flag for review only. False-positive dedups erode trust faster than missed dupes.
• Refresh the recent-issues context file weekly: without it, dedup is guesswork.
• Carve out security-sensitive reports: those don’t go through these agents; they go straight to a human.
• See also: Prep for your next sales call, Replace an agent currently in use, Create an agent from scratch, Add your first context file, Add an MCP server, Build your customer support agents.