How to Write an AI Agent Scope of Work: A Template That Prevents Costly Misalignments

Why Most AI Projects Go Wrong Before They Start

Most AI agent projects that fail or disappoint do so for reasons that were visible before a line of code was written. A scope that was too vague. Integrations that were assumed but not specified. Success metrics that were never agreed. Edge cases nobody surfaced in the kickoff.

A good scope of work prevents most of these failures. It forces clarity before money changes hands. It creates a shared understanding between client and developer. And — maybe most importantly — it gives both parties a reference point when something gets disputed three months in.

What follows is a complete template for an AI agent SOW. Use it to brief a developer, to evaluate a proposal you've received, or to structure the pre-project conversation that determines whether a build is going to succeed.

AI Agent Scope of Work Template

Section 1: Project Overview

1.1 Background

Describe the business context in two to three paragraphs:

• What does the business do?
• What problem is this agent solving?
• How is this handled today?
• What's prompting this project now?

Example: "Acme Retail is a UK-based online clothing retailer processing 2,000 orders per month. Customer support is currently handled by two part-time staff who spend approximately 35 hours per week responding to support emails. The majority of queries are order status checks, return requests, and product questions. Response times average 8–12 hours. The business is growing and cannot scale support headcount proportionally."

1.2 Project Goal

One sentence. What's the agent supposed to achieve?

Example: "Build and deploy an AI customer support agent that handles at least 65% of inbound support emails automatically, reducing average response time to under 5 minutes."

1.3 Success Criteria

List three to five measurable outcomes that define project success. These become the basis for acceptance at delivery.

Section 2: Agent Scope

2.1 In Scope — What the Agent Handles

List every interaction type the agent is expected to handle. Be specific.

2.2 Out of Scope — What the Agent Does NOT Handle

Be equally specific about what the agent won't do. Ambiguity here is what causes scope creep — usually three months in, when someone says "but I assumed the agent would also handle…"

• Complaints involving legal claims or formal dispute processes
• Requests for partial refunds outside the defined return policy
• Custom orders or bespoke product requests
• Any query not listed in the In Scope table above

2.3 Escalation Definition

Define exactly when and how the agent escalates to a human:

Section 3: Technical Specification

3.1 Communication Channels

List every channel the agent will operate on:

• Website chat widget (specify platform: Intercom / Crisp / custom)
• Email (specify: inbound address, send-from address)
• WhatsApp (specify: WhatsApp Business account required)
• SMS
• Other: ___

3.2 Integrations Required

List every system the agent needs to connect to, with read/write requirements:

3.3 Data and Authentication

How will the agent verify customer identity before accessing account data?

Example: "Customer identity verified by matching email address in the incoming email against the Shopify customer record. For sensitive actions (refund initiation), additional verification via order number required."

3.4 Knowledge Base

What information will the agent use to answer questions?

3.5 LLM and Infrastructure

Specify (or ask the developer to specify):

• Which LLM provider and model (see Anthropic's documentation or an equivalent provider's docs for current model specifications)
• Hosting infrastructure (cloud provider, region)
• Data residency requirements
• Expected query volume (queries per day/month)
• Expected response time requirement (p95 target)

Section 4: Non-Functional Requirements

4.1 Security

These should mirror the practices covered in AI agent security:

• Data encryption requirements (in transit, at rest)
• Authentication and authorisation requirements
• Audit logging requirements
• Third-party data processing agreements
• Penetration testing requirements (if applicable)

4.2 Compliance

List applicable regulatory requirements:

• GDPR / UK GDPR data handling requirements — see the ICO for current guidance
• Industry-specific requirements (FCA, HIPAA, etc.)
• Consumer protection requirements

4.3 Performance

4.4 Monitoring and Alerting

Define what monitoring is required and who receives alerts:

• Real-time error rate monitoring — alert if error rate exceeds 5% in any 30-minute window
• Daily performance dashboard accessible to client
• Weekly automated performance report delivered to [email]
• Monitoring access: client has read-only access to all monitoring dashboards

Section 5: Deliverables

Every deliverable the developer is responsible for at the end of the project:

• Deployed AI agent on [channels specified in 3.1]
• All integrations listed in 3.2 connected and tested
• Knowledge base loaded with content listed in 3.4
• Monitoring dashboards configured and accessible to client
• Handover documentation (architecture, how to update knowledge base, how to adjust escalation rules)
• Source code transferred to client repository
• Post-launch support period: [X weeks] of monitoring and rapid response included

Section 6: Timeline and Milestones

Section 7: Ownership and IP

Explicit statements on:

7.1 Code ownership: All code, prompts, configuration, and documentation created for this project is the sole property of [Client name] upon final payment.

7.2 Data ownership: All customer data, conversation data, and knowledge base content is the sole property of [Client name]. The developer has no rights to use this data for any purpose other than delivering the project.

7.3 Third-party licences: List any third-party tools, APIs, or services used, and confirm the client has or will have their own accounts for these.

Section 8: Acceptance Criteria

Define how delivery will be accepted:

Technical acceptance: All integrations pass automated test suite. Error rate below 1% over 48-hour monitoring period.

Functional acceptance: Agent correctly handles [X] representative test scenarios — built the way we outline in AI agent testing and QA — covering all in-scope interaction types.

Performance acceptance: Response time p95 below [X] seconds under [Y] concurrent users.

Success criteria acceptance: Measured against success metrics in Section 1.3 at [30/60/90] days post-launch.

Where Even a Good SOW Fails You

Two honest caveats before you treat this as a complete safety net. First, an SOW only protects you if both sides actually read it after signing. We've watched projects where the SOW was beautifully detailed and then immediately ignored, because the day-to-day conversation drifted into Slack and decisions got made that contradicted what was on paper. The SOW is a reference point, not a contract that runs itself.

Second, the level of specificity this template asks for can paralyse a kickoff if you treat it as a checklist to fill in. The point isn't to answer every question perfectly on day one — it's to surface the questions you can't answer yet, because those are the things that will bite you in week six if they aren't surfaced. A "we don't know yet, we'll figure out by week 2" answer in Section 3.5 is more useful than a confident wrong answer.

Related guides

• How to run an AI agent discovery workshop
• How to write a good AI agent brief
• How to evaluate AI agent vendors
• 7 red flags that your AI agent developer can't deliver
• AI agent development services

Using This Template

Share this template with any AI developer you're evaluating. Ask them to complete Sections 3 and 4 as part of their proposal. The quality and specificity of their answers tells you more about their capability than their portfolio does.

For developers who can't fill in Section 3 specifically — who can't tell you which LLM they plan to use and why, who can't describe the integration architecture — that's important information before you sign anything.

If you want help drafting a scope of work before you decide who to work with — even if you ultimately don't work with us — we're happy to do that.

Talk to us about your project — no commitment, just a conversation.

Frequently Asked Questions

What is an AI agent scope of work and why do I need one?

An AI agent scope of work (SOW) is a written document that defines exactly what an AI system will do, what it will not do, how success is measured, and what both parties are responsible for delivering. You need one because AI projects are particularly prone to misalignment — the technology is new, expectations are often inflated, and integration complexity is easy to underestimate. A clearly written SOW prevents the "but I assumed it would also…" conversations that derail projects and erode client-developer trust.

How detailed does an AI agent SOW need to be?

It needs to be detailed enough that both parties can independently read it and reach the same understanding of what is being built. In practice, that means every integration listed by name with its read/write requirements, every interaction type the agent will handle listed explicitly, success metrics that are measurable and time-bound, and a clear escalation definition. Vague language like "the agent will handle customer queries" is not a scope — it is the beginning of a dispute.

Who should write the AI agent scope of work — the client or the developer?

The best SOWs are written collaboratively. The client should own Sections 1 and 2 — the business context, what the agent will and will not handle, and what success looks like. The developer should own Sections 3 and 4 — the technical architecture, integration design, and non-functional requirements. Both parties should review and sign off on the complete document. If a developer hands you a proposal without completing the technical sections, treat that as a red flag.

What happens if something is missing from the scope of work after the project starts?

Anything not in the scope of work is out of scope by default. If a new requirement emerges mid-project, it should go through a formal change request process — the new work is scoped, priced, and agreed before it begins. This is not a technicality; it is what keeps AI projects financially predictable. The SOW template in this article includes an explicit out-of-scope list precisely to prevent the "but I assumed" problem.

How long does it take to write an AI agent scope of work?

For a well-understood use case — a customer support agent for a Shopify store, for example — a thorough SOW can be drafted in two to four hours if the right people are in the room. More complex projects with multiple integrations, compliance requirements, or novel agent behaviour may take several sessions across a week. The time spent on the SOW is almost always repaid by the time it saves in disputed work, rework, and misaligned expectations later in the project.

What should I check before signing an AI agent SOW from a developer?

Check that Sections 3 and 4 are completed specifically — not with placeholders like "TBD" or "as agreed." Confirm the success criteria in Section 1.3 are measurable and tied to a measurement window, not vague outcomes. Verify the out-of-scope list is explicit, not implied. Make sure the acceptance criteria define how delivery will actually be tested. And confirm that IP and data ownership are stated clearly: you should own the code and all customer data with no exceptions.

Can I use this SOW template for AI agents beyond customer support?

Yes. The structure applies to any AI agent project — sales qualification agents, internal knowledge assistants, document processing agents, scheduling agents, or anything else. Swap out the example content in each section for your use case. The principles are the same regardless of the agent type: define what it handles, what it does not handle, how it escalates, what systems it connects to, and how success is measured.