Solutions · Product
It gathers the evidence.You make the call.
Feedback lands in six places and gets read in none of them. An agent reads all six, groups the requests that are really the same, drafts the spec from the real quotes, and cites every one. You decide what to build. It does the reading.
Every claim cites the ticket it came from · drafts, never decisions
- Reads
- Tickets, threads, the tracker, the repo
- Writes
- Specs, notes and summaries, as files
- Cites
- The source behind every claim
- Decides
- Nothing. That part is still yours
01The handoff
It reads everything, so you can think.
Product work slowly turns into an inbox. Four hundred tickets, three channels, a tracker nobody has groomed since April, and a nagging feeling that the thing you are about to prioritise was already asked for in a thread you never saw.
Job 01
Feedback synthesis that holds up
It groups requests by what people actually want, not the words they used, counts how many separate accounts raised each one, and attaches the quotes. When someone asks "who asked for this", the answer is in the document.
Job 02
The first draft of the spec
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. It is a draft to argue with, not a plan to accept.
Job 03
A tracker that tells the truth
Duplicates merged, stale items surfaced, issues closed when their linked change request shipped three weeks ago. A backlog that is 40% archaeology is not a backlog.
Job 04
Release notes from the actual diff
It reads what merged since the last release, not what the tickets promised, and writes the note in your voice. Those two lists differ more often than anyone admits.
Job 05
The competitive watch
A scheduled session reads what changed in public, says what is truly new, and says plainly when nothing is. A weekly digest that invents a finding every week stops being read by month three.
Job 06
The pre-read for the review
Before the roadmap meeting: what moved, what slipped and why, and which assumptions in the last spec turned out wrong. Built from the tracker and the repo, not from memory.
02What comes back
A document with its sources inside.
A synthesis you cannot check is a synthesis you should not trust. So every group carries the tickets under it, and every claim about what people want carries what a person actually said.
Bulk export: draft spec
- Sources
- 31 tickets · 9 threads
- Accounts
- 14 distinct
- Status
- Draft · for review
- Prior art
- packages/export/
Fourteen accounts asked for the same thing in three different ways: "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. They are split out below and not counted in the total.
Prior art: packages/export/ already streams a single record set. The gap is pagination across the account, not serialisation, which shrinks this from a quarter to a fortnight.
Every group opens up
A cluster is not a claim, it is a list. The document carries the tickets behind each group, so a disagreement about the synthesis gets settled by reading, not by redoing the work.
It has read the codebase too
The session clones the repo, so the spec can say what already exists. A draft that knows serialisation is done and pagination is not is worth far more than one written from tickets alone.
It is a draft, and it says so
The document lands as a change request against main, marked as a draft. An agent does not make product decisions here. The point is that the reading is done before you make one.
03Where it reaches
Everywhere feedback actually lands.
Product feedback never lives in one system, and that is the whole problem. Connect each source once for the project. The credential is resolved on our side and never enters the machine.
Linear
Read the tracker as it really is: issues, states, links, comments. Write the groomed result back where you allow it. The tracker stays the system of record. The agent does not become a second one.
GitHub
Issues, discussions and what actually merged. Release notes come from here, because the diff is the only honest record of what shipped.
Zendesk, Intercom and the rest of the support stack
In the Easy connect catalogue: click through the OAuth screen and the connection belongs to the project. Support tickets hold the best feedback, and the worst summaries of it.
Notion and Google Drive
Where specs, research and six months of decisions live. It reads them as prior art, so a new draft does not reopen something you settled in March.
Slack
The one live channel. The thread where someone pasted a customer complaint is often the only place that complaint exists, and a mention in that thread starts a session on it.
Easy connect covers 3,000+ apps through their own OAuth screens. If your feedback lives somewhere outside the catalogue, like a community forum or an in-house portal, reach it through OpenAPI, GraphQL, raw HTTP or a remote MCP server instead.
04How it runs
Ask before the meeting. Run it every Monday.
The same session, started three ways. Product work is mostly reading, which makes the scheduled mode especially useful here.
01 · On demand
"What has anyone said about export?"
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.
02 · Human-assisted
It stops before it touches the tracker
Reading a tracker and rewriting it are different actions. Set the write to Ask and the run holds at that call, showing you exactly which issues it wants to merge or close. Approve it and the run carries on from there.
03 · Automated
The Monday digest and the release note
One cron trigger writes the weekly synthesis. A signed webhook from your release process starts a session that drafts the notes from the diff. Both land as documents someone reviews.
05Control
It gathers. You decide.
For a product agent, the failure is not a bad merge. It is a confident summary of something nobody said. So the controls here are as much about tracing every claim as about permissions.
01
A claim without a source is a bug
The synthesis format carries the tickets behind every group and the quote behind every claim. You enforce that in a skill file in your repo: versioned, diffable, and improved through a change someone reviews.
02
Approval gates are off until you set them
The shipped default is permissive: an action runs unless you said otherwise. Set Ask on anything that writes to the tracker and Block on anything that deletes from it. That is the real default, not the comfortable one.
03
Merge is default-deny
Specs, notes and research land on the session branch and reach main through a change request. An agent cannot merge unless an admin grants project.cr.merge in your project config, and widening that grant is itself a reviewed change.
04
Connector credentials stay out of the machine
The sandbox carries one project-scoped Machine token and no third-party keys. Your tracker and helpdesk credentials are decrypted server-side and attached to the outgoing call.
05
What it learns is a file you can read
Your conventions, your taxonomy, the way your team words a release note. All of it lives in the repo as markdown. You can read it, edit it, and diff what changed on the day the output changed.
06Other teams
Same machine. Every other team.
One project, one set of connectors, one memory that keeps growing. Each team writes the skills for its own work. Nobody builds a second system.
- SalesResearch, drafts and CRM cleanup, held for your yesOpen
- MarketingProduction work in your voice, because the voice is a fileOpen
- EngineeringReproduce it, patch it, open the change requestOpen
- FinanceThe close, the reconciliation and the variance note, with the working shownOpen
- PeopleScheduling, kits and onboarding, never the hiring decisionOpen
- ITRunbooks that run, and a platform that passes your reviewOpen
- Data ScienceA real machine, a real query, an analysis you can re-runOpen
- All solutionsEvery team on one page, plus the rules that never change between them.Open
Product
Hand off the reading.Keep the deciding.
One governed platform for product agents. Any model, your keys. Every action recorded.
- One machine per session
- Lands as a change request
- Every action recorded