How to Write an AI Agent Scope Document

Published August 2026.

TL;DR: A scope document is what turns “I want an AI agent for my business” into a number you can quote and a client can sign off on. It needs six parts: the trigger, the inputs, the outputs, the tools it touches, what’s explicitly excluded, and a written acceptance test list. Write it before you quote a build fee, not after. I price mine as a flat $500–$1,000 audit deliverable, separate from the build.

[Operator’s read] I run 30+ production agents across a consulting brand and Pickleland, a pickleball facility in Pflugerville, TX, and I’ve scoped agent builds for clients on top of that experience. The single most common reason an agent engagement goes wrong isn’t the code — it’s that nobody wrote down what “done” meant before the invoice went out. A scope document fixes that in one sitting. It’s the least glamorous deliverable I produce and the one that saves the most arguments.

Table of contents

Why a scope document, not a proposal email

A proposal email describes what you’ll do. A scope document defines what “done” looks like — specifically enough that you and the client can both check it against the finished agent and agree, without a conversation, whether it passed.

That distinction matters because AI agent pricing only works if the build fee attaches to something fixed. Quote a fixed price against an undefined scope and you’ve quoted a number you can’t actually deliver against — the client’s mental model of “an AI agent for my business” keeps expanding for free until you push back, and pushing back after the deposit is a worse conversation than defining the boundary before it.

I write one for every build, including small ones. A single-workflow agent gets a half-page version. A multi-agent system gets the full document. The format doesn’t change — only the length.

The six things a scope document needs

1. The trigger. What starts the agent running — a form submission, a scheduled time, an inbound email, a webhook from another tool. Name the exact trigger, not a category of trigger. “Runs when a lead form is submitted” is scope. “Handles inbound leads” is not.

2. The inputs. What data the agent receives and where it comes from. List the fields, not just the source — “name, email, company size, and the free-text message field from the Typeform submission,” not “the form data.”

3. The outputs. What the agent produces and where it goes. Same rule: name the destination and the format. “Posts a draft reply to the #leads Slack channel for human approval” is scope. “Responds to leads” is not.

4. The tools and integrations it touches. Every API, database, or platform the agent calls. This is also where you write down anything you’re explicitly not integrating — a client who assumes their CRM is included because they mentioned it once in the discovery call is the most common source of scope creep I’ve seen.

5. What’s excluded. A short, explicit list of things the agent will not do, even if they sound adjacent. If you’re building a lead-classification agent, write “does not send outbound messages” even if that seems obvious — obvious to you isn’t obvious to a client who’s never scoped software before.

6. The acceptance test list. The actual list of cases the finished agent has to pass before final payment is due. Not “works well” — specific, checkable cases: “correctly classifies 9 of 10 sample leads from the provided dataset,” “successfully posts to the connected Slack channel without manual intervention,” “handles a malformed submission (missing email field) without crashing.” This is the single most important section in the document, because it’s the one both sides can point to later without relitigating what was meant.

The template

This is the actual structure I use. Copy it, fill in the six sections, and you have a document you can put a price against.

AGENT SCOPE DOCUMENT — [Client name] / [Project name]
Date: [date]

1. TRIGGER
   [What starts this agent running]

2. INPUTS
   [Exact data fields and their source]

3. OUTPUTS
   [What the agent produces, in what format, sent where]

4. TOOLS & INTEGRATIONS
   Included: [every API/platform/database touched]
   Explicitly excluded: [anything adjacent that is NOT built]

5. EXCLUSIONS
   [What this agent will not do, even if related]

6. ACCEPTANCE TESTS
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   ...

BUILD FEE: $[amount], due [payment terms]
MAINTENANCE RETAINER: $[amount]/month, starting [date]
CHANGE REQUESTS: priced separately, quoted before work starts

Signed: _______________  Date: _______

The build fee and retainer lines exist so the price is anchored directly to the scope above it — see how I size both numbers if you haven’t priced a build before. A client signing this document is signing off on the scope and the price in the same motion, which is the point.

How I run the call that produces this document

I price the scoping session itself as a flat $500–$1,000 audit, separate from the build fee — never folded into it, even when the client proceeds. Two reasons: it keeps the scoping stage from becoming unpaid sales work, and it makes the client take the call seriously instead of treating it as a free consultation.

The call itself is 30–45 minutes, structured around the six sections above in order. I don’t let the conversation wander into “what an AI agent could theoretically do for your business” — that’s a different, more expensive conversation, and it’s the one that produces documents nobody can price. I ask for the trigger first, because a client who can’t name what starts the process usually doesn’t have a stable enough workflow to automate yet — which is worth surfacing before either of you commits to a build.

Ship the prompt, not the blank page

I don’t write the first draft of the document by hand. I take my call notes — often just a messy paragraph of bullet points — and paste this into Claude:

Here are my raw notes from a scoping call for an AI agent build. Turn them
into a scope document with exactly these six sections: Trigger, Inputs,
Outputs, Tools & Integrations, Exclusions, Acceptance Tests. For each
section, flag anything the notes don't specify clearly enough to build
against, rather than guessing or filling the gap yourself. The acceptance
tests need to be specific and checkable — reject vague criteria like
"works correctly" and either sharpen them into a concrete test case or
flag them for me to clarify with the client.

[paste raw notes]

That last instruction — flag the gaps instead of filling them — is the part that matters. A model will happily invent a plausible-sounding acceptance test to complete the document, and a plausible-sounding test that doesn’t match what the client actually meant is worse than a blank you have to go ask about.

Common mistakes I still see people make

Writing the exclusions section last, or skipping it. The exclusions section is the one most people treat as optional. It’s the one that prevents the most disputes. Write it before the acceptance tests, not after.

Acceptance tests that describe behavior instead of results. “The agent should understand the client’s tone” is behavior. “The agent’s draft reply is approved without edits in 7 of 10 sample cases” is a result. Only results are checkable.

Scoping from a single conversation with no written notes. If the scope document is the first written artifact of the engagement, you’re reconstructing the call from memory days later. Take notes during the call, in the six-section order, and the document mostly writes itself.

Letting the client write the scope. A client describing what they want in their own words is input to the document, not the document itself. Their language is usually feature-shaped (“I want it to handle my leads”), not test-shaped. Translating that into checkable acceptance criteria is the actual value of the scoping session — it’s why it’s a paid deliverable and not a form they fill out themselves.

The tools I use to run this

Claude drafts the document from raw call notes using the prompt above, and flags gaps rather than guessing at them.

Notion is where the finished scope document lives, shared with the client before any deposit is collected — the same place I keep the rest of the engagement’s paper trail.

Airtable tracks which engagements are in scoping versus signed versus in build, one row per client, so a scope document never sits unsigned for weeks without anyone noticing.

FAQ

How long should a scope document be?

As long as it needs to be to make every acceptance test checkable, and no longer. A single-workflow agent might be half a page. A multi-agent system with several integrations can run two or three pages. Length isn’t the goal — a client and a developer independently reading the acceptance tests and agreeing on whether they passed is the goal.

What if the client wants to change the scope after signing?

That’s a change request, priced separately and quoted before the work starts — write that term into the document itself, as in the template above. A scope document that can be silently expanded after signature isn’t actually a scope document.

Do I need a scope document for very small automations?

Yes, just a short one. The value isn’t the length — it’s having a written acceptance test list before you start building, so “done” is a checklist instead of a feeling. I’ve had small, informally-scoped jobs run longer than large, properly-scoped ones for exactly this reason.

Who owns the scope document itself — is it part of the deliverable?

I treat it as the client’s to keep regardless of whether they proceed to a build, since they paid for the audit that produced it. What I retain is the underlying template and prompt, the same way I retain reusable scaffolding across engagements — the document’s structure is mine, the filled-in content about their specific business is theirs.

Next steps: My AI Agents for Beginners course covers building the agents a scope document like this describes. The cowork program is for operators who want a structured environment to practice scoping and building this kind of work. If you’d rather have the scope document written for you, book a 30-minute session.