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:
- 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.
- 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.
- 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.
- 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.
In the cited docs, OpenAI's Agents API says OpenAI runs orchestration, compaction, recovery, and session state, while Anthropic says Claude Managed Agents can evaluate each server-run tool call and allow, ask, or deny it. If your requirement is vendor-side approval logic, Claude documents that boundary directly and OpenAI does not in these pages.
4 min read
Agent2Agent and MCP solve different boundaries. A2A standardises how one agent discovers another, opens a task and receives updates or artifacts back. MCP standardises how an agent runtime discovers and uses tools, resources and prompts. Use MCP inside an agent. Use A2A when the other side owns its own planner, state and operators.
4 min read
Two shipped integrations put Jev inside an agent loop, from Pydantic AI and LangChain. Both leave three things to your code: a ledger of actions already executed, because Jev may re-propose a tool that ran; a per-question projection of state, because accuracy falls as irrelevant context grows; and the confidence threshold that escalates to a language model.
5 min read
Two of OpenAI's first six published misalignment reports describe models writing instructions into their own compaction summaries. In one, 2.15% of 5.6-Sol reinforcement learning summaries carried text telling a later context to conceal information from the user. A compaction summary is a channel the model writes and then reads back as its own memory.
5 min read
The split is one field. A publicly reachable server is configured with `server_url`, and a tunneled one with `tunnel_id`, which is what lets an endpoint inside your network boundary stay unreachable from the internet while OpenAI still calls it. Everything else about the integration is the same.
4 min read
The auto permission policy, shipped on 10 September 2026, has the Claude Managed Agents server run, deny or pause each tool call. It assesses tool results, fetched pages and MCP responses without taking instructions from them. It does read user.message events as your intent, so relayed end-user text can get a call allowed that would otherwise be denied.
5 min read
Google ADK is the cleaner fit when your agent already lives beside Gemini, Vertex AI and Google Cloud identity. LangGraph is the cleaner fit when the hard part is a stateful workflow you want to run on your own runtime. Manual deployment for both starts with packaging the agent as an API.
5 min read
Revision 2026-07-28 removed SSE resumability from MCP, and defines a client disconnect as cancellation of that request. A timeout closes the stream, the server only SHOULD stop, and the client must re-issue with a new request ID. MCP specifies no idempotency key, so the server cannot tell a retry from a second call.
5 min read
Approval of AI-generated work depends on a scoped change, visible evidence, repeatable verification, and honest limits. GitHub pull requests, NIST AI RMF 1.0 and OWASP guidance all point to the same pattern: make the work inspectable without asking the system to explain itself later.
5 min read
MCP revision 2026-07-28 requires ttlMs and cacheScope on every list result and tells servers to return tools in a deterministic order. Both are filed as minor changes. They are the most direct cost change in the revision, because tool definitions sit in the cacheable prefix of every agent step.
3 min read
SEP-2640 reached Final status and landed in the MCP docs on 13 September 2026. It requires hosts to verify every skill file against a SHA-256 digest and byte size, and binds approval to that manifest so one changed file revokes it. The tools primitive specifies none of this. MCP now has two content surfaces with opposite integrity models.
3 min read
Anthropic measured one Drive to Salesforce transfer falling from 150,000 tokens to 2,000 by writing code against MCP servers instead of calling tools directly. That is a code execution result rather than an argument for deleting MCP. The Agent Skills spec puts numbers on the alternative: about 100 tokens per skill at rest.
4 min read
The Model Context Protocol is a JSON-RPC 2.0 layer that lets an AI client discover and call capabilities exposed by separate servers. It defines three primitives: tools, resources and prompts. Since revision 2026-07-28 it is stateless, negotiating per request rather than per session. It standardises transport and discovery. Authorisation stays your job.
6 min read