AI agents are moving toward shared interoperability protocols

Model Context Protocol gives an AI host a common way to discover and use resources, prompts and tools. Agent2Agent describes how one agent can discover another agent, exchange messages and manage stateful work that may produce artifacts over time. Google’s original A2A announcement described the two protocols as complementary rather than competing.

The distinction is operational. A database query, file read or payment API is usually a tool call with a defined schema. A travel-planning agent or claims agent may accept a goal, ask questions, update progress and return several artifacts. Flattening both into the same abstraction makes authority and lifecycle harder to reason about.

A production architecture should therefore name each boundary. MCP can connect a host or agent to capabilities. A2A can delegate a task to another agent. Existing APIs, event systems and job queues still remain useful underneath both.

MCP registries and A2A Agent Cards reduce integration friction by describing endpoints, capabilities and authentication requirements. They can support allowlists and internal catalogs. They cannot, by themselves, establish that the publisher controls the claimed domain, that the code matches the description or that a tool will respect its annotations.

The risk resembles a software package ecosystem. Names can be confusing, servers can change after approval and metadata may be incomplete or dishonest. GitHub’s registry work explicitly combines discovery with enterprise allowlist controls because easier installation without governance expands the attack surface.

Admission should verify publisher identity, endpoint ownership, code or artifact provenance where available, protocol version, security history and operational owner. Production clients should connect only to approved versions and re-evaluate them when metadata or behavior changes.

MCP tools publish input schemas, and A2A Agent Cards describe skills and supported interfaces. That helps a client construct requests and detect obvious type errors. It does not ensure that “customer,” “approved,” “price” or “delete” means the same thing across systems.

Schema descriptions also enter the model’s prompt and can influence tool selection. A vague or malicious description can steer the model toward an unsuitable capability. Optional fields, defaults, units and side effects need deterministic checks outside the model.

An internal capability catalog should add business semantics: owner, data classification, effect class, idempotency, rate limits, expected latency, authoritative source, required approvals and postconditions. Generated tool descriptions can assist discovery, but release authority belongs to reviewed contracts.

A remote call may involve a human user, an AI host, a workload identity, an MCP server, a delegated agent and one or more downstream services. One successful OAuth flow does not answer which party initiated the action or which permissions should survive the chain.

MCP authorization uses OAuth-based resource-server patterns and explicitly forbids token passthrough. Tokens should be audience-bound to the intended server, while downstream APIs receive separate credentials. A2A deployments similarly need to decide whether calls use a shared service identity or preserve each end user’s identity.

Delegation should carry the smallest useful authority and an auditable subject chain. Short-lived credentials, resource indicators, on-behalf-of exchange, workload identity and target-specific scopes reduce the chance that one compromised endpoint can reuse a credential elsewhere.

A2A tasks and evolving MCP task support acknowledge that agent work may run for minutes, hours or days. The remote system may stream status, request more input, produce partial artifacts or wait for a person. That lifecycle is useful, but it creates durable state that must be governed.

Every task needs an owner, correlation ID, deadline, budget, cancellation path and final-state definition. The caller must know whether retrying creates a new task or resumes the old one. A task that loses its authenticated user, exceeds its authority or survives after consent is withdrawn should stop.

State should not be hidden inside a chat transcript. Store protocol state, business state and model reasoning separately. A person taking over should see what has completed, which external systems changed and what remains uncertain.

MCP tool annotations can describe read-only, destructive, idempotent or open-world behavior, but the specification treats them as hints. A server may be wrong or dishonest, and the risk often depends on what other capabilities are present in the same session.

An email reader is not necessarily dangerous. Combine it with untrusted web content and an outbound messaging tool, and the agent may have private data, malicious instructions and an exfiltration path at once. Delegating to another agent can hide the same combination behind one apparently simple task request.

The host or gateway must evaluate the complete path. Deterministic policy should track which data entered the session, which content is untrusted, where output can leave and which actions are irreversible. Hints can improve user experience; enforcement belongs to identity, network, sandbox, policy and confirmation controls.

MCP has already changed transports, authorization discovery, task semantics and extension structure across releases. The July 2026 release candidate introduces a stateless core and breaking changes. A2A has also advanced through multiple protocol versions while cloud platforms expose different support levels.

Negotiation prevents obvious mismatches, but semantic compatibility requires more. A client may understand a field while applying different approval, streaming or task behavior. Gateways that aggregate many servers can make one upgrade affect hundreds of tools at once.

Maintain a compatibility matrix covering client, gateway, server, protocol and extension versions. Run recorded contract tests before upgrades, preserve a deprecation window and support rollback. Avoid automatically following an endpoint’s “latest” version in production.

Cloud and developer platforms are adding MCP and A2A gateways, registries, allowlists and credential services because production teams need one place to enforce identity, policy, schema admission, routing, observability and revocation. A direct connection from every agent to every server recreates the integration problem at the security layer.

The gateway should not become an invisible superuser. It needs tenant isolation, target-specific credentials, rate limits, protocol-aware logs, output scanning, confirmation hooks and a clear failure mode. Aggregated tool catalogs also require naming and collision controls.

The business case should compare adapter code removed with governance and operating work added. Shared protocols create the most value when several clients reuse several well-governed capabilities. A single stable integration may remain simpler as an ordinary API.