When does adopting an agent protocol beat plain HTTP or a queue between agents?

## Name what the protocol buys A senior answer to this question does not start from "protocols are good practice". It starts from the four capabilities an agent protocol supplies and asks which you lack: 1. **Discovery** — finding a peer you never integrated, reading what it can do, and choosing among candidates at runtime. 2. **A shared task contract** — a task identity and lifecycle so work survives a dropped connection, and a state that means "I need something from you". 3. **Capability negotiation** — both sides learning what the other supports (streaming, notifications, content types) without a coordinated release. 4. **Interoperability** — two agents built on different frameworks by different companies working together without a bespoke adapter each time. Every one of these is a **cross-boundary** capability. That is the tell. ## Inside one codebase, you already have all four When an intake agent and a negotiation agent live in the same repository and deploy together: - Discovery is compile-time. You know the negotiation agent exists; you wrote it. - The task contract is whatever you decide, and you can change both ends in one commit. - Capability negotiation is meaningless — there is one version deployed. - Interoperability is a non-problem: one language, one framework. What you actually need at that seam is delivery: durability if the receiver is down, backpressure when the producer outruns the consumer, retries, and dead-lettering for messages that cannot be processed. **A queue gives you exactly those and an agent protocol does not.** Putting an SQS queue between the intake agent and the negotiation agent — carrying a schema-validated payload — is not a downgrade from adopting a protocol; it is the better-matched tool. Add the schema and you have the one thing free text lacks: a checkable contract. The same logic favours a plain HTTP call when the interaction is short and synchronous, and a workflow engine when the pipeline needs durable multi-step execution with retries and human pauses. Inside a codebase, these still dominate in practice. ## Where the boundary actually is The adoption question is really an **ownership** question. Ask: - Do the two ends ship on the same release train? If yes, a shared type beats a negotiated contract. - Can I change both sides in one commit? If yes, you do not need version negotiation. - Do I know at build time who the counterparty is? If yes, you do not need discovery. - Is the counterparty's implementation something I am allowed to see? If no, you need an opaque protocol — and that is precisely what the agent plane offers, since peers exchange tasks and artifacts rather than prompts, memory or tools. The procurement case is the clean positive: your agent must source from supplier agents run by other companies, on stacks you do not control, whose capabilities change without telling you. There, hand-rolling an integration per supplier is the expensive option and the protocol is the cheap one. If a supplier exposes only plain REST endpoints and cannot stream, the REST-native alternative in the same family is the pragmatic meet-in-the-middle. ## The cost of adopting early Be explicit about it in an interview, because this is where judgment shows: - **Spec surface.** A protocol has versions, optional capabilities and behaviours you must implement correctly. It is a dependency with a roadmap. - **A new failure class.** Stale cards, unsupported capabilities, tasks that never reach a terminal state, notification endpoints that must be authenticated. None of these exist between two functions in one process. - **Indirection tax.** Debugging a protocol exchange is harder than reading a stack trace. - **Security surface.** Every remote agent boundary is a place where an untrusted party's text reaches your model. Prompt injection aimed at a delegated agent, lateral authority propagation across the graph, and confused-deputy patterns are all live concerns; the mitigation is per-agent identity and an effective permission equal to the intersection of the user's rights and the agent's allowed capabilities. This work is necessary at a real boundary and pure overhead at a fake one. ## A workable heuristic - **Same repo, same deploy** → typed function call, or a queue if you need durability and backpressure. No protocol. - **Different service, same organization** → HTTP or a queue with a versioned schema; adopt an agent protocol only if you genuinely need runtime discovery or long-running task semantics. - **Different organization or vendor** → agent protocol, with per-agent identity and delegated authorization. - **Reaching deterministic capabilities rather than peers** → that is the tool plane, a different problem with its own standard. "A standard for tools, an agent protocol for agents" is the sensible default framing as of mid-2026. ## Keep the migration cheap The way to avoid betting wrong is to make the transport swappable: put the schema-validated payload at the centre, and treat the queue, the HTTP call and the protocol client as interchangeable carriers of it. Then "adopt the protocol" is an edge change rather than a rewrite, and you can defer the decision until the boundary is real rather than hypothetical.