An AI agent product requirements document should do more than describe a feature. It should define the work the agent may perform, the information it may use, the actions it may take, the conditions that require human judgment, and the evidence that will decide whether the system is ready.
That extra detail matters because an agent operates across a workflow. It interprets context, selects tools, changes records, and handles exceptions. A vague requirement such as “help account managers prepare renewals” leaves product, engineering, security, and operations to discover the actual boundaries during implementation.
Use this template before choosing a framework or model. It turns an AI idea into a testable product specification that a cross-functional team can estimate, challenge, and approve.
Start with a one-page decision frame
Before writing the full PRD, align the team on six decisions.
| Decision | Question to answer |
|---|---|
| User outcome | What becomes faster, safer, cheaper, or more reliable for a named user? |
| Workflow boundary | Where does the agent start, where must it stop, and what remains outside scope? |
| Why AI | Which parts require interpretation, adaptation, or unstructured information? |
| Authority | What may the agent read, recommend, create, update, send, or approve? |
| Proof | Which release checks and post-launch metrics will show that it works? |
| Owner | Who owns quality, incidents, policy changes, cost, and ongoing improvement? |
If the team cannot answer these questions in plain language, implementation is premature. The PRD should expose unresolved decisions instead of hiding them behind a prototype.
1. Problem, user, and measurable outcome
Describe the current workflow from the user’s point of view. Name the delay, error, risk, or missed opportunity. Include a baseline and a target when reliable data exists.
Write the outcome as a change in work, not a model capability:
- Weak: generate renewal summaries with AI.
- Strong: reduce median preparation time for a renewal review from 45 minutes to 20 minutes while preserving every required source citation and manager approval.
Record the primary user, affected stakeholders, workflow frequency, current volume, and cost of a wrong result. Separate the business outcome from model-quality measures. Accuracy on a test set can support the outcome, but it is not the outcome itself.
2. Scope and non-goals
Define the smallest end-to-end workflow worth testing. State the trigger, the final state, and every important handoff in between.
For a renewal-preparation agent, the scope might be:
- A manager selects an account and review date.
- The agent retrieves approved account, support, usage, and contract data.
- It identifies changes, risks, and missing information.
- It drafts a review brief with links to evidence.
- The account manager edits and approves the brief.
Non-goals could include changing contract terms, sending customer messages, predicting churn without an approved model, or updating the CRM automatically. Explicit non-goals protect the first release from silent authority expansion.
3. Decide what should be agentic
Break the workflow into steps and classify each one.
| Step type | Use when | Example |
|---|---|---|
| Deterministic | Rules and inputs are stable | Check that required fields exist |
| Retrieval | The answer must come from approved sources | Fetch the latest signed contract |
| Model-assisted | Interpretation helps, but a person decides | Summarize account risks |
| Agentic | The path changes based on context and tool results | Investigate missing renewal evidence across systems |
| Human-only | Judgment, accountability, or risk requires a person | Approve a commercial recommendation |
OpenAI’s agent guidance recommends agents for workflows where deterministic approaches struggle with complex decisions, brittle rules, or unstructured data. It also treats tools and instructions as core design components. The PRD should therefore justify every agentic step and keep stable checks in normal software.
4. Users, roles, and handoffs
List every actor and the decisions they own. Include the end user, data owners, approvers, support team, security team, and system owner.
For each handoff, specify:
- what the person sees;
- what evidence accompanies the recommendation;
- which actions are available;
- how edits and overrides are recorded;
- what happens when nobody responds;
- who receives an escalation.
Design the takeover path as a product flow. OpenAI’s guidance identifies repeated failures and high-risk actions as common triggers for human intervention. A handoff that merely says “ask a human” is incomplete unless the right context, ownership, and deadline travel with it.
5. Context and data contract
Create an inventory of the information the agent needs.
| Data source | Fields or documents | Freshness | Access rule | Failure behavior | Owner |
|---|---|---|---|---|---|
| CRM | Account, stage, owner, notes | Near real time | Read selected account | Show unavailable source | Revenue operations |
| Support system | Open cases and severity | Hourly | Read account cases | Continue with warning | Support operations |
| Contract store | Signed agreement | On change | Read approved folder only | Stop the run | Legal operations |
Define source precedence when records disagree. State how personal, regulated, confidential, or customer-controlled data must be filtered. Include retention, deletion, residency, and audit requirements where they apply. Do not assume that access available to an employee should automatically be available to an agent.
6. Tools, permissions, and action boundaries
Describe tools as product contracts, not implementation shortcuts. Each tool needs a purpose, allowed inputs, expected output, timeout, retry rule, and safe failure state.
Build a permission matrix:
| Capability | Default | Additional control |
|---|---|---|
| Read approved account data | Allow for selected account | Log source and access time |
| Draft an internal brief | Allow | Label as draft and retain evidence links |
| Update CRM fields | Deny in first release | Require approved field allowlist and confirmation |
| Send an external message | Deny | Require named human approval before every send |
| Change pricing or contract terms | Deny | Human-only decision |
Apply least privilege to data and actions. Set limits on action count, retries, spend, and time. Define idempotency for any tool that changes state so a retry cannot create duplicate records or messages.
7. Instructions and policy hierarchy
The PRD should state which sources govern behavior and how conflicts are resolved. A useful order is:
- legal, security, and organizational policy;
- product-specific operating rules;
- workflow instructions;
- user requests;
- retrieved content.
Specify prohibited behavior, required disclosures, source-citation rules, uncertainty language, and conditions that force refusal or escalation. Retrieved documents are data, not authority to change policy. Test this distinction directly.
8. Failure modes and recovery
Create a failure table before building the happy path.
| Failure | Detection | User experience | Recovery |
|---|---|---|---|
| Required source unavailable | Tool error or stale timestamp | Name the missing source | Retry once, then pause or continue only if allowed |
| Conflicting records | Field comparison | Show the conflict and sources | Ask an owner to resolve it |
| Low-confidence interpretation | Evaluation or policy threshold | Mark the uncertain section | Route for focused review |
| Repeated tool loop | Action-count limit | Stop safely with run history | Hand off to the operator |
| Unauthorized action request | Permission check | Explain that approval is required | Create an approval request without executing |
Include partial completion, duplicate execution, malformed inputs, prompt injection in retrieved content, expired credentials, model unavailability, and downstream outages. Define what must be reversible and what evidence an incident responder needs.
9. Evaluation and acceptance criteria
Separate release acceptance from post-launch success.
Build a representative evaluation set with common cases, edge cases, high-risk cases, incomplete data, conflicting data, and adversarial instructions. Preserve expected evidence and permitted actions for each case.
Release criteria might include:
- required facts are supported by approved sources;
- prohibited actions never execute;
- high-risk recommendations always require approval;
- the agent stops within the configured action and retry limits;
- duplicate retries do not create duplicate side effects;
- reviewers can trace each important claim to its source;
- latency and cost remain within defined limits at expected volume.
Name the evaluator, scoring method, threshold, and response to a failure. A single average score can hide severe mistakes, so report critical-policy failures separately.
10. Product and operating metrics
Choose a small metric set that connects quality to the workflow.
- Outcome: median preparation time per approved renewal brief.
- Quality: percentage of required claims supported by an accepted source.
- Human effort: median edit time and escalation rate.
- Reliability: successful completion rate and tool-failure rate.
- Safety: unauthorized-action attempts blocked and critical-policy failures.
- Economics: cost per approved brief at the expected workload.
Add a baseline, target, measurement window, and owner to each metric. Define guardrails that can stop or roll back the release even when the primary outcome improves.
11. Non-functional requirements
State practical limits for latency, availability, throughput, concurrency, cost, observability, security, accessibility, and supported languages. Include expected workload and peak conditions.
For every run, decide what to log: model and policy version, tool calls, decision outcomes, source references, approvals, latency, cost, and errors. Exclude sensitive content that is not needed for audit or debugging. NIST’s AI Risk Management Framework emphasizes documented roles, transparent risk processes, ongoing monitoring, and clear accountability. Those responsibilities belong in the product plan, not in a later operations appendix.
12. Rollout, rollback, and ownership
Plan staged exposure:
- offline evaluation on approved examples;
- shadow mode with no user-facing output;
- internal users with read-only tools;
- a small production cohort with required approval;
- broader access after quality and guardrails hold.
For each stage, define entry criteria, exit criteria, monitoring period, incident owner, and rollback trigger. Record who may change prompts, tools, policies, models, and evaluation sets. Add a review date because data, capabilities, risks, and user behavior change after launch.
Copyable AI agent PRD outline
Use this outline as the working document:
- Document owner, approvers, status, and review date
- Problem, named user, baseline, and measurable outcome
- Workflow trigger, end state, steps, and non-goals
- Deterministic, retrieval, model-assisted, agentic, and human-only classification
- Users, roles, approvals, escalation, and handoff experience
- Data inventory, freshness, precedence, privacy, and access rules
- Tool contracts, permissions, action limits, and idempotency
- Instruction sources, policy hierarchy, prohibited behavior, and disclosures
- Failure modes, safe states, recovery, and incident evidence
- Evaluation set, graders, thresholds, and release acceptance criteria
- Outcome, quality, effort, reliability, safety, and cost metrics
- Latency, availability, observability, security, and accessibility requirements
- Rollout stages, rollback triggers, change control, and operating owners
- Open decisions, assumptions, dependencies, and target dates
Review the PRD before implementation
A review-ready AI agent PRD makes authority visible. A product leader can assess the outcome, an engineer can estimate the workflow, a security reviewer can challenge access, an operator can see failure behavior, and an executive can understand the evidence required to continue.
AppUnik designs AI into real products and workflows, with the integrations, data, and operating foundations needed after a prototype. If you are turning an AI opportunity into a buildable product, explore AI-first product engineering or discuss the workflow and success metric before selecting the implementation stack.
Evidence note
This article is a product-specification framework based on a verified AppUnik content gap and current primary guidance. It does not claim measured demand from AppUnik analytics. The example, thresholds, and template fields are editorial recommendations that teams should adapt to their own risk, data, and operating environment.
