An AI agent scope of work should define five things before build starts: what the agent is for and how success is measured; what it may do alone, with approval, and never; how it will be accepted, using pass rates on an agreed evaluation set rather than a demo; what it costs to run and how it changes when models are updated or retired; and who owns the prompts, evaluations and liability at the end. A scope that leaves any of these vague usually turns into a dispute at the first acceptance meeting.
Key Takeaways
- Write three autonomy lists: actions the agent takes alone, actions that need human approval, and actions it must never take.
- Agree an evaluation set and pass thresholds before build. Agent output varies between runs, so acceptance must be a pass rate across repeated runs.
- Separate the build fee from running costs such as model tokens, tools, hosting and human review, and put budgets and hard caps in writing.
- Plan for model changes: Anthropic gives at least 60 days’ notice before retiring publicly released models, so the scope must say who watches and how the agent is re-tested.
- Make sure prompts, evaluation sets, tool definitions and configuration transfer with the code, or the next team starts from zero.
Talk to Our Team About Your Project ->
What Makes Something an AI Agent?
An AI agent is software that uses a language model to decide what to do next in pursuit of a goal, then acts on that decision through tools. A chatbot answers; a fixed workflow follows steps someone wrote in advance; an agent plans its own steps, calls systems, checks the results and keeps going until the task is done or it hands over to a person.
Most production agents are built from the same five parts, and each one needs its own lines in the scope of work:
- Model: the reasoning engine that interprets the task and chooses the next action.
- Instructions: the system prompt and policies that define the agent’s role, tone and limits.
- Tools: the APIs, databases and applications the agent can read from or write to.
- Memory and context: the conversation history, retrieved documents and stored state the agent works from.
- Control loop and guardrails: the plan, act, observe cycle that repeats until completion, plus the approval gates, budgets and stop conditions around it.
The more of these parts a system has, and the more freedom it has to combine them, the more “agentic” it is. That freedom is what makes agents useful, and it is also what the scope of work has to bound.
Why Does an AI Agent Need a Different Scope of Work?
An AI agent needs a different scope of work because it behaves differently from conventional software. A normal application does the same thing every time for the same input; an agent reasons, chooses tools and may produce a different result on the next run. It also keeps costing money after launch and can change behaviour when its underlying model changes, even if nobody touches the code.
These differences explain why many agent projects stall. Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027 due to escalating costs, unclear business value or inadequate risk controls. A strong scope of work addresses all three before any code is written.
How AI Agents Evolved
Agents are the latest step in a long line of automation, and each step shifted more decisions from the developer to the system:
- Rules and scripts: rule-based chatbots and robotic process automation (RPA) followed fixed paths. They were predictable but broke whenever an input or screen changed.
- Conversational language models (2022): general-purpose chat models could understand and write natural language, but they could only produce text, not act.
- Tool use (2023): function calling and reasoning-and-acting patterns such as ReAct let models call APIs, read the result and decide the next step. This is the core of every modern agent.
- Standard connectors and computer use (2024): open protocols such as the Model Context Protocol made it easier to connect agents to business systems, and models began operating browsers and desktop applications directly.
- Production agents (2025 onward): long-running and multi-agent systems now handle support, operations, research and coding tasks end to end, often with real write access to company systems.
Each step widened what the software could do without a person in the loop. Contracts written for the scripted era assumed the developer decided every step; an agent scope of work has to define the decisions the system is now allowed to make on its own.
Part 1: Purpose and Boundaries
1. Business objective and success metric
State the problem in business terms, the metric that proves it is solved, the current baseline, and how and when the metric will be measured after launch. Examples: share of support tickets resolved without a person, average handling time, or analyst hours saved per week.
2. Client responsibilities and out-of-scope items
List what the client must provide and by when: system access, sample data for the evaluation set, subject-matter experts and time for testing. Add an explicit out-of-scope list. When a milestone slips, this section shows whether the cause was the vendor, the client or an upstream provider.
Part 2: What the Agent May Do
3. Autonomy limits
This is the most important section and the one most often left vague. Write it as three lists.
The “never” list matters most. Without it, every surprising action becomes an argument about what the agent was supposed to do.
4. Tools, systems and permissions
List every system the agent connects to, whether access is read-only or read-write, the exact permission scope, and who provisions and rotates the credentials. Grant write access per action, not per system, and default to least privilege.
5. Human approval and escalation
Name who approves each gated action, the expected response time, what happens if nobody responds, and how the agent hands a case to a person with full context. Approval steps should be enforced in the tools themselves, not only described in the agent’s instructions.
Part 3: How the Agent Is Proven
6. Evaluation plan and acceptance criteria
Agree an evaluation set of realistic tasks, how each task is scored and the pass thresholds before build starts. Because agent output varies, run each task several times and judge the pass rate across runs. Include a regression suite that runs on every change, and a sample of production outputs reviewed by people after launch.
State what happens when a threshold is missed: a fixed remediation window, a rerun on the same set at no extra cost, and the right to reject the milestone after an agreed number of failed attempts.
7. Security requirements and testing
Tie security to recognised public references so both sides share a baseline. OWASP published the 2026 edition of its Top 10 for LLM Applications on August 3, 2026, with prompt injection and sensitive information disclosure at the top and excessive agency rising from sixth to third, alongside a companion Top 10 for Agentic Applications. On May 1, 2026, CISA, the NSA and partner agencies from Australia, Canada, New Zealand and the UK published joint guidance titled Careful Adoption of Agentic AI Services. Coverage of that guidance notes that organisations should assume agentic systems may behave unexpectedly until standards mature.
The scope should name the risks to test, require prompt-injection and red-team testing before launch, and say who fixes findings and by when.
Security considerations for containerization. Agents that run code, browse the web or handle files should do that work inside isolated containers, so a successful prompt injection is contained to a disposable sandbox rather than reaching production systems. The scope should specify:
- Isolation level: standard containers for trusted workloads, and stronger sandboxes such as gVisor or Firecracker microVMs where the agent executes model-generated or user-supplied code.
- Least-privilege runtime: non-root users, read-only file systems, dropped Linux capabilities and no access to the host, the container runtime socket or shared volumes.
- Network egress control: an allowlist of domains and internal services the container may reach, with everything else blocked to prevent data exfiltration.
- Ephemeral environments: a fresh container per task or session, destroyed afterwards, so no data or compromise carries over between users.
- Secrets handling: short-lived, narrowly scoped credentials injected at runtime, never baked into images or exposed to the model’s context.
- Resource limits: CPU, memory, disk and time caps per container, which also guard against runaway loops and unbounded cost.
- Image supply chain: pinned and minimal base images, vulnerability scanning in the build pipeline and a software bill of materials for each release.
8. Observability, logging and audit
Require a trace of every model call, tool call and decision, with retention periods and access rules. Standard formats such as OpenTelemetry’s GenAI agent conventions keep traces portable between tools. Without traces, neither debugging nor audits are possible.
Part 4: Costs, Reliability and Change
9. Running costs and budget limits
Separate the build fee from running costs and say who pays each bill.
Agree an estimated cost per completed task, a monthly budget, hard caps per task and alerts when spend spikes. Unbounded consumption is now an OWASP top-ten risk in its own right, rising from tenth to sixth in the 2026 list.
10. Model and hosting choices
Name the models in scope, any fallback model, where the system is hosted and where data is processed. Hosting and data residency can decide compliance on their own. Allow model substitution, subject to re-running the acceptance evaluation, so the agent is not locked to one provider.
Open-source versus closed models. The choice between a closed, API-hosted model and an open-weight model changes cost, control and compliance, so the scope should record which is used and why.
- Closed models (for example Claude, GPT and Gemini, used through the provider’s API or a cloud platform) usually offer the strongest capability with no infrastructure to run. In exchange, data is processed by the provider under its terms, pricing is per token, and the provider controls when versions are updated or retired.
- Open-weight models (for example Llama, Mistral, Qwen, DeepSeek or gpt-oss) can be self-hosted in the client’s own cloud or data centre, which helps with data residency, fine-tuning and pinning a version indefinitely. In exchange, the client or vendor owns GPU hosting, scaling, security patching and evaluation, and capability may trail the leading closed models for complex agent tasks.
- Licences: many “open” models are open-weight rather than open source, and their licences can restrict commercial use, user numbers or competing products. The scope should name each licence and who has reviewed it.
A hybrid approach is common: a closed model for complex reasoning and an open-weight model for high-volume or sensitive steps. Whichever route is chosen, the scope should state who hosts each model, who pays for it and how a switch between them is evaluated.
11. Model updates and retirement
Model providers retire models on published schedules. Anthropic commits to at least 60 days’ notice before retiring publicly released models. A comparison of provider policies reports that OpenAI promises at least six months for generally available models, three months for specialised variants, and much shorter notice, such as two weeks, for previews. The same source notes that Anthropic’s September 30, 2026 notice for Claude Sonnet 4.5 set retirement for November 30, 2026, 61 days later.
The scope should keep preview models out of production, name who monitors deprecation notices, require the acceptance evaluation to be re-run on any replacement well before the retirement date, and say how resulting fixes are priced.
12. Reliability and failure handling
State that long-running tasks must resume from the last completed step after a restart, that tools with side effects must be safe to retry without duplicating actions, and what the agent does when a model or tool is unavailable.
Part 5: Ownership, Compliance and Commercial Terms
13. Ownership, IP and handover
Specify that the client owns project-specific code, prompts, evaluation sets, tool definitions, configuration and any fine-tuned models. List the vendor’s background IP, such as reusable frameworks, and require a perpetual licence to whatever the agent needs to run. State that client data, logs and outputs may not be used to train vendor or supplier models without written consent, and require documentation good enough for another team to take over.
14. Compliance responsibilities
Name the rules that apply and who owns each. In the EU, the Digital Omnibus on AI entered into force on July 27, 2026, moving high-risk obligations to December 2, 2027 for stand-alone systems and August 2, 2028 for AI embedded in regulated products. AI Act transparency obligations have applied since August 2, 2026, so the scope should say who ensures people know they are interacting with an AI system. Also name who signs data processing agreements for personal data and, where relevant, health-data agreements.
15. Milestones, payments, liability and warranty
Phase the work and tie payments to evaluation gates rather than calendar dates.
In the scope or the master agreement above it, state who is liable when an agent action causes harm, how liability caps apply, which model-provider terms pass through, and how long the vendor fixes defects after acceptance at no extra cost. Agree these terms with legal counsel.
Get a Custom Project Cost & Timeline Estimate ->
Example Acceptance Criteria
The thresholds below are illustrations, not benchmarks. Set real numbers from your baseline, task and risk level.
| Criterion | How it is measured | Example threshold |
| Task success | Share of evaluation tasks completed correctly across repeated runs | For example, 90% or higher |
| Critical errors | Any forbidden or harmful action on the evaluation set | Zero |
| Correct escalation | Share of cases correctly handed to a person | For example, 95% or higher |
| Grounding | Answers supported by retrieved sources in reviewed samples | For example, 95% or higher |
| Cost per task | Model, tool and hosting spend per completed task | Within the agreed budget |
| Latency | Time to complete a typical task | Within the agreed service level |
Sample Clause Language
Starting points only; adapt with your legal counsel.
Autonomy: “The Agent may retrieve records and prepare draft responses without approval. The Agent shall issue refunds or send messages outside the Client’s organisation only after approval by a Named Approver. The Agent shall not delete data, alter user permissions or contact any customer on the Exclusion List.”
Acceptance: “A milestone is accepted when the Agent meets each agreed threshold on the Evaluation Set across the agreed number of runs, with no Critical Errors. If any threshold is missed, the Vendor shall remediate and re-run the Evaluation Set within the agreed period at no additional charge.”
Model changes: “The Vendor shall monitor provider deprecation notices for all models in scope and shall re-run the Evaluation Set on any replacement model no later than 30 days before the scheduled retirement date.”
Running costs: “The Client pays model, tool and hosting charges directly. The Vendor shall configure per-task caps and spend alerts before launch, consistent with the agreed cost per task.”
Common Mistakes in AI Agent Scopes
Accepting on a demo: one good run says nothing about the next hundred.
No “never” list: every unexpected action becomes a dispute about intent.
Running costs left out: the first model bill should surprise neither side.
Treating the model as fixed: behaviour can change when a provider updates or retires a model.
Handing over code only: without prompts and evaluation sets, the next team cannot maintain the agent.
One-line security clauses: name the risks, the tests and who fixes what.
One-Page AI Agent Scope of Work Checklist
Business objective, baseline and success metric agreed
Client responsibilities and out-of-scope items listed
Autonomy lists written: alone, with approval, never
Systems, permissions and credential owners listed
Approvers, response times and handoff defined
Evaluation set, scoring, repeated runs and thresholds agreed before build
Security risks referenced and tests specified
Tracing, log retention and access agreed
Cost per task, monthly budget, caps and alerts agreed
Models, fallback, hosting and data location named
Model-change monitoring and re-evaluation defined
Resume, retry safety and outage behaviour specified
Ownership of code, prompts, evals and config confirmed; no training on client data
Compliance owners named for each applicable rule
Payments tied to evaluation gates; liability and fix period agreed
How AB Ark Scopes AI Agent Projects
AB Ark starts AI agent projects with a short discovery phase that produces the autonomy lists, the evaluation set and a running-cost estimate before a build fee is committed, then ties later payments to evaluation gates. AB Ark’s published case studies include agents that act on behalf of businesses, such as a 24/7 AI call agent that answers calls and manages bookings across multiple branches, the kind of system where clear autonomy limits and approval rules matter most. Teams planning an agent can start with AB Ark’s AI agent development service.
FAQs
What should an AI agent scope of work include?
The business objective and metric, client responsibilities, autonomy limits, tool access, human approval rules, an evaluation plan with acceptance thresholds, security testing, observability, running costs and caps, model and hosting choices, model-change handling, failure handling, ownership and handover, compliance owners, and payments tied to evaluation gates with liability terms.
How do you define acceptance criteria for an AI agent?
Agree a set of realistic evaluation tasks before build, decide how each is scored, run each task several times, and set thresholds such as a minimum success rate and zero critical errors. Accept on the pass rate, not on a single demo.
Who pays for model and API costs in an AI agent project?
The scope should name the payer. Commonly the client pays model, tool and hosting bills directly, separate from the build fee, with an agreed cost per task, monthly budget and hard caps.
What happens when the AI model behind an agent is retired?
Providers publish notice periods: Anthropic gives at least 60 days for publicly released models, and OpenAI promises longer notice for generally available models but much shorter for previews. The scope should require monitoring, re-running the acceptance evaluation on the replacement model, and switching before the retirement date.
Who owns the prompts and evaluation sets?
The client should own everything created specifically for the project, including prompts, evaluation sets, tool definitions and configuration, and these should transfer with the code. Vendor background IP usually stays with the vendor, with a licence for whatever the agent needs to run.
Write the “never” list first, agree how the agent will be measured second, and put costs and model changes in writing third. Everything else in the scope gets easier after that.
Schedule a Free Consultation Call ->
CTO & Co-founder At AB Ark Solutions
