A statement of work for an ordinary software project describes features. An AI agent is different. It takes actions, its output varies from run to run, and its behavior can shift when a model provider ships an update.
That is why a standard SOW template leaves gaps. This guide walks through each section an AI agent SOW needs, shows sample wording, and explains why each clause protects the buyer.
Why AI Agent SOWs Fail
Most disputes on agent projects trace back to three missing definitions. Nobody wrote down what the agent may do alone. Nobody agreed how "working" would be measured. Nobody said who owns the prompts and tests at the end.
A good SOW turns each of those into a checkable statement. If a sentence cannot be tested or signed off, it belongs in a proposal, not a statement of work.
Section 1: Business Goal and Baseline
Start with one workflow and one number. "Build an AI assistant for support" is a wish. "Reduce first-response time on billing tickets, measured weekly from the helpdesk export" is a goal.
● Name the workflow owner on the client side
● Record the baseline before build starts, with the period measured
● State who counts the result after launch, and from which system
Sample wording: "Baseline is the median time to first response on billing-tagged tickets for the four weeks before kickoff, taken from the helpdesk report by the support manager."
Section 2: Autonomy Limits
This is the clause most templates skip. Write three lists and keep them short.
➤ May do alone: read the knowledge base, draft replies, tag tickets
➤ Needs approval: send a refund, change an account setting, email a customer
➤ Must never do: quote contract terms, delete records, act outside business hours without a named on-call owner
The "must never" list matters most. When an agent surprises someone, the list settles the argument about intent in minutes.
Section 3: Tools, Data and Permissions
List every system the agent touches, with read or write access per system. Name who owns each credential and who can revoke it.
● Systems in scope, with environment (test or production)
● Data sources the agent may retrieve from, and sources it must not use
● Where data is processed and stored, including model provider region
● Retention and deletion of logs, transcripts and embeddings
● A plain statement on whether client data may be used to train any model
Accounts should be created in the client's name where possible. The vendor works as a user, and admin rights stay with the client.
Section 4: Evaluation Set and Acceptance Gates
A live demo shows one run. Acceptance needs many. Agree an evaluation set before the build starts, drawn from real cases, including awkward ones.
● Number of test cases and who supplies them
● Scoring method for each case (pass, fail, partial) and who scores
● Pass thresholds for quality, safety refusals and escalation behavior
● Repeated runs, so variation is visible
● What happens when a gate is missed: fix window, retest, or exit
Tie payments to these gates. A milestone is complete when the deliverable passes its stated check, not when a sprint ends. Our guide to LLM evaluation metrics before launch explains which scores to choose.
Section 5: Human Handoff and Failure Behavior
Agents fail. The SOW should say what happens next, in each channel.
● Who receives an escalation, how, and with what context attached
● Response time expected from that person
● Behavior during a model or tool outage: retry, queue, or hand off
● Whether a failed action can be retried safely without duplicating it
Sample wording: "If the CRM write fails twice, the agent stops, logs the attempt, and creates a task for the queue owner with the full conversation attached."
Section 6: Logging, Tracing and Audit
You cannot investigate what you did not record. Specify what is logged for each run: inputs, retrieved sources, tool calls, outputs and approvals.
State retention, who can access the logs, and how they are exported. For regulated teams, align this section with the documentation practices in the NIST AI Risk Management Framework. Our post on AI agent audit trails goes deeper.
Section 7: Security Testing
One line saying "the vendor will follow best practices" is not a security clause. Name the risks you care about and the tests that cover them.
● Prompt injection through retrieved documents or user input
● Data leakage across users or tenants
● Over-broad tool permissions
● Who fixes findings, and by when
Section 8: Running Costs and Caps
Model, hosting and telephony bills continue after launch. Agree who pays each one and how spend is watched.
● Estimated cost per 1,000 runs or conversations, supplied before launch
● Monthly budget, hard caps and alert recipients
● Whether usage is billed to the client directly or passed through
This avoids the most common post-launch surprise: a first invoice nobody planned for.
Section 9: Model Change Control
Providers update and retire models. Behavior can change with them. The SOW should name who watches for provider changes and how the agent is rechecked.
A simple rule works: any model or prompt change reruns the evaluation set, and results are shared before the change reaches production.
Section 10: Ownership and Handover
Code alone is not a working agent. Make sure the following transfer at the end, along with the right to change them.
● Application code and infrastructure configuration
● Prompts, system instructions and tool definitions
● Evaluation sets, scoring scripts and the last test report
● Runbook covering alerts, restarts and escalation contacts
● Removal of vendor access on a named date
Background IP the vendor reuses should be licensed to you on clear terms.
Section 11: Change Control and Out of Scope
List what is excluded: new channels, new languages, extra integrations. Then describe how a change is requested, estimated and approved.
Public procurement offers a useful model. Performance-based work statements under FAR 37.602 describe outcomes and measurable standards rather than methods, which suits agent work well.
Section 12: Support Window
State how long fixes are included after launch, how issues are reported, and response times by severity. Anything beyond that window is quoted separately.
Weak vs Buyer-Ready Wording
| SOW area | Weak wording | Buyer-ready wording |
|---|---|---|
| Goal | Build an AI agent for support | Cut median first response on billing tickets from a measured baseline |
| Autonomy | Agent handles requests | Three lists: alone, with approval, never |
| Acceptance | Works as demonstrated | Passes agreed evaluation set at stated thresholds over repeated runs |
| Costs | Usage billed as incurred | Estimate per 1,000 runs, monthly cap, named alert owner |
| Handover | Documentation provided | Code, prompts, evals, runbook, access removal date |
A Practical Example
A logistics team wants an agent that answers "where is my order" emails. Their SOW scopes one inbox and two systems: the order database (read) and the helpdesk (write drafts only).
The agent may draft and tag. Sending needs a human click for the first month. The evaluation set holds 120 past emails, including 15 angry ones and 10 with missing order numbers. Payment two releases only when 95 of 120 pass.
That SOW is two pages long. Every line can be checked.
Common Mistakes to Avoid
● Accepting the agent on one live demo
● Listing integrations without access levels
● Leaving running costs to a later conversation
● Handing over code without prompts or tests
How LuMay Approaches Agent SOWs
Our own product note: LuMay builds production AI agents as part of its AI engineering services. Use the checklist above with any vendor, including us. For background, see what AI agent development involves.
Start With One Workflow
Pick a single workflow, measure its baseline and draft the three autonomy lists. Those three steps make the rest of the SOW easier to write. If you want a second opinion on scope, talk to our engineering team.
References
● NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
● FAR 37.602, Performance work statement: https://www.acquisition.gov/far/37.602
● IEEE 3119-2025, Standard for the Procurement of AI: https://standards.ieee.org/ieee/3119/10729/
