The shift from AI assistants that answer to agents that act has transformed the landscape for AI builders. Microsoft Foundry's latest release addresses critical challenges in scaling AI agents, offering enterprise-grade security, observability, and production-ready tools. Engineers, founders, and operators can now leverage these advancements to build robust, secure, and scalable AI systems.
General Availability of Foundry Agent Service
Microsoft Foundry Agent Service is now generally available, providing a modern API and SDKs across Python, JavaScript, Java, and .NET. Built on OpenAI's Responses API, the service ensures wire compatibility for teams already using this API, enabling seamless migration with minimal code changes. Developers can deploy agents via REST endpoints or integrate them directly into Microsoft 365 and Teams environments.
The service supports prompt-based agents, which are now production-ready, while hosted agents and workflow agents remain in public preview. Hosted agents simplify operationalizing agent logic without requiring teams to manage infrastructure. Regional expansion to East US, North Central US, Sweden Central, Southeast Asia, and Japan East ensures compliance with data residency requirements and reduces latency for global deployments.
Key Takeaways
- Foundry Agent Service supports production-ready SDKs across multiple programming languages.
- Wire compatibility with OpenAI's Responses API simplifies migration.
- Regional expansion enhances global deployment capabilities.
"Microsoft Foundry has delivered real value for our team. The updated interface makes our services and workflows faster, more capable, and easier to use." - Andreas Hunderi, VP of Global IT at Corvus Energy
Voice Live Integration: Public Preview
Voice Live API integration with Foundry Agent Service is now in public preview, enabling real-time speech-to-speech interactions for agents. This feature is ideal for customer service, field support, and other scenarios requiring natural voice communication. Voice Live handles audio input and output while inheriting Foundry's security and monitoring features.
Gulf Air's Falcon Eye platform exemplifies the potential of Voice Live integration. By combining live operational data with voice-driven navigation, executives can make faster, more confident decisions using conversational interfaces. This integration transforms complex data into actionable insights through natural dialogue.
Builder note
Voice Live integration is particularly useful for scenarios requiring hands-free operation or real-time decision-making. Ensure your agents are optimized for natural language processing to maximize the benefits of this feature.
Observability in Foundry Control Plane
Observability tools in the Foundry Control Plane are now generally available, offering continuous evaluation and monitoring across the AI lifecycle. Built-in evaluators assess coherence, relevance, groundedness, retrieval quality, and safety. Custom evaluators allow teams to define metrics aligned with business logic and regulatory standards.
Continuous evaluation features include monitoring and alerting based on sampled production traffic. These tools enable systematic oversight, ensuring agents meet quality and safety standards in dynamic production environments.
| Signal | Why it matters |
|---|---|
| Built-in evaluators | Provide standardized metrics for assessing agent performance. |
| Custom evaluators | Allow alignment with specific business and regulatory requirements. |
| Continuous monitoring | Ensures ongoing quality and safety in production environments. |
Source Card
Foundry Agent Service, Observability, and Foundry Portal Now Generally ...Microsoft Foundry addresses key challenges in scaling AI agents by providing tools for security, observability, and voice integration.
Microsoft Foundry Blog
- Adopt Foundry Agent Service for enterprise-grade security and scalability.
- Leverage Voice Live API for natural voice interactions in production scenarios.
- Utilize observability tools to ensure continuous quality and safety.
- Production-ready SDKs across Python, JavaScript, Java, and .NET.
- Voice Live API integration for real-time speech-to-speech interactions.
- Continuous evaluation and monitoring tools in Foundry Control Plane.
- https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/building-production-ready-secure-observable-ai-agents-with-real-time-voice-with-/4501074
Builder implications
For teams evaluating Building Secure, Observable AI Agents with Microsoft Foundry, the useful question is not whether the announcement sounds important. The useful question is whether it changes how an agent system is built, tested, operated, or bought. The source from techcommunity.microsoft.com gives builders a concrete signal to inspect: Foundry Agent Service, Observability, and Foundry Portal Now Generally .... That signal should be mapped against the parts of an agent stack that usually become fragile first, including tool contracts, long-running state, evaluation coverage, cost visibility, failure recovery, and the handoff between prototype code and production operations.
Production lens
Treat this as a systems decision, not a headline decision. A builder should ask how the change affects the agent loop, what needs to be measured, which failure modes become easier to catch, and whether the team can explain the behavior to a customer or operator when something goes wrong. If the answer is vague, the technology may still be useful, but it is not yet a production advantage.
Adoption checklist
- Identify the workflow where AI agents, Microsoft Foundry, Observability, Voice integration already creates measurable pain, such as slow triage, brittle handoffs, unclear ownership, or poor observability.
- Write down the current baseline before changing the stack: latency, cost per run, recovery rate, review time, and the percentage of tasks that need human correction.
- Prototype against a real internal workflow instead of a demo task. The workflow should include imperfect inputs, missing context, tool failures, and at least one approval step.
- Add traces, event logs, and evaluation checkpoints before expanding usage. A new framework or model is hard to judge when the team cannot see where the agent made its decision.
- Keep rollback boring. The first version should let an operator pause automation, inspect the last decision, and return control to a human without losing state.
- Review the source again after testing. The source-backed claim should line up with observed behavior in your own environment, not just with launch copy or release notes.
| Area | Question | Practical test |
|---|---|---|
| Reliability | Does the agent fail in a way operators can understand? | Run the same task with missing data, stale data, and a tool timeout. |
| Observability | Can the team reconstruct why a decision happened? | Inspect traces for inputs, tool calls, model outputs, approvals, and final state. |
| Cost | Does value scale faster than usage cost? | Compare cost per successful task against the old human or scripted workflow. |
| Governance | Can sensitive actions be reviewed or blocked? | Require approval on high-impact actions and log who approved the step. |
What to watch next
The next signal to watch is whether builders start publishing implementation notes, migration stories, benchmarks, or reliability reports around this source. That secondary evidence matters because agent infrastructure often looks clean at release time and only shows its real shape once teams connect it to messy business workflows. Strong follow-on evidence would include reproducible examples, clear limits, documented failure recovery, and customer stories that describe what changed in the operating model.
Key Takeaways
- Do not treat a release as automatically production-ready because it comes from a strong source.
- Use the source as a reason to test a specific workflow, not as a reason to rewrite the entire stack.
- The best early signal is not novelty. It is whether the system becomes easier to observe, recover, and improve.