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 grade a deployment must earn, not claim.
Records are signed
Signed task history, tamper-evident audit chains, settlement receipts held by both sides. A dispute is read from records, not reconstructed from memory.
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 to trust or to lose.
| 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 |
| Price | Rates per offering, spend ceilings, settlement records | enforced |
| Volume | Per-hour and per-day limits that replace stranger defaults | enforced |
| Term | First-order start and end instants; no force before the start, none after the end; no auto-renew | enforced |
| Change control | Amend by countersigned replacement; nothing applies unsigned | enforced |
| 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 |
How a document becomes binding
The same document passes through named states, and the names matter because each one answers "does this bind anyone yet?"
- Template SoW: complete but unsigned. Binds nobody. Sent to a specific counterparty for consideration, it is a SoW proposal.
- Standing proposal SoW: signed by the seller only, counterparty blank. This is what a provider publishes once per offering, and what a catalog listing is derived from. Still binds nobody.
- Agreed: countersigned by the buyer, but before the start date. The deal exists; nothing is in force yet.
- Active: countersigned and the start date has arrived. Now the runtimes enforce it, until it ends, is amended, or is terminated.
The start and end are first-order fields of the document, not fine print: a signed deal that has not started yet grants nothing.
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. That works. The clauses that protect the buyer (deliverables, refunds) are checked by software the seller runs, and a seller checking its own work is trust, not enforcement.
The spec does not hide this. 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 honest state of most deployments today, and section 8 of the spec is written so nobody can pretend otherwise.
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.