An ordinary development contract describes a world where, when software breaks, it is the contractor's fault. Hence the warranty period, the acceptance procedure, the liability for defects. All of that holds as long as the product consists of code that both parties can see and control.
An AI agent is built differently. Besides the code, it contains a rented model, a set of text instructions for that model and access rights to your systems. The code isn't going anywhere, but the model lives on a schedule of its own. And the provider writes it.
Why does the model your agent runs on have a retirement date?
Model providers describe this schedule publicly. Anthropic sorts models into four states: active — fully supported; legacy — no more updates; deprecated — the model still works, but it already has a retirement date and a recommended replacement; retired — requests fail with an error.
Before retiring a publicly released model, Anthropic gives at least 60 days' notice to the customers who have it running in production. OpenAI keeps the same kind of public list of deprecated models with shutdown dates. The documentation notes separately that the partner platforms, Amazon Bedrock and Google Cloud, set their own dates. The status of the same model in the cloud where your agent runs may differ from its status in the provider's API, and you will find that out at the worst possible moment.
The second thing worth knowing before you sign: moving to a new version takes work — and not the work the client budgets for. Here is what we measured in-house. In spring 2026 Grow2.ai, our AI division, moved its own fleet of agents to the next model version: we had to rewrite the system prompts and fix several bugs in the wrapper code around the model that the previous, slower version had been masking. The API configs needed changes of their own: the fixed budget for the model's “thinking” gave way to an adaptive one — meaning the limit we used to keep our costs within is counted differently in the new version. This is our own measurement on our own fleet, not an industry norm.
None of that work looks like “change the line with the model name”. And none of it is described in a typical SOW.
Block 1. Why are prompts a product that belongs in the deliverables?
An SOW has a table of deliverables with a column for acceptance criteria. For a CRM project it lists things everyone understands: a discovery report, a configured pipeline, an imported database. For an agent, most of the value sits in texts that never make it into that table.
What should go on the list:
- the system prompts for every agent role, with their version history, not just the latest file at handover
- the model configuration: identifier, call parameters, limits and restrictions
- the evaluation set — scenarios with the expected result described in advance
- tool descriptions and call schemas, including the permissions the agent's account gets in your systems
- a decision log: why the prompt is worded the way it is, which options were rejected and for what reason
The most valuable line here is the third. The evaluation set is what you will use six months from now to prove that the agent behaves differently after a model update. Without it, both parties will describe quality in words, and words carry no weight in a dispute. Putting such a set together is a separate job that takes several days, and it should either be inside the scope of work or be honestly carved out of it with its own price tag.
Acceptance should be tied to the same set. In typical templates the client has a few business days to accept in writing or give a reasoned rejection, and silence often counts as acceptance. For an agent, “taking a look” during those days tells you almost nothing: acceptance has to mean a run of the evaluation set and a recorded result for every scenario.
Block 2. How is a license to the prompts different from owning them?
The intellectual property section of a typical IT contract works like this. Each party keeps what it had before the work began or created independently of it — that is background IP. For the deliverables, the client gets a license: upon full payment, worldwide, perpetual.
Then come three words. In a CRM project nobody reads them; in an agent project they are worth reading twice: non-exclusive, non-transferable, non-sublicensable. Plus the qualifier “for the client's internal purposes”. You can use the prompts. Hand them to another team to develop further? By the letter of the text, no.
On the other side of the text is the contractor's right to reuse. The standard wording lets the contractor take general knowledge, techniques, generalized libraries and code fragments away from the project, provided the client's confidential information is not disclosed. Without this clause the contractor's work makes no economic sense: they can't reinvent the router for every client.
The line has to be drawn by content. Treat as client-specific whatever contains the client's terminology, deal stage names, discount rules, sales scripts, the list of policy exceptions. Treat as general the solution architecture and the templates from which all of the above has been cut out. It is best to describe this boundary with two or three examples right in the SOW: in abstract wording it blurs within the very first month of work.
Block 3. How do you write a model migration procedure into the contract?
The contract already has a frame for this block — the change management section. Either party submits a written request, the contractor assesses the impact on scope, timeline and cost, and the change takes effect once both have signed. One thing is missing: a trigger that doesn't depend on what the parties want.
The trigger here is the provider publishing a retirement date or moving the model to deprecated. What follows is a description of who does what:
- who monitors the provider's announcements and how soon they must notify the other party
- how much time is allowed for the impact analysis, counted from the announcement
- a run of the evaluation set on the new model before the switch, with a written report on the discrepancies
- whether there will be a window in which the old and new versions run in parallel, and who pays for it
Money is where the gap most often sits. The word “support” in a contract usually has no definition, and each party reads it in its own favor. A sensible split: the run of the set and the discrepancy report are part of support, while rewriting prompts beyond an agreed number of hours goes as a separate change order at the contract rate. Set the number of hours yourself, based on the size of the agent — just don't leave it unnamed.
A separate word on the warranty. In typical contracts the warranty period for conformity to the specification is counted in weeks after acceptance, not months. A migration that happens eight months later falls outside that window under any reading, so invoking the warranty in that conversation is pointless. Either you agreed on migration as a separate block, or you didn't agree on it at all.
Block 4. What counts as a failed migration?
“The agent works after the update” is not an acceptance criterion: the criterion has to be comparative and numeric. How to take the baseline that number comes from, and how to word the threshold in the SOW, is covered separately in our piece on the acceptance rate; all that matters here is that the contract contains a number, not an adjective.
It looks roughly like this: on the same evaluation set, the share of scenarios passed without human intervention is no lower than the baseline value recorded before the migration, within a tolerance you agreed in advance. The baseline is put on record: the date, the model identifier and the result for each scenario separately.
This is also the place to spell out what happens when the target is not met. Our acceptance procedure gives two rounds of rework, after which the client has the right to terminate the SOW. Carrying that rule over to migration as is would be risky for both parties: the discrepancy may turn out to be a property of the new model rather than the quality of the contractor's work. A smarter way out is a rollback to the previous model while it is still available, and a review of the scope before its retirement date.
There is a worse case too: some scenarios can't be recovered on the new model at all, however many times you rewrite the prompt. That is exactly why the contract should state who pays for establishing that fact. Otherwise the fact-finding turns into a dispute over who is to blame and lasts longer than the migration itself.
What does the contract still not guarantee?
You don't need a separate “AI contract” for this: all four blocks fit into the existing sections of the master agreement and the SOW. But there is a limit, and it is better to say it out loud before signing.
What we don't do: we don't promise that migration will be free, and we don't guarantee that the agent's behavior will stay exactly the same after a model change. Nobody who doesn't build the model themselves can give that guarantee. What you can agree on is the procedure, the split of costs and the criterion — and that is enough to keep a model update from turning into a conflict.
What to check in your current contract
- open your current contract and search the list of deliverables for the word “prompt” — if it isn't there, that is your first edit
- ask your contractor whether an evaluation set exists for your agent and where it is kept
- check in the provider's documentation what status the model you are running on has right now
The third item takes five minutes and regularly turns out to be the most unpleasant: the model you launched on six months ago is already on the deprecated list with a date assigned.
If after this check you are holding a contract with none of the four blocks, send it to us. In one meeting we'll go through which blocks are missing, what to fix first and which of it is open to negotiation at all.
And one small thing that somehow never makes it into the contract and later costs a week: who holds the API keys, and under which legal entity's name the account with the model provider is registered. Check that while you're at it.