AI Agent Statement of Work: What to Put in It, Section by Section

An AI agent statement of work is a short document that defines one role for the agent, what will be delivered, which systems and permissions it receives, who approves what, how acceptance is judged and how everything is handed over. It should be specific enough that a new employee on either side could read it and know what the agent does, what it must never do and how anyone would know it works. Six parts cover most of what you need: role, deliverables, access, approvals, acceptance and handover.

Key takeaways

• Write the statement of work around one named role, not around a technology or a list of features.
• List deliverables as things you can inspect: configured access, written instructions, tested workflows, a monitoring view, documentation.
• Treat access and approvals as the core of the document. They decide what the agent can do when nobody is watching.
• Define acceptance as observable behavior against agreed examples, and name who signs it off.
• Put handover in from the start: the accounts, memory, instructions and records must stay with your company.

Why does an AI agent need a different kind of statement of work?

A traditional software statement of work describes a system that behaves the same way each time. An agent works differently. It reads context, makes choices, uses tools and sometimes acts on your behalf. Two identical requests can produce slightly different paths, and the agent will meet situations nobody listed in advance.

That changes what the document must do. It cannot only promise features. It has to fix the boundaries within which the agent is allowed to use judgment, and it has to say who is responsible when the agent reaches the edge of those boundaries.

A vague statement of work usually fails in one of three ways. The role is described as "help with operations", so nobody can say whether the agent did its job. The access is granted broadly because it was easier, so a mistake has a wide reach. Or the engagement ends and the company discovers that the instructions, the memory and the accounts sit inside the vendor's environment.

Each section below closes one of those gaps. If you have not yet decided what the role should be, start with the exercise in Write a Job Description for Your First AI Agent Role and bring the result into the document.

Role and deliverables: what is the agent hired to do, and what will exist when the work is done?

Start with the role, written the way you would write a job description. Name the role, the team it serves, the work it takes on and the work it explicitly does not take on. The exclusions matter as much as the inclusions, because they prevent quiet growth of scope.

A useful role section contains:

• A one-sentence purpose, for example: answers internal questions about open orders using the order system, and drafts replies for staff to send.
• The inputs it receives and from which channels.
• The outputs it produces and where they go.
• Out-of-scope tasks, stated plainly.
• The human owner of the role on your side, who answers questions and decides on changes.

Then list deliverables. This is where many documents drift into promises about intelligence or outcomes. Keep deliverables concrete and inspectable. For a first engagement, they typically include:

• The agent's written instructions and operating rules.
• The memory or knowledge sources it may draw on, and how they are kept current.
• The tools it can call, each with its purpose.
• The channels where people reach it.
• Test cases used to check behavior before launch.
• A monitoring view showing what the agent did and where it failed.
• Documentation sufficient for your team to understand and operate the setup.

A deliverable is something you could point to and verify. "A smarter assistant" is not a deliverable. "A set of test cases covering the twenty most common requests plus the situations where the agent must refuse or escalate" is.

Keep the first engagement narrow. One role with a clear boundary is easier to accept, easier to fix and easier to extend later. If you are weighing several candidates, How to Prioritize AI Use Cases: A Four-Factor Scoring Method helps you pick the first one before you write anything.

Access: which systems, accounts and permissions does the agent get?

Access is where an agent's usefulness and its risk meet. The statement of work should list every system the agent touches, the level of permission in each and the reason for it. If a permission has no stated reason, it should not be granted.

A few principles keep this section honest:

• Least privilege. Start with read access and add write access only where the role demands it, one action at a time.
• Separate identity. The agent should have its own account in each system, so its actions are visible and revocable without touching a person's login.
• Company ownership. The accounts, API keys and model provider accounts should be registered to your company, not to the implementer. The reasoning is covered in Who Owns AI API Keys in a Business? Company vs Provider Accounts.
• Named data scope. State which data the agent may read, which it must never see and where processed data is stored.
• Provider terms. Record whether the model provider may retain or train on your data, as agreed in writing.

For the authorization design itself, the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is a solid reference on deny-by-default and per-request checks. You do not need to copy it into the contract, but your technical contact should be able to explain how the agent's permissions follow those ideas.

A simple way to present this section is a table in your own words, with one row per system. Since the journal format here is plain text, a list per system works equally well:

• System name and owner on your side.
• The agent's account name.
• Allowed actions (read, draft, update, send).
• Prohibited actions.
• Who can revoke access and how quickly.
• Review date for the permission.

The last two lines are often forgotten. Access that cannot be revoked quickly or reviewed regularly will accumulate until nobody remembers why it exists.

Approvals: who decides what the agent may do alone?

The approvals section turns your risk tolerance into rules. For every action the agent can take, decide which of three modes applies:

• Act alone: low-impact, reversible actions, such as looking up a record or drafting a reply that nobody sees until a person sends it.
• Act, then report: actions that are easy to undo and are logged for later review.
• Ask first: anything that moves money, changes a customer record, sends external communication, deletes data or commits the company to something.

Write these as a decision guide the agent's instructions can follow. For each action, name the approver by role rather than by person, and state what happens if no approver responds. The default should be that the agent waits or escalates, not that it proceeds.

This section should also cover change control. Who may alter the agent's instructions, tools or permissions after launch? How are changes tested and rolled back? A short rule such as "no change to a live agent without a recorded approval and a test run" prevents most surprises. For the practical side of this, see How to Update an AI Agent in Production Without Breaking It.

Finally, include an incident clause. If the agent does something it should not have, who is notified, who can pause it and what is the first response? Pausing the agent should be possible for your team without asking the vendor for permission.

For a broader framing of risk and accountability, the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) offers vocabulary many leadership teams find useful. It is a reference, not a requirement for a first statement of work.

Acceptance and handover: how do you know it works, and what do you keep?

Acceptance answers a plain question: what must be true for you to say the work is done? Avoid acceptance language based on feelings, such as "the team is satisfied". Use observable criteria agreed before the build.

Good acceptance criteria usually include:

• A set of example requests with expected behavior, including examples where the correct behavior is to refuse or hand off.
• A review of real outputs by the role owner over an agreed period.
• Evidence that approval rules fire when they should.
• Evidence that logs and monitoring show what the agent did and why.
• A named signer on your side.

How to measure a trial period is its own topic, covered in How to Define Success Criteria for an AI Agent Pilot. On the evaluation method, Anthropic's piece [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) explains why test cases built from real tasks matter more than general impressions. For visibility into running behavior, the [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) describes logs, metrics and traces in terms your technical lead will recognize.

Handover is the other half of closing the work. Specify what you receive and in what form:

• Written instructions and operating rules, in a readable format.
• The memory and knowledge sources, with a description of how they are maintained.
• Tool and integration definitions.
• The test cases and the results of the latest run.
• An inventory entry for the agent: owner, purpose, systems, permissions, review dates.
• A runbook for pausing, restoring and changing the agent.
• A statement of what data the implementer holds, and how it will be returned or deleted.

The purpose is simple: if the relationship ended tomorrow, your company could keep the agent running or move it elsewhere. The practical detail is in AI Provider Exit Strategy: What to Keep, Export and Document.

If the agent will be operated by a provider after launch, add a short operations clause that says what is monitored, how often reviews happen and what response times apply to incidents. What to promise and what to leave out of that clause is discussed in AI Agent SLA: What to Define in Writing, and What Not To.

An illustrative scenario and a checklist for reviewing any draft

Here is an illustrative scenario, not a real engagement. A distribution company wants an agent for its customer service team. The role: answer staff questions about order status and draft replies to customers. The statement of work says the agent has read access to the order system through its own account, can draft but not send emails, and must ask a named team lead before any refund or address change. Deliverables include the instructions, the draft templates, a monitoring view and a set of test cases. Acceptance is a review of drafted replies by the team lead over an agreed trial, plus a check that every refund request was escalated. Handover includes all of the above, plus the accounts registered under the company's name.

Notice how small that is. It does not describe a transformation. It describes one role that can be checked.

Use this checklist on any draft, whether you wrote it or a vendor did:

• Is there exactly one named role, with exclusions?
• Is there a named owner on your side?
• Does every deliverable have a way to be inspected?
• Does every system have a stated permission level and a reason?
• Does the agent have its own accounts, registered to your company?
• Is every consequential action assigned to act alone, report or ask first?
• Can your team pause the agent without the vendor's help?
• Are acceptance criteria written as examples and observations, with a named signer?
• Does handover cover instructions, memory, tools, tests and records?
• Is there a stated position on data retention and provider training?

How Be Human approaches this: a first engagement is scoped around one useful role, with the memory and tools it needs, written approval boundaries and an observable success criterion. The agent runs under its own identity and accounts, and the instructions, permissions and context remain under your control. Where managed operations are included, they cover monitoring, recurring evaluations, integration maintenance, permission review and incident response, and each of those is written into the document as a defined activity rather than a general promise.

If you are still comparing partners before drafting, How to Choose an AI Implementation Partner for Your Company lists what to look for.

Frequently asked questions

How long should an AI agent statement of work be? It should be as short as it can be while still covering role, deliverables, access, approvals, acceptance and handover. For a single role, a few pages is usually enough. If the document grows because several roles are bundled together, split it into separate statements of work.

Who should sign off on the statement of work? The business owner of the role should sign, because they will live with the agent's behavior. A technical lead should confirm the access section, and whoever handles data protection or legal review should check the data and provider terms. Signing off by role keeps the document valid if people change jobs.

Should the statement of work promise specific results? It is safer to promise inspectable work and agreed tests rather than business outcomes. Results depend on your data, your processes and how your team uses the agent. Define success as observable behavior against examples and a review period, and keep outcome targets in your internal business case.

What happens when the agent's role needs to grow? Treat it as a change, not a quiet expansion. Write an amendment that updates the role, access, approvals and acceptance sections, test the new behavior, and record the approval. This keeps each stage of the agent's responsibility visible and reversible.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.