Agent-to-agent communication becomes difficult when every team invents its own invocation contract. One agent exposes a REST endpoint, another expects a function call, a third returns a proprietary task object, and none of them describe capabilities in the same way. The Agent2Agent protocol is meant to reduce that friction by giving agents a standard way to publish an agent card, accept tasks, exchange context, and return results. In Microsoft Foundry, A2A is now a first-class enterprise integration surface rather than only an experimental pattern.<\/p>\n
The current Microsoft implementation supports A2A 1.0 as generally available while retaining 0.3 as a preview path for older integrations. That detail matters because version negotiation, discovery, authentication, and task semantics all become part of the contract. A production design should not simply point at an endpoint and assume \u201cA2A\u201d is one unchanging protocol.<\/p>\n
Within the broader Microsoft AI agents<\/a> architecture, A2A is best understood as an agent boundary. It is useful when the remote component should remain an independently deployed agent with its own capabilities, identity, lifecycle, and reasoning. If the remote component is really just a deterministic operation, a normal tool or API is usually simpler.<\/p>\n An A2A integration begins with discovery. The agent card describes what an agent can do and provides the metadata a caller needs to decide whether the endpoint is appropriate. In Foundry, enabling incoming A2A publishes versioned agent-card URLs for the agent. New integrations should deliberately discover and target A2A 1.0 instead of relying on the preview default behavior that can appear when a client does not select a version.<\/p>\n This sounds like a small implementation detail, but it changes how teams manage distributed agent estates. A caller no longer needs hard-coded knowledge of every capability. The card can become part of service discovery, compatibility checks, and deployment validation. The important discipline is to keep the card aligned with the agent\u2019s real permissions and behavior. A card that advertises a broad capability while the underlying tool permissions have narrowed creates operational ambiguity.<\/p>\n The same principle appears in Microsoft Foundry agent architecture<\/a>: a production contract should describe the boundary that actually exists. Discovery metadata should not become a marketing description detached from runtime behavior.<\/p>\n Foundry serves A2A 1.0 and 0.3 on the same base protocol path. A caller can select the version by fetching the version-specific agent card, sending an A2A-Version header, or supplying the version in the query string. If two selectors disagree, Foundry rejects the request. That is desirable behavior because silent protocol ambiguity is much harder to debug than an explicit error.<\/p>\n Enterprise clients should therefore make version selection part of their deployment contract. A calling service can verify the versioned card during startup or health checks, record the negotiated protocol version in telemetry, and fail fast if the target agent no longer supports the expected contract. This is the same operational discipline teams already apply to API versions and schema versions.<\/p>\n Backward compatibility should also be intentional. Keeping a 0.3 path alive indefinitely may be convenient, but it can freeze callers onto preview behavior. A migration plan should identify callers, move them to 1.0, and then reduce reliance on preview semantics rather than treating dual-version support as permanent architecture.<\/p>\n Foundry A2A endpoints can use Microsoft Entra ID and other supported authentication patterns for remote A2A connections. The calling agent needs permission to invoke the target, and incoming Foundry A2A endpoints require authorization rather than exposing agent cards anonymously. This is important because an agent card itself can reveal useful information about capabilities, skills, and integration boundaries.<\/p>\n Identity should be scoped to the relationship. A central orchestrator that can invoke every agent with one highly privileged identity creates a wide blast radius. A stronger design gives each caller only the access required for the agents it should reach, then lets the target agent enforce its own tool and data permissions internally. Microsoft Entra identity architecture<\/a> is directly relevant because agent-to-agent trust still depends on ordinary identity boundaries.<\/p>\n Authentication does not answer every authorization question. The target agent still has to decide whether the caller may request a particular business action, whether user identity needs to be propagated, and which downstream resources can be touched. Those decisions should not be delegated to a natural-language instruction that says \u201conly do safe things.\u201d<\/p>\n A2A is not just a stateless request wrapper. Foundry retains A2A tasks and contexts for a defined period, and writes can extend that retention window. That creates state that operators need to understand when they design privacy controls, deletion processes, incident response, and replay behavior. A caller that assumes every A2A interaction disappears after the HTTP response can create a governance gap.<\/p>\n Task identifiers should be treated as durable correlation keys. They can connect the caller\u2019s trace with the remote agent\u2019s execution, retries, tool calls, and final result. When an interaction spans several agents, those identifiers make it possible to reconstruct where time was spent and which component produced a wrong intermediate result.<\/p>\n Conversation continuity is separate from business authority. Agent conversation state<\/a> can preserve context across turns, but a remote A2A task should not become the authoritative record of a transaction. If the remote agent approves, books, changes, or submits something, the system of record should store that fact independently.<\/p>\n It is tempting to treat every new protocol as a competitor. In practice, A2A and MCP often occupy different layers. MCP exposes tools and context resources to an agent runtime. A2A exposes an agent that can reason, manage a task, and return an agent-level result. One agent may call an A2A peer that itself uses MCP tools internally.<\/p>\n The choice should follow the abstraction required by the caller. If the caller needs a narrow operation such as \u201clook up this record,\u201d a deterministic API or tool keeps behavior easier to reason about. If the caller needs another autonomous component to plan, use its own tools, and manage a multi-step task, the agent abstraction becomes more appropriate. The agentic orchestration<\/a> layer should make that distinction clear instead of turning every service into an agent.<\/p>\n Over-agentizing an architecture increases latency, cost, and uncertainty. Each additional reasoning boundary introduces another place where a model can misunderstand the task, choose an unexpected tool, or produce an answer that needs validation. A2A is valuable because it standardizes a real agent boundary, not because every microservice should be converted into one.<\/p>\n A caller should not retry every failed A2A request blindly. Network timeouts, 429 responses, and temporary service failures can be retryable, but a retry can be dangerous if the remote agent has already performed a side effect. The caller needs enough task identity and result retrieval logic to distinguish \u201cthe request never reached the target\u201d from \u201cthe target completed work but the response was lost.\u201d<\/p>\nAgent cards make capability discovery explicit<\/h3>\n
Version negotiation should be deterministic<\/h3>\n
Authentication belongs to the agent relationship, not the prompt<\/h3>\n
Task and context retention create operational state<\/h3>\n
A2A and MCP solve different interoperability problems<\/h3>\n
Retries need to preserve task semantics<\/h3>\n