Welcome to Part 5 of our complete study series for the AI-103 Certification. After mastering RAG pipelines and search indexing in Part 4, we now step into Domain 2: Building & Orchestrating AI Agents with Microsoft Foundry. In this module, you will learn how to build autonomous systems using the modern Agent, Conversation, and Response model, equip them with tools (Code Interpreter, Bing Grounding, Foundry IQ via MCP), and coordinate multi-agent workflows.
 |
| Building & Orchestrating AI Agents with Microsoft Foundry: AI-103 Practice Questions |
In this free AI-103 practice exam module, you will solve 20 realistic, scenario-based questions covering the Azure AI Foundry Agent Service, built-in tools, MCP vs. A2A protocols, checkpointing, and agent orchestration patterns. Each question includes a deep, technical explanation so you understand exactly why each choice is correct or incorrect.
Building & Orchestrating AI Agents Practice Questions (Part 5)
Q1: Multi-Agent Orchestration Framework (.NET & Python)
Which framework is the Microsoft-recommended option for building multi-agent orchestrations in .NET and Python that integrate with Azure AI Foundry?
• C is correct: Microsoft Agent Framework is the direct successor to both Semantic Kernel and AutoGen, built by the same engineering teams. It reached general availability (version 1.0) on April 3, 2026, with stable APIs, native Model Context Protocol (MCP) support, and long-term support — making it Microsoft's current recommended path for building and orchestrating single- and multi-agent workflows in .NET and Python that integrate with Azure AI Foundry.
• A is incorrect: Semantic Kernel was Microsoft's original enterprise-grade orchestration SDK, but as of Microsoft Agent Framework's general availability (April 3, 2026), Semantic Kernel has entered maintenance mode — it continues to receive critical bug fixes and security patches, but new feature development now happens in Agent Framework instead.
• B is incorrect: AutoGen was Microsoft's research-oriented multi-agent framework, but like Semantic Kernel, it has been superseded by Microsoft Agent Framework, which merges AutoGen's agent abstractions with Semantic Kernel's enterprise features into one supported SDK.
• D is incorrect: LangChain/LangGraph is a popular third-party, non-Microsoft framework. While it can integrate with Azure OpenAI, it is not Microsoft's own recommended orchestration SDK for Foundry-native agent development.
Q2: Debugging & Observability in Multi-Agent Chains
A multi-agent workflow occasionally produces a wrong final answer. The team needs to see exactly which agent, tool call, or step introduced the error across the entire chain.
Which capability should they enable?
• D is correct: OpenTelemetry-based tracing/observability, built into Microsoft Agent Framework, records each step, agent, and tool call across a workflow's execution, letting the team pinpoint exactly where in the chain a failure or wrong result originated.
• A is incorrect: Checkpointing saves state for resuming interrupted workflows; it doesn't provide step-by-step visibility into what went wrong.
• B is incorrect: Content filtering screens for harmful content categories; it has no diagnostic function for tracing logic errors.
• C is incorrect: Streaming affects how output is delivered to the user in real time; it doesn't record or expose the workflow's internal execution steps.
Q3: Multi-Tool Integration (Knowledge Retrieval & Live API)
You are developing an AI customer service agent using the Microsoft Foundry Agent Service.
The agent must be able to:
• Answer user questions by extracting information from uploaded product manuals.
• Check real-time shipping status by querying an external backend order system.
The agent must be able to leverage both data sources to answer complex queries within a single conversational turn.
Which configuration approach should you implement?
• A is correct: To allow a single agent to seamlessly integrate static knowledge retrieval with live, dynamic data, you can configure it with multiple tools simultaneously. The Microsoft Foundry Agent Service supports enabling the native File Search tool (for querying uploaded documents like product manuals) alongside custom function tools (for executing live API calls) on the same agent definition.
• B is incorrect: Embedding entire manuals into the system instructions consumes excessive tokens and is less efficient than using the native retrieval tool.
• C is incorrect: The requirement explicitly asks for a single agent to handle both capabilities, making an external routing layer unnecessary.
• D is incorrect: While Code Interpreter can process files, it runs in a sandboxed environment without outbound internet access, meaning it cannot query an external REST API.
Q4: Persistent Configuration Storage (Agent vs. Conversation vs. Response)
You are building a custom customer support agent using the Microsoft Foundry Agent Service.
The application must support thousands of simultaneous user conversations. Each conversation must utilize the exact same underlying model, system instructions, and set of custom function-calling tools. You want to store this configuration centrally within Foundry so that it does not need to be transmitted by the client application at the start of every new chat session.
Which Foundry Agent Service object should you configure to persistently store these shared settings?
• Why C is correct: In the Microsoft Foundry Agent Service, the Agent object is the persisted, versioned orchestration definition that combines the model, instructions, tools, and parameters. By defining an Agent once (created and versioned via the project client), you can reference it across thousands of conversations without resending its configuration.
• Why the other options are incorrect:
- Option A is incorrect: A Response represents a single execution/generation call — the model actually processing input and producing output — not the stored configuration itself.
- Option B is incorrect: A Conversation holds the multi-turn message history for one specific user session, not the shared agent configuration.
- Option D is incorrect: An input item represents a single piece of content (a user message, for example) submitted within a conversation, not a persistent configuration object.
Note: This replaces the older Assistant/Thread/Run/Message model from the Azure OpenAI Assistants API, which was deprecated and retired on August 26, 2026. Agent, Conversation, and Response are the current equivalents.
Q5: Knowledge Base Retrieval (Azure AI Search Grounding Tool)
You are authoring an autonomous enterprise assistant using the Azure AI Foundry Agent Service. The agent must answer end-user inquiries by retrieving facts from an enterprise knowledge base stored in an Azure AI Search index. The solution must handle query generation, semantic search, and document retrieval automatically without requiring you to develop or host external retrieval functions.
Which built-in tool should you attach to the agent configuration?
• Why B is correct: The Azure AI Search tool is a native grounding mechanism in the Azure AI Foundry Agent Service. Attaching this tool links the agent directly to an existing Azure AI Search index, allowing the agent runtime to formulate search queries, retrieve context chunks, and synthesize grounded responses with citations automatically, without requiring custom retrieval code.
• Why alternative tools are incorrect:
- Why A is incorrect: The Code Interpreter tool executes sandboxed Python code within the agent runtime to carry out mathematical calculations, data transformations, and chart generation. It cannot connect to or query external search indices.
- Why C is incorrect: An OpenAPI custom function tool requires you to define, host, and maintain an external REST API endpoint. While it could theoretically connect to a search service, it violates the requirement to use a native, built-in tool that requires no retrieval code development.
- Why D is incorrect: The Bing Grounding tool queries the public web to provide up-to-date internet information. It has no access to private enterprise search indices hosted within your Azure tenant.
Q6: Domain-Specific Voice Agent Accuracy (Custom Speech)
A biopharmaceutical research organization is developing a hands-free laboratory voice agent. During laboratory testing, the agent's default speech recognition engine frequently misinterprets complex chemical compound names and proprietary drug formulations.
Which approach should the developers take to improve the agent's speech recognition accuracy for this domain-specific vocabulary?
• Why A is correct: Standard speech recognition models are trained on general conversational data and frequently misrecognize specialized technical jargon. Custom Speech (a capability of Azure AI Speech) allows developers to upload domain-specific reference texts, technical glossaries, and pronunciation guides to train a custom language model. Integrating this custom model into the agent's speech recognition pipeline reduces the Word Error Rate (WER) for specialized terms.
• Why other options are incorrect:
- Why B is incorrect: Adding search partitions in Azure AI Search expands index storage and query throughput for search requests; it has no effect on speech-to-text audio recognition.
- Why C is incorrect: Azure Private Link secures the transport layer by placing service endpoints behind private IP addresses in a Virtual Network (VNet). It has no effect on acoustic analysis, language modeling, or transcription accuracy.
- Why D is incorrect: Increasing embedding dimensions alters the mathematical representation of text chunks in a vector database for semantic search; it does not affect audio transcription or voice recognition.
Q7: Triggering Enterprise Workflows (OpenAPI & Logic Apps)
An AI Foundry autonomous agent needs to trigger multi-step, long-running business processes (such as processing an ERP order, sending emails, and updating internal database records) by invoking an Azure Logic Apps workflow.
Which tool configuration should you attach to the agent definition?
• Why D is correct: The OpenAPI tool in Azure AI Foundry Agent Service enables agents to discover and invoke external REST endpoints defined by an OpenAPI (Swagger) specification. Because Azure Logic Apps workflows can be exposed via HTTP request triggers and OpenAPI schemas, adding an OpenAPI tool allows the agent to execute long-running integration workflows autonomously.
• Why other options are incorrect:
- Why A is incorrect: Azure Monitor tracks application telemetry, metrics, and operational alerts; it is an observability service, not an execution tool for running business workflows.
- Why B is incorrect: The Azure AI Search tool is designed for retrieval-augmented grounding from vector and full-text indices; it cannot trigger external transactional business logic.
- Why C is incorrect: The Code Interpreter tool allows the agent to execute sandboxed Python code to perform arithmetic, data transformations, and chart generation; it cannot invoke external cloud services or Logic Apps.
Q8: Modeling Agent Capabilities (Tools & JSON Schemas)
You are configuring an autonomous customer service agent in Azure AI Foundry Agent Service. The agent must dynamically query an internal Azure AI Search knowledge store, execute a mathematical discount calculation, and invoke external REST endpoints to update an ERP database.
How are these capabilities modeled and exposed to the agent?
• Why A is correct: In the Azure AI Foundry Agent Service, external capabilities are integrated as Tools (such as the Azure AI Search tool, Code Interpreter tool, and custom Function/OpenAPI tools). Each tool includes a declarative schema detailing its purpose, expected input arguments, and output structures. During runtime, the reasoning model inspects these schemas and autonomously decides when and how to call each tool to complete the task.
• Why other options are incorrect:
- Why B is incorrect: Content Safety blocklists are safety mechanisms used to detect, flag, or intercept prohibited words, sensitive phrases, and toxic content. They provide moderation guardrails, not operational or computational capabilities.
- Why C is incorrect: Vector embeddings represent text chunks in numerical vector space for semantic similarity calculations. Embeddings represent information, not executable agent actions or API connectors.
- Why D is incorrect: Leaving external systems as standalone, decoupled applications without defining them as registered agent tools prevents the agent's underlying LLM from discovering or invoking them during execution.
Q9: Multi-Tool Architecture (File Search, REST API & Code Interpreter)
A developer is configuring a single Microsoft Foundry agent for a team of financial analysts. The agent must (1) answer questions from a set of quarterly PDF statements uploaded directly to the agent, (2) call the firm's internal REST API to fetch live ticker prices, and (3) compute weighted return figures and render a chart from numbers the analyst pastes into the conversation.
Which tool assignment satisfies all three requirements?
• Why this answer is correct: In the Azure AI Foundry Agent Service, requirements map directly to native tool capabilities:
1. File Search tool (for PDF statements): Automatically parses, chunks, embeds, and indexes uploaded documents (like PDF financial reports), enabling semantic retrieval with citations.
2. Custom Function tool with a JSON schema (for the internal REST API): Provides a declarative schema that describes endpoint signatures and parameters, allowing the agent to perform function calling to fetch real-time stock ticker prices.
3. Code Interpreter tool (for calculations and charts): Offers a secure, sandboxed execution environment where the agent writes and runs Python code dynamically to execute precise math and output visual charts.
• Why the other options are incorrect:
- Why custom functions for all three is incorrect: While custom code could technically handle everything, re-implementing document indexing and code execution from scratch adds heavy development and maintenance overhead, ignoring Foundry's built-in managed tools.
- Why File Search for both PDFs and API is incorrect: The File Search tool is strictly a retrieval mechanism for static document files. It cannot execute network calls or communicate with transactional REST APIs.
- Why Code Interpreter for all three is incorrect: Code Interpreter executes in a sandboxed container with outbound internet access strictly disabled, making external REST calls impossible. Furthermore, parsing multi-page PDFs using raw Python code in a sandbox is far less scalable than vector-indexed File Search.
Q10: Dynamic Workflow Planning (Magentic Orchestration)
A team needs a multi-agent workflow where the set and order of contributing agents isn't fixed in advance. A planner should dynamically decide, at runtime, which specialist agents to invoke and in what order, based on the specific request.
Which orchestration approach fits this?
• Why B is correct: Magentic orchestration uses a planner that dynamically determines which agents to involve and in what order at runtime, rather than following a predetermined structure — suited to open-ended tasks where the right sequence of specialists cannot be known in advance.
• Why other options are incorrect:
- Why A is incorrect: Sequential orchestration executes agents in a fixed, predetermined order every time.
- Why C is incorrect: Concurrent orchestration runs a fixed set of agents in parallel on the same input; it does not involve a planner deciding which agents to invoke dynamically.
- Why D is incorrect: Handoff transfers control between two specific agents based on scope, not an open-ended, dynamically planned sequence of multiple agents.
Q11: Cross-Session Long-Term Memory (External Datastore Pattern)
An enterprise is developing an executive assistant agent using the Azure AI Foundry Agent Service. The assistant must remember user-specific preferences (such as preferred meeting times, travel habits, and dietary restrictions) across independent conversation sessions and separate conversations that occur days or weeks apart.
Which architectural approach is recommended to implement persistent, cross-session memory for this agent?
• Why B is correct:
- Short-Term vs. Long-Term Memory: In the Azure AI Foundry Agent Service, a Conversation object maintains short-term history only for the duration of a single session.
- The External Profile Pattern: To achieve durable, cross-session memory across distinct conversations, the agent architecture must decouple long-term user memory from the transient conversation itself. User profile attributes and learned preferences are persisted in a database (such as Azure Cosmos DB or Azure Table Storage). When the user begins a new interaction, the application retrieves their profile from storage and dynamically injects those facts into the system instructions or initial context of the new conversation.
• Why other options are incorrect:
- Why A is incorrect: Hardcoding user preferences directly into the model's static deployment instructions cannot scale across thousands of distinct users. Any change to a preference would require editing and redeploying the agent, and static system prompts would cause one user's private data to be exposed to all other users sharing the same deployed model.
- Why C is incorrect: Foundation models have fixed weights trained on public web datasets up to their training cutoff date. They possess zero innate knowledge of private runtime end-users and cannot permanently store or remember personal state across API calls through their internal weights alone.
- Why D is incorrect: DNS TXT records are public domain-name system records intended for domain ownership verification and email security protocols (SPF/DKIM). They are publicly readable on the internet, heavily cached, have strict character limits, and represent a critical privacy and security violation if used to store user personal data.
Q12: Multi-Agent Orchestration Patterns (Matching)
Match each multi-agent orchestration pattern to its correct operational description. Each pattern is used exactly once.
1. One agent transfers control of the conversation to a different, more specialized agent when it determines the request is outside its own scope.
2. Agents execute one after another in a fixed order, with each agent's output becoming the next agent's input.
3. Agents take turns contributing to a shared conversation, similar to a multi-participant discussion, until a stopping condition is reached.
4. Multiple agents work on the same input in parallel, and their outputs are aggregated or compared afterward.
• 1 → Handoff: An agent recognizes a request is better handled elsewhere and transfers the conversation to a specialized agent, without the user needing to restart the interaction.
• 2 → Sequential: Agents run in a pipeline, one after another, where each step depends on the previous agent's output — useful when a task naturally decomposes into ordered stages.
• 3 → Group Chat: Several agents participate in a shared conversation thread, contributing in turn, which suits collaborative problem-solving scenarios with multiple areas of expertise.
• 4 → Concurrent: Multiple agents process the same input simultaneously and independently, which is useful for getting diverse perspectives or redundant validation before combining results.
Q13: Standardized Tool Server Integration (Model Context Protocol - MCP)
A platform team is building agents that need to call an expanding set of external tool servers — some maintained by other internal teams, some by third-party vendors — and wants new tool servers to be discoverable and callable by any agent without writing a new custom function integration for each one.
Which approach should the team adopt?
• Why B is correct: MCP standardizes how an agent discovers and invokes tools exposed by a server, so any MCP-compliant tool server can be connected without bespoke integration code per tool — new servers become usable by simply pointing the agent at them, which directly satisfies the "expanding set of tool servers, no per-tool custom integration" requirement. Microsoft Agent Framework and Microsoft Foundry Agent Service both support MCP natively for this reason.
• Why other options are incorrect:
- Why A is incorrect: Writing a bespoke custom function and schema for every tool server is exactly the repeated, non-scalable integration work the team is trying to avoid.
- Why C is incorrect: Azure AI Search indexes are for retrieval over indexed content; arbitrary external tool servers (which may perform actions, not just return searchable data) cannot generally be represented as a search index.
- Why D is incorrect: Disabling tool calling removes the agent's ability to invoke any external capability at all, which defeats the purpose entirely.
Q14: Core Agent Architectural Components (Select 3)
A cloud solutions engineer is defining an autonomous support agent using the Azure AI Foundry Agent Service SDK.
Which THREE core architectural components must be configured to establish a complete, functional agent definition capable of tool-augmented reasoning? (Each correct selection forms part of the complete solution. Select THREE.)
• Why A, C, and D are correct: In the Azure AI Foundry Agent Service (backed by the Agent, Conversation, and Response object model — the older Assistants API was retired August 26, 2026), a fully functional agent definition requires three core building blocks:
- Instructions (A): The system prompt establishing the agent's behavior, instructions, operational boundaries, and persona.
- Tools & Schemas (C): The set of capabilities available to the agent (Code Interpreter, File Search / Azure AI Search, or custom function tools) along with their JSON schemas so the model knows how to invoke them.
- Model Deployment (D): The specific deployed foundation model (such as GPT-4o) that executes the reasoning and determines when to trigger tools.
• Why other options are incorrect:
- Why B is incorrect: An Azure Cost Management budget is an infrastructure financial governance control configured at the subscription/resource group level; it is not an internal component of an agent definition.
- Why E is incorrect: Mutual TLS certificates are network-layer security mechanisms managed by Azure's networking stack; they are not part of an agent's logical definition schema.
- Why F is incorrect: Model deployments reside within the parent Foundry project/hub region. Agents do not require or accept a static list of global Azure regions in their configuration.
Q15: Production Agent Lifecycle (Agent Versioning)
A team has a production agent, published and in active use by several client applications, that they need to update with revised instructions and an additional tool. Existing client applications must continue working against the current, unchanged behavior until they explicitly opt in to the update.
Which approach should the team take when updating the agent in Microsoft Foundry Agent Service?
• Why B is correct: Agents in Microsoft Foundry Agent Service are stored as named, versioned assets. Creating a new version preserves the previous version's behavior for any client still referencing it by version, while making the updated instructions and tool available under the new version for clients that opt in — satisfying both the update requirement and the backward-compatibility requirement.
• Why other options are incorrect:
- Why A is incorrect: Editing the live definition in place immediately changes behavior for every client calling that agent, breaking the requirement that existing clients keep working against unchanged behavior until they opt in.
- Why C is incorrect: Deleting the agent removes the existing, working version entirely, which breaks every client currently referencing it — the opposite of preserving their existing behavior.
- Why D is incorrect: This is factually wrong — instructions and tools are core parts of an agent's definition and are exactly what a new version is meant to update; only being able to change the model would be an artificial and inaccurate limitation.
Q16: Cross-Platform Agent Delegation (A2A Protocol)
Two agents are built on completely different frameworks by two separate vendors. One agent needs to delegate a customer request to the other agent, which reasons over it independently using its own tools and returns a structured result.
Which protocol is designed for this?
• Why A is correct: A2A (Agent-to-Agent) is a standardized protocol built specifically for cross-platform delegation between independent agents, regardless of which framework or vendor built them. It uses Agent Cards for discovery and Tasks as the unit of delegated work, letting one agent hand off a request to another and receive a structured response back.
• Why other options are incorrect:
- Why B is incorrect: MCP (Model Context Protocol) standardizes how an agent connects to tools and data sources, not how two independent agents communicate with each other.
- Why C is incorrect: OpenAPI describes REST API schemas for tool invocation; it is not a protocol for agent-to-agent delegation.
- Why D is incorrect: RRF (Reciprocal Rank Fusion) is a search-result ranking and merging algorithm in Azure AI Search, completely unrelated to agent communication protocols.
Q17: Real-Time Progressive UI Rendering (Streaming Responses)
A team is building a chat interface for their Foundry agent and wants the assistant's reply to appear progressively, word by word, as the model generates it — rather than the user seeing nothing until the entire response is complete.
Which approach should the team implement when creating the response?
• Why B is correct: Streaming mode delivers the model's output incrementally, as a series of chunks, over the same connection — letting the application render text to the user as it's generated rather than waiting for the full response to finish, which is exactly the progressive-display behavior described.
• Why other options are incorrect:
- Why A is incorrect: Reasoning effort controls how much internal reasoning budget a model spends before answering; it doesn't change whether output is delivered incrementally or all at once.
- Why C is incorrect: A very small max_tokens value would truncate the response prematurely; it doesn't create a progressive-display effect, and would likely cut off the answer.
- Why D is incorrect: Polling for accumulated text depends on the underlying object actually being updated incrementally mid-generation, which isn't how the response is produced — streaming the response is the mechanism designed for this, not client-side polling of a static object.
Q18: Long-Running Resilient Workflows (Checkpointing & HITL)
A team is building a multi-step agent workflow that processes loan applications. The workflow can take several minutes to complete, must be able to resume from where it left off if the process is interrupted (such as a service restart), and must pause partway through to let a human reviewer approve or reject the application before the agent proceeds to disbursement.
Which TWO capabilities of Microsoft Agent Framework's graph-based workflows should the team rely on to satisfy these requirements? (Each correct selection forms part of the complete solution. Select TWO.)
• Why A is correct: Checkpointing persists the workflow's execution state at defined points, so if the process is interrupted, it can resume from the last checkpoint rather than restarting from the beginning — directly addressing the resumability requirement.
• Why C is correct: Human-in-the-loop support is a built-in capability of Agent Framework's graph-based workflows that lets a workflow pause at a specific node and wait for explicit human sign-off before proceeding — exactly the approval-gate requirement described.
• Why other options are incorrect:
- Why B is incorrect: Sampling temperature affects output randomness/creativity; it has no relationship to resumability or approval gating.
- Why D is incorrect: Context window size affects how much input a single model call can process; it doesn't provide resumability after an interruption or a human approval mechanism.
- Why E is incorrect: Disabling tracing removes visibility into workflow execution, which would make debugging interruptions harder, not easier — and it doesn't provide resumability or approval functionality either way.
Q19: Real-Time Public Web Retrieval (Bing Grounding Tool)
An agent must answer user questions about breaking news events from today, which don't exist in any internal or indexed company data.
Which tool should be attached to the agent?
• Why C is correct: The Bing Grounding tool connects the agent to live public web search results, making it the right choice for current, real-world information that is not part of any internal data source.
• Why other options are incorrect:
- Why A is incorrect: The File Search tool retrieves information strictly from documents uploaded directly to the agent or thread, not live public web content.
- Why B is incorrect: The Code Interpreter executes sandboxed Python code; it has no outbound internet access and cannot fetch news or query web endpoints.
- Why D is incorrect: Azure AI Search grounds responses in a private, indexed enterprise data source, not the public internet.
Q20: Integrating Custom Retrieval Pipelines (Function Calling)
You are developing a generative AI agent using the Microsoft Foundry Agent Service. The agent requires access to a proprietary document retrieval pipeline powered by Azure AI Search so it can ground its responses in internal company data.
Which design approach enables the agent to dynamically invoke this retrieval pipeline to answer user queries?
• Why A is correct: To enable an AI agent to interact with external systems, APIs, or custom retrieval pipelines, you must define the capability as a tool (via function calling with a JSON schema) and attach it to the agent's definition. When the agent determines it needs information from the pipeline to answer a query, it outputs the necessary arguments to call the tool, allowing your application to execute the retrieval and return the results to the agent.
• Why other options are incorrect: Disabling tools, setting max_tokens to zero, or placing endpoints in the system instructions will not enable dynamic execution of the pipeline by the agent.
Microsoft Foundry Agent Tools & Orchestration Cheat Sheet
Earning your credential as a Microsoft Certified: Azure AI Apps and Agents Developer requires knowing exactly when to use each tool, protocol, and pattern. Use this quick architectural reference to keep your concepts sharp before test day:
| Capability / Pattern | Core Function | Network & Scope Boundary | Status & Exam Relevance |
|---|---|---|---|
| Agent Object Model | Defines instructions, model deployment, parameters, and assigned tools persistently. | Tenant / Foundry project level. Referenced across thousands of user conversations. | Current (GA): Replaces the retired Assistants API (Threads/Runs retired August 26, 2026). |
| Code Interpreter Tool | Executes dynamic Python code for advanced calculations, data transformations, and chart rendering. | Strictly sandboxed container. No outbound internet access — cannot call external APIs. | Native built-in tool. Fast local mathematical and tabular data operations. |
| Bing Grounding Tool | Fetches real-time, live public web search results to ground answers in current world events. | Public internet search queries only. Cannot access private tenant data or internal indices. | Native built-in grounding tool for breaking news and non-indexed public facts. |
| Azure AI Search Tool | Queries private vector, full-text, or hybrid enterprise indices with automatic citations. | Tied to a specific Azure AI Search index in your Azure subscription. | Native tool for single-index enterprise RAG retrieval. |
| Model Context Protocol (MCP) | Standardized protocol connecting agents to dynamic tool servers and multi-source knowledge (Foundry IQ). | Agent-to-Tool / Agent-to-Data boundary across modular internal or external services. | Native open standard supported by Microsoft Agent Framework and Foundry. |
| Agent2Agent (A2A) Protocol | Standardizes task delegation and messaging between independent, heterogeneous agents. | Agent-to-Agent boundary across separate frameworks and third-party vendors. | Uses Agent Cards for discovery and structured Tasks for cross-platform execution. |
| Magentic Orchestration | Uses a dynamic planner agent to build and adapt sub-task graphs at runtime based on task state. | Multi-agent workflow with specialist sub-agents. | Experimental: Best for complex, non-deterministic tasks with no fixed order. |
| Checkpointing & HITL | Persists workflow state to resume after interruptions and pauses execution for human approval gates. | Graph-based state machine layer in Microsoft Agent Framework. | Essential pattern for high-risk, irreversible actions (financial transfers, data deletion). |
Key Takeaways for AI-103 Domain 2 (Building & Orchestrating AI Agents)
• The 2026 Object Model: Remember that Azure OpenAI Assistants API (Thread, Run, Message) was retired on August 26, 2026. The current Microsoft Foundry Agent Service standard is Agent (stored instructions/tools), Conversation (session message store), and Response (generation execution cycle).
• Framework Modernization: Microsoft Agent Framework (GA April 3, 2026) is Microsoft's primary SDK for agent development in Python and .NET. Semantic Kernel and AutoGen have both transitioned into maintenance mode.
• Sandbox Isolation (Code Interpreter): A frequent exam trap is assuming Code Interpreter can perform REST calls or pull live website content. It runs inside an isolated sandbox with zero outbound internet access. To fetch live external data, assign a custom function tool, an OpenAPI tool, or the Bing Grounding tool.
• MCP vs. A2A Protocols: Keep these two distinct protocols clear: MCP governs how an agent connects to tools, databases, and Foundry IQ knowledge servers. A2A governs how independent agents discover each other (via Agent Cards) and delegate tasks across different frameworks.
• Orchestration Maturity: Magentic, Sequential, Concurrent, Handoff, and Group Chat patterns are powerful multi-agent patterns, but Microsoft's documentation designates them as experimental. For resilient enterprise workflows, always pair them with OpenTelemetry tracing and checkpointing.
• Cross-Session User Memory: Conversations are session-scoped. To retain user preferences across days or weeks, implement the External Profile Pattern: store extracted user facts in an external database (like Azure Cosmos DB) and inject them into system context at session start.
Frequently Asked Questions (Foundry Agent Orchestration FAQ)
Review these quick, high-yield answers to master the most common agent design scenarios tested on the AI-103 certification exam:
Are these AI-103 practice exam questions updated for the 2026 certification syllabus?
Yes. This free AI-103 practice test reflects the current exam objectives, covering the Microsoft Agent Framework (GA April 2026), the retirement of the older Assistants API, native Model Context Protocol (MCP) integrations, and enterprise state management in Microsoft Foundry.
What is the difference between Semantic Kernel, AutoGen, and Microsoft Agent Framework?
Microsoft Agent Framework is the official, unified successor to both Semantic Kernel and AutoGen. It reached General Availability (GA 1.0) on April 3, 2026. While Semantic Kernel and AutoGen continue to receive security maintenance, all new multi-agent features, native MCP support, and enterprise tooling are developed under Microsoft Agent Framework.
What replaced the Thread and Run model in Azure AI Foundry Agent Service?
The older Azure OpenAI Assistants API model (Threads, Runs, Messages) was retired on August 26, 2026. Microsoft Foundry Agent Service now uses the Agent, Conversation, and Response model, where the Agent stores configuration centrally, Conversations manage multi-turn history, and Responses handle execution cycles.
When should an agent use MCP instead of the A2A protocol?
Use the Model Context Protocol (MCP) when an agent needs to connect to tools, documents, and data sources (such as Foundry IQ knowledge bases or tool servers). Use the Agent2Agent (A2A) protocol when two independent agents built on different frameworks or vendor platforms need to discover each other and delegate workloads.
Can the Code Interpreter tool make outbound HTTP or REST API calls?
No. The Code Interpreter tool executes inside a strictly isolated sandbox environment where outbound network access is disabled. To query external REST APIs or web endpoints, the agent must use an OpenAPI tool, a custom function tool, or the Bing Grounding tool.
Next Step in Your AI-103 Certification Journey
Outstanding work on completing this free AI-103 practice exam module on agent building and orchestration! You have mastered agent architectures, tool configurations, multi-agent coordination, and resilient state management in Microsoft Foundry.
Now that your agents can reason, call tools, and collaborate, the next step is making sure they perform efficiently at enterprise scale. In Part 6 of our study guide, we dive into Optimizing & Operationalizing Generative AI Systems, covering latency reduction, token budgeting, prompt caching, PTU provisioning, and automated continuous evaluation.
Keep your momentum going and move directly to the next part using the links below:
