Writing
Agents Need Protocols Between Each Other, Not Just Tools
Tool calling solves the inside of the loop. It says nothing about one agent reaching another built by a different team on another platform.
Notes
For the last year, most agent architecture has been discussed from the inside out: give a model tools, connect it to data, let it call functions, and keep enough state around the loop for it to finish a task.
That solves only one side of the problem.
Google's Agent2Agent protocol, announced on April 9, treats another boundary as a first-class engineering problem: what happens when one agent needs another agent, built by a different team, running on another platform, with its own tools, memory and internal logic? Google launched A2A as an open protocol with contributions and support from more than 50 technology and services partners.
I think this is the more interesting question for large agent systems. If agents become useful in production, we probably will not build one enormous agent that understands every domain. We will build specialised systems and need them to cooperate without exposing all of their internals to each other.
Tool use and agent collaboration are different contracts
MCP gave the industry a useful model for connecting AI systems to external capabilities and context. An MCP server can expose data sources and operations through a common interface instead of every AI application implementing another proprietary connector. Anthropic introduced it in November 2024 specifically as an open standard for connecting AI systems with external data and tools.
A2A is aimed at a different boundary. Google explicitly describes it as complementary to MCP: MCP provides agents with tools and context, while A2A is intended to let independent agents communicate and coordinate.
That difference matters.
A tool is usually passive. It has a defined operation, receives parameters and returns a result. The caller is expected to understand roughly what the capability does.
An agent can be opaque. It may have its own model, prompts, tools, data sources, policies and long-running state. The calling system may know what outcome it can request without knowing how that outcome is produced.
Treating such a system as one giant function call throws away part of what makes it useful.
An agent needs to advertise capability, not implementation
One of the more interesting pieces of A2A is the Agent Card.
Google's launch specification describes a JSON document through which an agent can publish its capabilities and connection information. A client agent can discover that description and decide whether the remote agent is suitable for a task.
That sounds simple, but the abstraction is important.
In normal software integration, we tend to expose methods: create_invoice, search_candidates, submit_render_job. With an agent, the useful boundary can be closer to capability: "I can research candidates across these systems," or "I can manage this part of the asset pipeline."
The internal workflow does not need to be shared.
This is closer to how teams work. I can delegate a task because I know someone's responsibility and expected output. I do not need access to every intermediate decision they make.
If multi-agent systems scale, I suspect this distinction between capability and implementation will become increasingly useful.
Tasks need lifecycle, not only request and response
The second part of A2A that stands out to me is its task model.
Google defines a task as a protocol object with a lifecycle. A remote agent can work on it over time, report status changes and eventually return an artifact. The protocol is designed for both quick exchanges and jobs that may take hours or days with human involvement.
That is a much better fit for real production work than pretending every agent interaction is a synchronous API request.
A render job is not a request-response interaction. Neither is a large repository migration, research task, asset conversion batch or localisation pass. These jobs have states: accepted, running, waiting for input, failed, completed. They may produce files rather than text. They may require another system to continue later.
Once agents operate on this kind of work, the communication layer has to represent those states explicitly.
The model can decide what to do. The protocol still needs to tell the rest of the system what is happening.
This could reduce the pressure to build a super-agent
There is a natural tendency in AI products to keep adding capabilities to one agent.
Start with search. Add code execution. Add company files. Add browser control. Add CRM access. Add the production database. Soon the same model is carrying a large tool catalogue, several security domains and a growing amount of context.
That architecture becomes difficult to reason about.
Specialisation offers another route. A finance agent can own finance-specific tools and permissions. A development agent can own repository access and test infrastructure. A production agent can understand asset state and render operations. A user-facing coordinator can delegate work without receiving every internal tool definition from every domain.
A2A is interesting because it was designed for agents that do not need to share memory, tools or context. Google describes this explicitly as one of the protocol's design principles.
For production architecture, that can become a security boundary as much as a software boundary.
I would use this carefully in creative pipelines
In a Blender, rendering or game-development pipeline, I would not split every small operation into a separate agent. That would create orchestration overhead without buying much.
But domain boundaries already exist.
An asset-management system has one type of state. Blender has scene state. A render farm has job state. An engine build system has another. A localisation pipeline may be maintained by a different service entirely.
Today I would normally connect those systems with APIs, scripts and queues. Agents can sit above those deterministic interfaces and interpret higher-level intent.
If those agent layers become independently useful, a common protocol between them starts to make sense.
For example, a production coordinator could ask an asset agent to prepare a group of models. That agent may use MCP tools or direct APIs internally to inspect metadata and validate files. It could then return an artifact and task status through A2A. The coordinator does not need to know whether the remote agent used Blender Python, a database query or another model to finish the work.
That separation keeps the integration surface smaller.
Protocols do not solve trust
A standard message format does not make multi-agent systems reliable.
If one agent sends another a wrong result, the error can move across the system just as easily as a correct result. Capability discovery does not prove competence. A completed task status does not prove that the resulting artifact is valid.
The evaluation problem from single-agent systems therefore becomes larger, not smaller.
Every delegation needs a contract around expected output. Important artifacts still need deterministic checks. Permissions still need to stay close to the system that owns them. Long-running work needs timeouts, cancellation and observable status.
There is another issue: identity. Once agents from different platforms can request work from one another, authentication and authorisation stop being optional implementation details. Google says A2A was designed around enterprise authentication and authorisation patterns rather than inventing a separate security model.
I would treat remote agents more like external services than trusted coworkers.
My prediction: agent systems will become distributed systems
The architecture I expect is becoming clearer.
MCP can standardise how an agent reaches tools and context. A2A can standardise how one agent delegates to another. The agent runtime manages reasoning, execution and state inside each system. Deterministic software continues to own permissions, source-of-truth data and validation.
Those layers solve different problems.
If this direction holds, agent engineering will start to inherit more ideas from distributed systems: discovery, routing, capability negotiation, task ownership, retries, status propagation, authentication and failure isolation.
That seems more realistic to me than expecting one model process to own an entire enterprise workflow.
OpenAI's Agents SDK points in the same architectural direction from inside a single application: it already includes multi-agent handoffs, orchestration and tracing rather than treating an agent as one isolated completion.
A2A is only two days old, and Google still describes the current specification as a draft, with a production-ready version planned later in the year. More than 50 technology and services partners supporting the launch is a useful signal, but it does not prove that the protocol will become the standard.
The larger idea matters even if A2A itself changes.
Agents need a common way to use tools.
Once there is more than one agent, they need a common way to work with each other too.
Sources
- Google Developers Blog, Announcing the Agent2Agent Protocol (A2A), 9 April 2025.
- Anthropic, Introducing the Model Context Protocol, 25 November 2024.
- OpenAI, New tools for building agents, 11 March 2025.
- Anthropic, Building effective agents, 19 December 2024.
More
Other write-ups
Approval Is Not Publication
Thirty seven items in the queue, one approved, nothing published. The last arrow in the diagram is the only one that pays.
Neural Rendering Is Crossing From Reconstruction Into Synthesis
Reconstruction filled in what sparse sampling missed. DLSS 5 generates appearance the renderer never computed.
The Renderer Is Becoming a Training Data Engine
The renderer used to sit at the end of the pipeline. Physical AI gives the same scene a second job: teaching a model.
Local AI Is Becoming a Compute Fabric
Local AI meant one model on one machine. Routing inference across the devices already on a network changes the unit.
Agent Infrastructure Is Becoming a Product Category
Every team used to build the loop, the store, the sandbox. That layer is being sold rather than written.
Choosing a local model with a stopwatch, not a benchmark
Three models, five hard tasks, code actually executed. The official build was 2.4 times faster and more accurate than a community repack of the same model.
We measured real time lighting against baked light, and baked won
A 3D product simulation that had to look like an offline render. The real time version ran at 60 frames per second and looked like clay. Here is the measurement and the architecture that replaced it.
What actually broke in an agency run by agents
Three failures from a delivery stack that runs on AI. None of them were the model's fault, and all three reported success while producing nothing.
A Task Without A Check Command Is Not Automated
If a task has no command that can fail, the pipeline advances on the appearance of work.
A Gate The Model Writes Is A Gate The Model Loosens
Three quality gates returned green while the work behind them was wrong, each for a different reason.
The Scoring Model Was Wrong And It Put The Worst Lead First
A weighted sum let one axis substitute for the other, so a company with money and no problem ranked in the top twenty.
Building Software Got Easy. Getting Value Out Of It Did Not
Aristo took weeks to build. Everything after the build is still in progress, and that gap is the whole story.
Capability Is Becoming an Operational Risk Surface
Safety questions used to be about the text. Once a model can act, the capability itself becomes something to operate.
The Scene Graph Is Becoming an API for AI
A scene graph exists for artists and software. Agents are becoming another consumer, and they need structure rather than pixels.
Animation Is Moving From Clips to Motion Priors
Authored keyframes and blended clips are giving way to asking which constraints define acceptable motion.
Materials Are Becoming Learned Programs
A material is texture maps, parameters and shader code. It is starting to become a small learned program that answers a rendering question.
Procedural Systems Are Expanding Beyond Geometry
Geometry Nodes started with a narrow name. Blender 5.2 puts physics, sound and object data through the same graph.
The Unit of AI Work Is Becoming the Task, Not the Turn
Chat taught us to think one turn at a time. Long-running agents make the task the thing that is scheduled, resumed and reviewed.
Game Engines Are Becoming Operating Systems for Worlds
Engines have been judged on what they render and simulate. The Unreal 6 roadmap points at operating a world rather than drawing one.
The Model Is Becoming a Replaceable Backend
Choosing a provider used to mean choosing an architecture. A stable interface makes replacement possible and evaluation makes it safe.
The Harness Is Part of the Capability
The same model behaves differently depending on context policy, tool design and execution feedback. That surrounding software is not neutral.
Physics Engines Are Becoming Trainable Components
A simulator predicts what happens next. A differentiable one can answer which parameter should change to stop the failure.
The Agent Needs an Environment, Not Just Tools
A search function and a database query were enough for short loops. Longer work needs a place to stand.
Coding Agents Are Becoming General-Purpose Computer Workers
Repositories were a friendly environment: text in, terminal actions, checkable results. That was a starting point, not a boundary.
Open Standards Outlive Model Generations
A year after the MCP bet, the argument can be checked against what happened rather than what was hoped.
Colour Management Is a Pipeline Contract
Blender 5.0 reads as better display options. Giving a file an explicit working colour space is an architectural change.
The Best Model May Be a Router, Not a Model
GPT-5 moves model selection inside the system. The interesting unit stops being which model and becomes which compute policy.
World Models Are Not Game Engines Yet
Genie 3 generates a navigable 720p world at 24 fps. Production work needs state you can inspect when something goes wrong.
Memory Is Becoming a System Capability
A follow-up to the long-context argument. Storing, selecting and expiring facts is turning into a named part of the product.
Coding Agents Change the Unit of Software Work
AI coding tools have been judged where code appears on screen. The boundary moves when the agent owns a task instead of a snippet.
Agents Need a Runtime, Not a Prompt Loop
An agent is no longer well described as a prompt inside a while loop. The useful abstraction owns execution around the model.
Reasoning Is Not the Only Path to Better Models
Longer thinking improves maths and code. A model that solves a logic puzzle and misreads ordinary intent is not the better production model.
Rendering Is Becoming a Reconstruction Stack
Sparse samples, motion data and lower-resolution frames become a larger final result. Debugging becomes layered when reconstruction sits in the middle.
Agent Reliability Is an Evaluation Problem, Not a Prompting Problem
When an agent misses a step, the usual fix is a stricter prompt. The failure is more often in how completion is detected.
MCP Might Matter More Than Another Model Release
A model can reason well and still be useless inside a company if it cannot reach the files, repositories and tools where work lives.
Computer Use Is the Missing Layer Between Models and Software
Most integrations assume useful software exposes the right API. Much of real software never did.
Inference-Time Compute Is a New Scaling Axis
o1 improves when it is allowed to spend longer on a problem. A benchmark score without a compute budget is an incomplete number.
The Final Pixel Won't Come From the Renderer
Geometry, camera and scene structure stay reliable ground truth. More of final appearance is moving into learned systems.
Open Models Are Becoming Research Infrastructure
Llama 3.1 gets discussed as a benchmark result. The licence terms change which experiments are possible at all.
The Model Is Becoming a Runtime
Function calling, code execution and structured output turn inference into a loop. The model stops being a text generator and starts being a control layer.
Multimodality Changes the Architecture, Not Just the Interface
GPT-4o is easy to read as a faster interface. Training one model end to end across text, vision and audio is an architectural change.
Benchmark Scores Are Not Model Capability
Claude 3 posts 86.8% on MMLU and 50.4% on GPQA Diamond. The chart is useful and it is not the same thing as capability.
Long Context Is Not Memory
Gemini 1.5 makes a million tokens usable. A larger working set is not a system that decides what should survive the session.