The features of Microsoft Foundry

Microsoft Foundry is more than a place to send a prompt to a model. It is a managed platform where you build agents, run them, check quality, and share them with your team. Concept 2 showed where you work—the Microsoft Foundry portal, Foundry projects, and who has permission to do what. Here you meet the main parts you will use from a first agent to production: agent types, models and deployments, tools and toolboxes, tracing, evaluations, guardrails, and publishing.

Picture a support assistant for a small online shop. A customer asks whether order 8842 can ship today. In Foundry, that message can start a prompt agent that reads its instructions, asks a model for a reply, and—if needed—calls a tool that looks up the order. Tracing saves a step-by-step record of the run. An evaluation can score the answer on test orders before you publish. Publishing gives a stable endpoint you can share in Microsoft Teams or Microsoft Copilot. The sections below walk through the same path in more detail.

Foundry Agent Service offers three agent types. Your choice sets how much code you write and how much Foundry runs for you. All three can use models from the Foundry model catalog and built-in platform tools, but they differ in how you set them up and who maintains the runtime.

• Prompt agents: you set instructions, a model, and tools in configuration. Foundry runs the agent—no application code or containers for you to maintain. Edit, save versions, test, evaluate, monitor, and publish from the Agents playground in the Microsoft Foundry portal, or define the same agent with SDKs or REST.
• Voice-based prompt agents (preview): prompt agents for real-time spoken conversations. You set the model, instructions, audio settings, optional greeting, and tools, then connect over a WebSocket with Voice Live while Foundry manages the runtime and tool calls.
• Hosted agents: you bring your own code or framework (for example Agent Framework or LangGraph), packaged as a container image or a .zip file Foundry builds into an image. Foundry deploys it with a managed endpoint, automatic scaling, a dedicated Microsoft Entra identity, and observability. You do not edit hosted agents in the agent-building UI, but you can run, evaluate, monitor, and publish them.

A model listed in the Foundry Models catalog does nothing for your app until you deploy it or, where supported, use an instant access model. Model deployment creates and manages model endpoints from the portal or from code. Deployment types include standard, global, data zone, provisioned throughput (PTU), batch, and priority processing, so you can balance speed, volume, and where data is processed.

Agent Service works with many catalog models, such as GPT-4o, Llama, and DeepSeek. You can point the agent at a different deployment to change models without rewriting agent code. Managed compute (preview) runs selected open-source and custom models on dedicated virtual machine capacity in your Foundry resource. The model router can send each request to a suitable model for cost and quality when you turn that feature on.

• Foundry Models catalog: find and compare models from Microsoft, OpenAI, Anthropic, Meta, partners, and community sources.
• Fine-tuning and model lifecycle features track versions, updates, and retirement schedules when you customize models on your data.
• Quotas and region availability: capacity limits depend on model and region; plan deployments before production traffic.
• For keys, billing, and deployment choices in depth, Concept 4 explains what to set on the Foundry resource and project.

Models produce text. Tools let an agent act—search the web, read files, run code, call your APIs, or reach company data. In Foundry, you attach tools to agents so the model can choose when to call them with structured inputs.

• Built-in tools include web search, file search, code interpreter, and memory (preview). The tool catalog lists what each tool needs before you attach it.
• Custom tools include function calling, OpenAPI tools that describe a REST API, Azure Functions, and Model Context Protocol (MCP) servers—including managed servers and servers you host.
• Tool connections can use keys, Microsoft Entra identities, sign-in on behalf of the user (On-Behalf-Of), or no authentication where that is appropriate.

A toolbox groups tools into one reusable bundle. You set up the tools once; Foundry exposes them behind one managed MCP-compatible endpoint that any agent can use. Authentication, governance, and versioning sit in one place, so you promote a new toolbox version to default instead of updating every agent by hand. To save a prompt agent with a tool attached, the tool must be fully set up first; reuse configured tools across agents.

A trace is the full record of one agent run. Spans are the steps inside a trace: each span is one operation with a start time, end time, and details. Common span names include invoke_agent for the whole run, chat for model work, and execute_tool for tool calls. Tracing is generally available for prompt and hosted agents; workflow and external agents are in preview.

• Turn on server-side tracing by connecting an Azure Monitor Application Insights resource to your Foundry project. Foundry writes traces to Application Insights; you do not need to change agent code for server-side tracing.
• In the portal, open Agents, select Traces at the top, and select Connect to create or link Application Insights. You need permission to read logs on the connected Application Insights resource before you can view traces.
• After the agent runs, open the Traces view, search or filter traces, and select a trace to walk through each span. The Traces page also shows Conversation results so you can review history, tokens, and tool calls for one conversation.
• How long traces are kept and what they cost follow your Application Insights and Log Analytics settings. The portal shows recent traces for debugging; long-term storage depends on how you configure Application Insights.

Tracing can store prompts, tool inputs, and outputs. Remove secrets and personal data before they are logged, and treat traces like production logs. Concept 13 goes further on span details, framework setup, and the Agent Monitoring Dashboard.

Evaluations score models and agents on test data or saved traffic so you can compare versions and catch quality drops before users do. An evaluation runs one or more evaluators and returns scores, and sometimes short explanations, in the Microsoft Foundry portal or through the SDK.

• Typical workflow: pick a target (agent, model, dataset, or traces), pick scope (single replies or full conversations), pick a data source (CSV or JSONL, generated data, simulated conversations, or production traces), choose evaluators, then start the run from Evaluation > Create, the agent Evaluation tab, or Metrics > Run full evaluation in the playground.
• On the project you need the Foundry User role. AI-assisted quality evaluators also need an Azure OpenAI connection with a deployed GPT model, such as gpt-4.1-mini.
• Single-turn evaluation scores one reply at a time (for example tool choice and safety). Full conversations (preview) scores multi-turn chats for task completion and satisfaction. Conversation-level evaluators include Customer Satisfaction and Task Completion; agent evaluators such as Intent Resolution apply to individual turns.

Run evaluations before publishing and again after important changes; repeating evaluation on production conversations helps catch drift. The agent optimizer (preview) tests prompt agents and hosted agents against a dataset and suggests better instructions, skills, tool descriptions, and model choices. Prompt agents start from the Optimize tab wizard; hosted agents need code set up for optimization first. Concept 8 and Concept 14 expand measurement, Prompt Optimizer, and red teaming.

• Identity: each agent can have its own Microsoft Entra identity so it reaches other services without shared passwords. After you publish an agent application, permissions on the project identity do not copy over—give the published agent identity only the access it needs.
• Access: Azure permissions and Foundry roles (Concept 2) control who can create, run, and manage agents and evaluations.
• Guardrails: named sets of checks on user input, tool call (preview), tool response (preview), and final output for risks such as hate, sexual content, violence, and self-harm. Agent guardrails are in preview; the guardrail you assign to an agent overrides the guardrail on its model deployment. Blocking level Medium blocks medium- and high-severity content for those content risks.
• Network: private networking is available for prompt agents; hosted agents can run inside your own Azure virtual network for session isolation.
• Policy and platform governance: Azure Policy, customer-managed keys, token limits, and cost tools appear in the capability reference for running Foundry at scale.

Foundry tracks versions as you save prompt agents; each saved version is fixed, so edits create a new version you can compare or roll back. Publishing promotes an agent to a managed resource with a stable endpoint. You can share published agents through Microsoft Copilot, Microsoft Teams, and the Entra Agent Registry. On the Details tab or when you select Publish, set the active version to Always use latest or pin a specific version so users get the build you tested.

• Attaching a tool that still needs sign-in or a connection, then failing to save the agent—finish tool setup before save.
• Testing only in the playground but never saving a version, then missing history, monitoring, or full evaluations—save versions for milestones you want to compare.
• Publishing without updating identities and tool connections for the published agent—recheck access after publish.
• Starting an evaluation without Foundry User on the project or without a judge model deployment for AI-assisted evaluators—check prerequisites first.

Several features here are preview: voice-based prompt agents, agent optimizer, full-conversation evaluation scope, and agent guardrails. Preview features use supplemental terms, have no service-level agreement, and are not recommended for production until you review support, security, and availability for your scenario.

Concept 4 explains how to control keys, understand cost, and choose model deployments on your Foundry resource—the practical layer beneath the features you mapped here.

• Start with the platform overview: What is Microsoft Foundry?
• For agent types, toolboxes, and the development lifecycle: Foundry Agent Service overview
• For portal evaluation steps and evaluator lists: Run evaluations in Foundry
• For trace concepts and span names: Agent tracing overview