The standard form service agreement for AI agent engagements. Published so parties, counsel and regulators can read it — then customised, agreed and sealed between a specific Buyer and a specific AI Provider.
Like a standard real-estate offer-to-purchase form: the blank form is public; the deal it produces is between the parties, and the stationer is not one of them.
exact.works is not a party to any SAISA and owes nothing under one. It is the drafting tool: it presents the form, helps both sides customise it, checks the result for internal consistency, and seals the terms they agreed.
It does not hold escrow, release or refund money, score or suspend an agent, decide a dispute, or hold anyone's credentials. The governing rule is short: liability comes from doing, holding or promising — not from specifying.
Formation is the process of turning a published standard form into the specific terms two parties have actually agreed, and fixing those terms so neither side can quietly revise them afterwards.
The form is the starting point. The parties negotiate from it and settle the scope, the criteria, the records each will keep, and what happens if it goes wrong. When they are agreed, the terms are hashed canonically and the hash is signed with a published key. Anyone holding the document can recompute that hash and check it.
The form is public. The agreement is confidential to the parties — exact.works holds a document while it is being drafted. Only the digest is anchored, and a digest is not your data.
AI agents are doing work worth real money with no contractual framework. No agreed scope. No acceptance criteria. No allocation of who carries which risk. No record either side could produce if the other disputed what happened. The SAISA is the independent contractor agreement for autonomous AI agents.
It does not wrap the agent. It wraps the engagement. The agent runs wherever it runs; the agreement says what it was hired to do.
Published prose. Liability, IP, confidentiality, records, change control and the dispute path the parties choose. Read it before you negotiate from it.
The engagement-specific and industry-specific terms: scope, records, and sector requirements such as Schedule F for financial services.
canonical hash over the agreed terms → signed with published key oath-2026-09 → optional RFC 3161 timestamp over the digest onlyThe published two-party agreement: liability allocation, IP, confidentiality, records, change control, and the dispute path the parties elect. Versioned, and citable in procurement.
Where the engagement gets specific: the authorised scope, the record standard, and any sector supplement the work triggers.
A formal modification, agreed by both parties and sealed the same way the original was, so it is always answerable which version governed when.
A narrow exception for a specific commercial arrangement, optionally with an expiry date.
Both sides read the same standard text. Nobody is negotiating against a document they have not seen.
Scope, criteria, records, change control, dispute path. The schedules the work triggers are attached.
The prose and the machine-readable scope are checked against each other before anyone signs. If the prose says one budget and the configuration says another, that is a defect in the draft, and it is surfaced rather than sealed.
A canonical hash over the agreed terms, signed with the published keyoath-2026-09and optionally anchored with an RFC 3161 timestamp over the digest only.
The party that built and operates the agent is liable for what the agent is; the party that hired and authorised it is liable for what it was pointed at. Both allocations run between the two parties. There is no third party in the middle of them, and none to sue instead.
A canonical hash over the terms, signed with a published key. Neither side can revise the deal after the fact and assert the revision was always there — and proving it takes only the document and a public key.
The agreement can require records to a stated standard — hash-chained, gap-detectable, anchored — which ordinary telemetry is not. Both parties should keep a copy, so the party holding the evidence is never the only one who has it.
What either side may alter after the other has come to rely on it is a term, not an assumption. Modifications are agreed and sealed, so the governing version at any date is answerable.
The SAISA does not specify where the agent runs. The same agreement governs an agent on NVIDIA NeMo, Docker, Kubernetes, AWS Lambda, Salesforce Agentforce, WebAssembly, or any MCP server. Runtimes execute. The agreement governs. Nothing about it requires the counterparty to adopt anyone's infrastructure — which is what a standard form has to be true of before it can become a standard.
What happens in a dispute is a term the two parties agree — notice, escalation, expert determination, arbitration, whichever they elect and before whichever institution they name. It is written into their agreement.
exact.works does not administer it. We do not decide, appoint, or hold funds pending an outcome. Drafting the mechanism is ours; running it is not.
The SAISA framework was designed by a licensed attorney (Wisconsin, Florida) with enterprise contracting experience. exact.works, Inc. is a Delaware corporation. Documents should be reviewed by your own counsel before execution.
Nothing in this document constitutes legal advice. The SAISA framework produces structured contractual artifacts for use by contracting parties. exact.works, Inc. is not engaged in the practice of law. All agreements must be reviewed by licensed counsel before execution.
Copyright 2026 exact.works, Inc. All rights reserved.