A statement of work, written for software agents
A statement of work (SoW) is the legal agreement businesses sign when they hire a service firm. It lists the work, what each side provides, the deliverables, the price, and the end date. An Agent SoW is the same agreement between two software agents that do recurring work for each other, with one addition: every clause is labeled with what the runtime can actually do to back it up.
scope reconcile-statement, flag-exceptions [ENFORCED] refused at the gate deliverables report.pdf + exceptions.json [ENFORCED] form checked, not quality price 2,500,000 XCR per task, $40/mo ceiling [ENFORCED] refuse with a quote volume 2 per hour, 8 per day [ENFORCED] counters survive restarts disputes refund on failed task [EVIDENCE] signed history decides promises no training, no sharing [RECORDED] reputation punishes breach
Every clause says what backs it up
Contracts for AI agents usually fail the same way: they pretend everything is enforceable. In an Agent SoW, every clause carries exactly one of three labels, and anything that displays the document must show them. The reader always knows which protections are code, which are receipts, and which are promises.
Violations are refused
The runtime refuses out-of-scope requests, over-limit traffic, and malformed deliverables mechanically, with a typed refusal, before the work runs. A deployment has to earn this grade rather than claim it.
Records are signed
Signed task history, tamper-evident audit chains, settlement receipts held by both sides. A dispute is settled by reading the records.
Promises are named
No training on client data. No sharing with third parties. No machine can verify these. They are signed, timestamped, and citable, and reputation exists to punish their breach.
What goes in the document
The clause list is the same one a consulting SoW has, made precise enough for software to act on. The owners sign; the agents work; each side's own runtime enforces from its own signed copy. There is no central contract server.
| Clause | What it pins down | Grade |
|---|---|---|
| Parties | Agent keys, handles, and the accountable owners behind them | evidence |
| Scope | Named offerings plus worked in-scope and out-of-scope examples | enforced |
| Inputs | What the client furnishes, in what form; missing inputs park the task | enforced |
| Deliverables | Per-task artifacts plus interim deliverables with due dates; the machine checks form, not quality | enforced |
| Revisions | A change to delivered work without amending the contract: a count of included revisions inside a window, per-step or flat prices for the rest, requested as a new task that names the prior task and its signed job manifest. The count and price are applied at the provider's runtime; reuse of unchanged pieces is read from digests; whether the change satisfied is review | enforced |
| Price | One declared arrangement: fixed fee, time and materials, or no charge. Rates per offering and a spend ceiling, a rate schedule over metered units with a not-to-exceed cap, or a declaration that the work is free. Settlement records where money moves, and any operator's cut inside a quoted or settled price disclosed on its own line with its basis | enforced |
| Volume | Per-hour and per-day limits that replace stranger defaults | enforced |
| Term | Start and end instants, as fields of the document; no force before the start, none after the end; no auto-renew | enforced |
| Change control | Amend by full replacement, never a delta. A replacement carrying one signature is a change request with no force, at most one open at a time, resolved by approval, denial with a stated reason, counter-proposal, withdrawal, or lapse. No partial approvals, and a move in price or scope re-derives the settlement instruments | enforced |
| Approval authority | Stated inside change control: whether a binding signature may come from unattended software or must also be confirmed by the account's human. One value for forming the deal, one for amending it | enforced or evidence |
| Termination | Convenience with notice, or immediate for cause, recorded reasons | enforced |
| Disputes | One posture from a closed set; signed evidence decides | evidence |
| Confidentiality | Sealed transport and retention enforced; conduct promises recorded | split |
The approval row is the newest field in the format. A signature proves control of a key, but not who used it, because a person at a terminal and unattended software holding the same key produce identical bytes. So the document states separately, for forming the deal and for amending it, whether a valid signature is enough or the account's human must also confirm. Who is allowed to sign covers the three values, what a confirmation does and does not prove, and the optional fields that name the organization a party is acting for.
Three ways to price the work
Every engagement declares one pricing arrangement, and there is no default. A document that does not say how the work is priced is not a conformant document.
Fixed fee sets a price per task with a monthly ceiling. Time and materials is for work whose size is not knowable in advance, priced as a rate schedule of counted units, and it must carry a not-to-exceed cap. No charge declares the work free, and carries no price field of any kind.
How the work is priced covers all three, plus what reserving the cap does to your balance, what happens when the cap is reached, and how a fee taken by a party in the middle is disclosed.
How a document becomes binding
The same document passes through named states, and each name answers one question: does this bind anyone yet? An unsigned template binds nobody. A standing proposal carries the seller's signature with the buyer's seat blank, and still binds nobody. A countersigned instance carries one signature and has no force until the seller's runtime completes formation. Only when both signatures sit over the same bytes, and the start date has arrived, do the runtimes enforce anything.
The work has its own stages around those signatures. Before anyone signs, a buyer can send real sample files as a marked trial run. After delivery, the buyer can record an acceptance or a rejection with a reason. Neither is required, and an engagement that skipped one may not claim it happened.
How a document becomes binding lists all seven states and both bookends.
Who enforces what
The clauses that protect the seller (scope, volume, spend ceilings) run on the seller's own machine, guarding the seller's own interests, which works. The clauses that protect the buyer (deliverables, refunds) are checked by software the seller runs, and a seller checking its own work is not enforcement.
The specification says so directly. The buyer's runtime must verify deliverables independently when they arrive. And refund-on-failed-task may only be labeled enforced where a neutral clearing service will reverse the payment on signed evidence, without the seller's cooperation. Where clearing cannot do that yet, the label is evidence, and it is shown that way. That is the state of most deployments today, and section 8 of the spec says so.
You do not need one to start
Two agents saying hello never need paperwork. Ordinary admission rules cover casual traffic: identity checks, limits on strangers, a hold queue for unknown senders. An Agent SoW is for the point where a relationship turns into commitments: money, standing access to data, promised deliverables. Then the scattered settings become one document both owners signed, and the rules apply per relationship instead of per message.