SAISA

Standard AI Services Agreement

The standard form for AI agent engagements.

Most of a deal like this is the same every time. The form settles that part
once, so the only thing left to work through is what actually differs deal
to deal — scope, records, limits, and what happens if it goes wrong.

Both sides read the same document, and neither side wrote it against the
other.

What it is

A SAISA is a bilateral service agreement governing a single AI agent
engagement. The parties settle, in writing:

— Scope of authorized actions (what the agent may and may not do)
— Success criteria (how delivery is measured)
— Records (what each side has to keep, and to what standard)
— Change control (what may be altered after the other side relies on it)
— Dispute path (what the parties agreed happens if something goes wrong)

Everything above is settled in the base form. Where the two sides of this
market genuinely disagree — the warranty standard, the liability cap, who
carries what after an incident — the form does not pick a side. It makes
the point an election, and records what the parties chose.

exact.works presents the form, helps both sides fill it in, and publishes a
way to check the result. It is not a party to the agreement and takes no
part in the engagement.

How it was drafted

A standard form is only useful if both sides believe it is not the other
side's paper. This one was drafted against that test.

The current form was written by an eleven-seat adversarial round table —
provider's counsel and buy-side counsel arguing opposite positions on the
record, alongside an errors-and-omissions underwriter, a regulatory
specialist and a standard-form expert. Twenty-three points were identified
as ones the parties should decide for themselves; nine of those were
contested between the two sides.

Where the sides agreed, the point is fixed in the base form. Where they
disagreed, the disagreement became an election rather than a default that
quietly favours whoever drafted. That is the whole method.

The bilateral structure

Customer                      Provider
──────────────────────────────
Defines scope                 Declares capabilities
Sets success criteria         States what the system does
Accepts or disputes           Performs within the agreed envelope

The seal

When the parties are agreed, the terms are hashed canonically and the
hash is signed with a published key (oath-2026-09).
Anyone holding a copy of the agreement can recompute the hash and check
it against the signature — that is what makes a later "that is not what
we signed" answerable.

The digest may also be anchored with an RFC 3161 timestamp. The digest,
and only the digest: the content of your agreement is never sent to a
timestamp authority, because a digest is not your data.

Records

The agreement can require each side to keep records to a stated standard —
hash-chained, gap-detectable, anchored — which ordinary operational
telemetry is not built to be. The standard is specified in the agreement, and
verification is defined to run on your side, against your own export.

Amendments and side letters

A SAISA is not static. The parties can modify an active agreement:

Amendments — formal modifications, agreed by both sides.
Side letters — narrow exceptions, with optional expiry.

Each modification is sealed the same way the original was, so the parties
can prove which version governed at any point in time.

Put your agent in writing

SAISA

Standard AI Services Agreement

The standard form for AI agent engagements. Most of a deal like this is the same every time. The form settles that part once, so the only thing left to work through is what actually differs deal to deal — scope, records, limits, and what happens if it goes wrong. Both sides read the same document, and neither side wrote it against the other.

What it is

A SAISA is a bilateral service agreement governing a single AI agent engagement. The parties settle, in writing: — Scope of authorized actions (what the agent may and may not do) — Success criteria (how delivery is measured) — Records (what each side has to keep, and to what standard) — Change control (what may be altered after the other side relies on it) — Dispute path (what the parties agreed happens if something goes wrong) Everything above is settled in the base form. Where the two sides of this market genuinely disagree — the warranty standard, the liability cap, who carries what after an incident — the form does not pick a side. It makes the point an election, and records what the parties chose. exact.works presents the form, helps both sides fill it in, and publishes a way to check the result. It is not a party to the agreement and takes no part in the engagement.

How it was drafted

A standard form is only useful if both sides believe it is not the other side's paper. This one was drafted against that test. The current form was written by an eleven-seat adversarial round table — provider's counsel and buy-side counsel arguing opposite positions on the record, alongside an errors-and-omissions underwriter, a regulatory specialist and a standard-form expert. Twenty-three points were identified as ones the parties should decide for themselves; nine of those were contested between the two sides. Where the sides agreed, the point is fixed in the base form. Where they disagreed, the disagreement became an election rather than a default that quietly favours whoever drafted. That is the whole method.

The bilateral structure

Customer Provider ────────────────────────────── Defines scope Declares capabilities Sets success criteria States what the system does Accepts or disputes Performs within the agreed envelope

The seal

When the parties are agreed, the terms are hashed canonically and the hash is signed with a published key (oath-2026-09). Anyone holding a copy of the agreement can recompute the hash and check it against the signature — that is what makes a later "that is not what we signed" answerable. The digest may also be anchored with an RFC 3161 timestamp. The digest, and only the digest: the content of your agreement is never sent to a timestamp authority, because a digest is not your data.

Amendments and side letters

A SAISA is not static. The parties can modify an active agreement: Amendments — formal modifications, agreed by both sides. Side letters — narrow exceptions, with optional expiry. Each modification is sealed the same way the original was, so the parties can prove which version governed at any point in time.