Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Note
This document refers to the Microsoft Foundry (classic) portal.
🔄 Switch to the Microsoft Foundry (new) documentation if you're using the new portal.
Note
This document refers to the Microsoft Foundry (new) portal.
Most businesses don't want just chatbots. They want automation that's faster and has fewer errors. That might mean summarizing documents, processing invoices, managing support tickets, or publishing blog posts. In all cases, the goal is the same: freeing people and resources to focus on higher-value work by offloading repetitive and predictable tasks.
Large language models (LLMs) introduced a new type of automation with systems that can understand unstructured data, make decisions, and generate content. In practice, businesses can have difficulty moving beyond demos and into production. LLMs can drift, be incorrect, and lack accountability. Without visibility, policy enforcement, and orchestration, these models are hard to trust in real business workflows.
Microsoft Foundry is designed to change that. It's a platform that combines models, tools, frameworks, and governance into a unified system for building intelligent agents. At the center of this system is Foundry Agent Service, which enables the operation of agents across development, deployment, and production.
Foundry Agent Service connects the core pieces of Foundry (such as models, tools, and frameworks) into a single runtime. It manages conversations, orchestrates tool calls, enforces content safety, and integrates with identity, networking, and observability systems. These activities help ensure that agents are secure, scalable, and production ready.
By abstracting away infrastructure complexity and enforcing trust and safety by design, Foundry Agent Service can help you move from prototype to production with confidence.
What is an AI agent?
Agents make decisions, invoke tools, and participate in workflows. They do these tasks sometimes independently and sometimes in collaboration with other agents or humans. They're foundational to real process automation.
Agents created via Foundry are not monoliths. They're composable units. Each agent has a specific role, is powered by the right model, and is equipped with the right tools. And each agent is deployed within a secure, observable, and governable runtime.
An agent has three core components:
- Model (LLM): Powers reasoning and language understanding.
- Instructions: Define the agent's goals, behavior, and constraints. They can have the following types:
- Declarative:
- Prompt based: A declaratively defined single agent that combines model configuration, instruction, tools, and natural language prompts to drive behavior.
- Workflow: An agentic workflow that can be expressed as a YAML or other code to orchestrate multiple agents together, or to trigger an action on certain criteria.
- Hosted: Containerized agents that are created and deployed in code and are hosted by Foundry.
- Declarative:
- Tools: Let the agent retrieve knowledge or take action.
Agents receive unstructured inputs such as user prompts, alerts, or messages from other agents. They produce outputs in the form of tool results or messages. Along the way, they might call tools to perform retrieval or trigger actions.
How do agents in Foundry work?
Think of Foundry as an assembly line for intelligent agents. Like any modern factory, Foundry brings together specialized stations that are each responsible for shaping part of the final product. Instead of machines and conveyor belts, the agent factory uses models, tools, policies, and orchestration to build agents that are secure, testable, and production ready. Here's how the factory works step by step:
1. Models
The assembly line starts when you select a model that gives your agent its intelligence. Choose from a growing catalog of LLMs, including GPT-4o, GPT-4, GPT-3.5 (Azure OpenAI), and others like Llama. The model is the reasoning core of the agent that informs its decisions.
2. Customizability
Shape the model to fit your use case. Customize your agent with fine-tuning, distillation, or domain-specific prompts. Encode agent behavior, role-specific knowledge, and patterns from prior performance by using data captured from real conversation content and tool results.
3. Knowledge and tools
Equip your agent with tools. These tools let the agent access enterprise knowledge (such as Bing, SharePoint, and Azure AI Search) and take real-world actions (via Azure Logic Apps, Azure Functions, OpenAPI, and more). This step enhances the agent's ability to expand its capabilities.
4. Orchestration
The agent needs coordination. Connected agents orchestrate the full lifecycle, such as handling tool calls, updating conversation state, managing retries, and logging outputs.
The agent needs coordination. Workflows orchestrate the full lifecycle, such as handling tool calls, updating conversation state, managing retries, and logging outputs.
5. Observability
Agents are tested and monitored. Foundry can capture logs, traces, and evaluations at every step. With full conversation-level visibility and Application Insights integration, teams can inspect every decision and continuously improve agents over time.
6. Trust
It's important to ensure that agents are suitable and reliable for the workload they're assigned to. Foundry applies enterprise-grade trust features, including identity via Microsoft Entra, role-based access control (RBAC), content filters, encryption, and network isolation. You choose how and where your agents run, by using platform-managed or bring-your-own infrastructure.
The result is an agent that's ready for production: reliable, extensible, and safe to deploy across your workflows.
Why Use Foundry Agent Service?
Foundry Agent Service provides a production-ready foundation for deploying intelligent agents in enterprise environments. Here's how it compares across key capabilities:
| Capability | Agent Service |
|---|---|
| Visibility into conversations | Full access to structured conversations, including both user-to-agent and agent-to-agent messages. Ideal for UIs, debugging, and training. |
| Multiple-agent coordination | Built-in support for agent-to-agent messaging. |
| Tool orchestration | Server-side execution and retry of tool calls with structured logging. No manual orchestration is required. |
| Trust and safety | Integrated content filters to help prevent misuse and mitigate prompt injection risks (XPIA). All outputs are policy governed. |
| Enterprise integration | Ability to bring your own storage, Azure AI Search index, and virtual network to meet compliance needs. |
| Observability and debugging | Full traceability of conversations, tool invocations, and message traces; Application Insights integration for usage data. |
| Identity and policy control | Built on Microsoft Entra with full support for RBAC, audit logs, and enterprise conditional access. |
Get started with Foundry Agent Service
To get started with Foundry Agent Service, you need to create a Foundry project in your Azure subscription.
Start with the environment setup and quickstart guides if it's your first time using the service.
Start with the environment setup and quickstart guides if it's your first time using the service.
You can create a project with the required resources. After you create a project, you can deploy a compatible model such as GPT-4o. When you have a deployed model, you can also start making API calls to the service by using the SDKs.
You can find a list of official samples with the new Python agent SDK on GitHub.
BCDR for agents
To support service resilience, Foundry Agent Service relies on customer-provisioned Azure Cosmos DB accounts for business continuity and disaster recovery (BCDR). This reliance helps ensure that your agent state can be preserved and recovered in the event of a regional outage.
As an Azure Standard customer, you provision and manage your own single-tenant Azure Cosmos DB account. All agent state is stored in this account. Backup and recovery rely on native capabilities in Azure Cosmos DB, which you control.
If the primary region becomes unavailable, the agent automatically becomes available in the secondary region by connecting to the same Azure Cosmos DB account. Because all history is preserved in Cosmos DB, the agent can continue operation with minimal disruption.
We recommend that customers provision and maintain their Azure Cosmos DB accounts, and that they configure appropriate backup and recovery policies. This effort helps ensure seamless continuity if the primary region becomes unavailable.
Related content
- Learn more about the models that inform agents.