Copilot and Agent PRD Template
Copilot and agent requirements: jobs, autonomy levels, actions and undo, approval points, eval acceptance criteria, latency and cost, failure UX, rollout
사용법: Use it when an AI feature chats, plans or takes actions on behalf of users; use the AI Feature PRD for single-prediction features. Fill the autonomy levels and the actions table with undo paths first, then write acceptance criteria as evaluations. The main pitfall is shipping the happy path and leaving failure UX to the model's default text.
미리보기
Copilot and Agent PRD: [Product or feature name]
Product requirements document for a copilot or agent: an AI feature that works alongside users and can take actions on their behalf. It records users and jobs, the autonomy level per action, actions with their undo path, human approval points, eval-driven acceptance criteria, quality, latency and cost targets, failure UX, transparency, telemetry and rollout. Based on common industry practice for AI product requirements, informed by the Guidelines for Human-AI Interaction (Amershi et al., CHI 2019) and the Google PAIR People + AI Guidebook. Replace every
[bracketed]value and every row marked Example.
Document control
| Field | Value |
|---|---|
| Document ID | [CPRD-001] |
| Product or feature | [Name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@product-manager] |
| Approvers / reviewers | [@eng-lead], [@design-lead], [@ml-lead], [@security], [@legal] |
| Target release | [Example: Beta in Q3, GA in Q4] |
| Surface | [Example: Side panel in web app; Slack app] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Upstream documents | AI Opportunity Canvas (ai-data/ai-opportunity-canvas), AI Use Case Intake (ai-data/ai-use-case-intake) |
Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Product | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Engineering | [@name] | [Decision] | YYYY-MM-DD |
| Design and research | [@name] | [Decision] | YYYY-MM-DD |
| Security and privacy | [@name] | [Decision] | YYYY-MM-DD |
| AI governance | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | Example: Added send_email action at autonomy level 2 with approval |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved for beta |
Contents
- Problem, users and jobs
- Goals, non-goals and scope
- Autonomy levels
- Actions, undo and approval points
- Interaction design
- Eval-driven acceptance criteria
- Quality, latency and cost targets
- Failure UX
- Transparency and user control
- Telemetry and feedback
- Rollout plan
- Risks, dependencies and open questions
- Traceability and glossary
1. Problem, users and jobs
1.1 Problem statement
[Describe the problem in user terms and its cost today.]
Example: Account managers spend about 5 hours a week preparing for renewal calls: pulling usage data, reading recent tickets and drafting a summary email. Preparation quality varies, and 1 in 5 renewals reaches the call without a usage review.
1.2 Users
| Persona | Context | Expertise | What they must stay in control of |
|---|---|---|---|
| Example: Account manager | Weekly renewal prep, desktop | Expert in accounts, novice with data tools | Anything sent to the customer |
| Example: Sales manager | Reviews pipeline | Expert | Discount approvals |
| [Persona] | [Context] | [Expertise] | [Control] |
1.3 Jobs to be done
| ID | Job | Frequency | Verifiable by user? | Copilot role |
|---|---|---|---|---|
| CPRD-JOB-001 (Example) | Summarise an account's last 90 days before a call | Weekly per account | Yes, against source links | Draft |
| CPRD-JOB-002 (Example) | Draft a renewal email with usage highlights | Weekly | Yes | Draft, user sends |
| CPRD-JOB-003 (Example) | Log call notes to the CRM | After each call | Yes | Act with confirmation |
| CPRD-JOB-004 (Example) | Propose a discount | Rare | Hard | Out of scope |
| [ID] | [Job] | [Frequency] | [Yes / No] | [Suggest / Draft / Act] |
2. Goals, non-goals and scope
| Type | Statement |
|---|---|
| Goal | Example: Cut renewal prep time from 5 hours to 2 hours per week per account manager |
| Goal | Example: 95% of renewal calls preceded by a usage review |
| Goal | [Goal] |
| Non-goal | Example: The copilot does not negotiate prices or send anything to customers without the user pressing Send |
| Non-goal | Example: No access to HR or payroll data |
| Non-goal | [Non-goal] |
In-scope systems: [Example: CRM (read and write notes), product analytics (read), ticketing (read), email (draft only).]
Out-of-scope systems: [Example: Billing, contract management.]
3. Autonomy levels
| Level | Name | What the copilot does | What the user does |
|---|---|---|---|
| 0 | Inform | Answers questions, explains, retrieves | Decides and acts |
| 1 | Suggest | Proposes an action or draft | Edits and executes it |
| 2 | Act with approval | Prepares and executes after explicit confirmation | Approves each action |
| 3 | Act and notify | Executes within limits, then reports | Reviews, can undo |
| 4 | Act autonomously | Executes and reports in a periodic digest | Audits samples |
| Job or action | Level at launch | Target level | Evidence required to raise |
|---|---|---|---|
| CPRD-JOB-001 Summarise account (Example) | 0 | 0 | Not applicable |
| CPRD-JOB-002 Draft renewal email (Example) | 1 | 1 | Never auto-send to customers |
| CPRD-JOB-003 Log call notes (Example) | 2 | 3 | Edit rate below 10% over 4 weeks and zero wrong-account writes |
| [Job] | [Level] | [Level] | [Evidence] |
4. Actions, undo and approval points
| ID | Action | Side effect | Autonomy level | Approval point | Undo path | Undo window | Blast radius |
|---|---|---|---|---|---|---|---|
| CPRD-ACT-001 (Example) | create_crm_note | Writes a note to an account | 2 | Preview card with Confirm | Delete note from the action history | 30 days | One account |
| CPRD-ACT-002 (Example) | update_next_step | Changes opportunity next step and date | 2 | Diff view with Confirm | Revert to previous value | 7 days | One opportunity |
| CPRD-ACT-003 (Example) | create_email_draft | Creates a draft in the user's mailbox | 1 | None (draft only) | Discard draft | Until sent | None until sent |
| CPRD-ACT-004 (Example) | schedule_meeting | Sends invitations to external people | 2 | Confirm with attendee list shown | Cancel meeting (notification already sent) | Partial | External recipients |
| [ID] | [Action] | [Effect] | [Level] | [Approval] | [Undo] | [Window] | [Radius] |
Approval point rules:
- Show exactly what will change, on which record, before the user confirms. Never ask for approval of an action the user cannot inspect.
- Group approvals only when the actions are of the same type and target the same record set; show the count.
- If the user does not respond, the action does not run. Pending actions expire after [Example: 24 hours].
- Actions that reach people outside the organisation always require approval, regardless of autonomy level.
5. Interaction design
5.1 Entry points
| Entry point | Context passed | Typical job |
|---|---|---|
| Example: "Prep this renewal" button on the account page | Account ID, user role | CPRD-JOB-001 |
| Example: Side panel chat | Current page, selection | Any |
| Example: Post-call prompt after calendar event ends | Meeting ID, attendees | CPRD-JOB-003 |
| [Entry point] | [Context] | [Job] |
5.2 Main flow
Describe the main flow for the most frequent job. Example: renewal preparation, from the account page to a logged next step.
5.3 Steering and correction
- Users can edit any draft inline before acting on it.
- Users can say what to change in plain language ("shorter", "mention the outage") and see a revised draft.
- Users can stop a running multi-step task at any time; partial results remain visible and no further actions run.
- [Additional steering control]
6. Eval-driven acceptance criteria
| ID | Criterion | Dataset | Metric | Threshold | Gate |
|---|---|---|---|---|---|
| CPRD-EVAL-001 (Example) | Summaries are faithful to source data | 200 real accounts, labelled by 3 account managers | Share of summaries with no unsupported claim | at least 95% | Blocking |
| CPRD-EVAL-002 (Example) | Every factual claim links to a source | Same set | Citation coverage | at least 98% | Blocking |
| CPRD-EVAL-003 (Example) | Actions target the right record | 150 scripted tasks | Wrong-record actions | 0 | Blocking |
| CPRD-EVAL-004 (Example) | Task completion for multi-step jobs | 150 scripted tasks | Completed without user correction | at least 80% | Blocking for level 3 |
| CPRD-EVAL-005 (Example) | Resistance to instructions embedded in tickets | 60 adversarial tickets | Unauthorised actions | 0 | Blocking |
| CPRD-EVAL-006 (Example) | Draft usefulness | 50 drafts rated by users | Mean rating out of 5 | at least 4.0 | Non-blocking |
| [ID] | [Criterion] | [Dataset] | [Metric] | [Threshold] | [Blocking / Non-blocking] |
Re-run all blocking criteria on every change to model, prompt, tools or retrieval index. Record results in the release notes.
7. Quality, latency and cost targets
| Job | Time to first token (p95) | Time to complete (p95) | Max tool calls | Cost per task |
|---|---|---|---|---|
| CPRD-JOB-001 (Example) | 1.5 s | 12 s | 6 | USD 0.03 |
| CPRD-JOB-002 (Example) | 1.5 s | 8 s | 2 | USD 0.01 |
| CPRD-JOB-003 (Example) | 1.0 s | 5 s | 2 | USD 0.005 |
| [Job] | [Target] | [Target] | [Limit] | [Cost] |
Monthly cost estimate (Example): 400 account managers x 25 tasks per week x 4.3 weeks x USD 0.02 average = USD 860 per month. Budget alert at USD 1,200.
Degradation rules: when a budget is exceeded, the copilot [Example: stops after 6 tool calls, shows partial results and asks whether to continue].
8. Failure UX
| ID | Failure | Detection | What the user sees | Recovery |
|---|---|---|---|---|
| CPRD-FAIL-001 (Example) | Data source unavailable | Tool error | "Usage data is unavailable right now. The summary below covers tickets and notes only." | Retry button; summary marked partial |
| CPRD-FAIL-002 (Example) | Low confidence or no source found | Retrieval score below threshold | "I could not find support for this in the account records." | Offer search link; no claim made |
| CPRD-FAIL-003 (Example) | Ambiguous request | Planner detects two matching accounts | Short clarifying question with both options | User picks one |
| CPRD-FAIL-004 (Example) | Action failed after approval | Tool returns error | Clear error, nothing partially written | Retry or open record manually |
| CPRD-FAIL-005 (Example) | Request out of scope | Policy classifier | States what it cannot do and where to go | Link to the right tool or team |
| CPRD-FAIL-006 (Example) | Wrong output noticed by user | Thumbs down or undo | Undo confirmation and optional reason field | Feedback logged for review |
| [ID] | [Failure] | [Detection] | [Copy] | [Recovery] |
Rules for failure copy: say what happened, what was and was not done, and what the user can do next. Do not blame the user. Do not apologise repeatedly. Never claim an action succeeded until the tool confirms it.
9. Transparency and user control
| Requirement | Implementation | Status |
|---|---|---|
| Users know the copilot is AI | Example: Label "AI copilot" on panel header and on every AI-written CRM note | [Planned / Done] |
| Capabilities and limits explained | Example: First-run card listing what it can read and change | [Status] |
| Quality expectations set | Example: "Check drafts before sending; summaries may miss recent changes" | [Status] |
| Sources shown | Citations link to the record or ticket | [Status] |
| Action history | Example: Panel tab listing every action, time, target and Undo | [Status] |
| Global controls | Example: Settings to turn off proactive prompts and to limit which systems the copilot may read | [Status] |
| Change notices | Example: Release note in the panel when abilities change | [Status] |
| Legal disclosure where required | Example: AI interaction disclosure per applicable law; see AI Content Transparency Plan (ai-data/ai-content-transparency-plan) | [Status] |
Run a full review of the interaction against the 18 guidelines using the
Human-AI Interaction Review (ai-data/human-ai-interaction-review).
10. Telemetry and feedback
| Event | Fields | Purpose | Retention |
|---|---|---|---|
copilot_invoked (Example) | Entry point, job type, user role | Adoption by entry point | 13 months |
action_proposed (Example) | Action ID, level, target type | Funnel to approval | 13 months |
action_approved / action_rejected (Example) | Action ID, time to decide | Trust and friction | 13 months |
action_undone (Example) | Action ID, time since execution | Quality signal | 13 months |
feedback_given (Example) | Rating, reason code, optional text | Quality review | 90 days for free text |
trace (Example) | Tool calls, latency, tokens, model version | Debugging, cost | 30 days, redacted |
| [Event] | [Fields] | [Purpose] | [Retention] |
Production quality metrics: acceptance rate of drafts, edit distance
before send, undo rate per action, rejection rate at approval points,
escalations to support, and the guardrail metrics from section 6. Trace
format and dashboards follow the LLM Observability Specification
(ai-data/llm-observability-spec).
11. Rollout plan
| Stage | Audience | Autonomy | Entry criteria | Exit criteria | Rollback trigger |
|---|---|---|---|---|---|
| Internal dogfood (Example) | 20 volunteers | Levels 0 to 1 | Blocking evals pass | 2 weeks, no severity-1 issues | Any wrong-record write |
| Beta (Example) | 10% of account managers | Levels 0 to 2 | Dogfood exit met | 4 weeks, goals trending to target | Undo rate above 15% |
| GA (Example) | All account managers | Levels 0 to 2 | Beta exit met; launch review approved | Not applicable | Severity-1 incident |
| Level raise (Example) | GA users opt in | Level 3 for CPRD-ACT-001 | Evidence in section 3 met | 4 weeks stable | Any wrong-record write |
Launch readiness is confirmed in the AI Launch Review
(ai-data/ai-launch-review). A kill switch disables all actions within
[Example: 5 minutes] while keeping read-only answers available.
12. Risks, dependencies and open questions
| ID | Type | Description | Mitigation | Owner |
|---|---|---|---|---|
| CPRD-RISK-001 (Example) | Over-reliance | Users stop reading summaries and repeat errors to customers | Citations, sampled QA, training | [@product-manager] |
| CPRD-RISK-002 (Example) | Indirect prompt injection | Ticket text instructs the copilot to change records | Tool permission limits; approval on writes; eval CPRD-EVAL-005 | [@security] |
| CPRD-RISK-003 (Example) | Dependency | CRM API rate limits at peak | Caching; backoff; partial results | [@eng-lead] |
| [ID] | [Type] | [Description] | [Mitigation] | [@owner] |
Open questions:
- [Example: Should sales managers see their team's copilot action history? Owner: [@product-manager], decide by YYYY-MM-DD.]
- [Question, owner, decision date]
13. Traceability and glossary
13.1 Traceability matrix
| Job | Actions | Acceptance criteria | Failure states | Telemetry |
|---|---|---|---|---|
| CPRD-JOB-001 (Example) | None (read only) | CPRD-EVAL-001, CPRD-EVAL-002 | CPRD-FAIL-001, CPRD-FAIL-002 | copilot_invoked, feedback_given |
| CPRD-JOB-002 (Example) | CPRD-ACT-003 | CPRD-EVAL-006 | CPRD-FAIL-005 | action_proposed |
| CPRD-JOB-003 (Example) | CPRD-ACT-001, CPRD-ACT-002 | CPRD-EVAL-003, CPRD-EVAL-004, CPRD-EVAL-005 | CPRD-FAIL-003, CPRD-FAIL-004 | action_approved, action_undone |
| [Job] | [Actions] | [Criteria] | [Failures] | [Events] |
13.2 Glossary
| Term | Meaning in this PRD |
|---|---|
| Agent | An AI system that plans steps and calls tools to reach a goal |
| Approval point | A step where the user must confirm before an action runs |
| Autonomy level | The degree to which the copilot acts without per-action confirmation (section 3) |
| Blast radius | The scope of harm if an action goes wrong |
| Copilot | An AI assistant embedded in a user's workflow that informs, drafts or acts |
| Undo window | The time during which an action can be fully reversed |
13.3 References
- Amershi, S. et al. (2019). Guidelines for Human-AI Interaction. CHI 2019. https://doi.org/10.1145/3290605.3300233
- Google PAIR, People + AI Guidebook (living document): https://pair.withgoogle.com/guidebook/
- Related templates: AI Feature PRD (
ai-data/ai-feature-prd), AI Agent Specification (ai-data/ai-agent-spec), Agent Evaluation Plan (ai-data/agent-evaluation-plan), Human Oversight Design (ai-data/human-oversight-design), AI Launch Review (ai-data/ai-launch-review).
Standard and licence note
Based on common industry practice for writing product requirements for AI copilots and agents, informed by the Guidelines for Human-AI Interaction (Amershi et al., CHI 2019) and the Google PAIR People + AI Guidebook, which are cited and not reproduced. The autonomy levels, IDs and examples are original to this template; example numbers and prices are illustrative. Check the current versions of the cited sources before use. Template licence: MIT.
관련 템플릿
AI Feature PRD Template
PRD for an AI-powered feature: why AI, failure and uncertainty UX, metrics, eval thresholds, cost per request, rollout
AI 및 데이터A2A Agent Card and Interface Specification Template (A2A 1.0)
A2A agent spec: Agent Card fields, skills, bindings, security schemes, operations, task states, parts, push, errors, discovery, example card, conformance
AI 및 데이터AI Agent Evaluation Plan Template (Task Success, Trajectory, Tool Calls)
Agent task suite, success, trajectory, tool-call and argument metrics, sandboxed harness, online tests, calibrated graders, statistics, ASI safety cases, gates