Foundry Agent Service Goes GA: How Microsoft Is Quietly Building the Enterprise OS for AI Agents

If you have been waiting for the moment when building production AI agents feels less like wiring together a science fair project and more like shipping normal enterprise software, that moment arrived this week. Microsoft announced that the next-generation Foundry Agent Service is now generally available, and it is one of the most important platform releases for AI agents so far this year.

I have been watching the Foundry roadmap closely, and this GA release is not just a marketing label. It combines the runtime, the security model, the voice channel, and the evaluation loop into one coherent platform. For teams building agents in the Microsoft ecosystem, it changes the conversation from "can we actually deploy this?" to "how fast can we iterate?"

Here is what shipped, why it matters, and what you should do next.

A Single Runtime Built on the OpenAI Responses API

The new Foundry Agent Service is built on the OpenAI Responses API, which means if you are already building agents with the Responses API wire protocol, moving into Foundry requires minimal code changes. You keep your agent logic. You gain Foundry's enterprise controls.

That is a deliberate choice by Microsoft. Rather than inventing yet another agent protocol and forcing everyone to migrate, Foundry meets developers where they already are. The same responses.create() pattern you use with OpenAI works inside a Foundry project, with an agent_reference pointing to a Foundry-managed agent definition.

For Python developers, the shift is straightforward. Agents are now first-class operations on AIProjectClient in the azure-ai-projects package. You create an agent version, start a conversation, and call the Responses API against it. If you are coming from the older standalone azure-ai-agents package, the migration is mostly about removing that pin and using the consolidated project client.

Why this matters: the hardest part of production agents is rarely the prompt. It is identity, networking, tool auth, tracing, and evaluation. Foundry handles those as platform concerns so your code can focus on the business problem.

End-to-End Private Networking

Enterprise agents live or die on networking. If your agent needs to call a SharePoint site, a SQL database, an SAP system, or an internal MCP server, those calls have to stay inside your network boundary. The public internet is a non-starter for a lot of regulated and sensitive workloads.

Foundry Agent Service now supports Standard Setup with private networking, including bring-your-own virtual network. The agent traffic never traverses the public internet. Container and subnet injection let the runtime talk locally to Azure resources. And crucially, private networking now extends to tool connectivity: MCP servers, Azure AI Search indexes, and Fabric data agents can all operate over private paths.

That is the difference between a demo and a production deployment. Retrieval-augmented generation is not just about the model answer. It is about where the documents traveled on their way to the model. Foundry keeps that path inside your boundary.

MCP Authentication That Matches Real Enterprise Patterns

Model Context Protocol, or MCP, has become the dominant pattern for giving agents tools. But MCP is only as secure as the authentication layer underneath it. Foundry now supports the full spectrum of enterprise auth patterns for MCP server connections:

• Key-based auth for simple shared internal tools.
• Entra Agent Identity for service-to-service calls where the agent authenticates as itself.
• Foundry Project Managed Identity for per-project permission isolation without credential management overhead.
• OAuth Identity Passthrough for user-delegated scenarios where the agent acts on behalf of the signed-in user.

OAuth Identity Passthrough is the standout. When an agent needs to access a user's OneDrive, their Salesforce org, or any SaaS API that scopes by user, passthrough lets the agent carry that user's identity through the OAuth flow. That is a much safer model than giving the agent a blanket service account and hoping for the best.

For key-based connections, you configure a Custom Keys connection in your Foundry project and reference it by project_connection_id. The secret stays in Foundry's managed connection store, not in your source code.

Voice Live: Agents You Can Actually Talk To

Voice is the most natural interface for many agent scenarios — field service, customer support, accessibility, hands-free manufacturing — but historically it has required stitching together three separate services for speech-to-text, language modeling, and text-to-speech. That meant three latency hops, three billing surfaces, and three failure modes.

Voice Live, now in preview, collapses that into a single managed speech-to-speech runtime. It handles semantic voice activity detection, semantic end-of-turn detection, server-side noise suppression, echo cancellation, and barge-in support so users can interrupt mid-response.

Best of all, Voice Live wires directly into an existing Foundry agent. The prompt, tools, and safety configuration stay where they are. Voice Live owns the audio pipeline. Because it shares the same agent runtime as text, you get the same traces, evaluators, and cost visibility. Voice does not become a second-class observability story.

Evaluations Are Now a Continuous Loop, Not a Pre-Ship Checkbox

This is the part I am most excited about. Running a test suite before launch is necessary but not sufficient. Real quality degrades over time as documents age, user behavior shifts, and new edge cases appear. Foundry Evaluations are now GA with three layers:

• Out-of-the-box evaluators for coherence, relevance, groundedness, retrieval quality, and safety.
• Custom evaluators so you can encode business logic, tone standards, or domain-specific compliance rules.
• Continuous evaluation that samples live traffic, runs your evaluator suite against it, and surfaces results through integrated dashboards.

All of it publishes into Azure Monitor Application Insights, so your agent quality telemetry sits next to your infrastructure health, cost, and traditional application telemetry. You can set alerts on groundedness drops or safety threshold breaches before users notice.

This is what continuous improvement for agents should look like: observe, understand, evaluate, optimize, validate, repeat. Foundry gives you the loop.

Toolboxes, A2A, and Routines: The Agent Mesh Gets Real

A few related capabilities are worth grouping together because they solve the same problem — connecting agents without rebuilding plumbing every time.

Toolboxes give agents on-demand access to tools with opt-in discovery and tool-level guardrails. Tool search inside Toolboxes, now generally available, lets agents find the right tool without loading the full catalog into every call. In one internal evaluation using a public benchmark of more than 44,000 tools and 7,000 queries, tool search reduced input-token consumption by over 60 percent for a 50-tool toolbox and over 97 percent for a 1,000-tool toolbox. That translates directly into lower latency and lower cost.

Agent-to-Agent, or A2A, is now generally available. Agents can call other Foundry agents through an open, standardized protocol. Teams can compose agents without point-to-point integrations, while centralized credentials and policy enforcement keep the mesh governable.

And Routines in Foundry Agent Service are GA, letting you run agents on a schedule, at a specific time, or in response to an external event. No custom schedulers, queues, or identity plumbing required. Combine Routines with the reminder tool, and a hosted agent can even schedule itself to continue a long-running task later.

What This Means for the Microsoft Ecosystem

Taken together, these releases make the case that Microsoft is building the enterprise operating system for AI agents. Not a chatbot. Not a single assistant. A platform where agents can be developed, deployed, governed, monitored, and improved like any other production service.

For organizations already invested in Azure, Microsoft 365, and Entra, the integration advantages are obvious. Your existing identity, networking, compliance, and observability foundations apply directly to agents. You do not have to build a parallel shadow infrastructure just because the workload happens to use a large language model.

For developers, the practical effect is that the distance between a prototype and production shrinks dramatically. The same code that works on your laptop can run inside a private network, authenticate through Entra, talk to an MCP server, serve a voice channel, and feed continuous evaluation — all within Foundry.

Three Things to Do This Week

If you are responsible for AI strategy, architecture, or development in a Microsoft environment, here are three concrete next steps:

1. Spin up a Foundry project with Standard Setup and private networking. Walk through the Responses API quickstart and deploy a prompt agent that calls an internal MCP server over your VNet. The sooner you validate networking and identity, the sooner you can move real workloads.

2. Define your agent governance checklist. Before approving agents in production, document which identity model each agent uses, which MCP servers it may call, which other agents it may invoke over A2A, and which actions require human approval. The technology is ready; your governance model needs to keep pace.

3. Set up continuous evaluation for one agent. Pick a production or pilot agent, connect the out-of-the-box evaluators, add one custom evaluator that reflects your business rules, and configure an Azure Monitor alert. Production quality is a living thing. Start measuring it.

The Bottom Line

The GA of the next-generation Foundry Agent Service is a signal, not just a release. Microsoft is betting that agents will become a standard layer of enterprise software, and it is building the platform that assumption requires.

For the rest of us, the work is simpler: learn the runtime, secure the networking, govern the identity, and start measuring quality. The tools are here. The roadmap is clear. The only question is how fast your team wants to move.

If you are already experimenting with Foundry Agent Service, I would love to hear what you are building. Drop a note in the comments or reach out — I am always curious about the real-world agent deployments happening inside the Microsoft ecosystem.