How Microsoft Foundry Agent Service Enables Future-Proof Agentic Systems

Today, nearly every AI vendor provides its own way of building and running agents. We have OpenAI Agents SDK, Claude Agent SDK, Google ADK, and more. The result is that the systems we build often become tightly coupled to vendor-specific models, SDKs, and APIs.

Over the last few years, or even months, we've seen the AI landscape evolve at an unprecedented pace. There is no indication that this trend will slow down anytime soon, so how can we build agentic systems flexible enough to survive the trial of time? How can we not come short on security while doing so? How can we embrace innovation without continuously rewriting our applications whenever the next generation of models arrives?

In this article, we’ll explore Microsoft Foundry Agent Service as a possible answer to most of these questions, and why it offers a compelling foundation for building secure, scalable, and future-proof agentic applications.

What is Microsoft Foundry Agent Service?

Microsoft Foundry Agent Service is a managed platform that enables us to build, deploy, and manage the complete lifecycle of AI agents and agentic systems. From initial prototyping to evaluation, deployment, and monitoring, it provides the capabilities needed to take agents from experimentation to production.

The service helps address many of the operational challenges our teams encounter when moving agents into real-world environments, including versioning, tool orchestration, identity management, security and governance, observability, and scalable execution.

Think of it as a managed runtime and control plane above supported models and agent frameworks. It does not eliminate platform coupling, but it can move much of that coupling away from application logic and into a consistent operational layer. This enables our teams to adapt to changes with significantly less architectural disruption as the AI ecosystem continues to evolve.

Why should I choose Microsoft Foundry Agent Service?

Through Microsoft Foundry Agent Service we can iterate in a fast yet coordinated pace from prototyping to production, all within a single platform. Instead of piecing together different services for development, deployment, testing, security, and monitoring, our teams can iterate quickly while maintaining a consistent operational model.

With a Foundry resource in place, we can deploy a model in minutes and create an agent definition in seconds. This is made possible through Prompt Agents, one of the primary agent types available in Foundry. Prompt Agents can be defined directly through the Foundry portal or programmatically using the available SDKs and REST APIs. They are ideal for rapid prototyping and scenarios where we want to focus on agent behavior rather than infrastructure management.

For more advanced scenarios, Foundry provides Hosted Agents. Unlike Prompt Agents, Hosted Agents are code-first and allow us to build agents using our preferred framework and application logic. The agent is then deployed to run on Foundry's managed runtime, enabling us to leverage the platform's capabilities while retaining full ownership of the code. Hosted Agents are particularly valuable when implementing complex workflows, custom orchestration logic, or integrations that go beyond prompt-based configurations.

Regardless of which approach we choose, once our agent is running on Foundry, it gains access to the broader platform capabilities that make operating agentic solutions at scale significantly easier. This includes tooling, integrated testing and evaluation, enterprise security and governance, built-in observability with support for enhanced instrumentation, and a consistent deployment experience across our entire AI ecosystem.

Let's explore the platform capabilities that make Foundry Agent Service a compelling runtime for enterprise-grade agentic systems.

Agent tools and toolboxes

Agents and agentic system capabilities go beyond standalone models mainly because of the tools we give them. Those allow them to interact with external systems, retrieve information, and even perform actions through tools.

This is another area where Microsoft Foundry Agent Service excels. Between built-in tools, partner-provided integrations, and custom tools developed by our teams, Foundry offers a rich ecosystem that can be used to extend our agents with minimal effort.

Many existing Azure services can be exposed directly to our agents as a tool. This allows us to leverage established enterprise capabilities such as managed identities, role-based access control, and existing security boundaries, ensuring that agents operate under the same governance standards as the rest of our applications.

Foundry also supports a wide range of integration approaches. We can connect custom MCP servers, consume external APIs through OpenAPI specifications, or expose local functions defined within our own application. The latter is particularly powerful, as it allows agents to access and orchestrate existing business capabilities without requiring significant architectural changes.

On top of individual tools, Foundry also introduces Toolboxes, which provide a centralized way to manage and reuse tool definitions across multiple agents. Instead of recreating the same integrations repeatedly, our teams can establish a shared catalog of approved tools, improving consistency, governance, and maintainability across agentic solutions.

Whether our infrastructure is built entirely on Azure or spans multiple cloud providers and services, Foundry's tooling ecosystem provides the flexibility required to connect agents to the systems that matter most.

Testing and evaluating agents in Microsoft Foundry

We can apply many of the testing practices we're already familiar with. Agent logic, tool implementations, orchestration code, and prompt generation can all be validated through traditional unit and integration tests.

However, the greatest value comes from validating the agent's behavior rather than its implementation.

This raises an interesting challenge: how do we test something that is inherently non-deterministic? Unlike traditional software, agentic systems can produce different responses to the same input while still achieving the intended outcome. Asserting against exact responses quickly becomes impractical.

This is where structured evaluations become invaluable. By running a curated dataset of prompts and expected outcomes against an agent, Foundry can generate scores across one or more evaluators, allowing our teams to measure aspects such as quality, relevance, groundedness, and safety. Rather than asking "Did the agent return this exact response?", evaluations help answer "Did the agent behave as expected?"

Evaluations also become critical when comparing agent versions or validating model upgrades. They provide quick feedback on possible regressions and, more importantly, help quantify improvements. This allows teams to make data-driven decisions when promoting new agent versions to production rather than relying solely on manual testing.

One limitation I've encountered is that evaluations currently focus on individual agents. For multi-agent workflows where the orchestration layer is entirely custom, I haven't yet found a native way to evaluate the complete workflow end-to-end. In these scenarios, additional custom evaluation infrastructure may be required. I'll explore the approach I adopted in a future article.

The key takeaway is simple: when building agentic applications, some of the most important tests are no longer validating code correctness, but validating agent behavior. To do that effectively, we need tools designed to handle the probabilistic nature of generative AI.

Observability from day zero

Anyone who has operated a production system understands the importance of monitoring. When issues arise, we want to understand what happened and respond as quickly as possible.

Microsoft Foundry provides built-in observability capabilities from day zero. Through its integration with Azure Monitor Application Insights, we can monitor operational metrics such as token consumption, latency, error rates, and overall agent performance.

Built on top of the OpenTelemetry standard, Foundry also supports distributed tracing across a variety of frameworks and SDKs, including LangGraph, LangChain, the OpenAI Agents SDK, and the Microsoft Agent Framework. At a high level, traces provide visibility into user interactions, agent responses, tool calls and their results, token consumption, and timing information such as execution duration and latency.

Combined with evaluations, these capabilities provide a comprehensive observability strategy for agentic systems. Our teams can not only understand how their agents behave in production, but also continuously measure quality, identify regressions, and validate improvements before they impact users.

How Microsoft Foundry enables enterprise security and governance standards

Security and governance are often among the biggest challenges when moving agents from experimentation into production. Microsoft Foundry Agent Service helps address these concerns by integrating with existing Azure security capabilities rather than introducing an isolated security model.

Through agent identities, agents can operate with their own security context, enabling role-based access control (RBAC), scoped permissions, policy enforcement, and auditing. This allows organizations to follow the principle of least privilege and grant agents access only to the resources they genuinely need.

For environments with stricter networking requirements, Foundry supports private networking capabilities, allowing organizations to control how agents communicate with internal and external systems and align agent workloads with existing network security standards. It's important to note that Hosted Agents have some limitations that you can read about here.

Foundry also provides built-in content safety capabilities, helping our teams detect and mitigate unsafe, harmful, or non-compliant interactions before they impact users or downstream systems. Every agent includes Microsoft's content filters by default.

Together, these capabilities make it easier to build agentic solutions that align with existing enterprise security and governance requirements, rather than treating AI agents as an exception to them.

Responding to change without rewriting our architecture

One of the biggest advantages of Foundry and its Agent Service is the combination of the extensive model catalog and the decoupling between agent definitions and model deployments.

An agent can reference compatible deployed models, and that association can be updated at any time. When a new model becomes available, we can deploy it alongside our existing workloads, create a new version of our agent that targets the new model, and validate the changes through our evaluation pipelines before promoting them to production.

This approach enables our teams to experiment with new models, compare performance, quality, and cost, and iterate safely without redesigning their agents or disrupting existing deployments. Whether we're adopting the latest reasoning model or evaluating a more cost-effective alternative, the process remains largely unchanged.

The key takeaway is simple: in Foundry, switching an agent underlying model becomes primarily an operational and evaluation decision rather than a full architectural redesign.

A native experience for .NET developers

For .NET developers, Microsoft Foundry Agent Service feels like a natural extension of the existing Azure development ecosystem. Through the Azure AI Projects client library for .NET, developers can manage agents, models, deployments, evaluations, and other Foundry resources directly from their applications using familiar Azure SDK patterns.

Authentication integrates seamlessly with Azure credentials, including managed identities, allowing applications to interact with Foundry resources without introducing additional authentication mechanisms. This means the same identity, configuration, and deployment practices already established across many .NET applications can be reused for agentic workloads.

Foundry also works well alongside frameworks commonly used in the .NET ecosystem, such as Semantic Kernel and Microsoft Agent Framework. Teams can continue using their preferred approach to define agent behavior while relying on Foundry as the operational platform responsible for hosting, security, observability, and lifecycle management.

For organizations already invested in .NET and Azure, this significantly reduces the learning curve. Instead of introducing an entirely separate technology stack, agentic workloads become another first-class citizen within the existing development platform.

Conclusion

One year from now (most likely, far less), the models we use today will be obsolete. The organizations that succeed will not be those that picked the perfect model, but those that built architectures capable of evolving alongside the ecosystem. Foundry Agent Service helps make that evolution an operational concern rather than an architectural rewrite.

References

Microsoft Foundry Agent Service
Test a hosted agent
Agent identity
Virtual Network for Foundry Agent Service
Observability in generative AI
.NET Foundry SDK