DEV Community

Cover image for AI Agents Have Protocols. They Still Need Behavioral Contracts.
varun pratap Bhardwaj
varun pratap Bhardwaj

Posted on

AI Agents Have Protocols. They Still Need Behavioral Contracts.

#ai #machinelearning #programming #softwareengineering

AI Agents Have Protocols. They Still Need Behavioral Contracts.

Canonical note: Publish the Medium version first. Then replace https://medium.com/@varun.pratap.bhardwaj/ai-agents-have-protocols-they-still-need-behavioral-contracts-b612da467aae in the DEV front matter with the final Medium URL before publishing on DEV.

AI agent infrastructure is rapidly standardizing connectivity.

We have protocols for tools, models, and agent-to-agent communication.

But a connectivity protocol does not answer a production question that becomes more important as agents gain side effects:

What is this agent allowed to do right now, what must remain true while it acts, and what evidence will prove the decision later?

That is the problem behind Agent Behavioral Contracts (ABC) and the open-source project AgentAssert.

The project started as a research question and is becoming a runtime architecture.

1. Prompts are useful. Prompts are not policy engines.

Consider a coding agent with shell access.

You can put this in the system prompt:

Never execute destructive commands.
Never access credentials.
Ask for approval before changing production.
Enter fullscreen mode Exit fullscreen mode

Those are useful instructions.

But the side effect is still controlled by whatever execution path actually calls the tool.

A stronger design creates an external behavioral decision:

tool.requested
      |
      v
normalize event
      |
      v
evaluate contract
      |
      +---- ALLOW --------> invoke tool
      |
      +---- DENY ---------> return refusal + receipt
      |
      +---- REQUIRE_APPROVAL
Enter fullscreen mode Exit fullscreen mode

Now the policy is no longer only something the model is expected to remember.

It is an executable artifact.

2. The ABC model

Paper I formalized an Agent Behavioral Contract around four ideas:

  • Preconditions — what must be true before execution.
  • Invariants — what must remain true during execution.
  • Governance policies — organizational and operational constraints.
  • Recovery mechanisms — what happens when behavior violates or approaches a boundary.

A minimal conceptual contract might look like this:

contract:
  name: production-write-policy
  version: 1.0

preconditions:
  - deployment_environment == "production"
  - actor_authenticated == true

invariants:
  - secrets_in_output == false
  - total_cost_usd <= 5.00

governance:
  - production_write requires human_approval
  - allowed_tools in approved_tool_set

recovery:
  on_violation:
    action: deny
    emit_receipt: true
Enter fullscreen mode Exit fullscreen mode

That snippet is intentionally illustrative rather than the canonical current ContractSpec syntax. In production documentation, the contract shown to users should be copied from a version-validated repository example.

The engineering principle is what matters:

policy becomes explicit, versioned, and independently evaluable.

3. Runtime enforcement needs an actual boundary

A contract is only useful as an enforcement mechanism if it is evaluated before the side effect.

That means the runtime architecture needs a Policy Enforcement Point.

Possible surfaces include:

  • MCP tool requests;
  • framework before-tool hooks;
  • model requests;
  • HTTP or gRPC gateways;
  • agent input/output boundaries;
  • memory write proposals;
  • job or workflow transitions.

The key word is possible.

No adapter should claim complete control merely because it can observe one surface.

For example, an MCP interposer can make strong statements about MCP calls that pass through it.

It cannot automatically control a product's unrelated native editor or shell path unless that path is also routed through an enforceable boundary.

So a useful integration matrix should state:

  • framework and verified version;
  • adapter version;
  • observable events;
  • pre-side-effect enforceable events;
  • excluded/native surfaces;
  • fail-open or fail-closed behavior;
  • conformance evidence.

That is more meaningful than a wall of integration logos.

4. Declare → Enforce → Prove

The product model for AgentAssert is increasingly simple.

Declare

A versioned ContractSpec defines the behavioral constraints.

Enforce

A covered event is normalized and evaluated.

A decision can be represented with a vocabulary such as:

ALLOW
DENY
MODIFY
REDACT
REQUIRE_APPROVAL
DEFER
ERROR / INCONCLUSIVE
Enter fullscreen mode Exit fullscreen mode

INCONCLUSIVE or an equivalent state is important.

If a required signal is unavailable, silently treating the action as compliant can be dangerous.

Prove

The decision should emit a receipt.

A useful receipt includes:

{
  "contract_version": "...",
  "event_type": "tool.requested",
  "normalized_action_hash": "...",
  "evaluated_rules": ["..."],
  "decision": "DENY",
  "coverage_profile": "...",
  "side_effect_status": "not_executed",
  "trace_id": "...",
  "timestamp": "...",
  "provenance": "..."
}
Enter fullscreen mode Exit fullscreen mode

This turns “the guardrail blocked it” into something independently inspectable.

5. Why trajectory-level behavior matters

Most agent evaluation still focuses heavily on single outcomes.

But an agent can produce a reasonable-looking final answer while violating important constraints during execution.

Examples:

  • it queried an unauthorized source;
  • it exposed data to a tool before redacting the final response;
  • it exceeded a budget;
  • it made a prohibited intermediate write;
  • it recovered after a drift event;
  • it repeatedly approached a threshold across a long session.

A behavioral contract therefore operates over a trajectory, not just the final text.

This is also where drift and recovery become meaningful.

The question is not only:

Was turn 17 acceptable?

It is:

Did the system remain within the declared behavioral envelope over the mission?

6. The composition problem

Now consider a multi-agent pipeline:

Agent A -> Agent B -> Agent C
Enter fullscreen mode Exit fullscreen mode

Each component has a measured success rate.

A naive reliability calculation can be badly misleading if the component failures are dependent.

Shared causes include:

same model
same context
same retrieval source
same memory
same orchestrator
same upstream API
same hidden assumption
Enter fullscreen mode Exit fullscreen mode

If a shared failure mode hits all three components, their errors can be highly correlated.

Now consider redundancy:

          -> Agent B1 ->
Agent A                  -> decision
          -> Agent B2 ->
Enter fullscreen mode Exit fullscreen mode

If B1 and B2 fail independently, redundancy may help significantly.

If they share the same failure cause, the apparent redundancy may provide far less protection.

So dependence interacts with topology.

This is the problem addressed by Paper II: compositional reliability without silently assuming independent failures.

7. A better reliability API

The important product idea from the V2 work is that reliability should expose its evidence basis.

Rather than returning:

reliability = 0.94
Enter fullscreen mode Exit fullscreen mode

a system should be capable of returning something conceptually closer to:

event:
  name: end_to_end_mission_success

mission_distribution:
  id: ecommerce-support-v3

topology:
  type: series

evidence:
  direct_runs: 420
  available_joint_moments:
    - [stage_a, stage_b]
    - [stage_b, stage_c]

guarantee:
  tier: 1
  lower_bound: ...
  confidence_parameter: ...

assumptions:
  - ...

limitations:
  - ...

valid_until:
  - model/version change
  - contract/version change
  - mission-distribution shift
Enter fullscreen mode Exit fullscreen mode

The exact representation can evolve.

The design principle should not:

never separate the reliability number from the assumptions that make it meaningful.

8. Direct observation should beat reconstructed confidence

If you can directly observe the system-level success event, that should usually be the primary evidence.

For example, if the mission is:

"Order changed correctly, customer notified, no unauthorized discount,
and audit record written"
Enter fullscreen mode Exit fullscreen mode

then directly evaluate that mission outcome across complete executions.

Do not throw away the end-to-end evidence and reconstruct success from component pass rates unless you have a specific reason.

This sounds obvious.

In modular AI evaluation, it is surprisingly easy to violate.

9. Sometimes the right answer is “uncertifiable”

Suppose:

  • one stage has missing logs;
  • failures are selectively absent;
  • the mission distribution changed after a model upgrade;
  • components were evaluated on incompatible datasets;
  • co-execution evidence is unavailable;
  • the integration cannot observe the event that the contract claims to enforce.

A production reliability system should not be forced to produce a reassuring number.

It should be allowed to produce:

UNCERTIFIABLE
Enter fullscreen mode Exit fullscreen mode

with reasons.

That is a stronger engineering interface than fake precision.

10. MCP is a useful first proof surface

MCP is particularly useful for demonstrating this architecture because the tool invocation boundary is concrete.

A credible demonstration should show:

1. start real downstream MCP server
2. perform prohibited request without contract
3. confirm side effect occurs
4. route server through AgentAssert guard
5. repeat same request
6. receive DENY
7. confirm downstream invocation count remains 0
8. verify decision receipt
Enter fullscreen mode Exit fullscreen mode

That is a much stronger demo than a screenshot saying “blocked.”

The critical proof is:

the prohibited side effect never reached the downstream tool.

11. The portable-contract direction

A portable behavioral layer needs canonical data structures.

The current product blueprint is converging around concepts like:

AgentActionEnvelope
ContractDecision
DecisionReceipt
CapabilityManifest
ContractBundle
EvidenceReference
ApprovalRequest
CertificationBundle
Enter fullscreen mode Exit fullscreen mode

This allows each framework adapter to map its native lifecycle into one common behavioral vocabulary.

The adapter then publishes what it can actually support.

For example:

C0 = observe only
C1 = pre-model decision
C2 = pre-tool decision
C3 = pre-side-effect + result handling + approval
C4 = receipts + replay protection + signed evidence + conformance
Enter fullscreen mode Exit fullscreen mode

The exact naming can still evolve, but capability-grading is much better than binary “supported / unsupported.”

12. Relationship to other agent infrastructure

Behavioral contracts do not replace the rest of the stack.

They complement it.

Protocols: connectivity.

Identity / authorization: who can access what.

Guardrails: selected input/output/call screening.

Observability: traces and telemetry.

Evaluation: scenario-based evidence.

Behavioral contracts: portable behavioral obligations connected to runtime decisions and trajectory-level evidence.

These layers should integrate rather than compete for one giant “AI safety” label.

13. The broader Qualixar architecture

The separation I find useful is:

LLM / model
    |
    v
SuperLocalMemory
governed durable context
    |
    v
AgentAssert
behavioral contract + runtime decisions
    |
    v
AgentAssay
evaluation / regression / assurance
    |
    v
Qualixar OS / bounded execution
orchestration, approvals, bounded workflows
Enter fullscreen mode Exit fullscreen mode

In shorthand:

Rent the LLM. Own the memory. Enforce the behavior.

The model is replaceable.

The organization's memory and behavioral policy should not be.

14. What I want AgentAssert to become

Not another prompt wrapper.

Not a logo collection.

Not a dashboard that produces an unexplained “reliability score.”

The target is a neutral behavioral-contract layer between agent intent and consequential action.

It should answer:

  1. What behavior is permitted?
  2. Can this action execute now?
  3. Did the agent remain within contract across the trajectory?
  4. What drifted, failed, or recovered?
  5. What reliability statement is justified by the evidence?

That is a difficult product.

It is also the kind of infrastructure I think agentic AI will eventually require.

Research and implementation

  • Paper I: arXiv:2602.22302
  • Paper II: arXiv:2608.12895
  • Code: github.com/qualixar/agentassert-abc
  • Project: agentassert.com

If you are running agents with consequential tools, start with one question:

Which action in your current stack would you most want an independent contract to deny before the tool ever sees it?

Top comments (0)