A sourced PRD draft in minutes, not days of manual writing.
Sagent turns a folder of product research (interview notes, specs, meeting docs) into a draft PRD, with every requirement linked back to the line it came from.
A separate step scores the draft against a rubric, flags what's missing or unsupported, and rewrites weak sections before you see it. You review, iterate with the AI, and finalize by hand when it's ready.
10 steps: 3 of them agents making real decisions, the rest deterministic.
I’m a PM who learned to build so I could stop describing the product I wanted and just ship it. Sagent is a rebuild of an earlier automation I built in n8n, nicknamed “PRD Genie”: it proved a pipeline that ingests research, extracts requirements, and self-evaluates the result, but it lived inside n8n and hit real limits I couldn’t fix there. This is that idea rebuilt as an actual product surface, and built deliberately as a portfolio piece: I wanted a place where an interviewer could see the reasoning, not just the output.
This app, like the rest of the [sage] suite, was built in close collaboration with Claude: I made the product and architecture calls, reviewed every change, and pushed back when the AI’s first answer wasn’t good enough. The build process is the same discipline the product itself is arguing for: AI does real work, but a human stays in the loop and nothing ships without a second look.
Connect on LinkedInWhat It Is
Why not just paste your notes into ChatGPT?
Connect a folder of research (interview notes, data exports, meeting docs, PDFs) or upload files directly. Run the pipeline and get a draft PRD where every requirement traces back to a source. Iterate with the AI by answering its clarifying questions, adding direction, and adjusting the file list. When it's ready, finalize it and switch to manual rich-text editing. Every version is saved and diffable the whole way through.
That question comes up with almost every reader. A raw chat prompt doesn't ground its claims in a real source. It won't tell you where a draft is weak. Nothing is versioned, so there's no diff and no protection for an edit you made an hour ago. And it isn't sitting on your actual research. You're re-pasting into the same blank box every time. Sagent closes those four gaps: grounding, evaluation, versioning, and a live research source.
“Sagent” (Sage + Agent) is one app, not a suite of separate tools. PRD generation is the first feature; prioritization and roadmap tooling come next, built as features inside this same app rather than spun off into new products. It’s already structured for that: shared auth, storage, and shell. So the next feature is additive, not a rewrite.
How It Works
The core loop
- 1Sign in with Google, connect a Drive research folder, upload files directly, or browse Jira issues and Confluence pages (seeded from a real workspace, read-only for now).
- 2Every file found is listed with a checkbox, checked by default. Uncheck to exclude anything before running.
- 3A sufficiency check runs before anything drafts. If the research doesn't add up to enough, you get specific questions to answer instead of a guessed draft, with a Generate anyway option if you'd rather push through.
- 4Run. A streaming progress view narrates each pipeline stage. Output: a draft PRD, an evaluation panel, and source attribution.
- 5Review the draft alongside the evaluation panel: quality score, gaps, unsupported claims, and the AI’s clarifying questions.
- 6Iterate: answer the clarifying questions, add free-text direction, adjust the file list, and re-run. Each run is a new version, diffed against the last.
- 7Repeat step 6 as many times as it takes.
- 8Finalize. The draft locks, and manual rich-text editing opens up, with autosave.
- 9Returning to AI from manual mode forks a new version. Hand-written edits are never overwritten.
- 10Export the finalized PRD to a Google Doc or Markdown download. (Export to Jira is a labeled stub. See Build Decisions.)
The Pipeline
Three agents, seven plain steps
Ten steps turn raw files into a finished PRD, and three of them are agents. The other seven (extracting text, deduping near-identical requirements, synthesizing findings, checking for gaps before drafting, drafting sections, checking for roadmap conflicts, saving the result) run the same way every time, because there's no real decision to make. The three agents exist only where a judgment call is required. One decides which documents are worth reading and when it's read enough. One decides which of two conflicting requirements to keep, or flags the conflict for a human. One scores the draft and decides whether to rewrite a section or look for more evidence before handing it back. That split follows Anthropic's own framework for agent design: fixed workflows for predictable steps, model judgment only where the path genuinely branches.
Here's every step in order:
- 1Extract textPulls raw text out of every uploaded file or Drive doc.
- 2Research AgentAgentDecides which documents to read and when it's covered enough.
- 3DedupeMerges near-duplicate requirements by similarity. No LLM call.
- 4Contradiction Resolution AgentAgentDecides which of two conflicting requirements wins.
- 5SynthesizeOne call turns the requirements into a product understanding.
- 6Gap checkOne call asks whether anything important is missing before drafting. If it is, the run stops and asks me instead of guessing.
- 7GenerateOne call drafts the 12-section PRD.
- 8Critique AgentAgentScores the draft and decides what's worth fixing before it's shown to me.
- 9Roadmap signalOne pass flags sequencing risk and scope conflicts. It's not a priority score.
- 10PersistSaves the version, the evaluation, and every source attribution.
The three agents are the only steps where the model makes a real decision. Here's what each one is actually deciding:
It decides which documents are worth opening, and when it's read enough. It looks at a short preview of each file and judges whether it's likely to hold anything new, versus a duplicate, a cover page, or generic boilerplate. It opens one, weighs what it found, then decides again: read another, or call the folder covered. It can't call the folder covered, though, until it has actually opened and read through at least one document on its own.
It decides which of two conflicting requirements wins, or admits it can't tell. Say one document says onboarding is three steps and another says five. Before it answers, it checks which file looks newer or more official, or searches the rest of the research for something that settles the tiebreaker. It only gets two of those checks. If neither turns up a real answer, it hands the conflict back to me as a specific, answerable question instead of just taking a guess.
It decides whether the draft is good enough, or needs a targeted fix before I see it. It reads the draft the way an editor would: what's missing, what's an unsupported claim, what's still vague. Below the quality bar, it can rewrite one weak section or go dig up evidence it missed, then score its own fix. It gets up to three passes, and it has to name the exact problem each fix is meant to close, not just tidy up a section with no clearly stated reason to point to. It actually runs this judgment twice now, not once. Before a draft exists, it checks whether the research itself is thin, and blocks with specific questions instead of letting a guess through, with a Generate anyway override for anyone who'd rather proceed. After a draft exists, it's the rewrite-or-search loop described above.
Three real agents in a nine-step pipeline, not nine. An agent making its own call is a real design choice, not free branding for a function that just runs once.
Every run picks one model, Haiku by default, Sonnet when I want stronger reasoning for a denser or messier source set. I choose it per run, not per stage. All three agents run on whatever I picked; they don't renegotiate mid-run.
What it does
Every requirement traces back to the file it came from.
A labeled source chip per key feature. Hover for the exact quote.
A quality score, missing sections, and unsupported claims, shown, not hidden.
Evidence coverage, citation accuracy, and contradictions resolved: three counts pulled from stored data, not another AI opinion.
The AI asks specific, answerable questions instead of a blank re-run box.
Every run is saved. Diff any two versions section by section.
Iterate with AI, finalize, then edit by hand, with autosave.
Pull research straight from a Drive folder, or upload files directly.
Google Doc or Markdown today; Jira mapping defined, shipping later.
Flags sequencing risk and scope conflicts across your own features. Never a fake priority score.
Browse real Jira issues and Confluence pages as research, seeded from a real workspace, read-only for now.
Pick a section layout at project creation: Standard, Lean/MVP, or Enterprise/Compliance-Heavy.
Draft, In Review, Approved, gated by a PM/Lead PM/Approver role switcher.
A public page naming exactly what's simulated here versus what real enterprise use would need.
Every requirement traces back to the file it came from.
A labeled source chip per key feature. Hover for the exact quote.
A quality score, missing sections, and unsupported claims, shown, not hidden.
Evidence coverage, citation accuracy, and contradictions resolved: three counts pulled from stored data, not another AI opinion.
The AI asks specific, answerable questions instead of a blank re-run box.
Every run is saved. Diff any two versions section by section.
Iterate with AI, finalize, then edit by hand, with autosave.
Pull research straight from a Drive folder, or upload files directly.
Google Doc or Markdown today; Jira mapping defined, shipping later.
Flags sequencing risk and scope conflicts across your own features. Never a fake priority score.
Browse real Jira issues and Confluence pages as research, seeded from a real workspace, read-only for now.
Pick a section layout at project creation: Standard, Lean/MVP, or Enterprise/Compliance-Heavy.
Draft, In Review, Approved, gated by a PM/Lead PM/Approver role switcher.
A public page naming exactly what's simulated here versus what real enterprise use would need.
Build Decisions
The choices that define the product
An agent only runs where there's a real branching decision: which document to read next, which of two conflicting requirements wins, whether a section needs a rewrite. Everything else stays deterministic on purpose. Autonomy costs predictable runtime and easy debugging, so it's spent only where a fixed script can't do the job. All three agents share the same guardrail contract, too. Each one has an explicit stopping condition (a hard cap, a quality threshold, or a diminishing-returns signal like two failed lookups in a row) and a defined failure behavior: fall back to a deterministic path, or hand it to me. None of them just run until it feels done.
Every requirement and key feature ties back to the source file it came from, and the exact quote. That's checked mechanically in code, not just prompted for. A PRD that invents requirements is worse than no PRD at all.
The critic’s self-score, missing sections, unsupported claims, and clarifying questions are shown in the UI, not buried in a log. You see exactly where the draft is weak and what to feed it next, instead of just getting a finished-looking document.
While iterating, every change comes from an AI re-run, so there's nothing manual to lose. Clicking Finalize locks the draft and switches to manual rich-text editing. Sequencing the two modes instead of merging them removes the hardest conflict in a tool like this: human edits colliding with AI regeneration.
Every AI run creates a new version, and any two versions can be diffed section by section. Returning to AI after a manual edit forks a new version instead of overwriting it. That's enforced at the database level, not just app logic. Nothing written by hand is ever silently lost.
PMs already keep research in Drive. Sign-in is Google OAuth; a selected Drive folder, or a direct upload, becomes the source corpus. The tool works on your actual research instead of asking you to paste it in fresh every time.
One more pass over the finished PRD's own features, checking for two things: features that quietly depend on each other, and features that contradict a stated goal or non-goal. No invented priority order, no effort estimate. The input doesn't support either. It's also deliberately not a fourth agent: there's no real decision to make here, just a structured read, so it stays one plain call instead of dressing up a formality as agentic.
PM/Lead PM/Approver roles, a review workflow, org-controlled PRD templates, and Jira/Confluence as research sources are all real, working UI on real data. None of it is backed by real multi-tenancy, server-enforced permissions, or a live Atlassian connection, and I say so directly rather than let the demo imply otherwise. The Enterprise Roadmap page names exactly what each one would need for a real deployment.
Multiplayer editing, write-back to Drive, billing, and a live (not read-only) Jira integration are still out of scope. Each would add real surface area without strengthening the core story this build is making.
What’s Next
From fixed pipeline to conversation, then to team
Today, the interaction model around the 3 agents is still fixed: my own code calls each loop in the same order, every run. One PM, one PRD, no way to ask for something ad hoc mid-run. Making that conversational is a different agentic problem than building the loops themselves: instead of my code deciding which loop runs next, the agent has to decide, picking research, resolve, or critique dynamically, mid-conversation. That needs a guardrail none of the three loops need today: scoping which tools are callable on a given turn, and capping how long a tool-call chain can run before it has to stop and answer. Two things change from here, and the order was deliberate. The interaction model moves first, from a fixed pipeline to something you actually talk to, because it reuses everything already built and needs no new permissions plumbing. The audience comes second: single-user to team is the heavier, less differentiated work.
Next: a conversational layer. You shape and interrogate your own PRD in natural language, with prompts like “does this cover offline?” or “add a non-goal about theming,” grounded in the same research corpus. The pipeline’s existing agent loops (research, resolve, critique) become callable tools an agent reaches for dynamically, instead of our code calling them in a fixed order.
The team direction got a first pass too, honestly scoped. Role-gated actions (PM, Lead PM, Approver), a Draft/In Review/Approved workflow, and org-picked PRD templates all shipped as real UI over real data. None of it is backed by an actual multi-tenant system: the roles live in your browser, not a real member table, and there’s no server check behind any of them. That was a deliberate choice, not a corner cut I’m hoping nobody notices. Building real enforcement for an app with one real user would protect nothing, so I built the workflow in full and said exactly what a real deployment would still need. Jira and Confluence already work the same way as research sources, seeded from a real workspace rather than invented, with no live connection and no write-back yet. The Enterprise Roadmap page names all of this directly, gap by gap.
Still ahead: the real version of each. An actual organization table with server-enforced permissions, tied to SSO instead of a toggle. A live, two-way Jira and Confluence connection, not a read-only preview. The agent proposing an action (create a ticket, notify an owner) where the team already works, always behind an approval gate, never automatically. No design work has started on any of this; it’s the direction, not a commitment.
Built With
Under the hood
Libraries & frameworks
- Next.js (App Router): server components, streaming, and Server Actions for the whole app
- TipTap: the rich-text editor behind manual edit mode, with autosave
- Claude API: requirement extraction, synthesis, generation, and evaluation with structured tool-use schemas, so output is always machine-readable.
- Zod: schema-validated structured outputs at every pipeline stage
- diff: section-by-section version diffing
Platforms & services
- Supabase: Postgres, Auth, and Storage, with row-level security scoping every table to its owner
- Vercel: hosting, with a streaming route for the multi-minute pipeline run
- Google Drive API: reading the research corpus and exporting finalized PRDs as Google Docs
- Langfuse: tracing every Claude API call across the pipeline, grouped into one trace per run
Say hello
I’m open to conversations about PM roles, ideally somewhere the product surface is genuinely complex and the team ships with intention.
If that describes where you’re hiring, I’d like to connect.
