Solutions · Product

The evidence, gathered — so the decision is yours to make.

Feedback arrives in six places and gets read in none of them. An agent reads all six, groups what is actually the same request, writes the spec against the real quotes, and cites every one of them. 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, summaries — as files
Cites
The source behind every claim
Decides
Nothing. That part is still yours
The handoff

Reading everything, so you can think about something.

The product job degrades into an inbox. Four hundred tickets, three channels, a tracker somebody stopped grooming in April, and a nagging sense that the thing you are about to prioritise was already asked for in a thread you never saw.

  1. 01

    Feedback synthesis that survives a challenge

    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.

  2. 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 already. It is a draft to argue with, not a plan to accept.

  3. 03

    The tracker, kept honest

    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.

  4. 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 register. The two lists differ more often than anyone admits.

  5. 05

    The competitive watch

    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.

  6. 06

    The pre-read for the review

    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.

The output

A document with its sources in it.

A synthesis you cannot check is a synthesis you should not trust. So every grouping carries the tickets underneath it and every claim about what people want carries the thing a person actually said.

specs/2026-07-bulk-export.mdDocument

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 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.

Illustration. The tickets, accounts and paths are fictional.

Every grouping 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 is a disagreement you can settle by reading rather than by re-doing 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 the serialisation is done and the pagination is not is worth an order of magnitude 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. Product decisions do not get made by an agent here — the point is that the reading is done before you make one.

Where it reaches

The places feedback actually lands.

Product feedback does not live in one system, which is the entire problem. Connect each source once for the project; the credential is resolved on our side of the wall and never enters the machine.

Linear
Read the tracker as it really is — issues, states, links, comments — and write back the groomed result where you allow it to. The tracker stays the system of record; the agent is not a second one.
GitHub
Issues, discussions and what actually merged. This is where release notes come from, 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 are where the highest-signal feedback is and the lowest-signal summaries get made.
Notion and Google Drive
Where specs, research and the last six months of decisions live. It reads them as prior art so a new draft does not re-litigate something settled in March.
Slack
The one live channel. The thread where a customer complaint got pasted 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 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.

How it runs

Ask before the meeting. Run it every Monday.

The same session machinery started three ways. Product work is mostly reading, which makes the scheduled mode unusually valuable here.

  1. 01On 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.

  2. 02Human-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 the call, showing you exactly which issues it wants to merge or close, and resumes from there when you approve.

  3. 03Automated

    The Monday digest and the release note

    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.

Control

It gathers. You decide.

The failure mode for a product agent is not a bad merge. It is a confident summary of something nobody said. So the controls here are about traceability as much as about permissions.

A claim without a source is a bug
The synthesis format carries the tickets behind every group and the quote behind every assertion. That is a convention you enforce in a skill file in your repo — versioned, diffable, and improved through a change someone reviews.
Approval gates are off until you set them
The shipped default is permissive: an action runs unless you have said otherwise. Set Ask on anything that writes to the tracker and Block on anything that deletes from it. We are stating the real default rather than the comfortable one.
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 has granted project.cr.merge in kortix.yaml, and widening the grant is itself a reviewed change.
Connector credentials never enter the machine
The sandbox carries one project-scoped Kortix token and no third-party keys. Your tracker and helpdesk credentials are decrypted server-side and attached to the outbound call.
What it learns is a file, not a black box
The conventions, the 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 the day the output changed.

The same platform, the other teams

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.

All solutions →
Product

Do the reading. Keep the deciding.

Open source and self-hostable. Any model, your keys. Kortix Cloud, your own VPC, or your own on-prem network.

Kortix for product teams