The current Microsoft Foundry Agent Service story has moved well beyond "host a prompt and call a model." The updated documentation now positions it as a managed runtime for building, deploying, securing, tracing, and publishing agents across enterprise Azure environments.
For cloud teams, that is the real headline. Once a platform handles identity, lifecycle, tool plumbing, observability, versioning, and stable deployment endpoints, it stops being a demo surface and starts becoming production infrastructure.
What stands out in the 2026 update
The April 29, 2026 update to the Foundry Agent Service docs describes three distinct agent types:
- Prompt agents for fast configuration-driven builds.
- Workflow agents for declarative multi-step orchestration.
- Hosted agents for framework-based, containerized custom logic.
That split is useful because it maps cleanly to how real teams work. Not every agent needs custom runtime code, and not every business workflow should be hidden inside a monolithic prompt.
The other signal is the tool story. Foundry now emphasizes built-in tools such as web search, file search, memory, code interpreter, MCP-compatible tool access, and custom functions, all with managed authentication and enterprise controls.
Why cloud teams should care
The biggest bottleneck in production agent systems is usually not model quality. It is everything around the model:
- How the agent authenticates to internal systems.
- How tool access is scoped.
- How traces are inspected when a workflow goes wrong.
- How versions are promoted between test and production.
- How network isolation, RBAC, and compliance are preserved.
Foundry Agent Service is explicitly addressing those concerns with Microsoft Entra identity, Azure RBAC, observability, Application Insights integration, private networking, managed publishing, and distribution into Microsoft 365 surfaces.
That makes it more interesting than a raw SDK alone. It offers a path for organizations that want agentic behavior without building their own control plane first.
The architecture decision that matters most
The most important decision is choosing the right agent type for the job.
Prompt agents
Use these when the problem is narrow and tool access is simple. Internal copilots, FAQ agents, and lightweight operational assistants fit well here.
Workflow agents
Use these when the business process matters more than improvisation. Approval flows, escalation routing, agent handoffs, and repeatable multi-step operations belong in this category.
Hosted agents
Use these when your team needs full orchestration control, custom runtime logic, or a framework such as LangGraph. Foundry handles the runtime and scaling, but your team owns more of the application behavior.
Practical implications for Azure delivery teams
If your stack already lives in Azure, the value proposition is straightforward:
- Build the agent with portal configuration or code.
- Connect tools with managed credentials.
- Test in the playground.
- Trace model calls and tool behavior.
- Publish a stable endpoint.
- Distribute it into existing Microsoft surfaces or custom apps.
That is a materially better story than assembling identity, tracing, and publish flows from scratch around a model endpoint.
Where this still needs scrutiny
The docs also make it clear that some capabilities remain in preview, especially around workflow and hosted agent paths, and some tools vary by region and support tier. Teams should still validate:
- Regional support.
- Preview dependencies.
- Tool availability by model.
- Network constraints.
- Cost tradeoffs for managed orchestration.
This is promising infrastructure, but it still deserves the same production diligence as any other new cloud platform surface.
Bottom line
The meaningful shift is that Microsoft is defining agents as a first-class cloud deployment target. If your team wants enterprise identity, publishing, monitoring, and tool governance wrapped around agent behavior, Foundry Agent Service is getting closer to being the platform layer rather than just the playground.