The agentic ecosystem is being equipped with open protocols to prevent each framework and provider from inventing its own connectors. MCP, A2A, and AGNTCY are often mentioned together, but they do not solve the same problem. MCP mainly connects an AI application to tools and data. A2A organizes exchanges between agentic applications. AGNTCY develops infrastructure components for discovery, identity, messaging, and observability of agent ecosystems.
Combining them can be relevant on a large scale. Stacking them on a simple internal assistant creates unnecessary complexity and security surface.
A2A v1.0 is presented by its project as a stable version ready for production; MCP published the specification on 2026-07-28. The maturity and AGNTCY interfaces must be verified for each component.
Why interoperability is becoming a topic
A company can use multiple models, frameworks, and products. A sales agent may need to request an analysis from a documentation agent, then use a CRM tool. Without a common contract, each interaction is a specific integration.
Interoperability aims at:
- discovery of abilities;
- job description;
- exchange of messages and artifacts;
- management of long-term work;
- identity;
- security;
- observability;
- portability between providers.
It does not replace the domain model, authorization rules, or data governance.
MCP: connect an AI application to capabilities
MCP standardizes the way a client discovers and uses tools, resources, and extensions exposed by a server. It is suitable when an agentic application needs to consult a repository, call a business API, or launch a governed capability.
The server can remain a façade over an existing service. The tools must be narrow, authorized, and observable. MCP does not turn a service into a standalone agent; it makes its capabilities consumable in a standardized way.
The 2026-07-28 specification adopts a stateless core and an extensions framework, which facilitates certain deployments at scale.
A2A: collaborating between agents
A2A aims at the exchange between agent-based applications that can be built with different frameworks and keep their internal functioning opaque. An agent publishes a capability map, receives a task, exchanges messages, and returns artifacts or a state.
The protocol is relevant when an agent delegates a task to another actor who has their own autonomy, lifecycle, and possibly their own organization. It handles long tasks and interactions better than the call of a simple tool.
A2A v1.0 marks a stabilization of the contract. Adoption does not exempt from verifying identity, holder, authorization, confidentiality, and outcome.
AGNTCY: open infrastructure for an Internet of agents
The AGNTCY project, hosted by the Linux Foundation, develops components around discovery, identity, messaging, and observability. Its Open Agentic Schema Framework offers a taxonomy to describe capabilities, domains, and relationships.
This level becomes interesting when many agents need to be found, qualified, and operated across teams or organizations. It is not a requirement to use MCP or A2A. The components and their maturity must be assessed individually.
Which protocol for which problem?
| Need | Probable minimum option |
|---|---|
| Call a stable business function | Classic API |
| Expose tools to multiple AI clients | MCP |
| Delegate a task to an agentic application | A2A |
| Discover and govern many agents | dedicated registry/infrastructure |
| Orchestrate some internal components | internal framework or workflow |
| Exchange with a partner | API or A2A depending on autonomy and duration |
Comparison of the roles of MCP, A2A, and an agentic infrastructure for discovery and observability.
Classic API or agentic protocol
An API remains preferable when the operation is deterministic, the contract is stable, and the actors are known. It is easier to test, secure, and operate.
An agentic protocol provides value when capabilities are discovered, tasks evolve, interactions are lengthy, or multiple providers need to collaborate. The criterion is not the use of an LLM, but the nature of the contract.
A combined architecture
A possible scenario:
- a coordinating agent receives a goal;
- he discovers a specialized agent through a registry;
- He delegates a task to him with A2A;
- The specialized agent uses MCP to access internal tools;
- the infrastructure collects identity, traces, and states;
- A policy validates the result before action.
Each layer must have a responsibility. The same need must not be encapsulated in multiple protocols without reason.
Discovery and trust
Discovering an agent card or a server does not mean trusting it. The registry keeps track of owner, version, origin, any certifications, capabilities, policies, and approval status.
Identity must work across borders. An organization may require a contract, an authorized list, and mutual authentication before any exchange.
The announced capabilities are verified. An agent does not receive more data just because it claims to have a skill.
Authorization and delegation
When an agent delegates, they must not transmit a general token. The delegation specifies:
- principal;
- beneficiary;
- task;
- resources;
- duration;
- budget;
- shares;
- possibility of sub-delegation.
The final service rechecks the rights. The delegation chain is visible in the audit.
Tasks, messages, and artifacts
A long task has a state, updates, a cancellation, and a result. Messages should not be confused with allowed commands. Artifacts — document, report, code, or data — have a type, an origin, and rights.
The orchestrator must be able to handle an unavailable agent, a partial result, or a timeout. It does not assume that a conversational response equates to business success.
Semantics of abilities
Two agents can both declare 'search' while producing incompatible results. Schemas, taxonomies, and business contracts remain necessary. OASF can help describe capabilities, but the company must define its own quality and data requirements.
Versions and extensions are negotiated. A change in capacity triggers a new qualification.
Distributed observability
A task traverses multiple agents, protocols, and tools. The correlation identifier, timestamps, and states must follow the path without exposing sensitive prompts.
The metrics include:
- total delay and by actor;
- delegations;
- errors;
- takeovers;
- costs;
- approvals;
- rejected results;
- applied policies.
A multi-agent system without end-to-end tracing is difficult to diagnose and bill.
Security
The main risks are:
- malicious agent or server;
- misleading capacity card;
- excessive delegation;
- injection into messages;
- exfiltration by a tool;
- dangerous artifact;
- delegation loop;
- uncontrolled consumption;
- tenant confusion.
Controls include allowed lists, budgets, maximum depth, schema validation, sandbox, approvals, network limits, and cut-off mechanism.
Avoid loops and cost explosions
An agent can delegate to another who in turn delegates. The orchestrator sets depth, number of tasks, duration, tokens, tools, and budget. Sub-delegations are explicitly allowed.
A task must be able to be canceled and resources released. Retries are idempotent and limited.
Version governance
MCP, A2A, and AGNTCY components are evolving. The organization maintains a compatibility matrix, test environments, and an update policy. Deprecations are handled as API changes.
SDKs simplify implementation but should not hide the actually supported version.
Start with minimal architecture
A first internal agent can use existing APIs and some MCP tools. A2A becomes relevant when another autonomous agent, possibly external, needs to collaborate. A distributed discovery infrastructure comes into play when the number of actors and boundaries require it.
This progression avoids building an 'Internet of agents' to automate a single workflow.
Standards in the service of governance
Open protocols improve portability and reduce specific integrations. They do not replace choices of trust, quality, and accountability.
Partitech can design a minimal architecture, develop MCP servers, integrate A2A, and evaluate agent-based infrastructure components. The goal is useful, testable, and secure interoperability, not a stack of standards.
Let's talk about your project
Define an interoperable and governed agentic architecture with Partitech. Contact Partitech.