OIP vs A2A: asking vs proving

Two protocols keep getting mentioned in the same breath because both have "agent" in the pitch. They do not compete. A2A is a wire protocol for conversations between agents that do not trust each other's internals. OIP is an execution and accountability substrate inside one build. Confusing them costs you real architecture time, so here is the honest comparison, spec detail included.

What A2A actually is

Agent2Agent (A2A) is the protocol Google announced in April 2025 and donated to the Linux Foundation in June 2025, with 100+ vendors signed on. It standardizes how one agent asks another opaque agent to do work:

• Discovery — Agent Cards. An agent publishes a JSON card (canonically at /.well-known/agent.json) declaring its identity, endpoint, version, skills (named capabilities with descriptions and example prompts), supported input/output modes, and auth requirements. A client agent reads the card and decides whether to engage. The card is a promise, not a proof — nothing in A2A verifies that a skill does what it claims.
• Transport. JSON-RPC 2.0 over HTTPS. Core methods: tasks/send (one-shot), tasks/sendSubscribe (with Server-Sent Events streaming), tasks/get, tasks/cancel, plus push notifications to a client webhook for long-running work.
• Unit of work — the Task. Every exchange creates a Task with a lifecycle: submitted → working → input-required → completed | failed | canceled. Tasks carry Messages (role user/agent) composed of Parts — TextPart, FilePart, DataPart (structured JSON) — and produce Artifacts, also made of Parts.
• Opacity by design. Agents never share memory, tools, or internal reasoning. You send a message; you get status transitions and artifacts. What happened inside is invisible, on purpose — that is what lets Salesforce talk to SAP without either exposing internals.
• Enterprise auth. The card declares auth schemes aligned with OpenAPI conventions — OAuth2, OIDC, API keys, mTLS. Identity is handled at the HTTP layer, not inside the payload.

What A2A deliberately leaves out: any record of what an invocation cost, any receipt you can audit later, any way to verify a claim in the card, any repair semantics when a task silently produced garbage. The task history lives with whichever server ran it, in whatever form it likes.

What OIP actually is

The Object Invocation Protocol is this build's substrate. Its unit is not a conversation — it is the work object: a directory row (fn, http, agent, or flow) whose contract is its docstring (WHAT / WHEN_TO_USE / ARGS / EX) and whose behavior is invokable by anyone holding the right capability:

• Discovery. GET /api/dispatch?registry=1 returns every invokable object with its self-description; ?ask=<question> answers "how do I do X" with the exact call. The registry is generated from the same rows that execute — it cannot drift from reality the way a hand-written card can.
• Invocation. POST /api/dispatch {key, body, actor} — or GET ?invoke=KEY&body=… for callers that can only open URLs. One envelope for every object type.
• The invariant loop. resolve → validate → execute → ledger → respond with data + _self + yield. Every invocation writes full request and response to an append-only ledger (D1, overflowing to R2), stamped with actor and trace.
• Receipts. Every response carries links.receipt → GET /api/dispatch?receipt=inv_ID returns the complete request, response, cost, and lineage of that exact invocation. This is the part A2A does not have at all: a third party can audit what happened without trusting the agent's memory.
• Lineage verbs. {replay: "inv_ID"} re-executes a past invocation from its recorded input. {key, body, repairs: "inv_ID"} links a corrective invocation to the failure it fixes, in both directions (repairs / repaired_by). Failure is a first-class, queryable object.
• Yield accounting. Every invocation records tokens in/out, cost in USD, and a material/waste flag. The build can tell you what a capability costs and which objects burn money without producing anything.
• Capability tokens. Share tokens scoped to read / act / a single row / N uses — a capability, in the object-capability sense, not a session. A model holding a one-shot row token can fire exactly that object exactly once, and the ledger records it did.

What OIP deliberately leaves out: multi-party federation. It is single-build by design — one directory, one ledger, one owner. There is no standard body behind it, no SSE task streaming, no cross-org identity story. It does not need one to do its job, which is making one build's every action provable.

The actual difference, side by side

• Unit — A2A: a Task with a conversation lifecycle. OIP: an invocation with a receipt.
• Peer model — A2A: opaque agents across organizations. OIP: objects inside one build.
• Discovery — A2A: an Agent Card, which is a claim. OIP: a registry generated from the same rows that execute, which is live fact.
• Evidence — A2A: task state only, held by whichever server ran it. OIP: an append-only ledger with full request/response and a receipt per invocation.
• Failure — A2A: a failed state, then nothing. OIP: repairs/repaired_by lineage plus replay from recorded input.
• Cost — A2A: out of scope. OIP: tokens and USD and a material/waste flag on every invocation.
• Trust — A2A: auth at the door (OAuth2/mTLS), then faith. OIP: auth at the door, then proof after every call.
• Streaming — A2A: SSE and push notifications. OIP: none — request/response plus async rows.
• Governance — A2A: a Linux Foundation standard with 100+ vendors. OIP: one build's law.

The compressed version: A2A standardizes asking. OIP standardizes proving. A2A tells you how to hand work to a stranger; OIP tells you exactly what happened to every piece of work you ran, forever, with the receipt to show a judge.

Where they compose instead of compete

If this build ever needed to accept work from outside agents, the layering is obvious and non-conflicting:

1. A2A at the door. Publish an Agent Card whose skills are OIP objects. skills[].name maps 1:1 to directory row keys; the card's examples come from each row's EX: line. The card stops being a promise and becomes a projection of the live registry.
2. OIP under the floor. Every incoming A2A Task becomes an OIP invocation. The Task's completed artifact carries links.receipt as a DataPart — so the external caller gets what A2A never gives them: an audit trail. A failed Task maps to a ledgered failure that repairs can later link to.
3. Cost surfaces upward. A2A has no cost semantics; an OIP-backed A2A server can put yield (tokens, cost_usd, material) in artifact metadata, which matters the moment two orgs bill each other for agent work.

That composition — A2A as the diplomatic protocol, OIP as the court record — is strictly stronger than either alone, and neither spec has to bend to do it.

The honest weaknesses, both directions

• A2A's card is unverified marketing until the first task returns; its "trust" story ends at authentication. Interop demos have outnumbered production cross-vendor deployments so far, and the spec is young enough that task semantics still shift between versions.
• OIP is one build's law, not a standard: no second implementation, no federation, and its opacity trade-off is inverted — everything is visible, which is correct for an owner auditing his own system and wrong for two competitors sharing a wire.
• Neither protocol makes an agent good. A2A will faithfully transport a bad answer with a valid lifecycle; OIP will faithfully ledger a wasteful invocation with a perfect receipt. Quality is a layer above both — which is exactly why this build routes model output through review gates before anything is published.

The rule of thumb

Reaching across organizations to an agent you do not control: A2A. Running work inside a system where every action must be provable later: OIP. Building something serious: A2A at the boundary, OIP-grade receipts underneath — because "the agent said it finished" is a status, and a status is not evidence.