Implement generative AI and agentic solutions
Foundry Agents, Tools, and Multi-Agent Orchestration
CoreBuild Foundry agents with clear roles, instructions, and tool schemas; give them retrieval, function calling, and memory; connect APIs, MCP servers, search, and Content Understanding as tools; orchestrate several agents; keep humans in control of risky steps; and monitor and evaluate agent behavior.
Aligned to the AI-103 study guide with skills measured as of April 16, 2026; guide and product behavior verified October 12, 2026.
Why this matters
Agents decide which tools to call and in what order, so a vague instruction, an over-broad tool, or a missing approval step turns into real actions with real consequences. AI-103 tests whether you can choose the right agent type, wire tools safely, track conversations, coordinate several agents, and diagnose failures from traces and evaluator results.
Must Know
- Foundry Agent Service offers prompt agents (declarative instructions, model, and tools that Foundry runs), voice-based prompt agents (preview, through Voice Live), and hosted agents (your own code and framework packaged as a container that Foundry runs with a managed endpoint and identity).
- Agents are identified by name and version. Calls run through the Responses API, and multiturn state lives in a conversation, through previous_response_id, or in items your app resends. With store set to false nothing is persisted.
- Instructions define the agent's role, goal, scope, and rules for tool use. Tool schemas (names, descriptions, and parameter definitions) are what the model reads when deciding whether and how to call a tool, so precise descriptions improve tool selection.
- Built-in tools include file search, code interpreter, web search, and Azure AI Search. Custom tools include function tools, OpenAPI tools defined by an OpenAPI 3.0 or 3.1 specification, and remote MCP servers.
- For a function tool, the response contains a function_call item; your app runs the function and returns a function_call_output with the matching call_id in the same conversation, after which the agent completes its answer.
- MCP tools default to require_approval always. The app receives an mcp_approval_request item and answers with an mcp_approval_response that approves or rejects the call; allowed_tools limits which server tools the agent can use.
- Microsoft Agent Framework, the successor to Semantic Kernel and AutoGen, provides sequential, concurrent, handoff, group chat, and magentic orchestration patterns. Workflows can pause for human approval through approval-required tools and request-info steps.
- The visual workflow builder in the Foundry portal (preview) is scheduled to retire on December 1, 2026; Microsoft recommends Agent Framework workflows deployed as hosted agents for new multi-agent orchestration.
- Agent tracing records model calls, tool calls, and decisions in Application Insights. Agent evaluators such as intent resolution, task adherence, tool call accuracy, and task completion pinpoint whether failures come from understanding, policy, or tool use.
Compare and Distinguish
- Prompt agent versus hosted agent: configuration-only with no runtime code versus your own orchestration code in a container.
- Function tool versus OpenAPI tool versus MCP tool: your app executes the call versus the service calls a described REST API versus the service calls tools exposed by a remote MCP server.
- Conversation versus memory: the running history of one interaction versus information retained for later sessions.
- Sequential versus concurrent versus handoff versus group chat versus magentic: fixed order, parallel fan-out, control transfer by context, shared discussion, and a manager agent coordinating specialists.
- Intent resolution versus task adherence versus tool call accuracy: understood the request versus followed instructions and policy versus called the right tools with correct arguments.
Scenario examples
- Scenario: An agent must look up order status in an internal API that has no public endpoint and requires business logic in the app. Think: a function tool executed by the application.
- Scenario: A procurement agent can read supplier data freely but must get a manager's consent before creating a purchase order through an MCP server. Think: require_approval set for the write tool only and allowed_tools to hide unneeded tools.
- Scenario: A research request needs a planner that assigns subtasks to specialist agents and adjusts the plan as results arrive. Think: magentic orchestration in Agent Framework.
Exam traps
- The agent service does not run your function tools; the calling application does.
- Setting require_approval to never for convenience removes the human checkpoint on every tool from that server.
- A longer instruction is not a substitute for accurate tool descriptions and parameter schemas.
- Sequential orchestration is wrong when independent analyses could run in parallel; concurrent orchestration reduces wall-clock time.
- Starting a new conversation drops earlier context unless memory or your own state carries it forward.
Key takeaways
- Pick the agent type by how much code and control you need.
- Describe tools precisely, run function tools in your app, and gate risky remote tools with approvals.
- Use tracing and agent evaluators to find whether failures come from intent, policy, or tool use.
How it works
- On each turn the model reads instructions, conversation items, and tool schemas, then either answers or emits tool calls that the runtime or your app fulfills.
- Approval requests pause the response until the app returns an approval decision referencing the original response.
Objects and administrative surfaces
- Foundry portal agents playground and agent versions.
- Foundry SDK create_version with a prompt agent definition, and responses.create with an agent reference.
- Project connections for MCP servers, OpenAPI tools, and Azure AI Search.
- Application Insights traces and the agent monitoring dashboard.
When to use it
- Use a single agent with several tools until specialization or separation of duties clearly requires more agents.
- Use handoff when a conversation must move to a specialist, such as billing, based on what the user asks.
Security and governance implications
- Give each tool connection the narrowest credential or managed identity scope it needs.
- Treat MCP tool descriptions and results as untrusted input that can carry injected instructions.
Troubleshooting signals
- If an agent never continues after approval, check that the approval response references the right request and previous response IDs.
- If the agent calls the wrong tool, review tool descriptions and run tool call accuracy and tool selection evaluators on traced runs.
More detail
- Define agent roles, goals, conversation tracking, and tool schemas.
- Integrate retrieval, function calling, and memory into agents.
- Connect OpenAPI, MCP, Azure AI Search, file search, and Content Understanding tools.
- Orchestrate multiple agents with safeguards, approvals, monitoring, and evaluation.
Ready for the quiz?
- When would you build a hosted agent instead of a prompt agent?
- What does the app send back after receiving a function_call item?
- How do you require approval for one MCP tool but not another?
- Which orchestration pattern lets a manager agent re-plan dynamically?
Related objectives
- D2.2.S1 — Define agent roles, goals, conversation-tracking approach, and tool schemas
- D2.2.S2 — Build agents that integrate retrieval, function-calling, and conversation memory
- D2.2.S3 — Integrate agent tools, including APIs, knowledge stores, search, content understanding, and custom functions
- D2.2.S4 — Implement orchestrated multi-agent solutions
- D2.2.S5 — Build autonomous or semiautonomous workflows with safeguards and approval flow controls
- D2.2.S6 — Integrate monitoring into deployed agents, evaluate agent behavior, and perform error analysis