
A2A Explained: How Agent-to-Agent Communication Differs from MCP
MCP answers "what can I call?" A2A answers "who can I hand this to?" Different questions, different failure modes.
Read tutorialSecurity boundaries for agent capabilities and execution, including isolation, authorization, permissions, approvals, and independent checks.
Tagged articles
19 articles in this tag.

MCP answers "what can I call?" A2A answers "who can I hand this to?" Different questions, different failure modes.
Read tutorial
The demo worked because the agent was running on your laptop. It had your credentials, your network, your home directory, and your shell history. Move it…
Read tutorial
The demo agent works. It reads the file, runs the test, patches the bug. Then it ships to a second tenant, the session runs for six hours, the process dies…
Read tutorial
Every agent builder hits the same wall. The first working agent is small: a system prompt, a few tools, a loop. Then someone needs release notes. Someone…
Read tutorial
Hop three. The context window is full. Half of it is plausible garbage — passages that matched the query, ranked well, and turned out to be useless. The…
Read tutorial
A scanner that flags ten thousand findings and a researcher who proves three are both "finding vulnerabilities." Only one of them has evidence you can…
Read tutorial
The agent writes the function, re-reads it, decides it looks correct, and stops. The code is wrong. This is the most common failure in autonomous coding,…
Read tutorial
The demo works. The agent reads the queue, drafts the update, and posts it. Then someone asks who approved the change, which run produced it, and how to…
Read tutorial
The agent worked yesterday. Today it burns forty thousand tokens before it reads your first instruction, and the hook that used to register identity with a…
Read tutorial
A team wires up an MCP server, watches the tools appear in the client, and concludes the integration works. Then a tool gets renamed upstream, a resource…
Read tutorial
An agent that only works until the container restarts is not an agent. It is a demo with a heartbeat.
Read tutorial
Two projects both advertise "open source, model-agnostic, multi-channel, MCP support." A builder picks one, ships it, and discovers the real difference the…
Read tutorial
Your agent has thirty tools, four MCP servers, and a plan-mode toggle. It still fumbles a routine refactor, and when it does, you cannot tell whether the…
Read tutorial
That is the shape of the failure I keep seeing in agent systems that look governed and are not. A team writes a planner prompt, a coder prompt, a reviewer…
Read tutorial
The loop that improves the harness can also edit the evaluator, the permissions, and the rollback path. That is the whole problem in one sentence.
Read tutorial
Two teams run the same model on the same task. One ships reliably. The other drowns in tool-call latency, context bloat, and incidents nobody can explain…
Read tutorial
A failed agent run rarely looks like an interface problem. It looks like a model problem: wrong tool, malformed arguments, an error swallowed and retried…
Read tutorial
Two teams ship the same model, the same prompt, the same tool list. One agent finishes a multi-step task. The other stalls, loops, and quietly corrupts its…
Read tutorial
The demo worked. Production didn't. Somewhere between the two, the system took a path nobody wrote down, and when it failed there was no artifact…
Read tutorial