Azure AI Foundry Agent Service

What it does

Azure AI Foundry Agent Service is the platform for building and hosting your own custom AI agents on Azure. You pick a model, give it instructions, wire up tools and knowledge, and Foundry runs the agent, including its threads and state, with no app server to maintain.

Key facts

Went GA at Build in May 2025; now folded under the Microsoft Foundry brand (docs and portal are mid-rename, so you'll see both "Azure AI Foundry" and "Microsoft Foundry").
Agents are model plus instructions plus tools plus knowledge; you build them in the Foundry portal or via SDK/REST.
Knowledge tools include Grounding with Bing Search, SharePoint, Microsoft Fabric and Azure AI Search; action tools include 1,400+ Logic Apps connectors.
Supports multi-agent orchestration and open interoperability (Responses API, wire-compatible with OpenAI agents).
Newer hosted agents deploy with one command to a session-isolated managed runtime with autoscaling and no idle cost, and accept code from Agent Framework, LangGraph, OpenAI Agents SDK, Anthropic Agent SDK and others.
Foundry agents can be published into Microsoft 365 Copilot and Teams; that publishing path was tracked for GA around June 2026, confirm current status.
Governance runs through Entra, Purview and Defender across Foundry, Copilot Studio and partner agents.

When to use / skip

Use Foundry Agent Service when you're a pro-code team building a custom agent: bespoke tools, your own orchestration, specific models, deployed as part of an app or platform. Use Copilot Studio instead when a maker wants a low-code agent grounded in Microsoft 365 data and surfaced in Teams or SharePoint without writing much. They're complementary, not rivals: Copilot Studio for low-code and M365 reach, Foundry for pro-code depth, and the two can call each other. Skip Foundry if nobody on the team writes code, the learning curve isn't worth it.

Configuration decisions

Pick your lane early: Copilot Studio (low-code) vs Foundry (pro-code), or a deliberate mix where Studio calls a Foundry agent.
Choose a hosting model: managed prompt agents vs the newer hosted agents for custom code and autoscaling.
Decide your knowledge sources up front (Bing, SharePoint, Fabric, AI Search) as they drive grounding quality and cost.
Sort governance through Entra, Purview and Defender before anything ships, not after.
If you need M365 Copilot or Teams surfacing, check the current publish-path status before you promise it.

Gotchas

The naming is in flux; "Azure AI Foundry" and "Microsoft Foundry" refer to the same thing right now, which confuses procurement.
Grounding tools like Bing Search and third-party models carry their own billing and terms on top of the service.
Hosted agents and some code-first SDKs are newer than the core GA, so check what's GA versus preview per feature.
It's a build platform, not a finished assistant, budget real dev and eval effort, unlike Copilot in Azure.
Multi-agent orchestration sounds tidy in demos and gets messy in production; test failure modes.

Consultant notes

The one-line client answer: Copilot Studio for makers, Foundry for developers, same governance plane.
Watch the brand rename in decks and SOWs so you're not quoting a product name the portal no longer uses.
The Logic Apps connector library is the easy win for giving an agent real actions without custom code.
Treat the M365 Copilot publish path as "check before promising", the dates have moved.

Verify GA vs preview per feature before scoping, this service ships faster than the docs settle.