# 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*.

<!--
Guidance: How to use this template
- Use this PRD when the AI does more than produce one answer: it holds a
  conversation, plans steps, or calls tools that change data. For a single
  prediction or generation feature, use the AI Feature PRD
  (`ai-data/ai-feature-prd`) instead.
- This is the product view. The engineering view of the same agent lives
  in the AI Agent Specification (`ai-data/ai-agent-spec`); tool scopes in
  Agent Tool Permission Design (`ai-data/agent-tool-permission-design`).
- Write sections 3 and 4 (autonomy and actions) before prompts or model
  choice. Every action with a side effect needs an owner, an approval rule
  and an undo path.
- Write acceptance criteria as evaluations (section 6) that can pass or
  fail on a named dataset. "Feels helpful" is not a criterion.
- Common pitfall: shipping the happy path and leaving failure UX
  (section 8) to the model's default apology text.
-->

## Document control

<!-- Guidance: Identify the product version, the decision makers and the related engineering documents. -->

| 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

<!-- Guidance: Any change to autonomy level, actions or approval points is a product change; record it here and re-approve. -->

| 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

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Problem, users and jobs](#1-problem-users-and-jobs)
2. [Goals, non-goals and scope](#2-goals-non-goals-and-scope)
3. [Autonomy levels](#3-autonomy-levels)
4. [Actions, undo and approval points](#4-actions-undo-and-approval-points)
5. [Interaction design](#5-interaction-design)
6. [Eval-driven acceptance criteria](#6-eval-driven-acceptance-criteria)
7. [Quality, latency and cost targets](#7-quality-latency-and-cost-targets)
8. [Failure UX](#8-failure-ux)
9. [Transparency and user control](#9-transparency-and-user-control)
10. [Telemetry and feedback](#10-telemetry-and-feedback)
11. [Rollout plan](#11-rollout-plan)
12. [Risks, dependencies and open questions](#12-risks-dependencies-and-open-questions)
13. [Traceability and glossary](#13-traceability-and-glossary)

## 1. Problem, users and jobs

<!-- Guidance: Start from the jobs users hire the copilot for, not from model capabilities. Questions: which jobs are tedious, frequent and verifiable? Which jobs do users want to keep doing themselves? Pitfall: one generic "assistant" persona that serves no job well. -->

### 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

<!-- Guidance: Make non-goals explicit, especially actions the copilot must never take. Pitfall: scope that grows through the prompt rather than through this document. -->

| 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

<!-- Guidance: Assign an autonomy level per job or action, not one level for the product. Raise a level only with evidence from evaluation and pilot data. Pitfall: granting level 3 to save clicks before error rates are known. -->

| 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

<!-- Guidance: List every action that changes state. For each, define who approves, how the user undoes it, and the blast radius if it goes wrong. Pitfall: actions that look reversible in the UI but trigger external effects (emails, webhooks) that cannot be recalled. -->

| 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.

```mermaid
stateDiagram-v2
  [*] --> Proposed
  Proposed --> AwaitingApproval: level 2
  Proposed --> Executed: level 3 within limits
  AwaitingApproval --> Executed: user confirms
  AwaitingApproval --> Discarded: user rejects or timeout
  Executed --> Undone: user undoes within window
  Executed --> [*]
  Undone --> [*]
  Discarded --> [*]
```

## 5. Interaction design

<!-- Guidance: Describe entry points, the conversation and action flow, and how users steer the copilot. Pitfall: a chat box as the only entry point when most jobs start from a record the user is already viewing. -->

### 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.

```mermaid
sequenceDiagram
  actor U as Account manager
  participant C as Copilot
  participant T as Tools (CRM, analytics)
  U->>C: Prep this renewal
  C->>T: Read usage, tickets, notes
  T-->>C: Data with source links
  C-->>U: Summary with citations and suggested next step
  U->>C: Log the next step
  C-->>U: Preview of CRM change
  U->>C: Confirm
  C->>T: update_next_step
  C-->>U: Done, with Undo
```

### 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

<!-- Guidance: Each criterion names a dataset, a metric, a threshold and a gate. A release cannot ship if a blocking criterion fails. The full protocol lives in the Agent Evaluation Plan (`ai-data/agent-evaluation-plan`) or LLM Evaluation Plan (`ai-data/llm-evaluation-plan`). Pitfall: thresholds set after seeing the results. -->

| 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

<!-- Guidance: Set targets per job, because a quick lookup and a multi-step task have different budgets. Show the cost calculation so finance can check it. Pitfall: a p50 latency target with no p95, which hides the slow tail users remember. -->

| 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

<!-- Guidance: Design each failure state explicitly with copy, recovery action and logging. Pitfall: confident wrong answers, which are worse than visible failures. -->

| 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

<!-- Guidance: Tell users they are working with AI, what it can do, how well, and what it did on their behalf. Pitfall: an action history that exists in logs but is not visible to the user. -->

| 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

<!-- Guidance: Define the events needed to measure section 2 goals and section 6 criteria in production, and the privacy limits on what is logged. Pitfall: logging full prompts with customer data by default. -->

| 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

<!-- Guidance: Roll out by cohort and by autonomy level. Each stage has entry criteria, exit criteria and a rollback trigger. Pitfall: raising autonomy and widening the audience in the same step. -->

| 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

<!-- Guidance: List product risks with owners. Security threats belong in the Agentic Threat Model (`ai-data/agentic-threat-model`); link to it rather than copying. -->

| 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

<!-- Guidance: Link each job to its actions, acceptance criteria and telemetry so reviewers can see that nothing ships untested. -->

### 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.