Agents & Protocols

What is an agent protocol?

An agent protocol is the contract between an AI application and the outside world. It specifies how a model-driven client discovers what a tool can do, how it invokes that capability, how results come back, and, crucially, what neither side is allowed to assume about the other.

That last part is where the engineering lives. A protocol that only defined message shapes would be a serialisation format. The Model Context Protocol specification is layered on JSON-RPC 2.0 for exactly that reason: the wire format is the settled part, and the specification spends its length on who holds state, who decides to act, and who is accountable when a capability fires at the wrong moment.

Why do agent systems fail at their edges?

The failure modes worth planning for are catalogued in the OWASP GenAI Security Project, and most of them live at a boundary rather than inside a component.

Because the model is rarely the weak link. In production, agent failures cluster at three boundaries, none of which are about reasoning quality:

• The discovery boundary. The client learns what a server offers at runtime. If that description is vague, stale or over-broad, the model picks the wrong capability, and the fault sits in the description rather than the model.
• The trust boundary. Tool output enters the model’s context as text. Any system that treats a database row or a fetched page as trusted input has a prompt-injection channel it has not accounted for.
• The state boundary. Assumptions about sessions, retries and idempotency differ between protocol revisions. Code that assumes a session exists where none does will hold state nobody is keeping.

What should you check before adopting a protocol?

Four questions, in order, before the integration work starts:

1. Which revision does the server speak? Protocol eras are not interchangeable, and detecting the wrong one produces failures that look like transport bugs. Probe first, cache the answer per server.
2. What privileges does it run with? A locally spawned server holds your user’s permissions. Installing one is a supply-chain decision, and it deserves the scrutiny you would give any dependency with network access.
3. What does it put in the context window? Capability definitions are sent on every step. A verbose server can cost more tokens than the work it performs, which is a budget question before it is a design question.
4. Who approves consequential actions? If the answer is “the model”, you have not designed the trust boundary, you have deferred it.

If you cannot answer all four, the integration is not ready, however well the happy path demos.

How should you read this cluster?

Start from the mechanism rather than the announcement. Protocol posts age badly because the specs move: the useful question is never “what is it” but “what does the current revision actually require, and what does the previous generation of writing still get wrong about it”.

Every article here is written against the live specification and names the revision it was checked against. Where a widely-repeated claim is now outdated, it is called out explicitly rather than quietly omitted. The gap between what the spec says today and what the ecosystem still repeats is where most of the value in this cluster sits.

What is out of scope for this cluster?

Framework tutorials and SDK walkthroughs. Those are well served by vendor documentation and go stale within a release cycle. The focus here is the layer underneath: what the protocol guarantees, what it deliberately leaves to you, and which of those gaps will become your incident.