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 threads with runs. 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 conversation in a thread, can invoke tools across multiple steps within 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(...), explicit CodeInterpreterTool(), manual thread/run management) and a newer Hosted agents / Agent Framework surface (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 → run against 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.