AI agent requirements should describe the task, available information, connected tools, action boundaries and how results will be checked. They provide a shared basis for decisions. A feature list without examples or acceptance criteria leaves important assumptions unresolved.
Describe the workflow first
Identify the user, the task trigger and the expected outcome. Explain how the work happens today: systems used, information consulted, approvals and exceptions. Include anonymised examples where sharing is permitted.
Define the first scope and its exclusions. An out-of-scope request should be handed to an appropriate person with context rather than inviting an improvised answer.
A reusable requirements outline
| Area | Information to provide |
|---|---|
| User | Role, context and practical need |
| Trigger | Message, form, event or manual action |
| Data | Sources, owner, freshness and access rights |
| Tools | Available actions, interfaces and constraints |
| Result | Format, recipient and approval process |
| Boundaries | Prohibited actions, limits and exceptions |
| Operation | Owner, monitoring and fallback |
The outline can remain concise. Its purpose is to expose disagreements and missing information, rather than to create a long specification for its own sake.
Make acceptance observable
Replace “the agent answers correctly” with concrete situations. For example, a complete request produces a draft from permitted sources; a missing reference leads to clarification; a sensitive operation waits for the required approval. These are illustrative criteria, not promises about a particular system.
Specify what the result must include and what must never be exposed. Build an example set with expected outcomes or review instructions. Reviewers should be able to explain why a case passes or fails.
Distinguish instructions from permissions
Telling an agent to follow a rule does not itself restrict its technical access. Identify actual permissions, application-level controls and human approval points. External documents may contain hostile instructions, a risk discussed by OWASP.
Document who provides test access, which data may be used and how issues are reported. Security decisions apply to the whole workflow, not only its prompt.
Make uncertainty explicit
Separate confirmed points, assumptions to test and decisions still required. Give each uncertainty an owner and a way to resolve it. Keep unknown dependencies visible in estimates. Define what evidence would support expanding the pilot.
The existing AI product discovery playbook addresses product value and scope. These requirements complement it by specifying the agent’s behaviour and limits.
Common questions
Must we choose a model immediately? No. Start with constraints and evaluate the choice against real examples and integration needs.
Can we consult a partner while questions remain? Yes. An initial discovery phase can resolve identified uncertainties and establish feasibility.
Who signs off the requirements? Business and technical owners should share acceptance criteria, with data and access owners involved in their areas.
Continue with agent budgeting and agent security. Discuss your project with Binov.
