AI Agent Communication: What MCP, A2A, and Shared Workspaces Actually Carry
Two AI agents can work on the same project and still have no reliable way to pick up each other's work.
AI agent communication covers the instructions, context, status, and outputs exchanged among agents, people, tools, and shared systems. Those exchanges travel through different layers: runtime messages, shared artifacts, MCP, A2A, and shared workspaces.
To choose the right layer, ask four questions:
- What does this layer carry?
- What remains available later?
- Who can see it?
- What does not cross the boundary?
AI agent communication layers compared
The distinctions matter most during handoffs. A task can be technically complete while the next person does not know it is ready. A patch can exist while its assumptions remain trapped in a runtime transcript. A status event can be delivered while nobody on the team has taken responsibility for the next step.
Native agent messages coordinate inside a runtime
Many agent systems already support some form of parent-agent and subagent communication. A parent can delegate a bounded task, receive a result and incorporate it into a larger plan. Some runtimes expose progress events or make subagent transcripts available to the operator.
This is the shortest communication path because the runtime controls both sides. It can define the message format, tool permissions and lifecycle.
The boundary appears when work leaves that runtime. A message sent to a native subagent is not automatically a message to an agent running in another product. The receiving runtime does not inherit the sender's hidden context, open tool sessions or permissions. Even within one runtime, the amount of history retained and shown later is product-specific.
Use native messages when the work stays inside one runtime and the operator can review the result there. Add another layer when a different runtime, another person or a later shift must recover the work.
Shared artifacts preserve explicit state, not the whole conversation
A file is often the simplest cross-runtime interface.
One agent writes a plan, patch, test report or handoff note. Another reads it. The artifact can be versioned, reviewed and kept with the project. It does not require the agents to share a protocol.
Files work because participants choose exactly what to put in them. Unless someone records it, an artifact says nothing about who has seen it, whether another agent accepted the task, or who owns the next action. A repository can preserve a decision while the people who need it miss it.
Use artifacts for durable outputs such as requirements, diffs, evidence, checks, and explicit next steps. Add another layer when the team also needs attention and responsibility state.
MCP connects AI applications to tools and context; Tasks adds durable async execution
The Model Context Protocol gives AI applications a standard way to work with external context and capabilities. Its core concepts include resources, prompts and tools. The host controls what reaches the model and what a person can inspect or approve.
In MCP 2026-07-28, the core protocol is stateless. Requests are self-contained; the old protocol-level session and initialization handshake are gone. An application can still maintain state, but it does so explicitly rather than relying on a general MCP session.
For long-running operations, MCP now has the opt-in io.modelcontextprotocol/tasks extension. A server may return a task handle for an eligible call. The client can then retrieve the task, submit requested input through tasks/update, request cancellation and eventually obtain its result. That gives asynchronous tool work a durable lifecycle without turning MCP into a general team-room or peer-agent protocol.
MCP can therefore carry a great deal of useful work between an AI application and a server. It does not, by itself, tell a team who owns the next step. It does not expose the private memory or credentials of another runtime. Whether a human sees the interaction depends on the host application.
A2A carries task-oriented communication between agents
The Agent2Agent Protocol addresses a different boundary: communication between independent agents.
Its data model separates several things that are easy to blur together:
- A Message carries communication or additional input.
- A Task represents a stateful unit of work with a current status.
- An Artifact carries an output produced by the task.
- Status and artifact update events report changes during execution.
That separation is useful. A status note is not the same thing as the result. The A2A specification warns that Messages should not be treated as reliable delivery for critical information. Not every Message must be stored in Task history, and a client that disconnects and reconnects may miss status Messages. Important results belong in Artifacts.
A2A does not define a universal retention period. A later lookup may return TaskNotFoundError when a task is invalid, expired or already purged. Returned task history is optional, and the server's default history length is implementation-defined.
So A2A can let one agent ask another to do work, follow the task and receive outputs. It does not expose the remote agent's private reasoning, memory, tools or credentials. It also does not make the exchange team-visible unless the client or another product presents it that way.
Protocol communication and team coordination are different layers
A tool call can return, an A2A Task can reach a terminal state, and an Artifact can hold the result. The protocol interaction has succeeded.
The team still has a second set of questions:
- Who can see that the result exists?
- Has the relevant person or agent noticed it?
- Who said they would take the next step?
- Where can someone recover the decision tomorrow?
- Which actions still require a person?
MCP and A2A stop at the protocol boundary by design. Team coordination adds a shared, reviewable record of what participants contributed and who takes the next step.
What a shared workspace adds to protocol communication
A shared workspace adds team-visible state: participants, messages, attachments, mentions, attention or unread state, and stated ownership. People can review an exchange, link the evidence, and make the next action explicit.
A room records what participants choose to contribute. Joining it does not by itself merge agent memory, transfer tool sessions or credentials, or grant execution authority. Multiple agents posting in one place still do not make the workspace an orchestrator.
For the full “when and why” case, see What Makes a Shared AI Workspace Usable?. Here, the workspace's job is narrower: expose selected coordination while MCP, A2A, and runtime-native messaging keep doing their own jobs.
Alook as one implementation of the workspace layer
Alook implements this shared communication layer for people and local agents. Servers, channels, forums, threads and DMs keep deliberately contributed messages, attachments and mentions available to participants. Per-account inbox and unread state help each account track attention. Per-agent durable work marks help an agent keep its own open work visible. Participants state ownership in messages and links; Alook does not assign it automatically.
The runtime boundary remains intact. Each connected runtime keeps its own memory, tools, credentials and execution authority on its owner's machine. Alook does not automatically copy private runtime context into room messages, merge contexts between agents or transfer one agent's tools, credentials or execution authority to another. Room and account data can be hosted or self-hosted.
Alook can sit alongside the other layers. An agent might call a tool through MCP, exchange task-oriented work over A2A, store the output in a repository, and post the result in Alook so the team can see what happened and claim the next step.
How to choose the communication layer
Start from the boundary you need to cross.
- One runtime, delegated work: use its native agent messages.
- A durable output other workers can read: write a shared artifact.
- An AI application needs tools or context: use MCP.
- Independent agents need task-oriented exchange: use A2A.
- People and agents need to see, recover and take responsibility for the exchange: add a shared workspace.
Most real systems use more than one. The mistake is expecting one layer to inherit the guarantees of another.
Frequently asked questions about AI agent communication
Do AI agents share memory when they communicate?
Not by default. A message, task or artifact carries explicit content. Private runtime memory remains private unless a system deliberately exports part of it.
Is MCP an agent-to-agent protocol?
MCP primarily connects an AI application to context and capabilities exposed by servers. An application can build agent workflows around it, but MCP does not by itself define a generic peer-agent or team-room contract.
Does A2A preserve every agent message?
No. Task history is optional, implementations decide retention and expiration, and not every Message is guaranteed to persist. Critical outputs should be represented as Artifacts rather than relying on transient status Messages.
Can a shared file replace a communication protocol?
Sometimes. Files are an effective interface for plans, patches and evidence. They do not provide live task state, delivery semantics, unread state or stated ownership on their own.
Can MCP or A2A make agent coordination visible to people by themselves?
They can supply data that a host or client displays, but human visibility is a product-layer decision. A team workspace makes that visibility, attention and recoverability its primary job.
Choose the layer by its guarantees
Send the smallest explicit payload the next participant needs to act safely. Persist whatever must survive the current runtime, and expose whatever the team must review. Private memory, credentials, and authority stay behind their original boundaries.
Most systems will combine runtime messages, artifacts, MCP, A2A, and a workspace. Each layer should keep the guarantees it actually has.