A2A, or Agent-to-Agent protocol, explained

The problem A2A addresses

As AI agents become specialized, one organization may use different agents for support, engineering, procurement, analytics, research, and operations. Those agents may be built with different frameworks or hosted by different vendors. Without a common communication layer, coordination becomes custom glue code.

A2A-style protocols aim to make agents discoverable and interoperable. An agent can advertise what it can do, receive a task, communicate progress, and return an artifact to another agent or client system.

Core concepts

• Agent identity: how another system knows which agent it is talking to.
• Agent card or profile: a description of capabilities, endpoints, authentication, and supported interactions.
• Task: the unit of work one agent asks another agent to perform.
• Message: communication during the task, including instructions, status, questions, or clarifications.
• Artifact: the output of work, such as a document, report, structured result, code change, or file.
• State: whether work is submitted, running, waiting, completed, failed, or cancelled.

A2A vs MCP

MCP and A2A solve different layers of the agent ecosystem. MCP is usually about connecting an AI application to tools, resources, and integrations. A2A is about one agent communicating with another agent. In simple terms: MCP connects agents to tools; A2A connects agents to agents.

They can work together. An engineering agent might use MCP tools to inspect a repository. A project-management agent might ask that engineering agent for a risk summary through an A2A-style task. The result could be returned as an artifact and stored in a knowledge base.

Workflow example

Imagine a vendor evaluation workflow. A procurement agent asks a research agent to create a vendor brief. The research agent uses web and document context to produce the brief. A security agent reviews the brief for compliance risks. A finance agent reviews pricing assumptions. The procurement agent assembles the final decision memo.

A2A-style communication helps this work stay structured. Each agent can own a domain, communicate status, and return artifacts rather than dumping everything into one giant prompt.

Why specialization matters

Different agents may have different tools, policies, memories, and domain instructions. A security agent may know compliance requirements. A coding agent may understand repository workflows. A procurement agent may know vendor evaluation criteria. A research agent may know how to gather and cite sources.

A2A-style interoperability lets systems preserve that specialization. Instead of one general agent pretending to be expert in every domain, a coordinating agent can delegate to a specialized agent and receive a structured artifact in return.

Artifacts are important

Agent-to-agent work should not only exchange chat messages. The durable output is often an artifact: a report, decision memo, code patch, spreadsheet, risk register, image, or structured data object. Artifacts make agent work easier to review and easier to hand off.

A strong A2A workflow should preserve who produced the artifact, what task it answered, what sources or tools were used, and what state the task ended in. Without provenance, multi-agent work can become hard to trust.

Failure and negotiation

Real workflows include incomplete information. A remote agent may need clarification, reject a task, report partial results, or fail because credentials are missing. A good agent-to-agent protocol needs status and error handling, not only happy-path task completion.

Negotiation is also useful. An agent may say that it cannot complete the requested task but can produce a narrower artifact. That keeps workflows moving without hiding limitations.

Design concerns

Agent-to-agent communication introduces governance questions. Which agents are allowed to ask for work? Which tasks require user approval? How are artifacts verified? How is sensitive data scoped? What happens when agents disagree? Who is accountable for the final decision?

A useful implementation should preserve identity, authorization, audit logs, artifact provenance, and human control points. Interoperability is valuable only if teams can trust how work moved through the system.

How to think about A2A in Kendr

Kendr's current resource model focuses on deep research, skills, MCP-style tools, and governed workflows. A2A is conceptually adjacent: it describes how specialized agents might coordinate as those workflows become distributed across systems.

For teams learning the space, the important idea is separation of concerns. Use MCP-style integrations for tools and context. Use A2A-style communication when one agent needs to delegate to another agent with its own capabilities and lifecycle.

Continue with AI agent protocols compared or agentic AI systems explained.

Frequently asked A2A questions

Does A2A mean agents act without humans?

No. Agent-to-agent communication can still be human-supervised. A coordinator can delegate work while humans review artifacts, approve risky actions, or decide the final outcome.

When is A2A useful?

A2A becomes useful when different agents have different capabilities, policies, tools, or memories. If one general assistant can do the whole job clearly, agent-to-agent delegation may be unnecessary.

What should teams watch for?

Teams should watch for accountability gaps. If several agents contribute to an answer, the system should preserve task history, artifact provenance, status, and decision ownership.

How to apply A2A thinking

Do not start with multi-agent complexity unless the work truly needs it. Start by identifying separate domains of expertise. If one task needs a research specialist, a security reviewer, and an implementation agent, A2A-style coordination may make sense. If the task only needs one workflow with tools, MCP and agentic planning may be enough.

The practical design question is: what should be delegated, what artifact should come back, and who owns the final decision?