An autonomous software agent is a program that takes a goal, makes a plan, calls tools, and produces an output. Many such agents exist. They are built by different teams, on different runtimes, with different model backends, and they live in different deployment environments. There is no standard for them to talk to each other, and — more importantly — there is no standard for the record of what they did.

AIP, the Agent Interoperability Protocol, addresses the second gap before the first. Its centerpiece is the audit chain: a per-host JSONL file in which every state-changing action an agent takes is recorded as a signed entry whose hash links to the prior entry in the same session. A third party with a copy of the file can verify the chain, and only the chain, with no help from the agent that wrote it. The math is the witness. The log is the receipt.

The shopping list

A family is texting about groceries. The messages are inconsequential, the people are trusted, and the only agent in the loop is a small assistant that watches the chat, picks out “we need milk” and “add eggs to the list,” and writes a shopping list. There is no adversary. There is no regulator. There is no blockchain. There is no third-party witness.

What there is on the assistant’s host? A local JSONL log. For every message the assistant saw, several audit entries are written, in order:

SESSION_OPEN
MESSAGE_OBSERVED      (msg-001, alice, family-kitchen, sha256="…")
KEYWORD_EXTRACTED     (msg-001, "milk", matchKind=substring)
ITEM_DEDUPLICATED     ("milk", action=kept)
CATEGORY_ASSIGNED     ("milk", dairy, confidence=1.0)
LIST_ENTRY_WRITTEN    ("milk", dairy)
SESSION_CLOSE

Each entry is signed with Ed25519 and linked by SHA-256 to the previous one. A week later, somebody asks: where did the milk on the list come from? The assistant’s log answers in two operations: find the LIST_ENTRY_WRITTEN entry, follow the trail back through CATEGORY_ASSIGNED, ITEM_DEDUPLICATED, and KEYWORD_EXTRACTED, to a MESSAGE_OBSERVED whose messageHash recomputes from the original text.

The assistant did not have to be there. A partner, a regulator, a future you — anyone with the log file and the assistant’s public key — can import verifyChain(sessionId) and check every signature and every hash link. No network call. No trust in the writer. No external timestamp authority. The receipt is the product.

What AIP is

AIP is a wire-level protocol for two autonomous agents to do five things across a trust boundary:

  1. Identify. Every participant is named by a W3C-style DID of the form did:aip:<agent-type>:<random-id>. The agent type is a small registered set — RESEARCHER, BUILDER, REVIEWER, DEPLOYER, ROUTER, and so on. The identifier is stable across key rotations.
  2. Authenticate. Every message is signed. The signature is Ed25519 over the canonical JSON of the envelope. There is no unsigned message in the protocol; this is a MUST, not a SHOULD.
  3. Negotiate. Before any work is exchanged, the two parties run a lightweight handshake. The initiator declares the capabilities it needs. The responder declares the subset it actually supports. The intersection becomes the working set for the session. If the intersection is empty, the responder rejects — no work is exchanged, no audit entry beyond SESSION_OPEN is written.
  4. Exchange work. A typed TASK envelope goes one way. A typed RESULT or ERROR envelope comes back. The wire contract is normative; the body is whatever the host wants.
  5. Account. Every state-changing action produces a signed audit entry. The entries form a cryptographic hash chain. A verifier walks the chain in linear time and detects retroactive tampering.

The default handshake is the lightweight variant: Ed25519 over canonical JSON with a signed principal claim. A zero-knowledge attestation layer is available for sessions that need cross-epoch unlinkability, but it is not required for conformance and not part of the default path.

What AIP is not

AIP is not a consensus or distributed-systems protocol. The audit chain is a local file, not a shared ledger.

AIP is not a cryptocurrency, blockchain, or token. There is no chain of blocks, no mining, no economic incentive, no global state, and no on-chain anything.

AIP is not a new cryptographic construction. The primitives — Ed25519, SHA-256, canonical JSON — are audited standards.

AIP is not an agent framework. It does not specify how an agent reasons, plans, or learns; only how it talks to another agent and how it records what was said.

AIP is not a privacy silver bullet. The structural “personal forces local” routing rule does real work, but it constrains a single layer of the stack. The trust root for a personal agent is the user’s local machine, hardware key, and session authorization. AIP is the receipts layer that sits between those roots and the rest of the world.

How it fits with the adjacent protocols

AIP is the envelope-and-attestation layer. A2A, MCP, ACP, and OAuth are adjacent layers, and the two are complementary, not competing.

  • A2A handles agent-to-agent task cards and discovery.
  • MCP handles model-to-tool integration over JSON-RPC.
  • ACP / FIPA-ACL supplies the performative vocabulary — INFORM, REQUEST, REFUSE — that gives a message its meaning.
  • OAuth 2.0 / JWT supplies bearer-token authorization for HTTP APIs.
  • W3C DIDs / VCs supply decentralized identifiers and verifiable credentials.

A reasonable deployment uses A2A discovery to bootstrap an AIP session, exposes MCP tools through an AIP-gated channel, carries ACP-style performatives as the envelope body, and authorizes the result via an OAuth-issued bearer token. ACP is the closest living ancestor to AIP. AIP carries forward that performative vocabulary and adds what ACP leaves to the application: Ed25519 signing, the W3C DID identity model, the capability-intersecting handshake, the hash-chained audit, and the routing-precedence privacy rule.

Audit out, handshake in

The conventional way to think about trust between two services is: establish a session, then do work. AIP reverses the emphasis. The handshake brings the session into being; the audit chain is what the agent leaves behind. The chain is the only layer that, once written, cannot be retroactively rewritten without leaving evidence.

Other layers — identity, routing, memory, tool calls — can be rebuilt or replaced. The audit chain is the one layer where the answer is structural. That is why AIP exists: to give the operating system a way to keep its promises.

Start with the code

The reference implementation is at github.com/githubscum/aip-protocol, version 1.1.0. The specification is published under CC BY 4.0. The reference implementation is Apache License 2.0. The package is brand-neutral: it refuses to construct a DID, sign an envelope, or write an audit entry until the host application supplies a DIDProvider for where keys live.

The Core-conformant shopping-list example from this article ships at examples/openclaw/shopping-list/. It is small enough to read in an evening and large enough to exercise every idea in this post. Install the package with:

npm install github:githubscum/aip-protocol#v1.1.0

The quickstart is short: register a DIDProvider, build a MessageEnvelope, write an AuditEntry. The conformance suite is npm test. The build is smoke-tested by npm run smoke.

For the normative text, read the full spec. For the 10-page version, read the concise whitepaper.

The seventh layer

AIP sits above transport, identity, and signing. It does not specify how an agent reasons, only how it communicates, and only how it accounts for what it communicated. Below it: HTTPS, WebSocket, W3C DIDs, Ed25519. Above it: orchestrators, workflows, applications.

AIP is the layer that crosses the agent boundary, in either direction, in a way that is verifiable, auditable, and private by default. Any developer can build an AIP-conformant agent. Any two AIP-conformant agents can interoperate regardless of their underlying model, runtime, or deployment.

End of transmission.