What is a PRD, and why agents need one

"PRD" is one of those acronyms that sounds like process overhead — a document you write to satisfy someone, then never read. In AI development it's the opposite: it's the difference between an agent building the thing you wanted and an agent building something plausible that misses the point. And agents need one more than human teams ever did.

Here's what a PRD actually is, why it matters even more when an agent is doing the building, and how it relates to the prompts and briefs you already use.

What a PRD is

A PRD — product requirements document — is a written description of what to build and why. A good one answers a few plain questions: what problem it solves, who it's for, what it must do, what it must not do, and how you'll know it worked.

That's it. It's not a spec in the sense of every implementation detail. It's the intent — the source of truth that keeps everyone building the same thing. Strip away the corporate baggage and a PRD is just: here's what you're making, and here's how you'll know you got it right.

Why agents need requirements, not vibes

Here's the thing that surprises people coming from "just chat with the AI." An agent is more dependent on clear requirements than a human team, not less.

A human handed a vague ask will push back — "wait, what about refunds?", "do users have accounts?". An agent mostly won't. Handed a vague ask, it makes an assumption and builds confidently on it. The result looks finished and is subtly wrong, because the requirements it needed were never stated, so it invented them. The teams writing PRDs specifically for AI code generation keep finding the same thing — the agent's output quality is downstream of how clearly the requirements were written.

Stuart Leo

A human with a vague brief asks questions. An agent with a vague brief makes assumptions — and builds on them, confidently.

What a good PRD contains

A PRD that's actually useful to an agent is tight, not long:

• The problem and who it's for. Why this exists, for whom.
• What it must do. The core requirements, in plain language.
• What it must not do. The boundaries — often more useful than the requirements, because they stop the agent over-building.
• Decisions and constraints. "Payments via this provider." "No user accounts yet." The choices already made, so the agent doesn't undo them.
• How you'll know it worked. The acceptance criteria — ideally things you can run.

Notice none of that is implementation detail. It's intent and boundaries. The agent figures out the how. The PRD nails the what and the why.

PRD vs prompt vs brief

These three get tangled, so here's the clean split:

The PRD decides. The brief scopes a piece of that decision into something an agent can build in a session. The prompt is just the message inside the work. In C², these stack — a PRD cascades down into briefs, which the agent executes. (That flow is the Cascade.)

Your first PRD

You don't need a template or a tool. Open a file and answer the questions: what am I building, for whom, what must it do and not do, what decisions are already made, and how will I know it worked. A page is plenty. Commit it to your contextbase.

That page is the thing that keeps your agent building the right feature instead of a plausible one. An agent without a PRD builds something plausible — a PRD is how you make sure it builds the right thing.

Start here: learn to write a PRD with an agent, see the Cascade from PRD to brief, or read the method.