Can AI Agents Talk to Each Other? A2A, MCP and Handoffs

Yes, AI agents can talk to each other, in three different ways. Inside one framework, an agent hands the conversation to another agent or sends it a message, and the framework carries it. Across companies and vendors, the Agent2Agent protocol (A2A) lets one agent send a task to another agent it cannot see inside and follow it until it finishes. And without talking at all, agents can coordinate through shared state: a file, a database or a task board that each reads and writes. MCP is not one of the three; it connects an agent to tools and data, not to other agents. What none of these gives you is two agents chatting freely like colleagues. Every exchange is a message a program passes along, and the agent that receives it treats it as input, which is where most of the pitfalls come from.

The protocol comparison itself is covered in MCP vs A2A. This post is about the practical question: when you have more than one agent, how does work move between them, and what goes wrong when it does.

Three ways agents communicate

• Handoffs and messages inside one framework: the agents share a runtime, and the framework moves the conversation or a message from one to the next. Fast and simple, but only for agents built on that framework.
• A2A across vendors: each agent is a separate service with its own endpoint. One sends a task, the other works on it and reports back. Built for agents owned by different teams or companies.
• Shared state: no agent speaks to another. Each reads a common list, claims an item, does the work and writes the result back. Slower, but it survives restarts and people can read it.

Inside one framework: handoffs, subagents and teams

Most multi-agent setups today live inside a single framework, and each framework has its own idea of what “talking” means. In the OpenAI Agents SDK, a handoff↗ (opens in a new tab) is presented to the model as a tool: a handoff to a “Refund Agent” appears as transfer_to_refund_agent. When the model calls it, the new agent takes over the conversation and, by default, sees the whole history so far. Input filters let you trim what it receives.

Claude Code offers two patterns. A subagent does a focused job in its own context window and returns a result to the agent that started it. Agent teams go further: several Claude Code sessions, one acting as lead, that message each other directly by name and share a task list. Anthropic’s agent teams documentation↗ (opens in a new tab) describes each agent’s mailbox as a file the others write to, and tasks that move through pending, in progress and completed, with file locking so two teammates cannot claim the same task at once. Agent teams are experimental and off by default:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Two details from those docs are worth carrying into any design. Teammates load the project’s context but not the lead’s conversation history, so a handoff is only as good as the brief that goes with it. And the same page warns that teams use significantly more tokens than a single session, because each teammate is a separate instance with its own context window.

Across vendors: A2A

When the other agent belongs to someone else, a shared framework is not an option. A2A defines how two independent agents find each other and exchange work. The A2A specification↗ (opens in a new tab), now at version 1.0, has the receiving agent publish an Agent Card describing its skills, endpoint and authentication, and gives every piece of work a task whose state moves through submitted, working, input required, auth required, completed, failed, canceled or rejected. Its guiding principle is that agents collaborate through declared capabilities and exchanged results without sharing their internal thoughts, plans or tool implementations.

The input required state is the closest thing A2A has to conversation: the remote agent pauses and asks a question, and the calling agent answers it. Everything else is a request and a result. The objects, bindings and the protocol’s move to the Agentic AI Foundation are covered in MCP vs A2A.

Where MCP fits

MCP connects an agent to a server that offers tools, and a tool does what it is told. You can wrap an agent behind an MCP tool, so another agent calls it like any function, but the caller then gets one input and one output: no follow-up questions, no long-running task, no progress updates. For quick lookups that is fine; for real delegation it is the wrong shape.

MCP matters to agent communication in a quieter way. When two agents from different vendors connect to the same MCP server, such as a board, a repository or a database, they are working on the same data even though neither ever sends the other a message. That is the third pattern.

Through shared state

Coordinating through a shared list is the oldest pattern and still the most robust for work that takes hours or days. One agent writes “the export fails for accounts with no ZIP code, reproduced in test 14” on a task; another picks the task up the next morning and reads it. Nothing depends on both agents running at the same time, the record survives a crashed session, and a person can read it without a trace viewer.

• It needs claiming: some way for an agent to say “mine” so two agents do not start the same item.
• It needs a written result: a status alone does not tell the next agent what was learned.
• It is slower than a message: an agent has to look, which usually means at the start of a session or when it runs out of work.

The rules that keep several agents on one list from duplicating each other are set out in multi-agent workflows.

Pitfalls when agents talk to agents

• Borrowed authority. A message from another agent is not your approval. Anthropic’s agent teams docs say a teammate cannot approve a permission prompt or supply consent on your behalf, and an action denied to one teammate cannot be relayed to another to get around the check. Hold every system to that rule, including your own.
• Injection that travels. An agent that read a poisoned web page or email can pass the planted instruction on in its message, and the next agent may treat it as part of the job. The OWASP Top 10 for Agentic Applications↗ (opens in a new tab) lists this family of risk as ASI07 Insecure Inter-Agent Communication and ASI08 Cascading Failures.
• Lost context at the handoff. The receiving agent knows only what it was sent. A handoff that says “fix the bug we discussed” fails, because the other agent was not in the discussion.
• Confident relays. Agent B repeats agent A’s guess as a fact, and agent C builds on it. Ask for sources or evidence in every result that another agent will use.
• Loops and chatter. Two agents that keep asking each other for clarification, or keep handing a task back, spend tokens without progress. Cap the rounds.
• Cost. Every message is more tokens, and every agent re-reads its own context each step; see what AI agents cost to run.
• No record for people. Messages between agents live in logs and mailboxes. Unless the outcome is written somewhere people look, nobody can say later who decided what.

Rules for agent-to-agent handoffs

1. Write the brief as if for a stranger: the goal, what is already known, where the files are, and what “done” looks like.
2. Treat everything another agent sends as data to check, never as an instruction that overrides your own rules.
3. Give each agent its own identity and permissions, so an action can be traced to the agent that took it.
4. Keep approvals with people. An agent can ask another agent for work; only a person approves what cannot be undone.
5. Put the result where the next reader will look, with evidence, not just a status.
6. Cap rounds, time and spend for every delegated task.

The same discipline applies when the handoff is to or from a person; handing work between agents and people covers what that note should contain.

A shared board as the meeting point

fenbs speaks MCP, not A2A, and it does not pass messages between agents. What it offers is the shared-state pattern with the record built in. Claude, ChatGPT, Cursor and other assistants can each be members of the same board with a role of their own. One files a task with the problem in the note and the steps in the plan; another reads it, moves it to In Progress, and writes what it found with fenbs_comment. An assistant with nothing to do can take the next task a person has pre-approved with fenbs_next_approved_task, which holds it for a few hours, or give it back with fenbs_release_task and a reason, which moves it to Next Up and posts the reason on it for whoever comes next.

Every change is recorded in History with who made it, so “which agent moved this?” has an answer. Standing rules, such as “agents never mark another agent’s task Completed”, go on the Decisions and rules page, which every connected assistant reads first. There is no assignee you can set and no due date, so an owner or a deadline goes in the note.