What a Fixed-Scope AI Engagement Should Include

AI projects have a reputation for drifting. A promising prototype turns into an open-ended retainer, the goal shifts every few weeks, and nobody can say when the work is finished. A fixed-scope engagement is meant to prevent that, but only if the scope is written precisely enough to be tested.

This is what we think a fixed-scope AI engagement should include, whoever delivers it. Use it to check a proposal before you sign, or to write one yourself.

01 // One system, one owner, one launch target

A fixed scope starts with a defined system, a named business owner, and a clear point at which the first version is in use. "Explore AI for customer operations" cannot be fixed-scope. "Build a reviewable triage queue for inbound service requests, used by the support team in production" can.

For a focused system with clear inputs and a known owner, a first production version typically takes three to eight weeks. Larger timelines are not wrong, but they usually mean the scope contains more than one system and should be split into phases with their own acceptance points.

02 // The sections a written scope should contain

A useful statement of work for an AI build covers more than features. At minimum it should describe:

• The workflow. How the work is done today, who does it, and where the system fits.
• Inputs and sources. Which systems and documents the build may read, and who grants access.
• Outputs and actions. What the system produces, and which actions it may take without approval.
• Human review. Which decisions stay with a person, and how they approve, edit, or reject output.
• Integrations. Each system the build connects to, and what happens if one is unavailable.
• Milestones. Dated checkpoints, each with something you can see working.
• Acceptance criteria. The tests that define "done", written before the build starts.
• Handoff. Documentation, credentials transfer, and who operates the system afterwards.

If a proposal is vague on any of these, ask about that section first. In our experience it is usually where the cost or the risk is hiding.

03 // Acceptance criteria are the scope

Features describe what will be built. Acceptance criteria describe how you will know it works. For AI systems the second matters more, because output quality varies with the input.

Good acceptance criteria name a representative set of real cases, including the difficult ones, and the standard each must meet. They cover behaviour on missing or malformed input, permission failures, and source text that tries to redirect the model, which OWASP lists as the leading risk for LLM applications. They also say how often a reviewer may need to correct output before the result counts as acceptable.

Our agent acceptance tests prompt produces a first draft of that test set, including the hostile and recovery cases teams tend to skip.

04 // Prove the riskiest part first

Every AI build has a step that decides whether it is viable: an integration without a clean API, a document type the model handles poorly, or a judgment call nobody has written down. A good fixed-scope plan schedules that step in the first milestone, with real examples, before the interface is polished.

Anthropic's guidance on building agents recommends starting with the simplest approach that solves the problem and adding autonomy only when it clearly helps. That principle also keeps scope honest. A simpler architecture is easier to estimate, test, and hand over.

05 // Agree data, risk, and operating terms up front

The NIST AI RMF Playbook organises AI risk work into four functions: govern, map, measure, and manage. A fixed scope does not need to adopt the framework wholesale, but it should cover the same ground in plain terms:

• what data the system may read, where it is processed, and how long anything is retained;
• which model providers are used and what their data terms are;
• how failures are logged, who is alerted, and how a person takes over; and
• the expected recurring cost of model usage, hosting, and monitoring after launch.

These terms are cheap to agree before the build and expensive to discover after it.

06 // Fixed scope, monthly partnership, or pilot

A fixed scope suits a defined system with a clear owner and launch target. An evolving product or multi-phase roadmap is usually better served by ongoing senior capacity, where priorities can change between releases. A limited pilot makes sense when the main question is whether the idea works at all, as long as it has written success and stop criteria and a decision point before broader investment.

We offer all three, and we describe how each works on our Studio page. Whichever you choose, the first step is the same: describe one workflow precisely. Our guide to scoping an AI automation pilot goes deeper on that step, and AI automation covers the systems we build most often.

A scope is fixed when both sides can test it, not when it has a price.