agent-readable feedback

What your coding agent needs to fix a user-reported bug

A user reports a bug. They write "the export button doesn't work." That sentence is everything they can give you. They cannot open DevTools. They cannot paste a console trace. A coding agent receives this and has nothing to act on — not because the agent is weak, but because the reporting process threw away every piece of evidence the user's browser already had.

The context gap: what a real user can and cannot tell you

When a developer reports a bug, they know to open DevTools, check the console, copy the error message, reproduce the steps, note the network request that failed. That is ten minutes of extra work your users will never do — nor should they.

The context exists, though. The user's browser logged the error. The failed network call is in the request history. The page URL, viewport, and user agent are all known. That data did not disappear when the bug happened; it is sitting in the browser's memory, waiting for a reason to be preserved.

The conventional answer is a better feedback form: add a "describe what you were doing" field, ask for the browser name, include a screenshot step. This moves the documentation burden onto the user. Some will fill it in. Most will not. And even the ones who try cannot give you a stack trace.

What your coding agent needs from a bug report

A coding agent investigating a user-reported bug needs three things at minimum:

  1. <strong>The error message and stack trace.</strong> Without this, the agent searches the codebase for anything that might produce the symptom. With it, the agent opens the right file on the first attempt.
  2. <strong>The network call that failed.</strong> A <code>500 POST /api/export</code> alongside a <code>TypeError</code> tells the agent both client and server are involved. A successful call tells the agent the problem is client-side — narrowing the search by half.
  3. <strong>Page state at the time of the report.</strong> The URL, query parameters, user role, and any metadata your app injects turn a vague reproduction case into a precise one.

This is the structure a well-formed bug report gives an agent. With developer-reported bugs, a developer assembles it. With user-reported bugs, it has to be captured automatically — the user cannot produce it themselves.

Capture context automatically, without asking the user to do more

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

  • The last N console log lines, including errors and stack traces
  • The last N network requests, with status codes and response payloads
  • Page URL, viewport size, user agent, and any metadata your app injects
  • A screenshot of the current page, with an optional annotation layer

None of that asks the user to do anything extra. The widget captures it automatically. The user writes their sentence and submits. The report that lands in your inbox already has the evidence a coding agent needs.

Every feedback item exposes a /context endpoint that returns that evidence as structured Markdown:

$ curl https://quell.sh/api/feedback/412/context \ -H "X-Quell-API-Key: $QUELL_API_KEY"

A coding agent reads this with a single authenticated request — no parsing, no JSON traversal. The Markdown contains the user's message, the console error, the failed network call, and the page state. The Quell MCP server gives coding agents like Claude Code direct access without writing the curl call.

From widget to fix: a worked example

The user wrote "the export button doesn't work." Here is how that report moves through the loop with the widget installed. The steps are illustrative — they show the shape of the handoff rather than a specific customer incident.

  1. The user clicks Export. The server returns 500 POST /api/reports/export. The widget captures the TypeError at reports.js:284, the failed network call, and an annotated screenshot. The user types their sentence and submits.
  2. The report arrives in the Quell inbox at identified trust (the app confirmed the user was signed in). A high-severity console error tags it as priority high.
  3. Claude Code, connected to Quell via MCP, fetches the /context export. The Markdown names the error site and the trigger.
  4. The agent opens ExportButton.ts, finds that reportData.rows can be undefined when the date range returns no data, adds a null guard, and opens a draft PR.
  5. You review the diff. The evidence supports the fix. You merge.

The steps-to-reproduce generator and the bug report template generator show the structure an agent works best with. The widget produces that structure from a one-sentence user report automatically. The Claude Code setup guide covers wiring the MCP connection.

Frequently asked questions

Does the user need a Quell account to submit a report?

No. The widget is public-facing. Anonymous users submit at public trust level; signed-in users submit at identified trust. The trust level affects how the report is routed — public reports go to a human queue by default before any automated action. The context capture happens regardless of trust level.

Can I control what context is captured?

Yes. The widget's capture settings are configurable per project: console line count and minimum severity, network request count and URL filter, and response body truncation length. If you handle sensitive data in network responses, filter those requests out before capture.

What does Quell cost?

Managed cloud from $4 per seat, free trial, no token tax. You bring your own coding agent — Claude Code, Cursor, or whatever you already use. Quell captures and structures the data; the AI is yours. Self-host is on the roadmap.

Does this work with coding agents other than Claude Code?

Yes. The /context endpoint is plain Markdown over HTTP. Any agent that can make an authenticated GET request can read it. The MCP server works with any MCP-compatible client. The CLI (quell context <id>) works in any terminal-based workflow.

How is this different from Jam or Marker.io?

Jam and Marker.io are built for developer-to-developer handoffs: a developer captures the bug and passes it to another developer or a ticketing system — the reporter always has DevTools access. Quell is an agent-native feedback platform built for the case where the reporter is a real user who cannot do that, and where the consumer of the report is a coding agent rather than a human reader. The widget captures what the user cannot; the MCP server and /context endpoint structure it for agent consumption.

Keep reading

agent-readable feedback

What to include in a bug report

Jul 2026 · 7 min

Claude Code

How to give Claude Code access to user feedback

Jul 2026 · 7 min

Point an agent at your first bug.

Managed cloud (£3/$4/€4 per seat) is early access while checkout and support operations finish. Bring your own AI.