AIP: designing for agent interoperability

Why a protocol

Multi-agent systems fail at the seams. Individual agents can be well-built, well-tested, and well-documented, but the moment two of them need to communicate across a system boundary, those guarantees evaporate. Each team makes local assumptions about what the other side expects, those assumptions harden into undocumented contracts, and those contracts break silently.

AIP (Agent Interoperability Protocol) is our attempt to make those contracts explicit. Not by mandating an implementation (too many runtimes, too many use cases for that), but by defining a common surface: what agents must be able to say about themselves, how they negotiate intent, and how they propagate trust across hops.

Scope

The hardest design question was scope. A protocol that covers everything becomes a framework; one that covers nothing is just a style guide. AIP sits between those: it owns the surface that agents must share, and defers everything else.

This scope boundary is not arbitrary. Every item in “out of scope” is something where local context should win: the agent’s runtime, the team’s tooling, the compliance regime. Mandating a transport or a memory model would make AIP unusable in most of the environments we actually care about.

{
"id": "task_9f3a2c",
"intent": "summarize_document",
"payload": {
  "doc_id": "doc_abc123",
  "target_length": "short",
  "language": "en"
},
"provenance": [
  {
    "agent":      "api-gateway-v1",
    "signed_at":  "2026-03-15T14:22:01Z",
    "sig":        "eyJhbGciOiJFZERTQSJ9..."
  },
  {
    "agent":      "router-v3",
    "signed_at":  "2026-03-15T14:22:01.084Z",
    "sig":        "eyJhbGciOiJFZERTQSJ9..."
  }
],
"constraints": {
  "deadline_ms":  1500,
  "auditable":    true,
  "compliance":   ["hipaa"]
}
}

Every task in AIP travels inside a typed envelope. The orchestrator stamps it before forwarding; the receiving agent verifies the full chain locally.

The trust model

Trust is the hardest part of multi-agent design in regulated environments. When an agent receives a task, it needs to know three things: who originated the request, what chain of agents it passed through, and what authority each hop had to delegate.

AIP’s trust model is chain-of-custody, not capability-based. Each envelope carries a provenance chain: a list of signed attestations, one per hop. The receiving agent can verify the full chain without calling out to any external authority. Offline verification is a hard requirement: audit logs in regulated industries must be self-contained.

Delegation rules

An agent may only delegate authority it was granted. It cannot elevate privileges, and it cannot grant more time than it was given. These rules are enforced by the receiving agent on validation, not by any central authority.

Constraint inheritance

Constraints travel with the envelope and tighten at each hop. If the original caller sets a 500ms deadline and the first agent takes 120ms, the remaining 380ms is what the next agent gets, not a fresh 500ms. Compliance constraints work the same way: an “output must be auditable” flag cannot be dropped by an intermediate agent.

Backwards compatibility

Protocols die from breaking changes. AIP uses a manifest versioning scheme: each agent declares the protocol versions it supports. The orchestrator negotiates the highest common version during registration. Agents on older versions continue to work with a reduced feature set rather than failing hard.

A protocol that breaks the fleet to add a feature has the wrong trade-off curve. Upgrade paths matter more than feature completeness.

Status

AIP v0.3 is the current specification. It’s in use in two production environments (one financial services, one healthcare) and covers the core envelope format and trust model. Version negotiation and constraint inheritance shipped in v0.3. Observability hooks are planned for v0.4.

The spec is open. We’re deliberately not publishing a reference implementation yet. We’d rather see independent implementations find the rough edges before we lock anything in. If you’re building something that touches multi-agent communication in a regulated context, we’d like to hear from you.