Microsoft Foundry Explained: Enterprise Architecture for Production-Grade AI Agents

Published 16 August 2026. Every product claim below was verified against Microsoft's own documentation on 17 August 2026, and each capability is marked GA, Preview or Retiring. Where Microsoft's own pages contradict each other — and there are twelve such places in this article — I say so rather than picking the convenient answer. This platform changes monthly; check the linked source before you commit to anything.

Most writing about Microsoft Foundry describes a place to call models. That was accurate in 2024. It is now roughly as accurate as describing Kubernetes as a way to run a container.

What Foundry has become is an opinionated enterprise platform for the whole lifecycle of an agent: choosing and routing models, defining agents declaratively or shipping them as code, grounding them in enterprise knowledge, giving them tools through governed protocols, granting them their own identities, confining them to a private network, evaluating their behavior, tracing what they did, and handing the resulting fleet to an organization-wide control plane.

That is a much larger surface than "an API endpoint", and it comes with a much larger set of decisions. This article is about those decisions.

One sentence frames everything that follows, and it is the thing I keep coming back to in architecture reviews:

The intelligence comes from the model. Production readiness comes from everything surrounding the model.

Where Foundry sits in Microsoft's AI portfolio

Foundry is one layer of a larger stack, and a great deal of confusion dissolves once that is clear. I mapped the whole portfolio in The Microsoft AI Stack Explained; the short version is that Microsoft 365 Copilot is an experience, Copilot Studio and Foundry are creation platforms at different abstraction levels, and Agent 365 is the control plane over everything either of them produces.

The practical selection rule: if a business team owns the process and the data is reachable through connectors, it belongs in Copilot Studio. If engineers own it, it needs custom code or specific models, it touches non-Microsoft data planes, or it will ship as a product, it belongs in Foundry. Most substantial enterprises run both, and the question worth answering in writing is which workloads go where.

The resource model, and why it matters more than it sounds

Foundry uses a two-tier hierarchy. A Foundry resource (ARM type Microsoft.CognitiveServices/accounts, kind AIServices) is, in Microsoft's words, the "top-level Azure resource where you manage governance settings such as networking, security, and model deployments." Beneath it, a project is the "development boundary inside the Foundry resource where teams build and evaluate use cases."

A project is a subresource, not a standalone resource. That single fact drives several later constraints: networking is configured at the account level and shared by every project underneath it, and changing it means creating new projects rather than reconfiguring existing ones.

This replaced the older hub-and-project model, which now lives in the foundry-classic documentation set. Microsoft's guidance is unambiguous about direction of travel — "new features primarily land on Foundry resource type" — while noting that some cases, such as open-source model deployments and prompt flow, still require a hub.

No retirement date has been published for the hub model or for the classic portal. The pressure is capability starvation, not an end-of-life notice. But specific things inside classic do have dates, and one of them is imminent:

The seven planes of a production Foundry architecture

A production agent is not a model plus a prompt. It is a system with at least seven distinct concerns, each with its own owner, failure mode and change cadence.

Foundry Agent Service: exactly two kinds of agent

Foundry Agent Service supports two agent types, and both are GA. Getting the distinction right is the first real architecture decision.

Prompt agents (GA)

A prompt agent is "defined entirely through configuration — instructions, model selection, and tools," and Foundry runs it for you. You create versions with create_version() and a PromptAgentDefinition.

One detail worth knowing before you design around it: knowledge is not a declared field on a prompt agent. There is no knowledge property. Grounding arrives through tools — file search, Azure AI Search, or the Foundry IQ MCP tool. If your mental model is "attach a knowledge base to the agent", the plumbing is one level of indirection away from that.

Prompt agents earn their place when the orchestration is genuinely simple: retrieve, reason, call a tool or two, answer. That is a large share of real enterprise use cases, and the operational savings are real — no container build, no image lifecycle, no registry, no dependency patching.

Hosted agents (GA)

A hosted agent is "your own code packaged as a container image" — or, in the newer path, a source archive with no registry involved at all (python_3_14, dotnet_10 runtimes). Foundry deploys and operates it while you keep the orchestration logic.

Framework support is where Microsoft's own documentation stops agreeing with itself. The Agent Service overview names Microsoft Agent Framework, LangGraph, the OpenAI Agents SDK, the Anthropic Agent SDK and the GitHub Copilot SDK. The concept page names Agent Framework, LangGraph and Semantic Kernel. Only Agent Framework, LangGraph and Semantic Kernel have dedicated how-to documentation. Python and .NET only; Go is listed as coming soon.

My reading, offered as judgement rather than fact: treat the documented three as supported, and treat the others as "probably works, no support path." If your architecture depends on one of the undocumented frameworks, prove it in a spike before it becomes a commitment.

A second caveat matters for anyone with a change-advisory board: the service is GA but several key SDK surfaces are prerelease — agent-framework-foundry-hosting, Microsoft.Agents.AI.Foundry.Hosting, and the source-deploy APIs in Azure.AI.Projects. "GA service, prerelease SDK" is a real state and it deserves an explicit risk acceptance rather than a shrug.

The runtime model people get wrong

Scaling in Foundry Agent Service is per session, not per replica. Each session gets a VM-isolated sandbox with a 15-minute idle timeout and a 30-day maximum lifetime. Sandbox sizes are 0.5, 1 or 2 vCPU with up to 20 GiB of session storage — and that sizing applies to a single session, not to a pool.

The number that belongs in your capacity plan: 50 concurrent sessions per subscription per region. For a customer-facing workload, that is a design constraint, not a footnote — it pushes you toward multi-region, multi-subscription topologies far earlier than most teams expect.

Terminology also moved: threads became conversations, runs became responses. Agents are identified by name plus version — there is no agent GUID. The Responses API is the single entry point, OpenAI-wire-compatible at {project_endpoint}/openai/v1/responses.

Microsoft Agent Framework: not just another SDK

It is tempting to file Agent Framework alongside LangGraph as one option among several. That undersells its position. Built by the teams behind Semantic Kernel and AutoGen, it shipped version 1.0 in April 2026 and is now the layer Microsoft points at from multiple directions: it is the migration target for retiring workflows, the documented path for using Claude with tools on Foundry, and the framework with first-class hosting integration.

The clean separation, which holds up in architecture reviews:

Semantic Kernel v1.x continues to receive critical fixes but is no longer where new capability lands. New work should start on Agent Framework.

Foundry IQ: the knowledge layer, and its default is over-sharing

Foundry IQ is the managed knowledge layer: knowledge sources are grouped into a knowledge base, which performs agentic retrieval — query planning across sources — and returns grounded answers with citations. Agents reach it through the knowledge_base_retrieve MCP tool, which Microsoft notes is "the only tool currently supported for use with Foundry Agent Service."

Two things about Foundry IQ deserve more prominence than they usually get.

First, its general availability is an API-version property, not a product property. Microsoft states plainly that "the Microsoft Foundry portal and Azure portal continue to provide preview-only access to all agentic retrieval features." GA lives behind REST API version 2026-04-01. If your team is clicking through the portal, they are using preview functionality regardless of what the GA announcement said.

Second — and this is the finding I would put on the first slide of any Foundry readiness review:

Source availability, since this changes what you can actually build:

If your grounding story depends on SharePoint — and for most enterprises it does — you are depending on a preview capability with an opt-in permission model. Plan accordingly.

Toolbox: reuse with a fleet-wide blast radius

Toolbox is GA, and it solves a real problem: defining the same tool independently inside forty agents is how you end up with forty slightly different authentication configurations. Toolbox centralizes the definition, with immutable versions and a default_version pointer, and exposes two MCP endpoints — a developer endpoint pinned to a version, and a consumer endpoint that always follows the default.

That convenience carries a governance consequence Microsoft states plainly: "every agent that points to the toolbox picks up the promoted version automatically, with no code changes." Promoting a default version is a fleet-wide production change. It needs the change control you would apply to a shared library release — staged promotion, a canary agent, a tested rollback, and an owner who is accountable for it. Nothing in the platform forces that discipline on you.

Current tool status, which is worth having in one place:

MCP: a connectivity standard, not a trust decision

Connecting Foundry agents to remote MCP servers, public and private, is GA. Managed connector namespaces are Preview and unavailable in several major regions including East US, West Europe and UK South. Tool approval defaults to "always" — a good default that teams disable early and regret later.

Microsoft's own language here is unusually direct, and it belongs in your risk register verbatim:

"Microsoft doesn't test or verify these servers. Microsoft has no responsibility to you or others in relation to your use of any remote MCP servers."

And: "Treat tool outputs as untrusted input."

That is the correct framing. MCP standardizes how an agent reaches a tool. It says nothing about whether that tool deserves to be reached. The trust chain runs agent → Foundry → toolbox → MCP client → MCP server → enterprise resource, and every hop is a place where authorization, provenance and output validation have to be decided by you.

The risks are the familiar supply-chain set applied to a new surface: malicious or compromised servers, tool descriptions crafted to manipulate the model's selection, excessive permissions granted at connection time, exfiltration through a tool's own network path, and credential misuse where one connection serves every user.

One point of care for writers and reviewers: the term "tool poisoning" does not appear in Microsoft's Foundry documentation. It is useful community vocabulary from the MCP security literature, and I use it as such — but do not attribute it to Microsoft.

Agent-to-agent: preview, and the authority question it raises

A2A support exists and is Preview end to end — the API type is literally a2a_preview. Inbound A2A requires Entra authentication, anonymous agent cards are not permitted, and callers need the Foundry Agent Consumer role.

The architectural point is more durable than the preview status. Multi-agent topologies raise questions that single-agent designs never surface: whose identity propagates across the hop, what authority the callee inherits, how much context is shared versus minimized, how recursion and loops are bounded, and how an action is attributed back to an originating human when four agents touched it.

An agent should not inherit another agent's authority merely because the call is technically permitted. In Foundry terms, that means OAuth identity passthrough is the only mode where user context survives the hop — for both MCP and A2A. Every other authentication mode collapses all users into a single downstream principal, which is fine for a read-only lookup and unacceptable for anything that writes, spends or discloses.

Models: choice, routing, and the churn nobody plans for

Foundry's model layer splits into two commercially distinct categories, and the distinction has real architectural weight:

Deployment type is where residency actually gets decided, and it is the most misread item in Foundry reviews. At-rest geography and in-flight processing geography are governed separately. Global Standard may process inference in any Azure region; Data Zone confines it to the US, EU or APAC zone; regional Standard keeps it in the deployment region. Batch offers a 24-hour turnaround at 50% less cost. The Developer tier has a fixed 24-hour lifetime and no SLA and no residency guarantee — never let it drift into anything but evaluation.

Model Router is GA, routing each prompt using a balanced, cost or quality preference. Two things to know: Claude models participate but must be deployed first, unlike every other routed model; and the default version 2025-11-18 is updated in place as new models are added. For cost optimization that is a feature. For a regulated workload where the model set is part of your control evidence, it is unmanaged change — pin a frozen version instead.

Claude in Microsoft Foundry

Claude reached GA in Foundry on 29 June 2026, billed in Claude Consumption Units through Azure Marketplace, pay-as-you-go only with no provisioned throughput option. It uses the native Anthropic Messages API at /anthropic/v1/messages with an anthropic-version header — not an OpenAI-compatible shim.

Four models run on Azure infrastructure: claude-opus-5, claude-opus-4-8, claude-sonnet-5 and claude-haiku-4-5. The rest run on Anthropic infrastructure, where Microsoft states data "might be processed outside Azure, including outside the selected Azure region." The Azure-hosted option gains Data Zone Standard in the US — and loses the /files and /skills APIs. A compliance choice is quietly also a feature choice.

Claude is currently available in US regions only. There is no EU or APAC data zone. I could not find a published timeline for one.

Two warnings that matter more than the feature list:

Why route Claude through Foundry rather than consuming it directly? The defensible answers are procurement and platform consistency: one Azure bill, one identity model, one set of network controls, one tracing pipeline, and a model layer that can be changed without renegotiating a contract. The costs are equally real: a 12-month rather than 18-month lifecycle, US-only regions, Marketplace billing that some subscription types cannot transact, and provider-side support. That is a trade, not a free win, and it should be documented as one.

Model lifecycle is an architecture concern

Models move through Preview, GA, Legacy, Deprecated and Retired, and a retired model returns 410 Gone. GA models get a minimum 60 days' notice; preview models get 30 days and are force-upgraded or terminated with no opt-out.

The next six months are busy: gpt-4o retires 1 October 2026 (replaced by gpt-5.1) — the largest blast radius in the window — and the Claude 4.5 family retires 19 October 2026 with no replacement listed.

There is also a live contradiction to be aware of: the Claude models page marks claude-opus-4-5, claude-sonnet-4-5 and claude-haiku-4-5 as GA, while the retirement schedule marks all three Preview. That is not academic — GA buys you 60 days and an opt-out, Preview buys you 30 and a forced upgrade. Query the Models API for lifecycleStatus and treat that as ground truth.

Identity: three principals, and conflating them causes real failures

This is where most Foundry designs go wrong, and the error is subtle because everything appears to work until a permission is denied for reasons nobody can explain.

Microsoft's own wording is precise and easy to skim past:

"The managed identity authenticates the blueprint to Entra ID. It doesn't directly access the downstream resource. The agent identity — not the managed identity — is the principal that requires RBAC role assignments on the target resource."

So there are three distinct principals in play: the user who initiated the task, the project managed identity that authenticates the agent definition, and the agent identity — a service principal in Entra ID — that actually holds permissions on your data. Granting the managed identity access to a database and wondering why the agent still cannot read it is a rite of passage worth skipping.

For blueprint credentials, prefer federated credentials backed by a managed identity, which Microsoft explicitly recommends for production because Azure handles rotation. Client secrets and certificates are supported and both put a rotation burden on you.

RBAC: the names changed, and Owner is not what you think

The current Foundry roles, with the old names now obsolete (role IDs are unchanged, so existing bindings hold):

Three consequences worth designing around:

A subscription Owner cannot invoke an agent. Azure Owner and Contributor grant no data-plane access whatsoever. That is excellent separation of duties if it is intentional and a production incident if it is discovered at 2am.

Foundry Owner is the only role holding both planes, which makes it the natural break-glass role and a poor default. Treat it as privileged access with just-in-time elevation.

Microsoft publishes an explicit anti-pattern, and it is worth quoting to your platform team: "Don't use the Azure AI Developer role for Foundry work. Despite the name, this role is scoped to Azure Machine Learning workspaces and Foundry hubs, not to Foundry projects or Foundry hosted agents."

One documentation caveat: the canonical Azure built-in roles reference does not currently list any of the five Foundry-prefixed roles, even though its own Azure AI Developer entry points at them. The role GUIDs are not published either — so build your IaC against role names and verify in a pilot subscription rather than hard-coding identifiers you cannot source.

Private networking for a regulated enterprise

Foundry offers three egress models: public, bring-your-own virtual network, and a Microsoft-managed virtual network. For regulated workloads the BYO model is usually the answer, and it comes with specifics you need before you design, not after.

The concrete requirements:

• The agent subnet must be delegated to Microsoft.App/environments — which tells you the platform runs agent compute on Azure Container Apps infrastructure.
• Size it /24. The documented minimum is /27, but capacity runs at roughly one IP per ten pods: a /27 supports around 17 concurrent sessions, a /26 around 50. Since the platform ceiling is 50 concurrent sessions per subscription per region anyway, /24 gives you headroom without waste.
• RFC 1918 only. Public ranges and CGNAT (100.64.0.0/10) are unsupported; avoid 172.17.0.0/16, which Docker reserves.
• Private DNS zones you will need: privatelink.cognitiveservices.azure.com, privatelink.openai.azure.com, privatelink.services.ai.azure.com, plus privatelink.search.windows.net, privatelink.documents.azure.com and privatelink.blob.core.windows.net.
• Dependencies to provision: Azure Storage (files), Cosmos DB (conversations and agent metadata, minimum 3000 RU/s across five containers), Azure AI Search (vector stores) and Key Vault. Their private endpoints are not created automatically.

Three constraints that have killed designs I have reviewed:

And the honesty item that belongs in every design review: "supported under network isolation" is not the same as "traffic stays private."

Governance therefore has to operate at tool-allowlist granularity, enforced in the agent definition and audited — because the network boundary will not enforce it for you.

Finally, two operational notes. There is no portal-level IP utilization metric; subnet exhaustion first appears as 5xx errors from the data proxy or failed provisioning, so synthesize your own capacity signal and hold utilization at or below 80%. And in teardown runbooks, the Foundry resource must be purged before the virtual network is deleted, or you are left with an undeletable VNet.

Hosted agent containers: what Microsoft does not do for you

A hosted agent is a container image you built, running code you wrote, pulling dependencies you chose. Foundry operates the runtime. It does not vouch for what is inside.

Microsoft's documentation covers registry authentication, a linux/amd64 requirement and advice against the :latest tag. I could find no Microsoft documentation of image signing, SBOM generation, vulnerability scanning gates or admission policy for hosted agent images. That is not a criticism of the platform — it is a correct division of responsibility — but it means the software supply chain is entirely yours:

• Private ACR with content trust and retention policies, subject to the 25 June 2026 project-date constraint above.
• Signed images and enforced provenance, in your pipeline.
• Vulnerability scanning as a release gate, not a dashboard.
• Pinned base images with an owned patch cadence, and an SBOM per release.
• Least-privileged runtime, no secrets baked into layers, egress restricted at the network layer.

Do not let "it is hosted by Microsoft" become an implicit claim that the application layer is secured by Microsoft. It is not.

Observability and evaluation: the closed loop

Tracing is GA for prompt and hosted agents, built on OpenTelemetry GenAI semantic conventions and flowing into Application Insights. Hosted agents emit automatically — the connection string is injected, no code change required.

Two properties of this loop deserve to be understood before you rely on it as evidence:

Evaluator maturity follows a pattern worth noticing:

The mechanical questions — did it call the tool correctly? — are GA. The questions that actually matter to a business owner — did it do what the user asked, did it stay within its brief — are Preview. Plan for that gap rather than discovering it during a regulator conversation.

One more constraint for isolated estates: pulling traces into an evaluation dataset requires Application Insights to allow public network access, and tracing over a virtual network is Preview. The most regulated environments therefore cannot run the documented production-trace-to-regression loop without relaxing isolation. That is a genuine architectural tension with no clean answer today; the workaround is an exported, sanitized evidence path you control.

Microsoft also ships an AI Red Teaming Agent built on PyRIT, producing an Attack Success Rate. Its GA or Preview status is not labelled in the documentation, so I will not claim one.

Guardrails: strong at the model, immature at the tool

Foundry's content controls are called Guardrails — a named collection of controls, defaulting to Microsoft.DefaultV2, which agents inherit from the model unless a custom guardrail is assigned.

Read that table twice, because the shape of it is the point: guardrail maturity is inverted relative to agentic risk. The model boundary — where a chatbot's risk lives — is GA. The tool boundary — where an agent's risk lives — is Preview. A regulated deployment should not treat Foundry guardrails as the sole control at the tool boundary. Compensating controls belong in the MCP and OpenAPI layers, in egress policy, and in deterministic approval gates outside the model, exactly as I argued in Agentic AI Security Architecture.

Where Agent 365 fits

Foundry builds, deploys and operates agents. Agent 365 governs them across the organization — alongside Copilot Studio agents, third-party agents and shadow agents. It went GA on 1 May 2026 and treats agents as first-class Entra identities through Entra Agent ID.

The integration specifics matter:

• Registry sync is automatic — published Foundry agents appear in the Agent 365 registry.
• Activity data collection is opt-in, per Foundry resource. Microsoft is explicit: "no data flows unless the tenant has valid Agent 365 license and administrator has accepted terms."
• Defender's agent threat detection is Preview (indirect prompt injection, secret leakage, evasion, LLM reconnaissance) — so a GA, licence-enforced governance story currently rests on a Preview detection surface.
• Purview enforces policy only on user-context calls. For app-only authentication — which is exactly how most unattended enterprise automation runs — you get audit visibility and classification, but not policy enforcement.

Which Foundry agent architecture should you choose?

My default advice: start with a prompt agent and be forced into a hosted agent by a specific requirement. Most teams reach for code first out of habit and inherit a container supply chain they did not need. And treat multi-agent as an architecture of last resort until A2A leaves preview — a single agent with well-scoped tools is easier to secure, evaluate and explain than four agents delegating to each other.

Three scenarios that exercise the newer capabilities

Multi-agent financial analysis. An orchestrator coordinates market research, financial data, risk and compliance agents, consolidating their output. This is the canonical A2A demo and the one I would be slowest to put into production. The hard parts are not technical: which agent's conclusion wins when risk and research disagree, whose authority the orchestrator carries when it calls the compliance agent, and who is accountable for the consolidated recommendation. Preview status aside, answer those three before building it.

Enterprise knowledge agent on Foundry IQ. SharePoint policies, OneLake data, structured sources and documentation, grounded through a knowledge base with citations. The architecture is straightforward; the governance is not. Every source needs an explicit permission-trimming decision, because the default does not trim. Add RAG evaluation for groundedness — Preview, but better than nothing — and a freshness policy, because a confidently cited stale policy document is worse than no answer.

Custom-code operations agent. A network and cloud operations agent as a hosted agent: query monitoring APIs and Azure Resource Graph, correlate against ITSM, prepare remediation. This is where hosted agents genuinely earn their complexity, because the correlation logic is real software. Keep the agent on the investigate-and-recommend side of the line and route any change through your existing approval and automation path. The agent's value is in the correlation, not in holding the write credential.

Architecture for a moving platform

The pace of change here is itself an architectural input. In the last twelve months Foundry was renamed, changed its resource model, replaced Assistants with Responses, replaced threads and runs with conversations and responses, retired an SDK, scheduled workflows for retirement before they ever reached GA, moved agent security onto a different licence, and turned over most of its model catalog.

None of that is a criticism. It is the operating condition, and designs that assume otherwise age badly. Practically:

1. Put a model abstraction in your own code. Foundry does not present one API — OpenAI models use /openai/v1, Claude uses the Anthropic Messages API, Agent Framework documents a third path.
2. Treat model IDs as versioned dependencies with expiry dates, owned by someone, in a manifest, with a tested successor. Anthropic's dateless identifiers look like evergreen aliases and are pinned snapshots.
3. Pin tool and toolbox versions in anything regulated, and make default-version promotion a change-controlled event.
4. Re-run evaluations when the model changes, which for auto-upgraded Standard deployments happens without asking you.
5. Read the retirement schedule on a cadence and treat it as a backlog input, not a surprise.
6. Prefer GA surfaces for anything load-bearing, and record an explicit risk acceptance where you depend on Preview — which, for agentic tool-boundary controls, you currently must.

Frequently asked questions

What is Microsoft Foundry? Microsoft's enterprise platform for building, hosting, grounding, governing and operating AI applications and agents on Azure. It combines a multi-provider model catalog, a managed agent runtime, a knowledge layer, a tool layer, evaluation and tracing, and integration with Entra, Defender, Purview and Agent 365. It was formerly Azure AI Foundry.

What is Foundry Agent Service? The managed service that deploys, runs and scales agents. It supports two agent types — prompt agents and hosted agents, both GA — with the Responses API as the single entry point and per-session sandbox isolation.

What is a prompt agent? An agent defined entirely through configuration: model, instructions and tools, created as versions with PromptAgentDefinition. Foundry runs the orchestration loop. Note that knowledge is not a declared field — grounding arrives through tools.

What is a hosted agent? Your own code, packaged as a container image or a source archive, deployed and operated by Foundry while you keep the orchestration logic. Python and .NET today, with Go listed as coming soon.

What is the difference between them? Who owns the orchestration loop, and therefore who owns the operational burden. Prompt agents trade implementation freedom for a much smaller surface — no image, no registry, no dependency patching. Hosted agents give you full control and hand you a container supply chain to secure.

What is Microsoft Agent Framework, and how does it relate to Foundry? Agent Framework is the application-level orchestration library, successor to Semantic Kernel and AutoGen, at version 1.0 since April 2026. Foundry Agent Service is the managed runtime it deploys onto. Agent 365 is the governance plane above both. It is also Microsoft's migration target for retiring workflows.

What is Foundry IQ? The managed knowledge layer — knowledge sources grouped into a knowledge base, agentic retrieval with query planning, grounded answers with citations, exposed to agents through an MCP tool. Its GA applies to REST API version 2026-04-01; both portals give preview-only access to agentic retrieval.

Does Foundry IQ honor my document permissions? Not unless you configure it. Microsoft states that document-level access controls are not automatically honored unless a knowledge source explicitly documents permission support. Permission trimming is opt-in per source and per-user filtering is Preview. Assume over-sharing until proven otherwise.

What is Foundry Toolbox? A GA capability for defining a tool once and reusing it across agents, with immutable versions and a default-version pointer. Promoting a default version propagates to every consuming agent with no code change — treat promotion as a fleet-wide production change.

Does Foundry support MCP? Yes — remote MCP servers, public and private, are GA. Managed connector namespaces are Preview and unavailable in several major regions. Tool approval defaults to always. Microsoft states it does not test or verify third-party MCP servers, and that tool outputs should be treated as untrusted input.

Does Foundry support A2A? Yes, in Preview end to end — the API type is a2a_preview. Inbound requires Entra authentication, no anonymous agent cards, and the Foundry Agent Consumer role for callers.

Can Foundry run Claude, and how? Yes. Claude has been GA in Foundry since 29 June 2026, billed in Claude Consumption Units via Azure Marketplace, using the native Anthropic Messages API. Four models are Azure-hosted; the rest run on Anthropic infrastructure where data may leave your Azure region. US regions only. Whether Claude works inside Foundry Agent Service is contradicted across Microsoft's own pages — do not assume it.

What is Model Router? A GA trained model that routes each prompt to a suitable underlying model on a balanced, cost or quality preference. Claude participates but must be deployed first. The default version updates in place, so pin a frozen version where the model set is part of your control evidence.

Foundry or Copilot Studio? Copilot Studio for business-owned processes over Microsoft 365, Dataverse and connectors. Foundry for engineering-owned work needing custom code, specific models, non-Microsoft data planes, or productization. They interoperate; the useful question is which workloads belong in each.

How does Agent 365 relate to Foundry? Foundry builds and runs agents; Agent 365 discovers, registers, governs and secures them organization-wide. Published Foundry agents sync automatically; activity data collection is opt-in and licence-gated.

Can Foundry agents run in a private network? Yes, via a BYO virtual network with an agent subnet delegated to Microsoft.App/environments, or a managed virtual network. Configure it at account creation — it cannot be changed later. Several tools are unsupported under isolation, and a few work but traverse the public internet.

How should a hosted agent be secured? Assume the application layer is yours. Microsoft documents registry authentication and image basics but publishes no guidance on signing, SBOMs, scanning gates or admission policy. Add those in your own pipeline, and check the 25 June 2026 project-date constraint before planning a private registry.

How do Foundry agents access enterprise APIs? Through OpenAPI tools, Azure Functions, MCP servers or code in a hosted agent — with the agent identity holding the RBAC assignment, not the managed identity. Use OAuth identity passthrough wherever user context must survive the hop.

What should I monitor in production? Traces (GA for prompt and hosted agents), tool-call accuracy and success, session concurrency against the 50-per-subscription-per-region ceiling, subnet IP utilization — for which there is no portal metric — and evaluation scores against a regression baseline. Remember message content is not captured by default.

How do I move an agent from prototype to production? Publish it, so it gets its own identity and audit trail. Assign least-privilege data-plane roles. Pin model and tool versions. Decide networking before creating the account, because it is immutable. Establish evaluation baselines and a regression dataset before traffic arrives. Register it in Agent 365 with a named human owner, and test the containment path before granting write authority.

The line that matters

Microsoft Foundry has become a genuinely capable enterprise platform. It will host your agent, isolate it, give it an identity, ground it in your data, trace it and hand it to a governance plane. That is a great deal of undifferentiated heavy lifting you no longer have to build.

What it does not do — and cannot do — is decide how much authority your agent should have, which data it should be allowed to reach, which actions it may take without a human, and how your organization proves afterwards that it operated safely. Those remain architecture decisions, and the platform will happily let you make bad ones quickly.

The gap between a demo agent and a production system is not model quality. It is identity, authorization, grounding hygiene, tool governance, network containment, evaluation and evidence. Foundry gives you the components. The architecture is still yours.

If you are standing up Foundry for production workloads — or reviewing a design that is already further along than its governance — Avalon does this work: agent identity and authorization models, Foundry IQ permission-trimming reviews before knowledge bases go live, network-isolated landing zones with the tool constraints mapped honestly, hosted-agent supply-chain pipelines, and evaluation harnesses that can actually gate a release. That sits at the center of my AI security and governance practice, and the contact page is the best way to reach me.

Sources

All verified against Microsoft's own documentation on 17 August 2026. Where two Microsoft pages disagree, both are cited.

Platform and agents — What is Microsoft Foundry? (opens in a new tab) · Foundry architecture (opens in a new tab) · Agent Service overview (opens in a new tab) · Hosted agents (opens in a new tab) · Quotas, limits and regions (opens in a new tab) · Workflows (opens in a new tab) · Migrate to the new Agent Service (opens in a new tab) · Migrate from the classic portal (opens in a new tab) · SDK overview (opens in a new tab)

Agent Framework — Overview (opens in a new tab) · Version 1.0 (opens in a new tab) · Anthropic integration (opens in a new tab)

Knowledge and tools — Foundry IQ (opens in a new tab) · Toolbox (opens in a new tab) · MCP tool (opens in a new tab) · A2A (opens in a new tab)

Models — Foundry Models overview (opens in a new tab) · Sold directly by Azure (opens in a new tab) · Partners and community (opens in a new tab) · Deployment types (opens in a new tab) · Model router (opens in a new tab) · Claude models (opens in a new tab) · Claude hosting comparison (opens in a new tab) · Claude GA announcement (opens in a new tab) · Lifecycle and support policy (opens in a new tab) · Retirement schedule (opens in a new tab)

Identity, RBAC and networking — RBAC for Foundry (opens in a new tab) · Authentication and authorization (opens in a new tab) · Agent identity (opens in a new tab) · Hosted agent permissions (opens in a new tab) · Private networking (opens in a new tab) · Networking options (opens in a new tab) · Networking deep dive (opens in a new tab) · Network isolation (opens in a new tab) · Standard agent setup (opens in a new tab)

Guardrails, observability and governance — Guardrails overview (opens in a new tab) · Agent 365 integration with Foundry (opens in a new tab) · Agent 365 overview (opens in a new tab) · Transition agent security to Agent 365 (opens in a new tab) · Defender AI agent detection (Preview) (opens in a new tab) · Purview for Foundry (opens in a new tab)

---

Published 16 August 2026; sources verified 17 August 2026. Every capability in this article is marked GA, Preview or Retiring as documented on that date, and twelve internal contradictions in Microsoft's own documentation are named in the text rather than resolved by guesswork. Availability changes monthly — verify against Microsoft Learn before making a commitment. No client, employer or engagement is named anywhere in this article, and the scenarios described are illustrative composites rather than descriptions of specific customer work.