Foundry Agents Go Bidirectional on A2A — LangGraph Can Now Call Foundry Natively
Azure AI Foundry has extended its Agent-to-Agent protocol support to full bidirectionality — meaning LangGraph agents can now invoke Foundry-deployed agents as native tools, and Foundry agents can call back into LangGraph-orchestrated workflows. This is a technically significant milestone that shifts multi-framework agent architectures from point-to-point integration hacks to a standardised, discoverable protocol. For enterprise architects designing production agentic systems, bidirectional A2A changes what is architecturally feasible in a multi-team, multi-framework organisation.
How A2A Works — Agent Cards and Capability Discovery
The Agent-to-Agent protocol is built around the concept of an agent card — a structured JSON document that describes an agent's identity, capabilities, input schema, output schema, and invocation endpoint. Agent cards are analogous to OpenAPI specifications but scoped to agentic capability declarations rather than REST endpoint documentation. When a LangGraph agent needs to invoke a Foundry agent, it first resolves the target agent's card from a registry, validates that the declared capabilities match the required operation, and then invokes the agent via the standardised A2A invocation interface.
The trust model in A2A uses Azure Managed Identity for Foundry-side agents and configurable credential providers for external callers like LangGraph. This means enterprise architects can enforce the same identity and access management policies on agent-to-agent calls that they apply to service-to-service API calls. All A2A invocations generate audit events in Azure Monitor, giving security teams visibility into the inter-agent call graph at runtime.
Bidirectionality vs One-Way Integration
Prior to this announcement, the common pattern for mixing LangGraph and Azure AI Foundry was one-directional: LangGraph as the outer orchestrator calling Foundry agents as tools via HTTP. Bidirectionality resolves this asymmetry. A Foundry agent handling a document processing task can now invoke a LangGraph subgraph specialised in entity extraction, receive the result, and continue its own workflow — without any LangGraph-specific orchestration code living in the Foundry agent itself.
This matters for organisational reasons as much as technical ones. In large enterprises, different teams own different agent frameworks. A data engineering team standardised on LangGraph for its tight Python integration can compose with an application team's Foundry-deployed agents without either team needing to migrate frameworks or maintain translation layers.
Enterprise Use Cases for Mixed-Framework Agent Systems
The most compelling enterprise use cases involve capability specialisation across organisational boundaries. A customer service Foundry agent that handles intent classification can invoke a LangGraph agent owned by the data team for real-time personalisation logic — without the data team needing to expose their logic as a traditional API. A second use case is gradual migration: an organisation moving from LangGraph to Azure AI Foundry can run hybrid architectures during the transition period, with new Foundry agents calling legacy LangGraph agents via A2A while the migration proceeds at a controlled pace.
Key Takeaways
- Bidirectional A2A means LangGraph and Foundry agents can call each other natively via standardised agent cards — no custom integration code required
- Agent cards provide discoverable capability declarations analogous to OpenAPI specs for agentic systems
- Azure Managed Identity and Azure Monitor integration give enterprise-grade trust and auditability to inter-agent calls
- Bidirectionality enables genuine multi-team, multi-framework agent composition without forcing framework standardisation
- Evaluate A2A as the integration fabric for any enterprise agentic architecture involving more than one agent framework
