A Feedback Board for AI Agents: Let Your Users Write the Prompt

A user writes to you at 11pm. "The export button does nothing on Safari."

You know what happens next, because it has happened a hundred times. You read it. You understand it. Then you open a tracker and type it again, in your own words, with the file paths and the reproduction steps and the context the user did not have. Then, later, you open a terminal and type it a third time, as a prompt.

Three writings of the same request. The first one was free and came from the person who actually hit the bug. The other two are yours.

That second and third writing is the part of the job that agents made absurd.

The last thing you still type by hand

Coding agents removed a lot of typing. They did not remove the brief. Something still has to tell the agent what to build, in enough detail that it does not guess, and that something is still a human sitting at a keyboard converting other people's words into instructions.

Except the conversion is often pointless. A good bug report already contains what an agent needs: what was expected, what happened, on which page, in which browser. A good feature request already contains the intent and the reason. The person who wrote it was closer to the problem than you were.

What we do instead is treat that text as raw material to be reprocessed, because the tool that collected it and the tool that executes work were never the same tool. Feedback lives in one product, tickets in a second, and the agent runs in a terminal that knows about neither.

Remove the gap and the rewriting step has nowhere to happen.

What a feedback board becomes when the board can execute

A public backlog is a page your users can reach. They report a bug, request a feature, upvote what someone else asked for, follow a thread, and watch a status change. So far this is a feedback board, and there are good ones.

The difference is where the ticket lands. It does not land in a feedback product waiting to be exported. It lands in the task board your agents already run from, as a first-class ticket, next to the ones you wrote yourself.

From there, moving it into In Progress spawns an agent whose brief is the ticket: the title, the description in the reporter's own words, the page they were on, the browser they used, and the conversation you have had with them since. Nobody rewrote anything. The prompt is the report.

The interesting consequence is not speed. It is that the person who described the problem is now the person who specified the work, which is what everybody claims to want from user feedback and almost nobody structures for. That inversion has a name, and it is a client-driven backlog: the queue stops being your guess about what matters and becomes a record of what was actually asked for.

Three doors, because people report where they are

A feedback board only works if reporting costs less than complaining somewhere else. That means meeting people where the problem happened.

The public page is the obvious door: a URL you share, with a list or a roadmap view, upvotes, and a form. It works for a product with users who will bookmark it, and it doubles as visible proof that the work is moving, which is worth more than a status email nobody reads.

The embeddable widget is the second: a small script on your own site that opens a form in place. The person never leaves the page where the bug is, which is exactly when they are most willing to describe it.

The Chrome extension is the third, and it is the one that changes behavior the most. Your user selects the broken text on any page, clicks the extension, and the ticket is filed with the URL and the selection already attached. What you receive is not "it does not work", it is a report with coordinates.

For an agency, the third door is usually the client themselves, and the client portal mode is invite-only: one board per client, nobody else can see it, no extra SaaS subscription in the stack.

Routing, because "the right agent" is not one agent

An incoming ticket is not addressed to anyone. That is the practical problem with any inbox: someone has to decide who takes it.

Tickets arriving from outside get routed to the agent whose specialty matches, so a broken layout goes to a frontend specialist and a leaking query goes to a backend one, without you triaging the queue by hand every morning. When nothing is configured, the fallback is deliberately dumb and predictable: the first development agent in the project, never a marketing or PM role that happens to sit at the top of the list.

You can also point a ticket at a whole team of agents instead of a single one, so that a client request goes through a dev step and then a QA step before it reaches you.

The part everyone forgets: what the reporter sees back

Collecting feedback is easy. Closing the loop is where products lose people.

When a ticket moves into development, its author is told. When it is prioritized, they are told. When you decide you will not do it, they are told, with the reason you wrote, which is far better than silence. And when the fix actually ships, they get a message that says so, grouped into one notification per release rather than five separate emails for five tickets.

There is a smaller detail that matters more than it looks: the commit that closes a user ticket credits its reporter by first name, and that credit survives into the public changelog. People who see their name attached to a shipped change report the next bug too. That is the entire retention mechanism, and it costs nothing. Run that loop for a few months and you get feedback-driven development as an observable fact rather than a slogan: the upvotes decide the order, and the order decides the releases.

If a request arrives vague, ticket scoping sits between the report and the work: a Product Manager agent turns the fuzzy request into a mockup of your actual product with the change applied, so you validate the idea on the same ticket before a line of code is written.

Where the classic tools stop

This is not a knock on the incumbents. Canny, Featurebase, Fider and UserVoice do collection, deduplication and ranking well, and they have years of polish on the parts that matter to product teams. They stop in the same place for the same structural reason: they were built for organizations where engineering is a different department, reachable only through an export.

The last row is the one that decides. On a large team, rewriting a request into a spec is a real job with real value, and the export is not the bottleneck. On a team of one to five people shipping with coding agents, that rewriting is the bottleneck, and it is pure loss.

What this does not solve

A feedback board wired to agents is not an autopilot, and treating it as one produces exactly what you would expect.

Bad tickets still produce bad work. A one-line report with no reproduction path gives an agent nothing to work with, and it will confidently do something wrong. The board can only pass along what was written.

Nothing merges itself. An agent produces a branch and a diff, and every rule you had about reviewing agent output still applies, especially for anything touching authentication, payments or data. A ticket from a stranger is not a reason to lower that bar. It is a reason to raise it.

And volume is real. A public board that succeeds gets noisy, which is a good problem with a real cost. Duplicates get flagged when they are submitted, upvotes separate what one person wanted from what forty people wanted, and closing a ticket with a written reason is faster than letting it rot. But someone still reads the inbox.

Setting it up

Open the backlog of a project, click Public backlog, pick a URL and a visibility mode. That is the whole setup, and the page is live at that point.

What you do next matters more than the setup. Put the link where your users already are: in the app, in your support replies, at the bottom of your release notes. A feedback board nobody knows about collects nothing, and the failure mode of this feature is not technical, it is that the link never gets shared.

AgentsRoom is the command center this runs on: a task board where a card becomes a running agent, a public or private feedback page wired into it, an embeddable widget, a Chrome extension, and client notifications that fire when the work actually ships. It works with Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe and Kimi Code.

Download AgentsRoom and publish your first board.

Frequently asked questions

What is a feedback board for AI agents?

A public page where users report bugs and request features, wired to the same task board your coding agents execute from. The difference with a classic feedback tool is the last step: instead of exporting the request to a tracker and rewriting it as a prompt, the ticket itself becomes the agent's brief, in the words the reporter used.

Can a user ticket really start an AI agent on its own?

Starting stays a deliberate act: someone moves the ticket into In Progress, and the agent spawns with the ticket as its prompt. What is automatic is the routing, which sends an incoming ticket to the agent whose specialty matches it. Full auto-execution of anything a stranger writes is not a feature, it is a security hole.

How is this different from Canny, Featurebase, Fider or UserVoice?

Those are excellent at collecting, deduplicating and ranking demand, and they all stop at the same place: they hand you a prioritized list, and a human still turns each line into work. They have no execution layer because they were built for product teams whose engineers are elsewhere. The bet here is the opposite one: the collection surface and the execution surface are the same object.

Do you have to make your roadmap public to use it?

No. Public, unlisted and invite-only are three separate modes. An agency running one board per client uses invite-only and no search engine ever sees it. A solo developer who wants requests and upvotes from users uses public. The execution part works the same in all three.

What stops a public board from filling up with noise?

Nothing stops the noise from arriving, and pretending otherwise would be dishonest. What the board changes is the cost of handling it: near-duplicates are flagged on submission, upvotes tell you what is actually wanted, and a ticket you will not do is closed with a reason that reaches its author. The tickets you do keep arrive with the context a stranger already wrote for you.