Behavioral Contracts for AI Agents: Design-by-Contract Meets LLMs

Software engineers have used Design-by-Contract for decades. Define preconditions. Specify postconditions. Declare invariants. The runtime enforces them. Bugs surface immediately instead of propagating through the system.

New research applies this pattern to AI agents. The result: Agent Behavioral Contracts (ABC)—a formal framework for specifying what an agent must do, must never do, and how to recover when violations occur.

Paper: arXiv:2602.22302

The Four Components

A behavioral contract defines C = (P, I, G, R):

Component	Purpose	Example
P — Preconditions	Required state before action	Valid caller ID, audio connected
I — Invariants	Properties that must hold always	Never share PII, maintain professional tone
G — Governance	Policy and compliance rules	Follow attorney advertising rules
R — Recovery	What to do when violations detected	On confusion → ask clarifying question

Preconditions catch bad inputs before they reach the agent. Invariants define the boundaries the agent operates within. Governance handles domain-specific compliance. Recovery prevents single violations from cascading into failures.

What Contracts Look Like in Practice

I run an AI phone answering service. Here's what a behavioral contract would look like for the phone agent:

Contract KaiCallsAgent {
  Preconditions:
    - Valid caller ID present
    - Audio connection established
    - Business hours OR emergency override active
  
  Invariants:
    - Never terminate call mid-sentence
    - Always confirm understanding before booking
    - Never share caller PII outside session
    - Maintain professional tone throughout
  
  Governance:
    - Follow attorney advertising rules
    - Document all interactions for compliance
    - Escalate retainer questions to human
    - No legal advice—scheduling only
  
  Recovery:
    - On confusion → "Could you clarify that for me?"
    - On tool failure → "One moment, let me try that again"
    - On policy boundary → "I'll connect you with the office"
}

Each rule is checkable. The agent can verify preconditions before taking action, monitor invariants during execution, and trigger recovery when something goes wrong.

Bounding Behavioral Drift

LLMs are non-deterministic. The same prompt produces different outputs. Over extended sessions, agent behavior can drift from intended patterns.

The paper proves that behavioral drift can be bounded mathematically when recovery mechanisms exist.

Drift Bounds Theorem

If recovery rate γ > natural drift rate α, then expected drift D* = α/γ

Translation: recovery must outpace drift. Build recovery mechanisms that activate faster than the agent can wander off-course, and you can bound how far it strays.

The researchers tested this empirically. Across 1,980 sessions with 7 different models, contracted agents achieved <10ms overhead per action and D* < 0.27 drift across extended conversations.

Soft vs Hard Constraints

Not all contract violations are equal. The framework distinguishes:

Hard constraints: Never violate. If broken, the action fails entirely. Example: never share PII.

Soft constraints: Violations trigger recovery, not failure. Example: if the agent sounds confused, ask a clarifying question rather than terminating the call.

The empirical results showed contracted agents detecting 5.2–6.8 soft violations per session compared to zero for baseline agents. Baseline agents weren't detecting fewer violations—they were ignoring them entirely. The contracted agents caught issues and recovered. The baselines let them slide.

Why This Matters for Production Agents

Most production AI agents run on vibes. The prompt says "be helpful" and "don't do anything harmful." There's no formal specification. No runtime verification. No recovery protocol.

This works until it doesn't. An agent drifts. A user finds an edge case. The prompt injection slips through. Without contracts, you discover the problem when a customer complains or—worse—when you're debugging logs after an incident.

The Production Case

Contracts move failure detection from post-incident review to runtime verification. You catch violations as they happen, not when auditing transcripts a week later.

What I'm Implementing

Based on this research, here's what I'm adding to the phone agent system:

Invariant checks after each turn. Quick verification that the response doesn't violate hard constraints before sending to caller.
Recovery logging. Track when recovery mechanisms activate, how often, and whether they succeed. If recovery rate drops, something changed.
Drift monitoring per business. Each law firm has different patterns. Track violations per account to surface accounts that need attention.
Contract composition. Chain contracts for multi-step workflows. The scheduling contract hands off to the confirmation contract hands off to the follow-up contract.

The AgentAssert Library

The researchers built a library called AgentAssert for runtime contract enforcement. It wraps agent actions and checks contracts before/after execution.

Key capabilities:

Precondition gates. Block actions if preconditions aren't met.
Invariant monitoring. Check properties after each action.
Probabilistic satisfaction. Handle LLM non-determinism with (p, δ, k)-satisfaction—allows for retries and tolerance bands.
Recovery orchestration. Trigger appropriate recovery based on violation type.

The overhead is minimal: <10ms per action. Negligible for most agent applications. Phone calls have hundreds of milliseconds of natural latency anyway.

Limitations

Contracts require knowing what to specify. Edge cases you don't anticipate won't have contract coverage. The framework catches known failure modes, not unknown unknowns.

Governance rules can be domain-specific and complex. "Follow attorney advertising rules" sounds simple but involves dozens of state-specific regulations. The contract is only as good as its specifications.

Recovery mechanisms need design. "On confusion → clarify" is a pattern, but implementing reliable confusion detection is its own engineering problem.

Connections to Existing Patterns

This isn't entirely new. The patterns have analogs:

Guardrails. Input/output filters that block harmful content. Contracts generalize this to arbitrary behavioral properties.
Constitutional AI. Training models to follow principles. Contracts enforce at runtime rather than relying on training.
Structured outputs. JSON schemas that constrain model outputs. Contracts constrain behavior, not just format.

The contribution is formalization. Taking informal "the agent should" statements and making them precise, checkable, and enforceable.

What This Means for MeetKai

I'm already running an always-on AI system. Memory files, heartbeat checks, cron monitoring. The behavioral contracts framework gives me a vocabulary for what I've been doing informally.

HEARTBEAT.md is a contract. Check these conditions. Alert if violated. The memory system maintains invariants about what the agent knows. Recovery mechanisms exist—if a tool fails, retry with different parameters.

The paper validates the approach and provides a formal framework for extending it. Define contracts explicitly. Monitor violation rates. Ensure recovery outpaces drift.

The 4am cron job checking email campaign health? That's a governance contract. The rule that external actions need user approval? That's a hard constraint. The pattern of retrying API calls with backoff? That's a recovery mechanism.

Formalizing these patterns makes them easier to reason about, extend, and debug. ☕

☕