Designing Multi-Agent Systems on A2A: Nodes, Memory and Governance

Once a company has more than a couple of AI agents in production, the hard problems stop being about prompts and start being about architecture: how agents talk to each other, where their state lives, who coordinates them and how anyone audits what they did. This article lays out a reference blueprint for such a system, using the Agent-to-Agent (A2A) protocol as the communication backbone. By the end you should be able to reason about the building blocks of a single agent, the memory and orchestration layers that tie many agents together, the governance controls a multi-agent network needs, and the trade-offs to budget for before you scale.

From generative AI to agentic AI

The underlying shift is from generative systems to agentic ones. Generative AI is prompt-driven: a person asks, the model produces content, and the interaction ends. Agentic AI is goal-driven: the system receives a high-level objective, breaks it into smaller sub-goals and works through them with little human steering. The practical consequence for architects is scope. Generative models automate individual tasks, while agentic systems can automate entire workflows, turning AI from a tool that reacts into a delegate that acts. That is what makes it possible to scale operations that used to need someone watching every step. If you want a deeper treatment of the vocabulary, see agentic AI explained, from language models to autonomous agents.

Probabilistic engines and formal reasoners

At the centre of each agent sits a decision-making model, typically a large language model, or a large image model for visual workloads. These models are probabilistic. They produce fluent, convincing output, but they can hallucinate, and fluency is not the same as correctness. Formal systems such as OWL ontology reasoners or Bayesian networks behave differently: their conclusions follow from explicit rules and probabilities, so they are mathematically dependable within their domain. A robust design uses each where it is strong.

The same pragmatism applies to reasoning depth. Techniques like chain-of-thought prompting improve accuracy by making the model work through intermediate steps, but each extra step costs latency and compute. Deeper reasoning is not free, and the right depth depends on how quickly the system has to respond. Once you have many such agents, each with its own model and reasoning style, you need a shared way for them to communicate. That is the role of A2A.

A2A as the interoperability layer

A2A was proposed in 2025 as an open protocol for agents built on different frameworks and by different vendors to work together. Its purpose is to stop multi-agent systems from fragmenting into vendor-specific silos: agents built with different frameworks or hosted by different vendors can exchange context and coordinate work through one common interface. Adoption is still evolving, so check the current specification before committing to details.

The five design principles

• Treat agents as agents. The protocol assumes participants can reason and act on their own initiative, not just answer a single request. That opens the door to collaboration toward long-term goals rather than simple request and response.
• Reuse existing standards. A2A is built on familiar web technologies (HTTP, Server-Sent Events and JSON-RPC), so it slots into existing enterprise stacks. This lowers integration cost and makes it realistic to wrap legacy services with an agent interface.
• Secure by default. A network of agents has a larger attack surface than a single service. The protocol is designed so that interactions are authenticated and protected, which reduces the risk of an attacker taking control of an agent or siphoning data through it.
• Support long-running work. Some tasks take hours or days and involve asynchronous hand-offs between specialists. The protocol keeps track of task state and session continuity so that such work does not fall apart halfway.
• Stay modality-agnostic. Agents may exchange text, code or multimodal data. This matters most in robotics and industrial automation, where agents combine readings from many kinds of sensors in real time.

Following these principles guards against two classic failure modes: coordination failure, where agents fail to act in concert, and inter-agent misalignment, where decentralized participants gradually drift away from the shared objective. The principles become concrete inside each agent through a modular perception, reasoning and action loop.

Inside a single agent node

Each node runs a closed loop of input, processing, action and learning. Because the loop feeds results back into the agent's internal state, the node stays aware of its environment and adapts, instead of mechanically running through a fixed script.

The four subsystems

1. Perception. This layer takes in signals of every kind: natural-language requests, API event streams, images. It uses retrieval-augmented generation (RAG) to anchor those inputs in real facts before they reach the reasoning layer.
2. Knowledge representation and reasoning (KRR). Here intent is interpreted using a mix of statistical and symbolic methods. The language model handles nuance and ambiguity, while formal checks can confirm that the resulting plan is logically consistent.
3. Action selection and execution. Decisions become concrete outputs through a defined catalogue of API calls or outbound messages. This is the boundary where the agent's reasoning touches the digital or physical world.
4. Learning and adaptation. The agent tunes its behaviour heuristically based on what worked before. Tracking which tool choices succeeded lets it act more efficiently next time.

The main execution pattern is ReAct, short for reasoning plus acting. The agent alternates between thinking about the next step and observing the result of an action, which keeps its reasoning grounded in what actually happened. The cost is that every thinking step is another model call, so these loops add compute spend and response time that you need to plan for. What keeps them coherent across steps and sessions is memory.

Persistent memory across time

Language models are stateless: each call knows only what is in its context. For long-horizon planning, persistent memory is what binds the steps together. Without it, agents forget progress during multi-stage tasks or when work passes between sessions, which leads to repeated work and fragile systems.

Three kinds of memory

1. Episodic memory records what happened during a particular task, including the reasoning steps taken and the attempts that failed, all within a single session.
2. Semantic memory stores durable facts and structured organizational knowledge that every task can draw on.
3. Vector-based memory is built for similarity search, letting an agent retrieve relevant context from very large collections through RAG.

Keeping these separate matters because they have different lifetimes and access patterns. Episodic memory is short-lived and task-scoped, semantic memory is long-lived and curated, and vector stores are optimized for fuzzy retrieval rather than exact lookup.

Shared context for hand-offs

At scale, agents also need shared context buffers. When one agent passes a subtask to another, the buffer carries the full background and current state, so the receiving agent does not start from zero. Distributing state like this, in turn, calls for a coordinating layer above the individual agents.

Orchestration and goal decomposition

As systems grow, a single general-purpose model gives way to an ensemble of specialists. Assigning roles, for example an agent that plans like a CEO, one that writes code and one that reviews it, typically yields better accuracy and depth than asking one model to do everything.

What a meta-agent does

A meta-agent, or orchestrator, supervises the ensemble. Its responsibilities include:

• Assigning each subtask to the agent best suited to it.
• Managing dependencies so that outputs flow to the right place in the right order.
• Resolving conflicts when agents produce contradictory results or contend for the same resources.

Planning with Tree of Thoughts

Orchestration depends on breaking a goal into sub-goals. Planning approaches such as Tree of Thoughts explore several reasoning branches instead of committing to a single chain, which helps resolve uncertainty and reduces the brittleness and hallucinations that single-path plans are prone to. Exploring several branches also multiplies model calls, so it sharpens the latency trade-off discussed earlier.

There is a further risk: emergent behaviour. When many autonomous agents interact in non-linear ways, the system can produce outcomes nobody designed or predicted. Orchestration reduces this risk but does not eliminate it, which is why governance has to be part of the architecture rather than an afterthought.

Security and governance

A network of agents has a wide attack surface, and one compromised or confused node can set off a cascade of errors across the whole chain. The safe posture is to treat every agent-to-agent interaction as a potential source of risk.

The main risks

• Error cascades. A hallucination or mistake early in the chain is passed along and corrupts the final decision. The article on preventing hallucination compounding in agent graphs explores this failure mode in depth.
• Adversarial attacks. Prompt injection or model poisoning can hijack what an agent is trying to do.
• Bias propagation. Agents can amplify skewed patterns in data and produce systematically unfair outcomes.
• Accountability gaps. In a long, orchestrated chain it becomes hard to identify which node caused a failure.

Governance-aware architecture

Three mechanisms address most of these risks:

• Role isolation limits each agent's authority and the APIs it may call, so a compromised agent can do only limited damage.
• Traceable decision logging records every reasoning step so that failures can be audited and attributed.
• Agent authentication verifies the identity of every participant in the workflow.

On top of these, a formal verification layer separates what sounds right from what is logically valid. It is the architectural answer to the persuasive-but-unreliable nature of language models described at the start.

Where this is heading: proactive intelligence and AZR

As modular agents and orchestrated agentic systems converge, the next step is proactive intelligence: systems that notice cues in their environment and start workflows before anyone asks.

One research direction relevant to this is the Absolute Zero (AZR) paradigm. Rather than learning from human-labelled examples, it improves through reinforced self-play, generating its own problems and reasoning without external training data. What keeps this grounded is verifiable feedback, such as running generated code or checking formal proofs, which replaces human annotation as the source of truth. Treat it as an active research area rather than a production-ready technique.

Design checklist

Before scaling a multi-agent system, check the design against these questions:

• Formal verification: Is there a logic layer that distinguishes persuasive model output from results that are actually valid?
• Memory partitioning: Are episodic, semantic and vector-based stores clearly separated?
• Protocol standard: Does all cross-framework and cross-vendor communication go through A2A?
• Governance controls: Are role isolation and traceable decision logging enabled for every autonomous node?
• Latency budget: Have you measured and tuned the trade-off between reasoning depth, such as Tree of Thoughts, and response time?

Key takeaways

• Multi-agent systems move the problem from building tools that answer questions to building ecosystems that solve problems on their own, and that shift is architectural.
• A2A provides the shared language; each agent still needs well-separated perception, reasoning, action and learning modules.
• Memory and shared context are what make long-running, multi-agent work coherent.
• Orchestration improves quality through specialization, at the price of latency and a risk of emergent behaviour.
• Governance, from role isolation to formal verification, belongs in the design from day one.