2.2. Building Agents with Foundry Agent Service
💡 First Principle: An agent is the chat-completion skeleton wrapped in a managed runtime that adds the four things a raw completion lacks — durable instructions, registered tools, knowledge sources, and persistent conversation state (conversations and responses; threads and runs in the Classic API). The Agent Service handles hosting, state, identity, and observability so your code carries only the agent's logic.
This is the conceptual heart of the heaviest domain. Where a completion is one-and-done, an agent persists: it remembers the dialogue in a persisted conversation (a thread, in the Classic API), can invoke tools across multiple steps within one response (a run), and can be grounded on your data. The exam tests whether you can recognize when a requirement crosses the line from "a good prompt will do" into "this needs an agent," and whether you can place each agent capability at the right configuration layer.
Surface note: Foundry exposes two agent surfaces — a Classic API (
project_client.agents.create_agent(...), explicitCodeInterpreterTool(), manual thread/run management) and the current surface: prompt agents created withproject.agents.create_version(...)and aPromptAgentDefinition, plus Hosted agents / Agent Framework (AzureAIAgentClient,as_agent(...), toolbox MCP endpoints, conversations). The next-generation Foundry Agent Service reached general availability in March 2026 (built on the OpenAI Responses API), and the Foundry SDKs shipped stable 2.0 releases; the Microsoft Agent Framework reached v1.0. 🧪 Hosted agents themselves remain in preview (GA expected around July 2026). Concepts transfer between both surfaces. Where SDK calls are shown, recognize the pattern (create agent → attach tools/knowledge → create a response on a conversation; Classic: start a run on a thread) rather than memorizing one method signature.
⚠️ Common Misconception: "More tools make a better agent." Each tool the model can choose from adds selection ambiguity and latency; a pile of overlapping tools lowers tool-choice accuracy. Scope tools tightly and describe them precisely — fewer, well-described tools beat many vague ones.