Feedback arrives in six places and gets read in none of them. The agent reads all six, groups the requests that are really the same, and writes the spec with every quote cited. You decide what to build.
Bulk export — draft spec
Fourteen accounts asked for the same thing in three different vocabularies: "bulk export", "give me a CSV", and "the API is too slow for a backfill". They are one request.
Two of the fourteen do not want an export at all. They want a scheduled delivery, and an export button would not close their ticket. Those two are separated out below rather than counted toward the total.
Prior art: packages/export/ already streams a single record set. The gap is pagination across the account, not serialisation — which changes the size of this from a quarter to a fortnight.
The product job turns into an inbox. Four hundred tickets, three channels, a tracker nobody has groomed since April, and the feeling that the thing you are about to prioritise was already asked for.
It clusters requests by what people actually want rather than by the words they used, counts how many distinct accounts raised each one, and attaches the quotes. When someone asks "who asked for this", the answer is in the document.
Written from the evidence and from the code that already exists — it reads the repo, so the draft knows which of the three proposals is nearly built already. It is a draft to argue with, not a plan to accept.
Duplicates merged, stale items surfaced, issues whose linked change request shipped three weeks ago closed. A backlog that is 40% archaeology is not a backlog.
It reads what merged since the last release, not what the tickets promised, and writes the note in your register. The two lists differ more often than anyone admits.
A scheduled session reads what has publicly changed, says what is genuinely new, and says plainly when nothing is. A weekly digest that manufactures a finding every week is a weekly digest nobody reads by month three.
Before the roadmap meeting: what moved, what slipped and why, which assumptions in the last spec turned out wrong. Assembled from the tracker and the repo rather than from memory.
A synthesis you cannot check is one you should not trust. So every group carries the tickets underneath it, and every claim carries the words someone actually wrote.
Fourteen accounts asked for the same thing in three different vocabularies: "bulk export", "give me a CSV", and "the API is too slow for a backfill". They are one request.
Two of the fourteen do not want an export at all. They want a scheduled delivery, and an export button would not close their ticket. Those two are separated out below rather than counted toward the total.
Prior art: packages/export/ already streams a single record set. The gap is pagination across the account, not serialisation — which changes the size of this from a quarter to a fortnight.
A cluster is not a claim, it is a list. The document carries the tickets behind each group, so a disagreement about the synthesis is a disagreement you can settle by reading rather than by re-doing the work.
The session clones the repo, so the spec can say what already exists. A draft that knows the serialisation is done and the pagination is not is worth an order of magnitude more than one written from tickets alone.
The document lands as a change request against main, marked as a draft. Product decisions do not get made by an agent here — the point is that the reading is done before you make one.
Product feedback never lives in one system, which is the whole problem. Connect each source once for the project. Credentials are resolved on our side, never in the machine.
Easy connect covers 3,000+ apps through their own OAuth screens. If your feedback lives somewhere that is not in the catalogue — a community forum, an in-house portal — it is reachable through OpenAPI, GraphQL, raw HTTP or a remote MCP server instead.
Three ways to start the same session. Product work is mostly reading, which makes the scheduled one unusually useful.
Ask in a Slack thread. The session reads across the tracker, the tickets and the threads, and answers in the same thread with the document attached.
Reading a tracker and rewriting it are different actions. Set the write to Ask and the run holds at the call, showing you exactly which issues it wants to merge or close, and resumes from there when you approve.
One cron trigger writes the weekly synthesis. A signed webhook off your release process starts a session that drafts the notes from the diff. Both land as documents someone reviews.
The risk here is not a bad merge. It is a confident summary of something nobody said. So these controls are about evidence as much as permissions.
One project, one set of connectors, one memory that compounds. Each team writes the skills for its own work; nobody stands up a second system.