# AI Agent Requirements Document Template

Use this document for one bounded agent workflow and environment. Replace every bracketed field, remove sections that do not apply, and keep a reason for each exclusion.

This template is educational material, not legal, security, privacy, compliance, financial, workforce, or risk advice. Do not put passwords, tokens, private keys, recovery codes, customer records, sensitive personal data, or model private reasoning in this document. Use protected references for sensitive evidence and architecture details.

## Requirements Document Record

- Requirements document ID: [Stable ID]
- Agent ID: [Stable ID or To be assigned]
- Workflow ID: [Stable ID]
- Organization ID: [Stable ID]
- Source tenant, workspace, and account IDs: [Every applicable boundary]
- Target tenant, workspace, and account IDs: [Every applicable boundary, or Same as source]
- Environment: [Development | Test | Staging | Production]
- Version: [Version or digest]
- Status: [Draft | In review | Approved baseline | Superseded | Retired]
- Business owner: [Approved work identity]
- Product owner: [Approved work identity]
- Technical owner: [Approved work identity]
- Requirements owner: [Person responsible for completeness and traceability]
- Reviewers: [Domain, user, data, security, privacy, legal, risk, operations, and accessibility reviewers as applicable]
- Related business case: [Protected reference]
- Related charter: [Protected reference]
- Related roadmap and release: [Protected references]
- Handling classification: [Classification]
- Authorized readers and editors: [People or roles]
- Retention period: [Policy or date]
- Approved baseline date: [Date or Not approved]

This document specifies intended behavior, constraints, and acceptance evidence. It does not grant access, approve a pilot or production release, waive policy, or authorize an operation. Identity, authorization, approval, gateway, runtime, tool, and target-system controls must decide and enforce each operation at execution time.

## Requirement Syntax and Traceability

Write one verifiable statement per row. Use stable IDs so design, tests, evidence, incidents, and changes can point to the same requirement.

Useful patterns:

- Always: The agent shall [behavior or constraint].
- Event: When [trigger], the agent shall [response].
- State: While [state], the agent shall [behavior or constraint].
- Failure: If [failure or invalid condition], the system shall [safe response].
- Prohibited: The agent shall not [action or outcome].

| Field                | Required content                                             |
| -------------------- | ------------------------------------------------------------ |
| Requirement ID       | Stable prefix and number, such as `FUN-001`                  |
| Statement            | One testable behavior, constraint, or quality threshold      |
| Source and rationale | Stakeholder, policy, risk, dependency, or measured need      |
| Priority             | Must, Should, Could, or Will not                             |
| Verification method  | Test, Analysis, Inspection, or Demonstration                 |
| Acceptance evidence  | Exact result, threshold, and authoritative evidence source   |
| Owner                | Person accountable for interpretation and acceptance         |
| Dependencies         | Other requirement IDs, systems, data, or decisions           |
| Status               | Draft, Accepted, Blocked, Implemented, Verified, or Rejected |

Master traceability table:

| Requirement ID | Statement            | Source and rationale   | Priority   | Verification method | Acceptance evidence    | Owner   | Dependencies        | Status   |
| -------------- | -------------------- | ---------------------- | ---------- | ------------------- | ---------------------- | ------- | ------------------- | -------- |
| [ID]           | [The agent shall...] | [Reference and reason] | [Priority] | [Method]            | [Threshold and source] | [Owner] | [IDs or references] | [Status] |

Every requirement produced in sections 1 through 12 must have exactly one row in this master traceability table. The detailed matrices in later sections add design context; they do not replace the master row or any required field.

## 1. Problem, Users, and Intended Outcome

- Workflow problem: [Measured problem]
- Current workflow and baseline: [Steps, volume, time, quality, cost, exceptions, and source]
- Intended business or user outcome: [Outcome]
- Primary users and initiating principals: [Stable IDs or roles]
- Affected people and groups: [Description]
- Domain experts consulted: [People or roles]
- User and affected-party research: [Protected references]
- Expected benefits: [Measured claims or hypotheses]
- Potential harms and unwanted outcomes: [List]
- Minimum useful result: [Threshold]
- Guardrail outcomes that must not worsen: [Measures]
- Authoritative outcome source: [System or record]
- Decision requested from this requirements baseline: [Prototype | Pilot preparation | Release design | Other]

## 2. Scope, Assumptions, and Constraints

In scope:

- Workflow trigger: [User, event, schedule, parent agent, or system]
- Start state: [State]
- Completion state: [Observable outcome]
- Allowed users, teams, regions, channels, and environments: [Boundaries]
- Allowed task types: [List]
- Maximum volume, rate, duration, concurrency, and cost: [Limits]

Out of scope:

- Prohibited or deferred tasks: [List]
- Unsupported users, data, systems, and environments: [List]
- Decisions reserved for humans or deterministic systems: [List]
- Uses that require a separate requirements baseline: [List]

Assumptions and constraints:

| ID   | Assumption or constraint | Owner   | Validation method | Due date | Result or response |
| ---- | ------------------------ | ------- | ----------------- | -------- | ------------------ |
| [ID] | [Statement]              | [Owner] | [Method]          | [Date]   | [Result]           |

## 3. Workflow and Functional Requirements

Map the normal, exception, ambiguous, prohibited, timeout, retry, duplicate, cancel, resume, and human-handoff paths.

| Step   | Trigger and preconditions | Required behavior | Tool or system | Human role | Completion evidence      | Failure behavior       |
| ------ | ------------------------- | ----------------- | -------------- | ---------- | ------------------------ | ---------------------- |
| [Step] | [Conditions]              | [Behavior]        | [Reference]    | [Role]     | [Authoritative evidence] | [Fail-closed response] |

Functional requirements:

| Requirement ID | Statement                                              | Source and rationale | Priority   | Verification method | Acceptance evidence | Owner   | Dependencies | Status   |
| -------------- | ------------------------------------------------------ | -------------------- | ---------- | ------------------- | ------------------- | ------- | ------------ | -------- |
| FUN-[###]      | When [trigger], the agent shall [observable response]. | [Source and reason]  | [Priority] | [Method]            | [Evidence]          | [Owner] | [IDs]        | [Status] |

Define requirements for:

- Input validation and unsupported requests
- Planning and task decomposition, if applicable
- Tool selection, order, parameters, and result handling
- Human questions, confirmation, approval, correction, appeal, and handoff
- Idempotency, duplicate detection, retry, timeout, and cancellation
- State creation, update, retention, recovery, and reconciliation
- Output format, required fields, citations, provenance, and destination
- Completion confirmation from the authoritative target system

## 4. Authority, Identity, and Human Decision Requirements

Authority matrix:

| Operation                                                         | Initiating principal | Agent identity | Target system and object | Tenant scope | Material parameters | Required approval | Enforcement point | Evidence source | Failure behavior          |
| ----------------------------------------------------------------- | -------------------- | -------------- | ------------------------ | ------------ | ------------------- | ----------------- | ----------------- | --------------- | ------------------------- |
| [Read, draft, write, send, execute, spend, schedule, or delegate] | [Principal]          | [Identity]     | [Target]                 | [Boundaries] | [Limits]            | [Rule]            | [Control]         | [Reference]     | [Deny, stop, or hand off] |

Requirements shall cover:

- Attributable and revocable agent identity
- Initiating principal capture and current authentication
- Per-operation authorization with source and target tenant binding
- Least-privilege grants, expiry, revocation, and reauthorization
- Approval identity, current authority, exact scope, expiry, replay protection, and evidence
- Separation of request, recommendation, approval, execution, and verification where required
- Delegation depth, child-agent identity, inherited limits, and termination
- Prohibited actions and non-waivable limits

Approval in this document is not runtime authorization. An approval service or target system must still validate current authority and bind the exact action before execution.

## 5. Data, Privacy, and Record Requirements

| Data source or output | Purpose   | Owner   | Classification | Allowed fields | Prohibited fields | Quality and freshness | Residency  | Retention and deletion | Recipient   | Evidence    |
| --------------------- | --------- | ------- | -------------- | -------------- | ----------------- | --------------------- | ---------- | ---------------------- | ----------- | ----------- |
| [Reference]           | [Purpose] | [Owner] | [Class]        | [Fields]       | [Fields]          | [Rule]                | [Location] | [Rule]                 | [Recipient] | [Reference] |

Requirements shall cover:

- Purpose limits and data minimization
- Authorized source, field, recipient, and destination boundaries
- Accuracy, completeness, freshness, conflict, and missing-data rules
- Sensitive data detection, rejection, redaction, and escalation
- User notice, consent, access, correction, deletion, objection, and appeal where applicable
- Test-data generation and production-data restrictions
- Record retention, legal hold, deletion, and proof of deletion
- Logs and evidence that omit secrets and unnecessary sensitive content

## 6. Context, Knowledge, Skill, and Memory Requirements

Inventory every model-visible or behavior-shaping input. Authentication material, secrets, and model private reasoning are excluded.

| Context form                             | Stable ID or source | Authority and scope                  | Permission source               | Route or delivery source       | Evaluated version or capture rule         | Freshness owner | Change response                    |
| ---------------------------------------- | ------------------- | ------------------------------------ | ------------------------------- | ------------------------------ | ----------------------------------------- | --------------- | ---------------------------------- |
| System or harness prompt                 | [Reference]         | [Authority]                          | [Source]                        | [Delivery]                     | [Version]                                 | [Owner]         | [Continue, retest, or stop]        |
| Knowledge or instruction                 | [ID]                | [Informational or must-follow scope] | [Reference]                     | [Direct or Group Always route] | [Published version]                       | [Owner]         | [Continue, retest, or stop]        |
| Skill package                            | [ID]                | [Authorized scope]                   | [Reference]                     | [Direct or Group Always route] | [Published digest]                        | [Owner]         | [Continue, retest, or stop]        |
| Working Memory                           | [ID]                | [Authorized scope]                   | [Reference]                     | [Direct or Group Always route] | [Version or baseline]                     | [Owner]         | [Continue, reset, retest, or stop] |
| Artifact                                 | [ID]                | [No instruction authority]           | [Access source]                 | [Explicit input]               | [Exact Artifact version ID]               | [Owner]         | [Rule]                             |
| Message                                  | [ID]                | [No instruction authority]           | [Can message and access source] | [Inbox delivery]               | [Message ID and pinned Artifact versions] | [Owner]         | [Rule]                             |
| MCP descriptor or approved configuration | [Reference]         | [Capability only]                    | [Source]                        | [Delivery]                     | [Version]                                 | [Owner]         | [Rule]                             |
| Runtime input or tool result             | [Source]            | [No self-granted authority]          | [Execution authorization]       | [Runtime]                      | [Capture rule]                            | [Owner]         | [Rule]                             |

Permissions govern repository access while routes govern delivery independently. Always routes resolve the current published Knowledge or Skill and current Memory, so a version recorded here does not pin delivery. Define the response when resolved context differs from the tested baseline. AGENTS.md is the familiar combination of must-follow Knowledge and Always routing, not a separate Resource type. MCP tool results are Runtime context.

Artifacts and messages have no instruction authority. Messages pin exact Artifact versions, while Artifact access grants apply to the whole Artifact, including history and future versions.

Requirements shall define conflict handling, authority order, provenance, freshness, unavailable context, untrusted content, prompt injection response, update review, and the conditions that require retesting.

## 7. Tool, Integration, Runtime, and Architecture Requirements

| Component                                                           | Stable ID | Purpose   | Owner   | Trust boundary | Authentication | Allowed operations | Limits   | Timeout and retry | Failure response | Exit path |
| ------------------------------------------------------------------- | --------- | --------- | ------- | -------------- | -------------- | ------------------ | -------- | ----------------- | ---------------- | --------- |
| [Model, runtime, tool, integration, queue, state store, or monitor] | [ID]      | [Purpose] | [Owner] | [Boundary]     | [Method]       | [Operations]       | [Limits] | [Rules]           | [Response]       | [Path]    |

Requirements shall cover:

- Model and runtime capability limits without naming an unapproved vendor
- Isolation, filesystem, network, code execution, and persistence boundaries
- Tool schemas, parameter validation, allowlists, and target confirmation
- Credential brokering without exposing credentials to model-visible context
- Rate, spend, token, latency, concurrency, and resource limits
- External dependency availability, degradation, substitution, and exit
- Queues, schedules, callbacks, webhooks, and duplicate or late delivery
- Portability and replacement requirements for models, runtimes, context, and tools

## 8. Quality, Evaluation, and Acceptance Requirements

| Measure ID | Requirement IDs | Population and conditions | Numerator and denominator | Source and window | Required threshold | Stop threshold | Reviewer   | Evidence    |
| ---------- | --------------- | ------------------------- | ------------------------- | ----------------- | ------------------ | -------------- | ---------- | ----------- |
| [ID]       | [IDs]           | [Population]              | [Definition]              | [Reference]       | [Threshold]        | [Threshold]    | [Reviewer] | [Reference] |

Define representative normal, variation, boundary, ambiguous, missing-data, conflict, prohibited, malicious, failure, recovery, and change cases. Include failed, aborted, retried, rejected, escalated, and manually corrected runs under precommitted denominator rules.

Acceptance requirements shall cover:

- Primary workflow outcome against a measured baseline
- Task quality and required-field completeness
- Prohibited outcomes and zero-tolerance control failures
- Authorization, approval, tenant isolation, and data-boundary tests
- Prompt injection, unsafe tool call, timeout, retry, duplicate, and recovery tests
- Human edit, rejection, escalation, review time, and queue-load measures
- Reliability, latency, cost, support load, and accessibility
- Independent review where policy or risk requires it
- Conditions similar to the intended deployment, with every material difference recorded

A passed evaluation verifies only the tested release, conditions, requirements, and evidence. It does not approve a pilot, production release, or wider authority.

## 9. Security, Reliability, Monitoring, and Evidence Requirements

| Signal or event | Requirement IDs | Source   | Required dimensions                                                | Threshold   | Alert route | Response owner | Retention | Evidence trust level |
| --------------- | --------------- | -------- | ------------------------------------------------------------------ | ----------- | ----------- | -------------- | --------- | -------------------- |
| [Signal]        | [IDs]           | [System] | [Tenant, principal, agent, run, target, action, version, and time] | [Threshold] | [Route]     | [Owner]        | [Period]  | [Level]              |

Requirements shall cover threat modeling, input and output validation, tenant isolation, data loss prevention, tamper-evident evidence, dependency failure, safe degradation, suspension, incident response, recovery, and reconciliation.

For context evidence, distinguish compilation, response issuance, integration acknowledgment, host-confirmed session injection, and agent consumption. One stage does not prove the next. Record consumption only from direct, authenticated attestation by a trusted integration or provider; otherwise record it as unknown.

Target-system confirmation is required for consequential external effects. An agent trace alone does not prove that an action completed, a queued action was canceled, or downstream state was restored.

## 10. Human Experience, Accessibility, and Operating Requirements

- User notice and disclosure: [Requirements]
- Supported user roles and training: [Requirements]
- Human review capacity and service levels: [Requirements]
- Handoff content and destination: [Requirements]
- Override, correction, appeal, and feedback: [Requirements]
- Accessibility and language support: [Requirements]
- Support ownership and escalation: [Requirements]
- Operator proficiency and recertification: [Requirements]
- Documentation and runbooks: [References]
- Monitoring and review cadence: [Schedule]

Automation must not silently transfer work to reviewers. Define queue capacity, unavailable-reviewer behavior, after-hours handling, and the response when human review cannot occur within the required time.

## 11. Stop, Recovery, Change, and Retirement Requirements

| Boundary                                  | Stop or rollback method                     | Owner   | Confirmation source   | Deadline | Missing-confirmation response | Last test  |
| ----------------------------------------- | ------------------------------------------- | ------- | --------------------- | -------- | ----------------------------- | ---------- |
| New and in-flight runs                    | [Method]                                    | [Owner] | [Reference]           | [Time]   | [Escalation]                  | [Evidence] |
| Credentials and sessions                  | [Method]                                    | [Owner] | [Reference]           | [Time]   | [Escalation]                  | [Evidence] |
| Queues, schedules, callbacks, and retries | [Method]                                    | [Owner] | [Reference]           | [Time]   | [Escalation]                  | [Evidence] |
| Pending approvals and held actions        | [Invalidate or require fresh authorization] | [Owner] | [Target confirmation] | [Time]   | [Escalation]                  | [Evidence] |
| Child agents and delegated grants         | [Method]                                    | [Owner] | [Reference]           | [Time]   | [Escalation]                  | [Evidence] |
| Tools, integrations, and context routes   | [Method]                                    | [Owner] | [Reference]           | [Time]   | [Escalation]                  | [Evidence] |
| Persistent state and external work        | [Method]                                    | [Owner] | [Reference]           | [Time]   | [Escalation]                  | [Evidence] |

Define material-change triggers for purpose, users, affected people, authority, data, context, tools, model, runtime, controls, evaluation, external effects, or obligations. Each trigger shall state which requirements and tests reopen.

Retirement requirements:

- Decision authority and effective date: [Rule]
- User and affected-party notice: [Requirement]
- Replacement or manual fallback: [Reference]
- Identity, credential, grant, route, integration, schedule, queue, callback, and delegation removal: [Requirements]
- Data, Memory, Artifact, log, and evidence retention or deletion: [Requirements]
- Pending and external action reconciliation: [Evidence]
- Final activity and access verification: [Evidence]
- Inventory, ownership, and documentation update: [Evidence]

## 12. Review, Baseline, and Change Record

Requirement review:

| Reviewer                  | Scope             | Decision                    | Conditions or unresolved items | Evidence              | Date   | Expiry |
| ------------------------- | ----------------- | --------------------------- | ------------------------------ | --------------------- | ------ | ------ |
| [Authenticated principal] | [Requirement IDs] | [Accept, Return, or Reject] | [Items]                        | [Protected reference] | [Date] | [Date] |

Baseline decision:

- Decision: [Approve baseline | Return for changes | Reject]
- Authenticated decision maker: [Principal]
- Authority source and effective role: [Reference]
- Exact requirements version: [Version or digest]
- Workflow, environment, and tenant scope: [Boundaries]
- Included and excluded requirement IDs: [IDs]
- Evidence cutoff: [Time]
- Conditions and due dates: [List]
- Decision time and expiry: [Times]
- Protected decision evidence: [Reference]

Change record:

| Change ID | Requirement IDs | Reason and source | Impact analysis | Required retests and reviews | Decision   | Effective version |
| --------- | --------------- | ----------------- | --------------- | ---------------------------- | ---------- | ----------------- |
| [ID]      | [IDs]           | [Reason]          | [Impact]        | [Tests and reviewers]        | [Decision] | [Version]         |

An approved requirements baseline authorizes design and verification only within the stated decision. It does not grant runtime access or approve deployment. Reconcile implemented behavior and observed configuration against the exact baseline before each pilot or release decision.