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.
Last updated: June 2026

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_action tool-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:

PartRoleExample
ModelThe reasoning engine (a deployment)gpt-4o, o3-mini
InstructionsSystem persona and rules"You are a refunds assistant; never exceed $500."
ToolsCapabilities the agent may invokefunction, code_interpreter, file_search, bing_grounding, OpenAPI tools
Threads / messagesStateful conversation memoryRecalls 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:

DimensionFoundry Agent ServiceMicrosoft Agent Framework
What it isManaged, hosted agent runtime in Microsoft FoundryOpen-source SDK + runtime (Python and .NET)
HostingMicrosoft hosts threads, runs, and stateYou host and deploy (local, container, anywhere)
Best forSingle enterprise agents with governance, identity, and tracing built inCode-first, complex multi-agent orchestration and custom workflows
LineageSuccessor to the Assistants-style APIConverges AutoGen (multi-agent research) + Semantic Kernel (enterprise plugins/memory)
OrchestrationConnected/sub-agentsSequential, 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:

PatternFlowWhen to use
SequentialAgent A's output feeds Agent B, then CPipelines: research → draft → edit
ConcurrentSeveral agents run in parallel on the same inputGather independent perspectives, then merge
Group chatAgents converse in a shared thread, a manager picks who speaksBrainstorming, debate, review boards
HandoffOne agent transfers control to a more specialized agentTriage routing (billing → technical)
MagenticA manager agent plans, delegates, and re-plans dynamicallyOpen-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_action is not an error and not completion — it means "the agent is waiting for your tool output." A question showing a run stuck at requires_action is 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.

Test Your Knowledge

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?

A
B
C
D
Test Your Knowledge

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?

A
B
C
D
Test Your Knowledge

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?

A
B
C
D
Test Your Knowledge

An agent run is stuck at status requires_action. What is the correct interpretation and response?

A
B
C
D