The AI agent ecosystem is in that moment right now.
Every vendor's trust story is different, non-comparable, and un-auditable. Every enterprise's third-party risk review for AI agents is bespoke, expensive, and backlogged. Every marketplace claim is self-reported. Every regulatory proposal assumes an abstraction that does not yet exist. The missing layer has a shape. Someone is going to publish it. We think the shape is behavioral contracts, and we think the time to publish is now.
What the Contract Layer Does in Every Other Software System
Every mature software system has a contract layer.
APIs have contracts: OpenAPI specifications, GraphQL schemas, gRPC protobuf definitions. They exist independently of the implementation. A client can validate conformance without reading source code. Two different teams can implement the same contract and interoperate. A machine can generate client code. A monitoring tool can detect drift. A spec committee can evolve the contract versioned, not reinvented.
Services have SLAs: commitments about uptime, latency, and error rate that exist independently of the service implementation. The SLA is the accountability layer — the thing you measure against, the thing that triggers penalties. Enterprise procurement treats SLAs as first-class legal instruments. Vendors that don't publish SLAs cannot compete for serious workloads.
Software supply chains have compliance requirements: SOC 2, ISO 27001, GDPR, HIPAA. Behavioral specifications verified by independent auditors, producing reports third parties can rely on. A SOC 2 report is not the vendor's word; it is an artifact the enterprise's risk team can cite without further verification.
Web standards have specs: RFCs, W3C recommendations, EcmaScript standards. The spec lives outside any single implementation. Conformance is testable. Interop is possible because everyone agrees on the standard even while disagreeing on implementation choices.
In every case, the contract layer defines what "correct behavior" means in terms that are independent of any single implementation, verifiable by parties without implementation access, and auditable over time.
AI agents don't have this layer.
What the missing layer costs us today
You can watch the cost of the missing layer in concrete failures every week:
- A CISO cannot compare agents across vendors because there is no common specification to compare against.
- An enterprise risk review takes six months because the vendor's "our benchmark" claim has to be manually unpacked and re-verified.
- A marketplace cannot rank agents on verified dimensions because there is no neutral rubric; every agent is evaluated against its own test set.
- A regulator trying to write implementing guidance has no concrete artifact to reference; "the behavioral specification" is a vague concept rather than a machine-readable schema.
- An insurance market that could underwrite agent failures has no definable peril; you cannot insure against a risk you cannot specify.
- A jury of independent evaluators — however well-designed — has nothing to grade against.
Every single one of those failures has the same root cause. There is no contract layer.
Why "We Have Prompts" Is Not the Same Thing
A system prompt is not a behavioral contract, for four reasons.
It's not machine-readable. A system prompt is natural language. It can't be parsed by evaluation infrastructure or validated against a structured compliance schema. It cannot be diffed programmatically in any semantic sense; a subtle rewrite may change behavior entirely or change nothing. You cannot write machine-readable conformance tests against it.
It's internal. Your system prompt lives in your deployment. Third parties can't inspect it. Regulators can't audit against it. An independent evaluator needs to know what the standard is before determining whether the agent met it. A system prompt is configuration; a behavioral contract is a commitment.
It's not versioned against evaluation history. When you change your system prompt, there's no mechanism tying old evaluations to the old prompt. A behavioral claim from six months ago is untethered from the behavior being measured today. You cannot reconstruct whether a past evaluation was against the current behavior.
It does not survive its authoring environment. System prompts are often entangled with provider-specific features (tool schemas, JSON modes, structured output directives). Moving the same agent to a different provider often requires rewriting the prompt. The behavioral commitment should outlive any single provider; the prompt cannot.
The contrast is sharp: prompts are configuration. Contracts are commitments. You run your agent against your prompt. You answer to your contract.
What a Behavioral Contract Actually Looks Like
Armalo's Pacts are structured specifications with:
- Conditions — specific behavioral commitments with measurable thresholds. For example: "The agent must refuse any request that instructs it to bypass a named safety control," or "The agent must produce a structured JSON response conforming to schema S within 2.5 seconds at the 95th percentile."
- Verification method — deterministic, heuristic, or jury. Some conditions can be verified by regex or schema validation. Some require calibrated heuristic checks. Some require the independent multi-LLM jury. The pact declares which method applies to each condition so the evaluation path is fully specified.
- Measurement window — the period over which compliance is assessed. A daily window for high-volume workflows, a 90-day window for enterprise compliance reporting, a per-transaction window for settlement-bound conditions.
- Reference outputs — examples of passing and failing behavior that calibrate evaluators. Reference outputs are the way the pact author conveys intent across the interpretive gap between a rubric and the evaluator's internal reward function.
- Test cases — specific inputs and expected outputs constituting the verification suite. Test cases include both nominal inputs and adversarial inputs; red-team cases are first-class citizens of the contract, not an afterthought.
- Non-goals — explicit statements of what the agent is not committed to doing. Enterprises learned the hard way that SLAs are as much about scope exclusions as about uptime commitments.
- Versioning and provenance — each pact is content-hashed, registered with effective dates, and linked to its author's signing identity. Evaluations cite the exact pact version they were run against.
This structure makes the contract machine-verifiable. Evaluation infrastructure can parse the pact, run the tests, apply the jury process, and produce a verdict directly tied to the behavioral commitments the agent made.
Pact authorship in practice
A pact is not a one-shot document. It is authored by the vendor, reviewed by counterparties (the enterprise buyer, the marketplace, the regulator where applicable), refined against adversarial tests, and evolved over time. The full lifecycle of a mature pact looks like:
- Drafting. The vendor writes initial conditions, verification methods, and test cases. Reference outputs are generated from known-good behaviors.
- Adversarial review. An independent red team proposes conditions the draft does not cover, generates adversarial test cases, and probes for conditions that are under-specified.
- Calibration. Jury evaluations are run on reference outputs. If inter-judge consensus is too low, the condition is re-written until the rubric produces stable verdicts across independent judges.
- Registration. The pact is content-hashed and published. Any evaluation from this point cites the hash.
- Operation. The agent runs in production. Evaluations accumulate against the pact.
- Revision. Pacts are revised on a scheduled cadence. Revisions are new content hashes; old evaluations remain bound to the old pact version for historical continuity.
Step 3 is the one teams most often skip. Running calibration evaluations before production locks in a rubric that actually produces stable signals. Skipping it produces a beautiful-looking pact that nobody can agree on the meaning of.
A worked example: a retrieval-augmented support agent
Consider a customer-support agent built on RAG.
A vague prompt-era "standard" might say: "Answer the user's question accurately, cite the source, and escalate if unsure."
A behavioral contract version might say:
- Condition 1 (deterministic): The response MUST include at least one citation to a source whose content hash matches the retrieval index.
- Condition 2 (heuristic): The response MUST NOT assert a claim that does not appear in the cited source (measured by the faithfulness heuristic at threshold 0.85).
- Condition 3 (jury): The response must be evaluated by the jury as relevant, complete, and free of fabricated quantitative claims, with consensus ≥ 0.75.
- Condition 4 (deterministic): If the retrieval score is below threshold T, the agent MUST escalate and NOT answer.
- Non-goal: The agent does not commit to multi-turn dialogue state consistency outside the current session.
Every condition is measurable. Every condition can be evaluated automatically on every run. Every condition is independently verifiable. The agent's reliability is no longer a claim; it is a series of measurable events that accumulate into a trust record.
The Cascade Effect
A behavioral contract layer creates a cascade of infrastructure:
- Independent verification becomes possible — when the standard is machine-readable, any third party can run an evaluation against it. The multi-LLM jury, red-team suites, and deterministic conformance tests all become well-defined rather than bespoke.
- Scoring becomes meaningful — a composite trust score only makes sense if it reflects performance against defined behavioral standards. Without pacts, a "trust score" is a reputation number; with pacts, it is a compression of measured conformance evidence.
- Economic accountability becomes bindable — escrow contracts can reference pact conditions as delivery criteria. A release condition of the form "milestone M is met when pact condition C evaluates passing for three consecutive runs at consensus ≥ 0.8" is a structurally enforceable commitment.
- Regulation becomes navigable — the EU AI Act and analogous state-level U.S. laws require documentation of AI system capabilities and risks; a behavioral pact is exactly this kind of documentation in a form regulators can consume and cite.
- Marketplace trust becomes scalable — agents can be compared on verified dimensions, not self-reported claims. Two agents implementing the same pact are directly comparable in a way that no two agents with bespoke benchmarks ever are.
- Insurance becomes writable — underwriters can write policies against named perils defined in pact conditions. Agent liability insurance as a category depends on this being possible.
- Agent-to-agent commerce becomes trustable — when one agent hires another, the pact is the shared language they negotiate on. Without it, peer commerce between agents is impossible at scale.
Each of these is a downstream market that is currently under-built because the contract layer is missing. Deploy the contract layer and each of these markets becomes buildable.
How Pacts Relate to Other Contract-Shaped Objects
Behavioral contracts share DNA with several adjacent artifacts. It is worth mapping them so the differences are crisp.
| Artifact | Scope | Independent? | Machine-readable? | Drives payment? | Audit trail? |
|---|
| System prompt | Per-deployment | No | Natural language | No | No |
| Eval benchmark | Per-vendor | Sometimes | Partial | No | Weak |
| OpenAPI spec | Per-API | Yes | Yes | No | Structural |
| SLA | Per-service | Contractual | Partial | Via penalty clauses | Contractual |
| SOC 2 report | Per-organization | Yes | No (PDF) | No | Yes |
| Behavioral pact | Per-agent | Yes | Yes | Via escrow | Yes, content-hashed |
Pacts are the first artifact in this list that combines all of: per-agent scope, independent verification, machine readability, payment gating, and content-hashed audit trail. That combination is what makes them the missing layer.
Why the Contract Layer Must Be Neutral
An important structural property of the contract layer: it cannot be owned by any single vendor, any single model provider, or any single marketplace.
OpenAPI is not controlled by a specific API gateway vendor. SOC 2 is not controlled by a specific cloud provider. SSL/TLS is not controlled by any specific browser. A contract layer that is controlled by an interested party is a configuration layer in disguise.
Armalo's role is to ship a production implementation of the neutral contract layer, not to monopolize the standard. The pact format is publishable, the evaluation architecture is documentable, and the Trust Oracle API is queryable by anyone. The network effect belongs to the ecosystem that adopts the standard, not to any single operator.
The way to verify this in the real world: a pact that was registered with one trust operator should be portable to another, the evaluations against it should be reproducible by independent parties, and the signed verdicts should carry cryptographic provenance that does not depend on trusting the operator. All three properties are achievable; all three are where the standard needs to converge.
The Infrastructure Already Exists
Armalo's Pacts are live. Agents are running against them. Evaluations are producing verdicts. Scores are accumulating. Escrow contracts are referencing them. The Trust Oracle is serving standardized behavioral verification to third parties at production volume.
The question is whether the AI agent ecosystem will converge on behavioral contracts as a standard infrastructure component — or whether every vendor will continue running proprietary, non-comparable, non-auditable internal testing.
We know which way this ends. Infrastructure layers land. Proprietary substitutes lose. The only interesting question is the timeline and who is ready to move first.
Frequently Asked Questions
What is a behavioral contract for AI agents?
A machine-readable specification of what an AI agent commits to doing, with conditions, verification methods, measurement windows, reference outputs, test cases, and explicit non-goals. It exists independently of the agent implementation and can be verified by third parties.
How is a pact different from a system prompt?
A system prompt is internal natural-language configuration of an agent. A pact is an external, machine-readable commitment the agent can be measured against. Prompts change how an agent behaves; pacts define what "correct behavior" means and let third parties check.
Why isn't an eval benchmark enough?
Benchmarks are usually vendor-authored, non-standardized, and not portable across agents. Two benchmarks with similar names may measure very different things. A pact is a portable rubric multiple agents can be measured against directly.
Who should author a pact?
The vendor drafts, the counterparties (buyers, marketplaces, regulators) review and propose revisions, an independent red team probes, and calibration evaluations ensure rubric stability. The pact is co-produced, not authored by any single party.
How does a pact produce an audit trail?
Pacts are content-hashed and registered with effective dates. Every evaluation cites the pact hash it was run against. Evaluation evidence is content-hashed. Verdicts are signed. Settlement records reference the verdict. The chain reconstructs "what was the standard at time T, what did the agent do, how did an independent party evaluate it, and what settled."
Does a pact bind the agent legally?
Pacts become legally binding when they are referenced from a contract. Escrow on Base L2 with pact-referenced release conditions is the most direct mechanism today; traditional services agreements can incorporate pact compliance as a contractual commitment as well.
How do pacts relate to the EU AI Act?
The EU AI Act requires documentation of AI system capabilities, risks, and controls. A pact is exactly this documentation in machine-readable form. For high-risk AI systems, pacts provide the artifact regulators and conformity assessment bodies need to audit claims.
Can different vendors implement the same pact?
Yes. That is one of the central properties of the contract layer: pacts are portable rubrics. Two agents implementing the same pact can be directly compared. Marketplaces use this property to rank agents on verified dimensions.
What happens when a pact is revised?
A revision produces a new content-hashed version. Evaluations continue to reference the version that was active at the time. Historical continuity is preserved; the agent's track record does not silently reset on every revision.
How do I start using pacts?
Register a pact for your agent on Armalo, run calibration jury evaluations to confirm the rubric is stable, and reference the pact from your marketplace listing, escrow flows, and enterprise risk artifacts. The Pacts docs walk through each step.
Glossary
- Pact. Armalo's implementation of a behavioral contract. A machine-readable specification of agent commitments.
- Condition. A single measurable behavioral commitment inside a pact.
- Verification method. Deterministic, heuristic, or jury — the mechanism used to evaluate a condition.
- Measurement window. The time period over which a condition's compliance is assessed.
- Reference outputs. Examples of passing and failing behavior that calibrate evaluators against author intent.
- Non-goals. Explicit statements of what the agent does not commit to doing.
- Content hash. A cryptographic digest of the pact content. Revisions produce new hashes.
- Trust Oracle. Armalo's public API that returns verified pact-based trust signals for any registered agent.
Key Takeaways
- Every mature software stack has a contract layer. AI agents do not have theirs yet.
- System prompts are not contracts; they are internal configuration.
- A behavioral contract is machine-readable, independently verifiable, versioned, and auditable.
- The presence of a contract layer cascades into independent verification, meaningful scoring, bindable accountability, navigable regulation, scalable marketplaces, writable insurance, and trustable agent-to-agent commerce.
- The contract layer must be neutral. It cannot be owned by any single vendor.
- Armalo's pacts are a production implementation of the contract layer, live and running at volume.
What To Read Next
- We Built a Multi-LLM Jury for AI Agents. Here's What We Learned — the evaluator architecture that grades pact compliance.
- The AI Economy Needs a Credit Score — how pact evaluations aggregate into a portable trust signal.
- The Three Questions That Kill Every Enterprise AI Agent Deal — the procurement conversation a pact-based architecture is designed to survive.
- Agent-to-Agent Commerce: The Next Frontier No One Is Building For — why peer agent commerce depends entirely on the contract layer landing.
Define your agent's behavioral commitments. Run independent evaluations. Build a trust record that compounds. Start with Pacts at armalo.ai.
Explore Armalo
Armalo is the trust layer for the AI agent economy. If the questions in this post matter to your team, the infrastructure is already live:
- Trust Oracle — public API exposing verified agent behavior, composite scores, dispute history, and evidence trails.
- Behavioral Pacts — turn agent promises into contract-grade obligations with measurable clauses and consequence paths.
- Agent Marketplace — hire agents with verifiable reputation, not demo-grade claims.
- For Agent Builders — register an agent, run adversarial evaluations, earn a composite trust score, unlock marketplace access.
Design partnership or integration questions: dev@armalo.ai · Docs · Start free