3.1 Agentic Solutions: Foundry Agent Service and the Microsoft Agent Framework
Key Takeaways
- Domain 3 (Implement an agentic solution) is an explicit 5-10% AI-102 domain added in the December 23, 2025 outline; older notes omit it.
- Foundry Agent Service is the MANAGED, hosted single-agent runtime; the Microsoft Agent Framework is the open-source SDK (AutoGen + Semantic Kernel converged) for code-first multi-agent orchestration.
- Every agent = model + instructions + tools (function, code_interpreter, file_search, bing_grounding, OpenAPI) + stateful threads.
- Multi-agent orchestration patterns to know: sequential, concurrent, group chat, handoff, and Magentic (dynamic manager-led planning).
- requires_action means the run paused for your code to execute a tool and submit outputs - it is not an error or completion; secure every tool with managed identity and least privilege.
Quick Answer: Domain 3 (Implement an agentic solution, 5-10%) tests building autonomous, tool-using agents. The two pillars are the Microsoft Foundry Agent Service (the managed, hosted runtime for single agents) and the Microsoft Agent Framework (the open-source SDK — the convergence of AutoGen and Semantic Kernel — for code-first single- and multi-agent orchestration). Know the agent anatomy (model + instructions + tools + threads), the
requires_actiontool-call loop, and the multi-agent orchestration patterns (sequential, concurrent, group chat, handoff, and Magentic).
Where This Sits on AI-102
Agentic solutions are a small but explicit domain — 5-10%, the lowest-weighted of the six skill areas — on an exam of roughly 40-60 questions in 100 minutes, passing at 700/1000 for about US$165. It was promoted to a named domain in the December 23, 2025 outline, so older study notes omit it. The live AI-102 retires June 30, 2026 (successor: AI-103, Azure AI App and Agent Developer Associate), and the successor leans even harder into agents — making this material the most future-proof part of your prep.
Agent Anatomy
An agent is an LLM wrapped with instructions, tools, and persistent memory so it can plan and act over multiple steps rather than answer once. Every agent is assembled from four parts:
| Part | Role | Example |
|---|---|---|
| Model | The reasoning engine (a deployment) | gpt-4o, o3-mini |
| Instructions | System persona and rules | "You are a refunds assistant; never exceed $500." |
| Tools | Capabilities the agent may invoke | function, code_interpreter, file_search, bing_grounding, OpenAPI tools |
| Threads / messages | Stateful conversation memory | Recalls earlier user constraints across runs |
Built-in tools matter on the exam: code_interpreter runs sandboxed Python (data analysis, charts); file_search is managed RAG over uploaded files with automatic chunking and citations; function tools call your own APIs; bing_grounding and OpenAPI tools reach external web and REST services. Prefer a built-in tool over hand-rolled code when one fits the requirement.
Foundry Agent Service vs. Microsoft Agent Framework
This comparison is the highest-value distinction in Domain 3:
| Dimension | Foundry Agent Service | Microsoft Agent Framework |
|---|---|---|
| What it is | Managed, hosted agent runtime in Microsoft Foundry | Open-source SDK + runtime (Python and .NET) |
| Hosting | Microsoft hosts threads, runs, and state | You host and deploy (local, container, anywhere) |
| Best for | Single enterprise agents with governance, identity, and tracing built in | Code-first, complex multi-agent orchestration and custom workflows |
| Lineage | Successor to the Assistants-style API | Converges AutoGen (multi-agent research) + Semantic Kernel (enterprise plugins/memory) |
| Orchestration | Connected/sub-agents | Sequential, concurrent, group-chat, handoff, Magentic patterns |
On the Exam: "Managed, governed, single agent fast" → Foundry Agent Service. "Code-first, several specialized agents collaborating, custom control flow" → Microsoft Agent Framework. If a scenario names AutoGen or Semantic Kernel, the modern answer is to migrate to the Microsoft Agent Framework, which unifies both — do not pick the legacy SDKs as a new build target.
Multi-Agent Orchestration Patterns
A single agent struggles with broad, multi-skill tasks; multi-agent systems decompose work across specialists. Memorize the named patterns:
| Pattern | Flow | When to use |
|---|---|---|
| Sequential | Agent A's output feeds Agent B, then C | Pipelines: research → draft → edit |
| Concurrent | Several agents run in parallel on the same input | Gather independent perspectives, then merge |
| Group chat | Agents converse in a shared thread, a manager picks who speaks | Brainstorming, debate, review boards |
| Handoff | One agent transfers control to a more specialized agent | Triage routing (billing → technical) |
| Magentic | A manager agent plans, delegates, and re-plans dynamically | Open-ended tasks with no fixed steps |
The requires_action Tool-Call Loop
Whichever runtime you choose, the execution heartbeat is identical: create agent → create thread → add message → create run → poll. When the agent decides to call a tool, the run enters requires_action and pauses. Your code executes the requested tool, submits the outputs, and the run resumes — looping as many times as the task needs before reaching completed.
while run.status in ("queued", "in_progress", "requires_action"):
run = client.agents.get_run(thread_id=thread.id, run_id=run.id)
if run.status == "requires_action":
outputs = []
for call in run.required_action.submit_tool_outputs.tool_calls:
result = run_tool(call.function.name, json.loads(call.function.arguments))
outputs.append({"tool_call_id": call.id, "output": json.dumps(result)})
client.agents.submit_tool_outputs(thread_id=thread.id, run_id=run.id,
tool_outputs=outputs)
Common Trap:
requires_actionis not an error and not completion — it means "the agent is waiting for your tool output." A question showing a run stuck atrequires_actionis testing whether you know to submit tool outputs, not to retry or fail.
Securing and Testing Agents
Autonomy multiplies risk: every tool an agent can call is an attack surface. Authenticate agents and their downstream tools with managed identity (never embedded keys), scope each tool to least privilege, and wrap inputs/outputs with Content Safety (prompt shields for injection arriving through tool data, harm filters on responses). Use Foundry's tracing and evaluation to test runs: inspect each step's tool calls and intermediate reasoning, score task completion, and watch token cost — agents loop, so an unbounded tool loop or a runaway multi-agent group chat can be far more expensive than a single chat completion.
Always choose the simplest design that meets the requirement: a single function call beats an agent, and one agent beats a multi-agent system, unless the task genuinely needs dynamic multi-step tool use.
A team needs a single, governed customer-support agent with built-in identity, tracing, and managed hosting, and minimal infrastructure work. Which option fits best?
You must orchestrate several specialized agents in code with custom control flow, and you want the modern unified SDK rather than the legacy research and enterprise toolkits. What should you use?
In which multi-agent orchestration pattern does a manager agent dynamically plan, delegate to specialists, and re-plan as results come back, rather than following a fixed sequence?
An agent run is stuck at status requires_action. What is the correct interpretation and response?