A requirements document for an AI agent should make the future system easier to build, test, and say no to. It is not a wish list of everything the model might do.

Describe the job in context

Write who the user is, what starts the interaction, what information is available, and what a successful outcome looks like. Include the current process and the point where the agent should help. “Answer questions” is not enough; “help a support adviser find the current policy and draft a reply” gives the team something to design.

Define knowledge and permissions

• Which sources are authoritative?
• Who owns and reviews them?
• Which users, tenants, or roles may retrieve each source?
• How quickly must changes appear?
• What should happen when the answer is not found?

Document the data the agent must never expose. Retrieval relevance and access control are separate requirements; both belong in the document.

Define actions and boundaries

List each tool, its inputs, outputs, side effects, approval requirement, timeout, and retry behaviour. Say what the agent may suggest, what it may execute, and what must always go to a person.

Include examples of normal, ambiguous, adversarial, and out-of-scope requests. Those examples become the first evaluation set and help different stakeholders discuss the same behaviour.

Define operations before launch

Specify logging, redaction, retention, cost limits, latency expectations, monitoring, incident ownership, rollback, and the kill switch. Name the person responsible for source quality and the person responsible for the integration.

Finally, define acceptance criteria and a pilot stop rule. A good requirements document does not promise autonomy. It makes the intended boundary clear enough that the team can test it honestly and improve it safely.