Microsoft Foundry Agent Service Review

Microsoft Foundry Agent Service is a managed Azure platform for building and operating agents, not a flat-price AI employee. Its most consequential buying distinction is between Foundry-native prompt/workflow agents and hosted agents running your own containerized code: the runtime responsibilities and cost meters differ.[9][10][11]

What Microsoft Foundry Agent Service includes#

The official product page describes hosted agents, open protocols, managed memory, Toolbox, voice integration, Entra Agent ID, observability, private networking and publishing into Teams or Microsoft 365 Copilot.[9] Those are product capabilities, not a promise that every dependency or enterprise license is bundled into the runtime price.

For hosted agents, you package code as a container image, push it to Azure Container Registry and deploy it into Foundry. The platform supplies the endpoint, identity, scaling and session-state infrastructure; you own the code inside the sandbox.[11] That is a substantial reduction in infrastructure work, but not an outsourced application-development service.

• Best for: an Azure-oriented engineering team with identity, networking and governance requirements that justify the platform's integration surface.
• Also useful for: teams bringing existing framework code rather than rewriting everything as prompt-only definitions.[11]
• Avoid if: you expect a no-code employee that independently designs your business process and resolves access policy.
• Compare carefully if: portability means more than using an open protocol. Session APIs, identity integration and operational configuration still require migration work.

Our self-hosted versus hosted responsibility guide is a useful companion: “managed” should identify which layer a vendor operates, not imply that no engineering remains.

Pricing: verified East US rates and the missing-rate trap#

The static pricing-page retrieval showed $- placeholders. In a real browser, the default Central US / USD view rendered hosted compute as N/A. After explicitly selecting East US / USD, the same official page displayed $0.0994 per vCPU-hour and $0.0118 per GiB-hour.[10] We captured the selected region/currency and rendered page. Do not interpret a placeholder or N/A as a zero price, and do not generalize this regional example to every Azure offer.

The East US browser view also showed these built-in tool meters:[10]

• File Search Storage: $0.11 per GB of vector storage per day, with 1 GB free.
• Code Interpreter: $0.033 per session.
• Web Search: $14 per 1,000 transactions.
• Custom Search: $14 per 1,000 transactions.

Model tokens are separate. The page also identifies separate charges or licenses for connections such as Logic Apps, Fabric, SharePoint, Grounding with Bing Search, Foundry IQ and licensed data. Published prices are estimates; Microsoft directs buyers to the pricing calculator or a sales quote for their agreement and offer.[10]

An illustrative compute-only budget#

At the captured East US USD rates, a 1 vCPU / 2 GiB sandbox costs $0.123 per active session-hour: $0.0994 plus twice $0.0118. One hundred aggregate active session-hours would be $12.30 for hosted compute alone. This is arithmetic using public rates, not a measured bill. It excludes model tokens, tools, connected services, observability, storage outside that meter, support and tax.[10]

“Aggregate” matters. The documentation says each session gets its own sandbox, and CPU/memory settings describe one session rather than the whole agent. Oversizing is multiplied by concurrent sessions.[11] A model request's token cost and a sandbox's active-session cost answer different questions.

Use the agent cost calculator guide to build a budget with separate columns for runtime, inference, tools and human operations. If an estimate contains only the model tokens, it has not priced the hosted application.

Scale to zero is not zero cost between requests#

The current hosting documentation describes a session idle timeout configurable from 2 through 60 minutes, defaulting to 15 minutes. Each request resets the timer; compute is deprovisioned when the idle window expires. The platform persists the session filesystem and restores it when the session resumes.[11]

That is different from stopping the billing clock the instant an answer is returned. As a simple illustration, ten 1 vCPU / 2 GiB sessions each remaining active for a full 15-minute idle window represent $0.3075 of additional compute at the captured rates. It is not a forecast of total spend, and actual session timing must be measured.[10][11]

The supported sandbox combinations listed in the retrieved documentation are 0.5 vCPU / 1 GiB, 1 vCPU / 2 GiB, and 2 vCPU / 4 GiB. The documented total disk budget is up to 20 GiB at 1 vCPU or larger, scaling down for smaller CPU tiers. Approximately 20% is reserved for system use; the remainder is shared by the image and writable locations, not all available as user-upload storage.[11]

Right-size from a representative workload and inspect Application Insights rather than choosing the largest sandbox by reflex. Our background monitoring and webhooks guide discusses the broader event-driven versus continuously active design decision; it is not a Foundry configuration tutorial.

Persistence, recovery and deletion boundaries#

Hosted agents use separate concepts for sessions, conversations and a durable state store. The documentation says $HOME and /files persist across turns and idle periods. Conversation history persists independently of compute. State-store items also persist independently and have configurable aging behavior.[11]

Session persistence is not indefinite retention: the platform permanently deletes a session after 30 days of inactivity. The state store has a default 30-day idle window for items, renewed by writes, and can be configured not to expire them.[11] Buyers should map each kind of data to the correct lifetime instead of assuming every file, message and checkpoint follows one rule.

Background execution and resilient execution are also different. Background mode lets work continue after the initiating request returns; resilience addresses interruptions to the hosting process.[11] The integration guidance warns that local tool side effects can replay if a crash occurs before a continuation token is saved.[12]

Our engineering recommendation is to keep external operations idempotent where possible. A persisted filesystem does not by itself prevent sending the same message twice or reissuing a payment instruction. Before relying on recovery, test a crash immediately before and after a reversible external action and inspect the operation record. We did not perform that test here.

Identity, private networking and tool safety#

Current documentation distinguishes the per-agent Entra identity, used by the running agent for models and downstream services, from the project managed identity, used for infrastructure operations such as registry access. External-resource permissions must be assigned deliberately. Interactive user delegation and autonomous/background access are different modes.[11]

This distinction is especially important when reading older troubleshooting threads: advice about a preview deployment's project identity should not automatically override the current runtime-identity model. Use the current documentation for the exact deployment generation and inspect which principal actually made the denied request.

The retrieved hosting page states that projects created after June 25, 2026 support a private, network-secured Azure Container Registry, while older projects require the registry to remain reachable over its public endpoint.[11] A search snippet retrieved during research showed a different cutoff date; we give priority to the freshly fetched page, not the snippet. Verify the current limitations before a regulated deployment rather than using this review as a networking approval.

The same documentation tells buyers to review third-party tool/model data flows and implement their own responsible-AI safeguards. Data may leave organizational or geographic compliance boundaries through connected systems.[11] Our MCP security guide is relevant here: a managed identity and an authenticated MCP endpoint do not automatically authorize every action an agent might propose.

Frameworks, protocols and release maturity#

The hosted-agents concept page lists Python and C# support and framework-agnostic protocol libraries. Responses is oriented toward conversational agents with platform-managed conversation history, streaming and background lifecycle; Invocations allows custom payloads and more application-owned state/protocol handling.[11]

For teams choosing a tool interface, our MCP versus API guide separates discoverable tool access from the runtime that operates the agent. Using an open protocol can help reuse integrations without making every platform feature portable.

The current Agent Framework integration page explicitly says Microsoft Foundry Hosted Agents is generally available, while the Python agent-framework-foundry-hosting integration is prerelease.[12] Do not conflate the stability label of the managed service, a language package and an older announcement. Pin and test the actual dependency set you deploy.

Versions are immutable snapshots. The concept page says one endpoint serves one version at a time with 100% of traffic, and traffic splitting between versions is not supported.[11] If your rollout policy requires a canary, design and validate an appropriate routing strategy rather than assuming the hosted endpoint supplies percentage rollout controls.

Developer complaints: useful failure cases, not a failure rate#

In Foundry Samples issue #515, developers reported agents that worked locally or showed “Running” after deployment but timed out in the playground or terminal. The February–March 2026 discussion includes hypotheses involving RBAC, streaming and registry visibility, with disagreement about the root cause.[19] One commenter explicitly said they were not fully certain which change resolved their case. We treat that as a troubleshooting lead, not a verified universal fix.

In the VS Code extension's issue #318, a maintainer attributed readiness-probe failures to an SDK breaking change and proposed pinning azure-ai-agentserver-core==1.0.0b7; the original reporter replied that it worked on January 26, 2026.[20] That historical resolution is evidence for dependency/version compatibility risk, not a recommendation to install an old preview version today.

These reports are especially useful for designing acceptance tests: verify actual model/tool invocation after deployment, capture request IDs and logs, and test the identity used by the hosted runtime. They do not establish current outage prevalence, latency distribution or a general customer-satisfaction score. A targeted Reddit search returned no usable results in this run, so no Reddit consensus is claimed.

Company, legal terms, cancellation and exit#

Foundry Agent Service is an official Microsoft Azure offering. Microsoft's Azure legal hub separates purchasing agreements, Product Terms, data-protection obligations and service-specific legal information.[9][13] The account's commercial agreement matters; this review does not infer a Foundry-specific refund entitlement from Microsoft's corporate identity.

Azure's cancellation guidance says billing stops after subscription cancellation, services are disabled and outstanding usage can still appear on a final invoice. Its final-billing discussion warns that charges and invoices can lag cancellation. It also says canceling an Azure support plan does not produce a prorated refund for the remaining month.[14] That support-plan rule should not be mistaken for a universal refund statement covering every Azure product.

Do not cancel a shared Azure subscription merely to stop an agent. The same guidance says removing resources is an alternative for preventing unwanted charges.[14] For a real exit, inventory dependencies, stop the relevant workloads, preserve required data, remove unused billable resources and inspect subsequent usage. We did not execute this teardown.

Before procurement, confirm:

• Which Azure agreement and service terms apply to the intended model and tools.
• Your support plan, escalation path and service-level commitments.
• Data residency across models, tools, tracing and connected systems.
• Export of conversation data, state, files and application configuration.
• Which resources keep incurring costs when the hosted agent is idle or removed.

Paid advertising evidence and its limits#

A fresh Google Ads Transparency lookup for azure.microsoft.com returned no ads in the captured view. Broadening the lookup to microsoft.com showed an approximate “~40K ads” domain result with verified Microsoft Corporation and Microsoft Limited entries.[24] This supports the presence of Microsoft-domain advertising, not a count of Foundry campaigns. We did not identify an attributable Foundry Agent Service creative in that captured result.

The local historical ad cache did not establish a Foundry-specific campaign either. We make no claims about Foundry ad spend, targeting effectiveness, conversions or ROAS. A large parent-brand advertising footprint is not performance evidence for this runtime, and a zero-result subdomain query is not proof that no campaigns exist.

Alternatives: infrastructure, models or a finished agent?#

For code-first stateful applications using a different execution model, our Cloudflare Agents review examines durable identities, resource billing and recovery limitations. Compare the application architecture and operational requirements, not just a minimum monthly charge against an Azure hourly rate.

For a buyer deciding on a model and SDK rather than Azure hosting, the Claude for AI Agents review covers separate API, SDK and subscription boundaries. Foundry hosting and model-provider procurement are related decisions, not interchangeable products.

For a person who wants an inspectable agent with tools, memory, skills and scheduling under their own control, Hermes Agent is a different category of alternative.[21] The self-hosted installation route makes sense when local control is the objective and the operator accepts configuration, permissions and maintenance. FlyHermes is relevant only when operating a Hermes deployment is the bottleneck; it is not presented here as a replacement for Azure tenant governance, enterprise contracts or Foundry integration.

Proposed evaluation before production#

This is a test plan, not work we claim to have run:

1. Deploy a minimal agent in the intended region and validate a real response, not only a “Running” status.
2. Add one read-only tool; confirm per-agent identity and a deliberately denied request.
3. Measure active-session duration, CPU/memory use, tokens, tools and tracing costs separately.
4. Resume after idle deprovisioning and check files, history and state-store behavior independently.
5. Interrupt background work around an external side effect and verify duplicate prevention.
6. Roll back to a previous immutable version and confirm endpoint behavior.
7. Remove the test workload and reconcile remaining Azure resources and charges.

Foundry's strongest argument is the managed Azure runtime around code your team still owns. Approve it when that boundary fits your operating model—and when a regional, complete-cost evaluation supports the purchase—not because “no additional charge” was mistaken for an all-inclusive agent price.

Sources#

[9] https://azure.microsoft.com/en-us/products/ai-foundry/agent-service — Foundry Agent Service | Microsoft Azure [10] https://azure.microsoft.com/en-us/pricing/details/foundry-agent-service — Foundry Agent Service - Pricing | Microsoft Azure [11] https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agents — Hosted agents in Foundry Agent Service - Microsoft Foundry | Microsoft Learn [12] https://learn.microsoft.com/en-us/agent-framework/hosting/foundry-hosted-agent — Foundry Hosted Agents | Microsoft Learn [13] https://azure.microsoft.com/en-us/support/legal — Microsoft Azure Legal Information | Microsoft Azure [14] https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/cancel-azure-subscription — Cancel and delete your Azure subscription - Microsoft Cost Management | Microsoft Learn [19] https://github.com/microsoft-foundry/foundry-samples/issues/515 — Requests to hosted agents in Foundry are timeout · Issue #515 · microsoft-foundry/foundry-samples · GitHub [20] https://github.com/microsoft/microsoft-foundry-for-vscode/issues/318 — [ContainerProbesFailed] User Error Occured - Container readiness probes failed · Issue #318 · microsoft/microsoft-foundry-for-vscode · GitHub [21] https://hermes-agent.nousresearch.com/docs — Hermes Agent Documentation | Hermes Agent [24] https://adstransparency.google.com/?region=anywhere&domain=microsoft.com&hl=en — Google Ads Transparency: Microsoft domain lookup