When your team ships faster, you get more bug reports. That is obvious. What catches teams out is that the triage step scales at the speed of a human, not a CI pipeline. Reading each report, deciding what merits a fix, routing it to the right person or agent: that is a human job, right up until it does not have to be.
The answer is not "let the AI decide." It is separating the reports that already carry enough authority for automated action from the reports that need a human to read them first.
Why report volume grows when you ship with AI
Coding agents make it much faster to build features and fix bugs. As a side effect, they expand the surface area of your app. More features, more edge cases, more things that can break for a subset of users in a way your tests did not catch.
The result is more bug reports, arriving faster. If your team is small and your agent is doing a significant share of the coding work, the reports will outpace what you can manually triage.
A second effect is less visible: internal pipelines now submit reports too. CI systems catch regressions. Agents file their own failure reports when they hit a missing tool or an ambiguous schema. The volume includes a mix of public user reports (which need careful handling) and internal signals (which can often be acted on immediately). Treating them the same way is where teams lose time.
Not every report is ready for automated action
The most common mistake in automated triage is routing all reports through the same path. Public user feedback and an agent-submitted failure report have almost nothing in common from an authority standpoint, even if they describe a similar symptom.
A public user who submits a bug report has not been verified. They might have seen a genuine bug. They might have misunderstood a feature. Their report might reference environment details specific to their machine. Routing that directly to an agent that auto-creates a GitHub issue produces noise: issues that need triage, tickets that duplicate each other, PRs that fix something no one else can reproduce.
An agent-submitted report is different. The submitting agent has a scoped API key. It knows the codebase. Its report already has structure: the error message, the relevant code path, the reproduction case. That report can move to an issue immediately.
The gap between those two cases is what a trust model is for.
What trust-aware routing does in practice
Quell assigns every feedback submission a trust level before anything else happens. The level is derived from how the submission was authenticated, not from what the user claims about themselves.
The five levels are public, identified, reporter, agent, and admin. The feedback trust levels post covers the full model. In terms of triage automation, the practical distinction is between two groups:
Reports that wait for a human first:
- <code>public</code> submissions (anonymous widget reports, no sign-in): go to the inbox queue for human review before any automatic action
- <code>identified</code> submissions (the app confirmed a user identity): useful additional context, but still reviewed by default
Reports that can move immediately:
- <code>reporter</code> submissions (signed-in, verified users): eligible for automatic issue creation on projects that opt into a trusted-reporter policy
- <code>agent</code> submissions (a scoped API key, a CI pipeline, an internal tool): can create GitHub or Linear issues immediately per project policy
- <code>admin</code> submissions: unrestricted
When you set the routing policy per project, triage happens in two lanes. Public reports land in the queue for a human to read. Agent and pipeline reports move directly to your issue tracker. You do not have to decide each one; the decision is made at submission time by the authority the submitter carries.
Setting up the automated lane
The Quell queue shows all open reports filtered by trust level. You can set a project-level routing rule: reports at agent trust or above auto-create a linked issue; everything else waits.
For internal pipelines and CI systems, the setup is a scoped API key with feedback:write permission. The key goes in the pipeline's environment. Reports submitted with that key arrive at agent trust and move to the issue tracker without waiting for a queue review.
For a coding agent connecting to Quell via MCP, the setup is the same key with feedback:read added. The agent can list and read reports from the inbox, comment on items, and update status. If you give it feedback:integrations, it can also create the issue. The agents page lists the full scope matrix.
The widget captures reports from real users. Those arrive at public or identified trust by default and land in the human queue. They carry the console trace, failed network request, and page context automatically, so when a human does triage them, they have the evidence a coding agent needs to investigate.
Frequently asked questions
Can I route all user bug reports to an agent automatically?
You can, but it is rarely the right call for public submissions. An anonymous user report may be a genuine bug or may be a misunderstanding of a feature. Auto-creating an issue for every one creates noise. The more useful pattern is routing agent-submitted and pipeline reports automatically, keeping public reports in a human queue where they can be triaged before moving to your issue tracker. This is what trust levels are for.
What trust level should a CI system use?
A CI pipeline that submits reports should use a scoped API key with feedback:write permission. Quell derives agent trust from API key authentication. Reports submitted this way can be configured to auto-create a GitHub or Linear issue immediately, since the submitter is a known internal system rather than an unverified external user.
How does Quell know whether to auto-create an issue?
The routing rule is set per project, not per submission. You choose the minimum trust level at which automatic issue creation is allowed. The default is that only agent and admin submissions trigger auto-creation. Public and identified submissions go to the queue. You can raise or lower the threshold per project depending on how much confidence you have in your reporter base.
Does automated routing work with GitHub and Linear?
Yes. Quell can create linked issues in GitHub or Linear when a submission meets the project's routing threshold. The issue title and body come from the feedback item and its /context export. The integration is idempotent: if an issue already exists for a given feedback ID, a second auto-create call links to the existing one rather than creating a duplicate.
What does the human triage queue look like?
The queue page shows reports that need a decision: open items sorted by trust level, source, and priority. Each report shows the user's message, the trust level it arrived at, and the attached context (console errors, failed requests, screenshot). A human can triage in bulk, reassign to an agent, or create an issue manually. The automated lane runs in parallel: reports that qualify move through without touching the queue at all.