We built a feedback widget that lets a coding agent fix its own bug reports

A coding agent does not need a prettier ticket. It needs the evidence that existed when the bug happened: the console error, failed request, page state and screenshot. Agent-readable feedback keeps that evidence attached so the agent can investigate the real failure instead of inventing a plausible one.

The problem: "can't reproduce" is a feedback-format problem

A bug report that arrives as a Slack message looks like this:

the export button isn't working on the reports page

A developer reads that and immediately needs to know: which browser, which account, which report, what HTTP response did the server send, was there a JS error in the console? The user already reproduced the bug. The reporting process just threw away the useful part of the reproduction.

Now imagine the same report lands in your agent's context window instead of your Slack. A coding agent faces the same problem, but with less tolerance for ambiguity. It cannot DM the user. It cannot look over the user's shoulder. If the feedback is a sentence, the agent produces a guess-fix or bounces the ticket back to you. Either way, you lose the round-trip advantage of having an agent at all.

The format of the feedback is the bottleneck, not the agent's capability. A larger model cannot recover a console trace you never kept.

What rich context looks like before the user hits submit

Quell's browser widget captures context automatically, in the background, before the submit button is pressed. By the time the user clicks "Send feedback", the report already contains:

• A screenshot of the page, with a freehand annotation layer
• A transcript (if the user chose voice input)
• The last N console log lines, including errors and warnings
• The last N network requests, with status codes and response bodies
• Page URL, viewport size, user agent, and any custom metadata your app injects

None of that requires the user to do anything extra. The widget buffers it continuously. Submit is just the moment you stop the buffer and attach it to the report.

The report is stored server-side. The interesting part is how it gets out.

The /context endpoint: feedback as Markdown

Every feedback item in Quell exposes a Markdown export at GET /api/feedback/:id/context. An agent reads it with a single authenticated request — no parsing, no JSON traversal, no wrapper SDK:

The response is plain Markdown, structured for agent consumption. The example below is illustrative: it uses representative fields to show the shape of the handoff rather than claiming a particular customer incident.

An agent drops this into its context with a concrete lead: a TypeError at reports.js:284 alongside a POST /api/reports/export returning 500. That is enough to start in the right file and test a hypothesis instead of guessing from the user's sentence.

The MCP server and CLI

If you want the agent to pull feedback proactively rather than being handed a URL, Quell ships an MCP server and a quell CLI. Run quell mcp in Claude Code's MCP config and the agent gains 10 tools: list feedback, get a single item with its /context export, comment, update status, open a GitHub or Linear issue, and more.

The scoped API key system means you can give an agent feedback:read and feedback:comment without touching admin operations. Trust-aware routing controls what happens next: a submission tagged agent or admin can auto-create a GitHub issue immediately; a public submission goes through human triage first, so you are not flooding your issue tracker with noise.

A worked example, end to end

Here is how the illustrative Export button report would move through the loop.

1. A user hits the Export button on the Reports page. The POST /api/reports/export returns 500. The widget captures the console TypeError, the failed network call, and an annotated screenshot — automatically.
2. The report lands in the Quell admin inbox tagged identified. Priority is set to high; a comment is added: "blocking a user before a board meeting."
3. Claude Code, running with the Quell MCP server, picks up the item and fetches /context. The Markdown tells it everything: the error site, the trigger, and the user impact.
4. The agent opens ExportButton.ts, sees that reportData.rows can be undefined when the date range returns no data, adds a guard, and opens a PR.
5. Quell does not decide whether code can merge. That remains a repository policy. In my workflow the PR is review-required: I inspect the diff and tests, then merge if the evidence supports the fix.

Built with itself

The Export example above is illustrative. The dogfood loop is not. The Quell widget runs on the Quell admin UI, and I use it when I find bugs while building. The report becomes a /context artefact that a coding agent can inspect before it proposes a change. The PR still gets human review by default.

Quell has no external paying users yet and no case study to hide behind. That makes the evidence bar more important, not less. The useful receipt is three traceable artefacts together: the report, the context the agent read and the resulting issue or PR. If one is missing, it is a product claim, not a dogfood receipt.

No token tax, no mandatory AI

Quell has no built-in AI. "No token tax" means you bring your own agent — Claude Code, Codex, or whatever you already pay for. Quell captures and structures the data; the intelligence is yours. The server is a TypeScript Node process with a zero-dependency widget. Managed cloud (£3/$4/€4 per seat) is in early access — self-serve checkout opens after Postgres SaaS ships. Self-host is on the roadmap; the Dockerfile is in the public repo.

Try it

Request early access for managed cloud, or browse the source on GitHub — self-host is on the roadmap; the Dockerfile is in the public repo. The API reference has everything you need to wire up a scoped key and point an agent at your first feedback item. If you run into a bug while setting it up, submit it through the widget. The loop will close it.