AI agent services contracts: 9 clauses to agree before you sign in 2026

Most AI agent projects do not fail in the model. They fail in a document signed three months before anyone wrote a line of code, which is to say they fail in the AI agent services contract.

We build AI agents for a living, which puts us on the other side of these agreements. We have signed the statements of work that end with a system running quietly in production, and we have seen the ones that end in a dispute about whether the thing works. The difference almost never comes down to which model was chosen. It comes down to whether anyone wrote down what working means, who owns the evaluation set, who pays when inference costs triple, and what happens the day the chosen model is retired.

Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls in its June 2025 prediction. Read that list again. None of those three are machine learning problems. All three are things a contract can settle before the build starts.

This article is for founders, CTOs, and operations leaders who have a proposal for AI agent services on their desk and want the engagement to end in production rather than in a demo. You will get the 9 clauses that decide the outcome, what a fair version of each one looks like, how to stage the money so risk is shared, and the 5 questions that reveal whether a vendor has actually run an agent in production. If you are still deciding whether AI agents are relevant to your business, this is not the piece for you. If you are about to sign, it is.

The change worth aiming for is simple. You go from a vague pilot that produces a polished demo and nothing you own, to a signed scope where the agent has to hit an agreed number on your own data, inside your own systems, with the prompts and evaluation set in your name.

‍

Key takeaways

• Most AI agent engagements fail on scope and acceptance terms, not on model quality.

• Acceptance should be a measured pass rate on a frozen set of your real cases, agreed before development starts.

• You should own the system prompts, orchestration code, evaluation set, golden answers, and logs, not only the output.

• Model deprecation is a scheduled event, so the contract needs a re-qualification and re-test clause.

• Inference cost belongs in the contract with an assumed volume and a mechanism for when volume moves.

• Autonomy limits, escalation, and rollback are commercial terms, not engineering preferences.

• Under the EU AI Act, the builder and the buyer usually hold different roles, and the contract should name which is which.

• A vendor who will not sign an accuracy number on your data is giving you useful information for free.

‍

Why AI agent projects fail in the contract

AI agent projects fail because the contract measured effort instead of outcome, and because nobody agreed in advance what a finished agent looks like.

Here is the pattern, and it repeats almost word for word across industries. A logistics company signs a 12 week engagement for an agent that will handle inbound order emails. Week 10, the demo runs beautifully across 20 carefully chosen messages. Week 14, it reaches the operations team, and within days someone notices it quietly misreads delivery windows on scanned PDFs. Nobody wrote down which document types were in scope. Nobody agreed a target accuracy. Nobody said who pays for the extra 6 weeks of work. The vendor believes the engagement is delivered because the demo passed. The client believes the system is broken because a person still has to check every message. Under the contract that was actually signed, both of them are right.

Traditional software contracts work because the deliverable is deterministic. A feature either renders the invoice list or it does not, so acceptance can be a checklist and everyone reads it the same way. An agent is probabilistic. It extracts the right delivery window 94% of the time, and whether 94% is a success or a failure depends entirely on a number that, in most engagements, nobody ever wrote down.

That single gap creates the other four. Without an agreed threshold there is no objective point of completion, so there is no clean moment to release final payment, no basis for judging a regression after launch, and no way to tell a genuine defect apart from a change request. Every argument that follows is really an argument about a missing sentence.

The good news is that this is cheap to fix. Getting these terms right adds a few days to a procurement process and removes the most common reason these projects are quietly shelved 6 months in.

‍

What an AI agent services contract actually covers

An AI agent services contract is the agreement that defines what an AI agent must do, how well it must do it, who owns the components that make it work, and who carries the responsibility when it behaves badly in production. It sits on top of a normal software services agreement and adds the terms that only matter because the system is probabilistic and because it takes actions on its own.

In practice the paperwork is usually three documents. A master services agreement covering the commercial relationship, liability, and confidentiality. A statement of work per phase, carrying the scope, the acceptance criteria, and the price. A data processing agreement plus an AI addendum, covering processing locations, subprocessors, training data exclusions, and regulatory roles.

What you will usually be handed instead is a standard software statement of work with the word AI inserted into the deliverables list. That template was written for deterministic systems. It has no language for accuracy, no language for drift, no language for model retirement, no language for autonomy, and no language for the cost of inference. Those five gaps are where the money leaks, and they are exactly what the clauses below close.

‍

The 9 clauses to agree before you sign

Treat these as a checklist to run against any AI agent services proposal. You do not need every one in full legal dress for a small pilot, but you should be able to answer each question in a sentence before money changes hands.

1. A named process, not a use case

The scope should name one process, one process owner, one system of record, and one number that has to move.

Improve customer support with AI is an ambition, not a scope, and it cannot be delivered or refused. Compare it with this: the agent triages inbound support email in the Benelux queue, assigns a category and a priority from a fixed list of 6, drafts a reply for 4 of those categories, and reduces median first response time from 4 hours to under 30 minutes. Now both parties know what done means, and a reviewer can tell whether it happened.

Write the out of scope list with the same care. It is the more valuable half of the section, because every change request and every uncomfortable conversation in month 3 comes from something that was assumed rather than excluded. Name the channels, document types, languages, and edge cases the agent is not expected to handle in this phase.

2. Acceptance as a measured pass rate on a frozen test set

Acceptance should be a measured pass rate on a versioned set of your own real cases, with the threshold agreed before development begins.

This is the single most valuable clause in the whole document. Before the build starts, both parties freeze a set of real historical cases from your business, typically 200 to 500 of them, write down the correct outcome for each, and agree the score the agent has to reach. The final payment tranche depends on hitting it. Nothing else in the contract does as much work.

The reason a frozen set matters is that a demo proves almost nothing. An agent that passes a live demonstration has passed one sample, of one distribution, on one day, usually chosen by the person being paid. A versioned test set can be re-run in month 9 to prove the system still performs, which turns acceptance into something you can also use as a maintenance instrument.

Useful things to measure, chosen to fit the process rather than all at once:

• Task completion rate on the full set, which is the headline number

• Field level accuracy where the agent extracts structured data

• Escalation rate, meaning how often it correctly hands off instead of guessing

• Latency at the 95th percentile, because a correct answer 4 minutes late can still fail the process

• A zero tolerance list of outcomes that must never occur, each of which fails the run outright

Two protections belong next to the threshold. There should be no deemed acceptance, meaning the work is not accepted simply because you did not object within 10 days. And there should be a defined remediation right, usually 2 rounds of fixes within a set window before either party can walk. If you want the engineering detail behind setting these numbers, we covered it in our guide to AI agent evaluation before production.

3. Ownership of prompts, evaluation sets, and fine-tuned artifacts

You should own the system prompts, tool definitions, orchestration code, the evaluation set with its golden answers, and the production logs.

Most ownership disputes are not bad faith, they are silence. A vendor develops a prompt library that gets reused across clients, and the contract never distinguishes between their generic framework and the version that encodes your escalation rules, your product taxonomy, and 40 hours of your team's corrections. When the relationship ends, both sides discover they assumed different answers.

Ask for assignment of all work product created for you, with a narrow licence back to the vendor for genuinely generic tooling if they need it. Add an explicit carve out that your data and your outputs are never used to train a model that serves anyone else, and put that sentence in the statement of work rather than burying it in the data processing agreement, where it is easy to lose.

Pay particular attention to the evaluation set. It encodes your definition of correct, it is expensive to rebuild, and whoever holds it controls whether any future vendor can be judged fairly. Of everything produced during the engagement, it is the asset most worth insisting on.

‍

If you are earlier in this process and still shaping the business case rather than the paperwork, our SaaS AI Blueprint walks through how to scope, cost, and sequence an AI build so the commercial terms have something solid to attach to. It is free and takes about 20 minutes to read.

‍

4. Model change, deprecation, and re-qualification

The contract should treat model retirement as a scheduled maintenance event with named responsibilities and a named payer.

Frontier models are retired on published timelines, and an agent tuned against one version can behave measurably differently on the next. Formatting drifts, refusal behaviour shifts, and tool calling reliability moves. None of that is a defect in anyone's work, it is a property of building on infrastructure someone else versions.

The terms that handle it are short. A notice period before the vendor changes a model in production. An obligation to re-run the full acceptance suite before any model change goes live. A documented rollback path. And a clear answer on who pays for the re-qualification, which in a fair contract sits inside the monthly retainer when the vendor or provider initiates the change, and is chargeable when you ask for a switch.

Ask the question directly in the first meeting: if the model you are proposing is retired in 9 months, who re-tests it and who pays? A vendor who has actually operated an agent for a year answers this immediately. A vendor who has only built demos will improvise, and you will hear it.

5. Who pays for tokens, and what happens when volume moves

Name the expected cost per run, the assumed monthly volume, and the mechanism that applies when real volume moves beyond an agreed band.

Inference cost is the line item that surprises people, because it scales with usage in a way that licence fees do not. An agent that costs 11 cents per run is comfortable at 4,000 runs a month and a genuine budget conversation at 60,000. The contract should state the assumption out loud so that success does not arrive as an unpleasant invoice.

Decide whose accounts the models run on. For anything heading to production, client owned provider accounts are almost always the right answer. You see the real bill rather than a marked up one, you keep the relationship with the provider if the vendor leaves, and you can set your own spend limits. A vendor who insists on holding the keys should be able to explain why in one sentence.

Then add a cost efficiency obligation, because prompt size, model routing, and caching are engineering choices that the vendor controls and you pay for. A reasonable clause says that if actual cost per run exceeds the estimate by more than 25%, the vendor proposes optimizations within an agreed number of days at no extra charge.

6. Autonomy limits and the escalation path

The contract should list which actions the agent may take alone, which require human approval, and what it does when it is uncertain.

This looks like an engineering detail and it is really a liability question, because it decides who is answerable when the agent sends the wrong thing to a customer. Three tiers cover most processes. Actions the agent takes silently, such as classifying and enriching. Actions it takes and reports, such as sending a templated acknowledgement. Actions it prepares and a person releases, such as anything touching money, contracts, or a customer commitment.

Define uncertain behaviour explicitly, because this is where agents cause real damage. There should be a confidence threshold or an abstain path, a defined behaviour when a tool call fails or returns nothing, and a named human queue that receives the handoff. An agent with no specified behaviour for uncertainty will guess, confidently, and the guess is what ends up in a complaint.

7. Data residency, processing, and EU AI Act roles

The contract should name where data is processed, which subprocessors are involved, and which party holds which role under the EU AI Act.

Under the EU regulatory framework for AI, obligations differ depending on whether you are placing a system on the market or using one in your own operations. In a typical agency engagement the builder and the buyer end up in different roles, and the duties that come with running a system in your business, including human oversight and monitoring, land on you rather than on the vendor. If nobody names those roles in writing, you will discover them during an audit instead.

The practical terms are concrete rather than abstract. Named processing regions for both the model calls and the storage. A subprocessor list with a notice period for changes. A log retention period that matches your own policy. Documented human oversight arrangements. And a written commitment that your data is excluded from provider side training.

For a Dutch or wider European buyer this is not paperwork for its own sake. It frequently determines whether the agent is allowed to touch customer data at all, which makes it a scoping question, not a legal formality to resolve at the end.

8. Post-launch monitoring, drift, and the support SLA

Agree who watches the agent after go-live, exactly what they watch, and what response applies when quality degrades rather than when the service goes down.

Agents degrade quietly, and that is what makes this clause matter. Nothing throws an exception when an agent starts categorising 8% more tickets incorrectly because your product mix changed, or because a supplier redesigned the invoice template it had learned to read. The system stays up, the dashboards stay green, and the damage accumulates in a queue somebody else is quietly cleaning up.

The terms that catch it are a named monitoring owner, a monthly regression run of the frozen acceptance suite, alert thresholds on the metrics that matter, and a defined response when a regression is confirmed. Uptime commitments are the wrong instrument on their own, because an agent can be 100% available and 100% wrong at the same time. Ask for a quality SLA with the same teeth as the availability one.

9. Exit, transition, and portability

Agree at signature what you receive if the relationship ends, and at what price.

Exit clauses are boring right up to the week you need one. Require a documented handover covering architecture, prompts, the evaluation set, and operational runbooks. Require export of logs and configuration in a usable format rather than a screenshot pack. Agree a transition assistance period at pre-agreed rates so the price is not negotiated at your weakest moment. And avoid dependencies on vendor proprietary hosting for any component you cannot redeploy yourself.

There is a simple test for whether this clause is real. Could a competent engineer who has never seen the project keep this agent running 30 days after your vendor stops replying to email? If the honest answer is no, you have not bought a system, you have bought a dependency, and the contract should price that in.

‍

What a contract-ready scope looks like next to a vague one

The gap between a proposal that becomes a working agent and one that becomes a dispute is usually visible on a single page. Same budget, same technology, very different outcomes.

‍

The right hand column is not harder to write. It is the same information, made specific enough to be checked by someone who was not in the room. If a vendor resists moving from left to right, that resistance is the most useful signal you will get during the whole procurement.

‍

‍

How to stage the money so risk is shared

Split the engagement into 3 commercial stages, and let the uncertain part be small and cheap to stop.

Stage 1 is a paid discovery, fixed price and short. It produces the named process definition, the frozen evaluation set with golden answers, a data readiness assessment, and a modelled cost per run. This is the stage where most projects should be allowed to die, and a partner who is comfortable telling you not to proceed after it is worth more than one who is not.

Stage 2 is the build, priced fixed against the acceptance threshold agreed in stage 1, with the final 15% to 25% released only when the acceptance run passes. Because the target was set before anyone started building, that final tranche is a clean gate rather than an argument.

Stage 3 is the run, a monthly retainer that explicitly covers monitoring, the regression runs, model re-qualification, and a defined allowance of improvement work. Making this stage visible in the first proposal is a small honesty test. Agents have a running cost whether or not the contract admits it, and the vendors who hide it are the ones you find out about in month 4.

This shape works because it prices the uncertain part cheaply, ties the expensive part to a number both sides agreed while they were still friendly, and puts the ongoing cost on the table before anyone has committed.

‍

5 questions that reveal whether a vendor has run an agent in production

You do not need to be technical to run this test. Ask these 5 questions in the first commercial conversation and listen for whether the answers are specific or general.

• What accuracy will you sign for on our data, and on how many cases?

• Can you show an evaluation report from a previous engagement, redacted if needed?

• Who owns the prompts and the evaluation set when we finish?

• What happens when the model you are proposing gets retired, and who pays to re-test?

• What did one of your agents get wrong in production last quarter, and how did you find out?

The last question is the sharpest one, and it is the reason to ask all 5 in the same meeting. Every agent that has run in production for a year has failed at something. A partner who has been there will tell you what it was, how they detected it, and what they changed in their monitoring afterwards. A partner who has only shipped demos will tell you their agents work well. One of those answers is evidence, the other is a brochure.

‍

How Codelevate structures AI agent engagements

We work in the 3 stages described above, and we put the acceptance number in the statement of work before the build starts.

In practice that means the discovery phase ends with a frozen evaluation set built from your own historical cases, a target we are willing to be measured against, and a cost per run modelled at your real volume. If the discovery says the process is not ready, usually because the data is inconsistent or the process itself has never been defined clearly enough for a person to follow, we say so and you have spent a small amount to learn something expensive. The prompts, the evaluation set, and the orchestration code are yours from day one, and the model runs on your provider accounts so you see the actual bill.

That is also the standard we apply to ourselves when we are the ones being reviewed. If you want to see how the delivery model works in more detail, our AI development services page sets out the phases, the team shape, and how engagements are typically priced.

‍

The takeaway

An AI agent services contract is not legal overhead sitting between you and the interesting work. It is the mechanism that decides whether the interesting work reaches production. Name the process, freeze the test set, agree the number, own the artifacts, plan for model changes, and write down what happens when quality slips. Six sentences, and they remove most of the reasons these projects are quietly abandoned.

If you take one thing from this article, take the frozen evaluation set. It converts a subjective argument about whether an agent is good into an objective statement about whether it passed, and it keeps working long after the launch.

Two ways to go further. The SaaS AI Blueprint covers scoping and costing an AI build before you get to contract stage, and it is free. And if you have a proposal in front of you right now, you are welcome to book a free call with our team and walk through it with people who sign these documents from the other side. No pitch, and we will tell you if the scope on your desk is sound.