Microsoft Foundry A2A Tool Reaches GA for Agent-to-Agent Calls

Agent-to-agent communication becomes an operational system when discovery, authentication, retention and failure handling are standardized.

Microsoft Foundry A2A Tool now supports Agent2Agent protocol version 1.0 as a generally available integration. A Foundry agent can call a remote A2A-compatible agent, and a Foundry agent can expose an incoming endpoint for external callers. Microsoft keeps the earlier a2a_preview tool and protocol 0.3 available for existing preview integrations.

The GA and preview paths are different products

Tool type	Protocol	Status	Recommended use
a2a	1.0	Generally available	New integrations and production evaluation
a2a_preview	0.3	Preview	Existing preview integrations during migration

Production clients should explicitly negotiate or request protocol 1.0 rather than depend on a default. Foundry serves both versions through the same base path, so a silent version assumption can produce behavior that differs from the implementation a team tested.

Three architectures now sit behind one announcement

• Incoming endpoint: an external caller discovers and invokes a Foundry agent.
• Outgoing A2A tool: a Foundry agent calls another A2A-compatible agent.
• Hosted agent through a toolbox: an agent consumes an A2A connection exposed through a managed MCP endpoint.

These patterns are related but have different trust boundaries. An incoming endpoint needs authorization on the target agent. An outgoing tool needs a project connection and credentials for the remote endpoint. A toolbox centralizes versioning, policy and credentials across several agents, which can reduce duplication but increases the importance of its own access policy.

Foundry-hosted discovery is authenticated

Foundry-hosted A2A agent cards and protocol endpoints are not public discovery pages. They use Microsoft Entra ID. The calling identity needs the required role on the target project, and incoming A2A must be enabled on the target agent. For Foundry-to-Foundry calls, Microsoft documents the https://ai.azure.com audience.

Connection method	Use case	Control to verify
No authentication	Public test endpoint only	Confirm no privileged capability is exposed
Custom key	Legacy remote endpoint	Store the secret in a project connection
OAuth 2.0	Third-party delegated access	Review scopes, token audience and expiry
User Entra token	User-context calls	Prevent privilege escalation across users
Project managed identity	Service-to-service access	Assign the narrowest target role
Agentic identity	Foundry agent target	Verify the target project role and audience

The current A2A 1.0 limits shape the product

Microsoft documents text-only modality for incoming Foundry A2A 1.0 endpoints, with no streaming responses. A product that needs images, audio or token-by-token output must keep those requirements outside this path or confirm a later update. The remote agent processes the task and returns a result; the original Foundry agent remains responsible for the user conversation.

The target prompt agent must support the Responses protocol before it can be exposed as an incoming A2A endpoint. This requirement is easy to miss when migrating a classic agent that previously used Connected Agents.

A2A tasks and contexts remain for 60 days

For Foundry agent targets, Microsoft says A2A tasks and contexts are retained for 60 days from their most recent write. Each new write resets that clock. This creates a data-governance decision before the first call: what information is placed in a delegated task, which project stores it, and whether the retention period fits the application’s obligations.

• Exclude credentials and unnecessary personal data from delegated context.
• Map the target project’s region and access roles.
• Record which agent received each task and the task identifier returned.
• Define a deletion or minimization process where the product requires one.
• Prevent a retry loop from extending retention indefinitely through repeated writes.

A2A does not replace a workflow engine

A2A is useful when one agent delegates a bounded task to a specialized agent. Microsoft separately recommends workflows for declarative sequential, group-chat or human-in-the-loop orchestration. If the product must guarantee that legal review happens before publication, a workflow with an explicit approval step is safer than hoping two agents negotiate the policy correctly.

The managed OAuth consent guide provides a reusable identity checklist. The AI agent cost-control guide explains why every delegated model and tool call also needs a budget, trace and completion metric.

Migration checklist from preview or Connected Agents

1. Inventory every a2a_preview, agent.as_tool and Connected Agents dependency.
2. Create a protocol 1.0 A2A project connection with the narrowest authentication method.
3. Enable incoming A2A only on agents that must be called externally.
4. Assign the calling identity the minimum target-project role.
5. Test text-only behavior, non-streaming latency, timeouts and retries.
6. Review the 60-day task and context retention boundary.
7. Add recursion limits so agents cannot delegate to each other forever.
8. Keep human approval in a workflow for consequential actions.
9. Cut over one caller at a time and retain a rollback to the preview path during validation.

The practical verdict

The Microsoft Foundry A2A Tool makes standardized cross-agent delegation more credible for production evaluation. The GA label applies to protocol 1.0, not every multi-agent pattern around it. Text-only responses, no streaming, explicit identity requirements and 60-day context retention remain material product constraints. Teams that treat those limits as architecture inputs can gain interoperability without turning agent discovery into an uncontrolled trust network.

Primary sources

• Microsoft Foundry A2A launch post
• Microsoft Learn A2A implementation guide

Checked September 21, 2026. Protocol support, retention and SDK requirements can change; verify the current Microsoft Learn page before deployment.