What an Agent PRD Contains That a Feature PRD Doesn't

A feature PRD documents what to build and how success looks; an agent PRD must also specify the boundaries of autonomous behavior, every plausible failure mode, exactly when the agent escalates to a human, and the evals that gate its release. The difference isn't length — it's a whole category of section that a static feature has no need for.

Quick Answer: An agent PRD keeps the feature PRD's problem, users, and success-metric sections, then adds behavior boundaries, a failure-mode inventory, escalation rules, eval criteria, and staged rollout gates — because an agent makes decisions at runtime that a feature spec never has to.

Why a Feature PRD Can't Cover an Agent

A feature PRD works because the thing it describes is deterministic once shipped: a button either shows a modal or it doesn't, and QA can verify every path. An agent PRD for writing PRD for AI agent work has to account for a system that chooses its own path at runtime, across inputs nobody enumerated in advance.

That gap is structural, not stylistic. A checkout flow has a fixed number of states a designer can draw. An agent that triages support tickets, drafts SQL, or negotiates a calendar slot has an effectively unbounded input space, and its behavior is probabilistic rather than fixed by if/else branches.

Three consequences follow directly:

1. You can't spec every path, so you spec the boundaries instead — what the agent is allowed to do, not every thing it will do.
2. Failure isn't a bug ticket, it's a first-class design surface — the PRD has to describe how the system behaves when it's wrong, not just when it's right.
3. "Done" isn't a merged PR — it's passing a defined eval bar, because there's no way to manually test every input the agent will see in production.

This is the same shift Anthropic describes in its guidance on building effective agents: the harder engineering problem isn't the model call, it's the surrounding scaffolding — tool access, guardrails, and the conditions under which the system asks for help instead of guessing.

Where the Agent PRD Model Comes From

None of this is invented for agents specifically. It borrows from decades of human-in-the-loop automation and safety-critical systems engineering, where "what happens when the automation is uncertain" has always been a first-class design question, not an afterthought.

NASA's human-automation function-allocation research and the aviation industry's cockpit automation standards both wrestled with the same core question long before "AI agent" was a product category: when should the system act, when should it ask, and when should it refuse. Agent PRDs are that discipline, applied to LLM-driven products.

Side-by-Side: Feature PRD Sections vs. Agent PRD Sections

A direct comparison makes the additions concrete rather than abstract. Below, the left column is a standard feature PRD outline; the right column is the same document adapted for an agent, with new sections in bold.

The pattern across every added row is the same: a feature PRD assumes a human reviewed every code path before ship, so it only needs to describe the happy path plus a short edge-case list. An agent PRD assumes nobody reviewed every path the model might take, so it has to describe the space of wrong answers as deliberately as the space of right ones.

Why Each Addition Exists, Not Just What It Is

• Goal + non-goals exists because an underspecified goal is the single most common cause of an agent doing something technically correct but practically wrong — for example, "reduce ticket volume" without a non-goal against auto-closing unresolved tickets. For a deeper walkthrough of getting this section right, see how to write an agent goal without drift.
• Tool access boundaries exist because an agent's blast radius is a function of what it can touch, not what it intends to do — the same argument underlying least-privilege agent tool access.
• Failure-mode inventory exists because "the agent might be wrong" is not actionable; "the agent might cite a stale price and confidently repeat it" is a spec-able, testable scenario.
• Escalation triggers exist because confidence in an LLM's own output is not reliable self-reported information — the PRD has to define externally-observable conditions that force a handoff.
• Eval suite exists because manual QA doesn't scale to an unbounded input space, so a pass/fail bar has to substitute for a test plan.

The Section-by-Section Agent PRD Template

An agent PRD reads best as feature-PRD sections a reader already recognizes, with the agent-specific sections inserted at the point they become relevant rather than bolted on at the end. Below is a working template you can adapt directly.

1. Problem & Context

Same as a feature PRD: what pain point, for whom, backed by evidence. State why an agent (versus a deterministic workflow or a simple form) is the right shape for this problem — this framing check matters, because plenty of "agent" ideas are actually a JTBD-style workflow problem in disguise. If the underlying job is well understood, ground it against the jobs-to-be-done complete guide before reaching for autonomy.

2. Goal, Scope & Non-Goals

State the agent's goal as a single outcome sentence, then immediately list what it is explicitly not trying to optimize. Non-goals are where most agent PRDs are thin, and where most agent incidents start.

• Goal: one sentence, outcome-framed, not task-framed ("resolve tier-1 billing questions," not "answer messages")
• In-scope inputs: the channels, data sources, and triggers the agent may act on
• Explicit non-goals: the adjacent things it must not attempt, stated as plainly as the goal

3. Behavior Boundaries & Tool Access

List every tool, API, or data source the agent can call, and — separately — what each one is not authorized to do. A read-only CRM lookup and a CRM write are different permission grants and belong in different rows of this section, not folded into "CRM access."

4. Failure-Mode Inventory

This is the section a feature PRD has no analog for. Rather than a short "known limitations" bullet list, build a structured taxonomy of how the agent can fail, ranked by likelihood and impact, following the same goal-tools-constraints-failure-escalation backbone laid out in the five-part agent spec structure.

1. Input failures — malformed, ambiguous, or adversarial user input
2. Reasoning failures — plausible-sounding but factually wrong output (hallucination)
3. Tool failures — an upstream API times out, rate-limits, or returns unexpected data
4. Scope creep — the agent attempts something adjacent to, but outside, its stated goal
5. Compounding failures — an earlier wrong step becomes the input to a later step

For a broader map of how these failure classes interact with multi-step agent design, the agentic workflows complete guide covers the underlying architecture patterns.

5. Escalation Rules

For every failure mode above, state the observable trigger condition and the handoff action — never "escalate when uncertain," since an LLM's uncertainty isn't a reliable signal a system can act on.

• Trigger: confidence score below threshold, tool call fails twice, user explicitly requests a human, or the request matches a defined out-of-scope pattern
• Handoff action: what the agent hands off (full context, partial draft, or just a flag), and to whom
• User-facing behavior: what the human sees during and after handoff — silence here erodes trust fast

6. Evals & Acceptance Criteria

Replace "acceptance criteria" with a concrete eval suite: a labeled test set, a scoring rubric, and a numeric bar the agent must clear before each rollout stage. State who owns updating the eval set as real traffic surfaces new edge cases — an eval suite that's frozen at launch stops reflecting reality within weeks.

7. Rollout Gates

Stage the launch itself around the eval scores above, not a single ship date — shadow mode against real traffic with no user-facing action, then limited release to a small cohort with human review of every action, then broader release with sampled review, each stage gated on holding the prior stage's eval bar.

What Doesn't Change Between the Two Doc Types

It's worth naming what stays identical, since it's easy to over-rotate and treat an agent PRD as an entirely separate discipline. The problem statement, target user, competitive context, and top-line success metric sections carry over unchanged — an agent PRD is a feature PRD with a harder middle, not a different document from scratch.

Where the two diverge further is upstream of the PRD itself: understanding the underlying customer job before deciding an agent is even the right solution shape benefits from the same rigor as any feature decision, including mapping the emotional highs and lows a user hits along the way — the kind of view the customer journey complete guide walks through.

Where Prodinja Fits

Writing this structure by hand in a generic doc tool means the failure-mode taxonomy, the escalation rules, and the eval gates live in separate places and drift out of sync as the agent changes. Prodinja's Spec Studio keeps the agent's behavior spec as a living PRD — comments and PR-style diffs attached directly to the sections that change, so a revised escalation rule doesn't quietly disconnect from the eval it's supposed to gate.

The Agentic Workflows tool in Prodinja's Studio is designed to walk a PM through the goal-tools-constraints-failure-escalation backbone directly, rather than leaving it to memory or a template nobody re-reads. It's built as the structured intake for exactly the sections this article lays out — goal and non-goals, tool boundaries, failure modes, and escalation triggers — so the agent PRD has a home that mirrors how the document actually needs to be reasoned about.

Key Takeaways

• An agent PRD keeps everything a feature PRD has — problem, users, metrics — and adds sections a static feature never needed.
• Non-goals matter as much as goals for an agent, because an underspecified goal is the most common root cause of technically-correct-but-wrong behavior.
• Tool access is a permission grant, not a feature list — spec what's withheld as explicitly as what's granted, per the least-privilege principle.
• Failure modes belong in a structured taxonomy, not a short "known limitations" bullet, because failure is a first-class design surface for autonomous systems.
• Escalation triggers must be observable conditions, not "when uncertain" — an LLM's self-reported confidence isn't a reliable signal.
• Evals replace manual QA as the release gate, because nobody can manually test an unbounded input space the way they'd test a fixed UI flow.
• Rollout should be staged and gated on eval scores, not shipped on a single date the way a feature typically is.

Frequently Asked Questions

What is an agent PRD?

An agent PRD is a product requirements document for an AI agent that includes everything a standard feature PRD covers, plus behavior boundaries, a failure-mode inventory, escalation rules, and eval-based rollout gates — sections needed because the agent's runtime behavior isn't fully determined in advance.

How is writing a PRD for an AI agent different from a normal PRD?

Writing PRD for AI agent work adds a focus on the space of things that can go wrong, not just the intended path — because an agent chooses its own steps at runtime across an input space too large to manually test, unlike a fixed feature with a bounded set of UI states.

Do agent PRDs need eval suites instead of acceptance criteria?

Yes, in addition to standard acceptance criteria — an eval suite with a labeled test set and numeric pass bar substitutes for the manual QA a static feature would get, since nobody can exhaustively test every input an agent might see in production.

When should an agent escalate to a human instead of acting?

An agent should escalate on observable, predefined trigger conditions — a confidence score below a set threshold, a repeated tool failure, an explicit user request for a human, or a request matching a known out-of-scope pattern — never on a vague "when uncertain" instruction, since self-reported model confidence isn't a reliable signal to build escalation logic around.

What goes in the failure-mode section of an agent PRD?

The failure-mode section inventories how the agent can fail, typically across input failures, reasoning failures (hallucination), tool failures, scope creep, and compounding failures where one wrong step feeds the next — ranked by likelihood and impact rather than left as a short "known limitations" note.