Pacts, Prompts, and SLAs — What's the Difference?
Why none of the alternatives give you what a behavioral pact actually provides.
When developers first hear about behavioral pacts, they often ask: "Isn't this just a system prompt? Or an SLA? We already have those."
No. And understanding why matters for building agents that can actually earn trust at scale.
System Prompts: Instructions, Not Contracts
A system prompt is an instruction set. It tells the model what to do, what tone to use, what to avoid. It's informal, human-readable, and not verifiable by any external party.
System prompts have three fundamental limitations as trust infrastructure:
1. They're private and unverifiable. A buyer can't see your system prompt (nor should they — it likely contains proprietary logic). They have no way to know whether your agent actually follows it. You could claim your system prompt says "never disclose PII" while the agent merrily echoes back credit card numbers.
2. They don't define verification methods. A system prompt says "be accurate." But accurate by what measure? Verified how? By whom? With what pass threshold? None of these questions have answers in a system prompt.
3. They don't create accountability. If an agent violates its system prompt instructions, there's no record of the violation, no dispute mechanism, no economic consequence. The system prompt isn't a contract — it's a suggestion to the model.
System prompts are fine for operational configuration. They're not trust infrastructure.
SLAs: Coverage Without Behavioral Specificity
Service Level Agreements define operational commitments: uptime, latency, support response time. SLAs are verifiable in the narrow sense that you can measure uptime and latency objectively.
But SLAs don't cover the behavioral surface that matters most for AI agents:
- Does the agent produce accurate outputs?
- Does it refuse harmful requests?
- Does it stay within its declared scope?
- Does it correctly calibrate its confidence?
A 99.9% uptime SLA tells you the agent responded. It says nothing about whether the response was correct, safe, or appropriate.
SLAs also lack the adversarial evaluation component that trust scoring requires. An uptime SLA is measured passively from production traffic. Agent trust requires active adversarial testing — inputs specifically designed to probe failure modes.
The Pact: A Formal Behavioral Contract
A pact combines what system prompts and SLAs each do partially, and adds what neither does at all.
| Property | System Prompt | SLA | Pact |
|---|---|---|---|
| Defines expected behavior | ✅ (informal) | ❌ | ✅ (formal) |
| Externally verifiable | ❌ | ✅ (operational only) | ✅ (behavioral + operational) |
| Specifies verification method | ❌ | ❌ | ✅ |
| Creates accountability trail | ❌ | Partial | ✅ |
| Supports adversarial testing | ❌ | ❌ | ✅ |
| Queryable by third parties | ❌ | Sometimes | ✅ (Trust Oracle) |
| Contributes to portable reputation | ❌ | ❌ | ✅ |
The pact is not a replacement for system prompts — you still need those for operational configuration. And it's not a replacement for SLAs — you still need those for operational commitments. The pact sits above both: it's the behavioral specification that makes evaluations possible.
What a Pact Is Not
A pact is not a guarantee. A Platinum-tier agent with a perfect pact can still fail on a novel input. The pact specifies the behavior that should hold. Evaluations verify that it does hold across a test distribution. Neither is a guarantee of future performance on all possible inputs.
A pact is not a legal contract. It's a trust infrastructure artifact, not a legally enforceable agreement. The economic enforcement mechanism is the escrow bond — if an agent commits a behavioral violation in a financed deal, the escrow is the recourse, not the courts.
A pact is not a model card. Model cards describe training data, capabilities, and limitations of a base model. Pacts describe the behavioral commitments of a deployed agent — typically built on top of a base model, but with specific system configuration, RAG, tool calling, and guardrails that the model card doesn't cover.
The Chain of Trust
Pacts fit into a broader accountability chain:
Agent (the deployed system with all its configuration)
→ Pact (what it commits to doing)
→ Evaluations (adversarial tests of that commitment)
→ Score (evidence of compliance)
→ Trust Oracle (verifiable to third parties)
→ Marketplace / Escrow / Deals (economic activity unlocked)
Every link in this chain depends on the link before it. An evaluation without a pact is just arbitrary testing. A score without evaluations is self-reported. The pact is the specification that gives the rest of the chain meaning.
In the next lesson, we'll get into the mechanics of writing conditions that actually hold up under adversarial evaluation.
New courses drop every few weeks
Get notified when new content goes live — no spam, unsubscribe any time.
Start building trusted agents
Register an agent, define behavioral pacts, and earn a verifiable TrustMark score.