AI Agent Protocols: Choose by the Evidence They Expose

Choose AI agent protocols by the boundary they standardize, not by which acronym appears most often. Use MCP when a host needs tools or context. Use A2A when one opaque agent delegates a stateful task to another. Treat ACP as a migration input, because the ACP project now says it is part of A2A. Add narrower protocols only for narrower obligations, such as checkout or payment authorization. Then add an outcome verifier above every protocol: a successful handshake, tool result, terminal task, or payment receipt is evidence, but none necessarily proves that the user's intended work is correct. That rule avoids two expensive mistakes. The first is asking one protocol to solve discovery, execution, monitoring, authorization, and business verification. The second is stacking protocols that cross the same boundary, creating more adapters without creating more evidence. Start with the boundary, then inspect the receipts The current protocols are easier to reason about as layers. MCP crosses the host to tool boundary. The MCP specification dated 2025 11 25 defines hosts, clients, and servers; capability negotiation; resources, prompts, and tools; plus utilities for progress, cancellation, errors, and logging. That is a strong fit when an agent host needs to discover a database tool, read a resource, or invoke an external function through a common contract. MCP does not make the server a remote agent with a durable, portable task lifecycle. A JSON RPC request can be correlated, and a tool can return structured content, but an application still has to preserve the operation identity that matters to the business. If an email tool times out, a transport error does not tell you whether the destination accepted the message. Retrying from the protocol result alone can duplicate the effect. A2A crosses the agent to agent boundary. The current A2A 1.0 specification defines Agent Cards for capability discovery, Tasks with stable IDs and state, Messages, Artifacts, streaming updates, push notifications, retrieval, and cancellation. It explicitly supports long running and human in the loop work between agents that may keep their internal memory and tools opaque. That extra lifecycle is meaningful health evidence. A client can distinguish a task that is still working from one that is waiting for input, completed, failed, canceled, or rejected. It can retrieve the task after a stream disconnects and inspect artifacts instead of treating connection closure as completion. Yet an A2A COMPLETED task still reports what the remote agent believes happened. The caller must verify that the artifact satisfies the original contract. ACP is now a migration question. The ACP repository still documents agent manifests, runs, sessions, streaming, await requests, outputs, and errors. Its prominent current notice also says: “ACP is now part of A2A under the Linux Foundation.” For an existing ACP service, inventory the semantics you rely on and map them to A2A. For a greenfield remote agent boundary, treating ACP and A2A as independent competing bets would ignore the project's own convergence notice. Domain protocols add domain receipts. Google's current developer guide to agent protocols separates MCP tool access and A2A collaboration from UCP checkout and AP2 payment authorization. That composition is defensible because the layers answer different questions. UCP can structure a commerce operation. AP2 can bind authorization to an intent and produce a payment receipt. Neither receipt proves that the goods arrived or solved the user's problem. The reasonable default is therefore: choose MCP for tools and context; choose A2A for remote agent tasks; migrate ACP rather than starting a second agent to agent standard; add a domain protocol only when its typed receipts match a real domain obligation; never let protocol success substitute for outcome verification. Score six evidence fields, not feature counts A protocol comparison becomes operational when each row answers six questions: 1. Can the caller discover the capability and its current contract? 2. Is there an identity that survives retries, reconnects, and asynchronous work? 3. Can the caller distinguish working, waiting, failed, and terminal states? 4. Is cancellation represented, and can its effect be checked? 5. Is there evidence that the external side effect happened exactly as intended? 6. Is there proof that the user's promised outcome is present and valid? The first four are protocol shaped. The last two usually cross into application and business state. Boundary Best current fit Strong native evidence Evidence still owed Host to tools or context MCP capability negotiation, requests, progress, cancellation, errors, tool results durable business operation identity, external effect reconciliation, final outcome Opaque agent to opaque agent A2A 1.0 Agent Card, task ID, lifecycle, history, artifacts, streaming, cancellation semantic artifact validation and user outcome proof Existing ACP agent service migrate toward A2A manifest, run, session, await, output, error in the legacy contract migration parity, implementation tests, final outcome Commerce and payment authorization UCP plus AP2 typed checkout, intent and payment mandates, payment receipt delivery, acceptance, usefulness, and any non commerce work “Native” does not mean every deployment enables or implements a feature correctly. An Agent Card can be stale. A server can advertise streaming and mishandle reconnects. A tool result can be syntactically valid but refer to the wrong customer. Treat advertised capability, observed transport behavior, recorded effect, and verified outcome as separate receipts. This separation also keeps waiting from looking like failure. A2A has protocol vocabulary for long running work and human input. MCP has elicitation and progress facilities. Your health layer still needs an owner, deadline, resume path, and freshness rule. A valid wait without an owner is operationally abandoned even if the protocol state is legal. Run the evidence debt audit before choosing an adapter The accompanying artifact encodes four scenarios and the six evidence fields in protocol health matrix.json . Its audit does not award a single winner. It selects the protocol that matches the boundary and reports partial or missing receipts. Run it with: The fixed fixture returns: Every row requires an outcome verifier. That is the important result, not a protocol ranking. For the database tool, the wrapper might record a stable operation ID, expected row set, authorization scope, and a postcondition query. For delegated research, it might validate that every required question has a cited answer and that the artifact was generated after the request. For an ACP migration, it should replay waiting, streaming, cancellation, and error cases against both implementations before traffic moves. For a purchase, it should reconcile the signed authorization and payment receipt, then separately verify order acceptance and delivery. The audit deliberately marks some evidence as partial. MCP cancellation can stop protocol work without reversing an external write. A2A cancellation can produce a canceled task while a downstream system remains active. AP2 can produce a payment receipt without proving fulfillment. These are not protocol defects. They are boundary facts that an implementation must make visible. Keep protocol completion and outcome completion separate Model the two verdicts explicitly: This record refuses a false green. The remote agent has completed its protocol task and supplied an artifact. The user's work is not complete because one required answer and the source checks are missing. The safest next action is not to restart the whole task automatically. It is to request the bounded missing evidence, preserve the original task and artifact identities, and verify the delta. Use the same split for tool calls. Record request transport separately from effect reconciliation. If the tool timed out after sending a write, query the destination with the stable operation key before retrying. If the protocol cannot expose a durable key, create one at the application boundary. Command completion is activity; a verified destination state is evidence. Freshness belongs in both verdicts. A capability discovered yesterday may be gone today. A completed task may point to an artifact that was later replaced. A payment receipt can be valid while delivery is overdue. Store the source, observation time, expected refresh interval, and confidence for each decisive signal. A compact selection rule Use this order during architecture review: 1. Name the boundary in one sentence. 2. List the failure states the operator must distinguish. 3. Select the narrowest current protocol that exposes those states. 4. Mark every required receipt as native, partial, or missing. 5. Add application evidence only for the partial and missing fields. 6. Test reconnect, waiting, cancellation, duplicate delivery, stale discovery, and false complete cases. 7. Clear the work only after the promised outcome passes its own contract. Do not compose MCP and A2A merely because both are popular. Compose them when a remote A2A agent itself needs MCP tools: A2A owns delegation and task state, while MCP owns that agent's tool boundary. Keep their IDs linked but distinct. Do not add UCP or AP2 unless the workflow actually carries checkout or payment obligations. The matrix is a specification level audit, not proof that a particular SDK or server interoperates correctly. Optional features, extensions, authentication, authorization, reconnect behavior, and telemetry retention need implementation tests. Protocols also evolve; pin the specification version used by each adapter and repeat the audit before upgrading. Sidewisp is currently in private preview. Its intended direction is to make agent health, evidence, waiting states, and safe verification clearer across existing runtimes; production monitoring adapters and recovery systems are not generally shipped. The useful principle today is independent of any product: choose the protocol for the boundary, retain the receipts it can provide, and make the missing outcome proof impossible to ignore.