AppMatic Tech builds MCP servers that connect AI agents to business systems and designs agent architectures that combine MCP with the A2A protocol, using Node.js, Python, FastAPI, and Laravel. AppMatic Tech's production MCP work saved construction teams 32% of project management time. AppMatic Tech is based in Ahmedabad, India, with 330+ products shipped.
AI agents now need two kinds of connection. The first is downward, to the systems an agent works with: databases, CRMs, ERPs, and file stores. The Model Context Protocol (MCP) standardised that connection. The second is sideways, to other agents: a supplier's procurement agent, a client's reporting agent, or a platform vendor's support agent. The Agent2Agent protocol (A2A) standardises that one. Both protocols now sit under the Linux Foundation, and both appear in the same architecture diagrams, which is why teams confuse them. This guide explains what each protocol does, how they differ, and when a business needs one, the other, or both.
Key takeaways
MCP is agent-to-tool; A2A is agent-to-agent.
| Point | Detail |
|---|---|
| MCP connects agents to systems | Tools, resources, and prompts exposed by an MCP server |
| A2A connects agents to agents | Stateful tasks delegated to a remote agent the caller does not control |
| Both are Linux Foundation projects | A2A since June 2025; MCP under the Agentic AI Foundation since December 2025 |
| A2A is stable | Version 1.0 with SDKs in five languages and more than 150 supporting organisations |
| Discovery differs | MCP lists tools on connection; A2A publishes an Agent Card at a well-known URL |
| Most teams start with MCP | A2A matters once work crosses team or company boundaries |
What is the A2A protocol?
A2A (Agent2Agent) is an open protocol for communication between AI agents that may run on different frameworks, in different companies, behind different security boundaries. Google launched A2A in April 2025 with more than 50 partners and transferred the protocol, specification, and SDKs to the Linux Foundation in June 2025.
By April 2026, the Linux Foundation reported:
| Milestone | Status in April 2026 |
|---|---|
| Specification | Version 1.0, the first stable release, adding multi-protocol support, enterprise multi-tenancy, updated security flows, and signed Agent Cards |
| Supporting organisations | More than 150, including AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow |
| SDKs | Python, JavaScript, Java, Go, and .NET |
| Cloud platforms | Azure AI Foundry, Copilot Studio, and Amazon Bedrock AgentCore Runtime |
| Related protocols | The Agent Payments Protocol (AP2), for agent-driven transactions, with more than 60 supporting organisations |
The design goal is that an agent built with one framework, such as LangGraph, can delegate a sub-task to an agent built with another, such as CrewAI, without either side sharing internal memory, prompts, or tools.
What is MCP, and where does MCP fit?
MCP (Model Context Protocol) defines how an AI application connects to tools and data. An MCP server exposes tools the model can call, resources it can read, and prompts it can use, over JSON-RPC 2.0. In December 2025 the Linux Foundation launched the Agentic AI Foundation with three founding projects: Anthropic's MCP, Block's goose, and OpenAI's AGENTS.md.
MCP is how an agent reaches a construction project database, a CRM, or an ERP with governed, auditable access. The fundamentals are covered in what is an MCP server, and the internals in MCP server architecture explained.
How do A2A and MCP differ?
| Dimension | MCP | A2A |
|---|---|---|
| Direction | Agent to tool or data source | Agent to agent |
| Other side | A server the team usually owns, wrapping a system | An agent another team or company owns, treated as a black box |
| Unit of work | A tool call that returns a result | A task with an ID, a lifecycle, and artifacts |
| Duration | Usually seconds | Seconds to days, with interruptions for input or authorisation |
| Discovery | The client lists the server's tools on connection | The client reads the agent's Agent Card |
| State | Mostly stateless calls | Stateful tasks grouped by a context ID |
| Updates | Request and response | Polling, streaming over Server-Sent Events, or push notifications to a webhook |
| Typical owner | Internal platform team | Partnership, integration, or platform team |
The simplest test: if the other side is a system, use MCP. If the other side is an agent that reasons on its own and may take minutes or days, use A2A.
How does an A2A interaction work?
An A2A exchange follows six steps:
- Discover. The client agent fetches the remote agent's Agent Card, which the specification recommends publishing at
/.well-known/agent-card.jsonon the agent's domain. - Authenticate. The Agent Card declares the required scheme, such as OAuth tokens or API keys, and credentials travel in HTTP headers, separate from A2A messages.
- Send a message. The client sends a message with one or more parts: text, structured JSON data, inline binary data, or a URL to a file.
- Receive a task or a reply. The remote agent answers immediately with a message, or creates a task for longer work.
- Track progress. The client polls, holds a streaming connection, or registers a webhook for push notifications.
- Collect artifacts. The task produces artifacts, the concrete deliverables, and ends in a terminal state.
The core concepts:
- Agent Card
- A JSON document describing the agent's identity, endpoint, skills, capabilities, and authentication requirements. Sensitive details can sit in an authenticated extended Agent Card.
- Task
- A stateful unit of work with a unique ID. Tasks can pause in
input-requiredorauth-required, and end ascompleted,canceled,rejected, orfailed. - Message and parts
- One conversational turn, with a role of user or agent, containing text, data, raw bytes, or URL parts.
- Artifact
- A deliverable produced by a task, such as a report or a structured result, which can be streamed incrementally.
- Context ID
- A server-generated identifier that groups related tasks into one conversation.
When should a business use MCP, A2A, or both?
| Scenario | Protocol | Reason |
|---|---|---|
| Let an internal assistant query the company database | MCP | The other side is a system the team controls |
| Let ChatGPT or Claude read project data | MCP | AI clients connect to tools through MCP servers |
| Let a client's procurement agent request quotes from a supplier's agent | A2A | Two independent agents, two companies |
| Let a developer's portfolio agent request progress reports from each contractor's reporting agent | Both | Each contractor's agent uses MCP internally and A2A externally |
| Orchestrate several in-house specialist agents | Often neither at first | A single framework's native orchestration is simpler until boundaries appear |
A common mistake is adopting A2A for agents that all live in one codebase. A2A adds discovery, authentication, and task tracking that pay off across organisational boundaries, and add overhead inside one.
What does a combined MCP and A2A architecture look like?
A practical example comes from construction. A real estate developer runs a portfolio agent that needs weekly progress from every contractor. Each contractor runs a reporting agent connected to its own project data.
- Inside each contractor: the reporting agent reads daily reports, photos, and schedules through an MCP server with read-only, project-scoped tools.
- Between companies: the developer's portfolio agent discovers each contractor's Agent Card and sends a task: "Summarise progress on Block C this week."
- Long-running work: the contractor's agent may pause the task in
input-requiredif the site manager must approve the summary. - Delivery: the finished summary returns as an artifact, with photo links, to the developer's agent.
The contractor never gives the developer database access, and the developer never sees the contractor's prompts or tools. AppMatic Tech's construction platform already exposes project data through an MCP server, as described in can ChatGPT or Claude read your construction project data, which is the inside half of this pattern.
What security controls do agent protocols need?
Agent protocols widen the attack surface: an agent now accepts instructions from another agent it cannot inspect.
- Verify identity. Use signed Agent Cards, introduced with A2A 1.0, and pin trusted agents rather than accepting any card found at runtime.
- Separate public and sensitive capabilities. Publish only what discovery needs, and keep details in an authenticated extended Agent Card.
- Treat remote output as untrusted input. Text from a remote agent can carry prompt injection, so it never flows into tool calls without validation.
- Scope MCP tools tightly. The agent that accepts external tasks should reach only the tools those tasks need, read-only where possible.
- Log every hop. Record task IDs, context IDs, the calling agent, and every MCP tool call, so any action can be traced across companies.
- Rate-limit per caller. External agents get quotas, like any API client.
Pro tip: Put a human approval step on any A2A task that commits money, data, or reputation, using the
input-requiredstate. A2A was designed for interrupted tasks, so approval does not need a custom protocol extension.
The MCP side of these controls is covered in MCP server security best practices.
Is A2A ready for production in 2026?
The adoption signals are strong: a stable specification, five official SDKs, support in the main enterprise agent platforms, and production use reported in supply chain, financial services, insurance, and IT operations. The Linux Foundation's roadmap still lists an interoperability specification, registry consolidation, expanded testing tooling, and security best practices, and academic reviews point out that agent protocols do not yet express governance rules, such as who may delegate what to whom.
AppMatic Tech's recommendation in 2026 is to build MCP servers for the systems an agent needs now, design agents with clean task boundaries, and adopt A2A where a real external partner is ready to integrate, rather than exposing agents publicly in anticipation.
How AppMatic Tech builds agent integrations
AppMatic Tech has shipped 330+ products since 2017, holds a 5.0 Clutch rating, and keeps an 83% client retention rate. AppMatic Tech's Construction MCP Server gives AI assistants governed access to project data, saved teams 32% of project management time, and supports companies running 500+ concurrent projects.
Related guides: how to build an MCP server, MCP server vs custom API, and AI agent development architecture patterns. The service is described on the MCP server development page, and agent work under AI agent development. Scoping starts at contact@appmatictech.com or the contact page.
Sources
| Claim used in this article | Source |
|---|---|
| A2A 1.0, 150+ organisations, SDK languages, cloud platforms, AP2, roadmap, relationship to MCP | Linux Foundation, A2A surpasses 150 organizations |
| A2A launch by Google and transfer to the Linux Foundation in June 2025 | Wikipedia, Agent2Agent |
| Agentic AI Foundation launch with MCP, goose, and AGENTS.md | Linux Foundation, Agentic AI Foundation |
| Agent Card, Task, Message, Part, Artifact, context ID, update mechanisms, authentication | A2A, Key concepts |
| Task states | A2A, Life of a task |
| Agent Card well-known path and extended Agent Cards | A2A, Agent discovery |
| Governance gaps in agent protocols | arXiv, Governance gaps in agent interoperability protocols |
| Construction MCP Server results | AppMatic Tech, Construction MCP case study |
Frequently Asked Questions
- What is the difference between A2A and MCP?
- MCP (Model Context Protocol) connects an AI agent to tools and data sources, such as a database, a CRM, or a file store, through tool calls. A2A (Agent2Agent) connects one AI agent to another AI agent, often owned by a different team or company, through stateful tasks. The Linux Foundation describes the two protocols as complementary.
- What is the A2A protocol?
- A2A (Agent2Agent) is an open protocol, launched by Google in April 2025 and transferred to the Linux Foundation in June 2025, that lets AI agents built on different frameworks discover each other, delegate tasks, and exchange results. Agents publish an Agent Card describing skills and authentication, and work is tracked as tasks with defined states.
- Does a business need both A2A and MCP?
- Most businesses need MCP first, because MCP is how an AI agent reaches internal systems and data. A2A becomes necessary when an agent must hand work to an agent outside the team's control, such as a supplier's, a client's, or a platform vendor's agent. Architectures that do both use MCP inside each agent and A2A between agents.
- Is A2A ready for production use in 2026?
- A2A reached a stable 1.0 specification, has SDKs in Python, JavaScript, Java, Go, and .NET, and is supported in Azure AI Foundry, Copilot Studio, and Amazon Bedrock AgentCore Runtime. The Linux Foundation reported more than 150 supporting organisations in April 2026. Governance, registries, and testing tooling are still maturing, so production use needs careful security design.
- Where is an A2A Agent Card published?
- The A2A specification recommends publishing the Agent Card at the well-known path /.well-known/agent-card.json on the agent's domain. Agents can also be discovered through curated registries or direct configuration, and sensitive capability details can sit in an authenticated extended Agent Card available only to verified clients.