ARD: The Agent Requirement Document

Software teams have PRDs (Product Requirement Documents). AI agent teams need ARDs.

An Agent Requirement Document is a structured spec that defines an AI agent’s identity, capabilities, constraints, and success criteria before implementation begins. It’s the difference between building an agent that works and building an agent that wanders.

Why ARDs Exist

Without a clear spec, agent development follows a predictable failure pattern:

Developer gives the LLM a vague prompt
Agent sort of works for the demo
Edge cases multiply exponentially in production
Nobody knows what the agent is supposed to do vs. what it’s actually doing
Six weeks later, the project is abandoned

The ARD Template

Every ARD has seven sections:

1. Identity

**Name:** Sales Follow-Up Agent
**Owner:** Revenue Operations
**Model Tier:** Sonnet (specialist)
**Trigger:** After every sales call transcript is processed

Who is this agent? What’s its role in the organization? What model powers it?

2. Objective

**Primary Goal:** Ensure every sales call results in a follow-up
action within 2 hours.

**Success Metric:** 95%+ of calls have follow-up actions created
within the SLA window.

One sentence. One metric. If you can’t define the objective crisply, you’re not ready to build.

3. Capabilities

**Can:**
- Read call transcripts from the transcription service
- Create tasks in the CRM (Salesforce, HubSpot)
- Draft follow-up emails (saved as drafts, not sent)
- Update opportunity stage and next steps
- Query the calendar for scheduling conflicts

**Cannot:**
- Send emails without human approval
- Modify deal values or forecasts
- Access financial data beyond pipeline stage
- Contact customers directly

Capabilities are a whitelist, not a blacklist. If it’s not listed, the agent can’t do it.

4. Inputs & Outputs

**Inputs:**
- Call transcript (text, from transcription service)
- CRM context (contact, opportunity, last activity)
- Calendar availability (next 5 business days)

**Outputs:**
- CRM task with action items and due date
- Draft follow-up email (in drafts folder)
- Pipeline update (stage, next steps, notes)
- Summary notification to the sales rep

5. Constraints

**Guardrails:**
- Never hallucinate commitments not in the transcript
- Always include a human review step for emails > 200 words
- If unsure about next steps, flag for human review rather than guessing
- Maximum 3 API calls to external services per execution
- Timeout: 60 seconds max execution time

6. Error Handling

**If transcript is empty:** Skip, log warning, notify ops
**If CRM contact not found:** Create a placeholder, flag for review
**If calendar unavailable:** Default to "within 48 hours" for follow-up
**If any API fails:** Retry once, then queue for manual processing

7. Review Cadence

**Weekly:** Spot-check 10% of outputs for quality
**Monthly:** Review success metrics, adjust prompts
**Quarterly:** Full ARD review — still solving the right problem?

When to Write an ARD

Before building any agent that will run in production
Before expanding an existing agent’s capabilities
When an agent starts behaving unexpectedly (the ARD becomes the debugging reference)
When handing off an agent to another team member

Agent Tree Architecture — How agents work together in a hierarchy
Build Your First Agent — Put the ARD into practice
Why Agents Replace SaaS — The business case for agent-first operations

About the author: JD Davenport builds AI agent systems at OpenClaw. Follow on LinkedIn for updates on building AI agents for business.