What's changed: Added per-section figures (cert-figure-retrofit). New AI-103 Chapter 3 (agent implementation = Foundry Agent Service, composition = model + instructions + knowledge + tools, tool types = function calling/file search/code interpreter, threads and runs · multistep reasoning, multi-agent = orchestrator/handoff/parallel, safety = least privilege/human-in-the-loop/monitoring & evaluation/Content Safety)
3.1Implementing Agents
Understand implementing agents with Foundry Agent Service from a developer’s view—composing model, instructions, knowledge (RAG), and tools (function calling); multistep reasoning; and managing threads/runs.
Chapter 2’s function calling is the foundation of agents. In AI-103 you implement and operate agents with Foundry Agent Service—agents that take a goal and autonomously perform multiple steps. An agent is composed of "model + instructions + knowledge (RAG) + tools." At runtime, via a thread (conversation context) and runs, the model repeats multistep reasoning: "think → call a tool → observe → decide next." Developers design each tool’s definition, permissions, and validation.
3.1.1Tools an agent uses
- Function calling (custom function): your own functions (inventory lookup, booking API, internal-system integration).
- File search / knowledge tool: search connected data (e.g., Azure AI Search) as grounding evidence.
- Code interpreter: a built-in tool that performs calculation/data processing via code execution.
- Built-in tools: ready-made tools for web or specific-service integrations.
3.1.2Threads and runs
An agent’s conversation accumulates in a thread, and each user message triggers a run. Within a run, the agent calls tools as needed, receives their results (tool output), continues reasoning, and returns a final response. When a tool is an app-side function, the run enters a "requires tool action" state and resumes once the app executes the function and returns the result. Developers handle this lifecycle (create → tool action → complete) and design retries and timeouts on failure.
Common: (1) "build/run agents in Foundry" = Foundry Agent Service. (2) agent = model + instructions + knowledge (RAG) + tools. (3) "call your own logic" = function calling (custom function); "search connected data as evidence" = file search/knowledge tool; "calculation/code execution" = code interpreter. (4) conversation context = thread, one-turn processing = run; for app functions, the run requires tool action and resumes after you return the result.
Watch out: (1) knowledge (RAG · what it knows) vs tools (functions · what it can do) differ. (2) function calling (your functions) vs code interpreter (built-in code execution)—do not confuse. (3) For app-side tools, the model only returns a request—execution and validation are the app’s responsibility; the run waits until you return results. (4) Because agents act autonomously, keep tool permissions minimal (consistent with Chapter 1 RBAC).
3.1.3Section summary
- Implement agents in Foundry Agent Service as "model + instructions + knowledge (RAG) + tools"
- Tools: function calling (custom) / file search & knowledge / code interpreter / built-in
- Runtime: context in a thread, multistep reasoning in a run; app functions pause the run until you return results
- Design least-privilege tools and retries/timeouts (governance for autonomy)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which service is used to build and operate agents in Microsoft Foundry?
Q2. Which built-in tool lets an agent perform calculation/data processing via code execution?
Q3. In which unit does an agent’s conversation context accumulate?
Q4. When an app-side function is used as a tool, which correctly describes the run and the developer’s responsibility?
Q5. Which tool lets an agent search connected data (e.g., internal docs) as grounding evidence?
Q6. Which correctly distinguishes an agent’s "knowledge" from its "tools"?