1.1.2. What an "Agent" Actually Is
💡 First Principle: An agent is a model plus four things it lacks on its own: instructions (a durable role), tools (actions it can request), knowledge (data to ground on), and a thread (persistent state across turns). Strip those away and you have a one-shot chat completion. The agent is the loop that lets a model act, not just answer.
A plain chat completion is a vending machine: one input, one output, no memory of the last transaction. An agent is closer to a capable assistant who remembers the conversation, can look things up, can use a calculator or call an external system when needed, and keeps working until the task is done. Concretely, the Foundry Agent Service binds a deployed model to a set of instructions, registers tools the model may invoke (function tools, code interpreter, file search, connected/OpenAPI tools, Bing grounding), attaches knowledge sources, and manages threads (the conversation/state) and runs (a single execution that may take several tool-calling steps).
This is the single most important distinction on the exam, because the heaviest domain (30–35%) is generative-AI-and-agentic, and a large share of those questions hinge on recognizing when a requirement needs the agentic loop (tool use, multi-step, memory) versus a simple completion.
⚠️ Exam Trap: "An agent is just a chatbot with a fancier prompt." A better prompt improves a single response; it cannot give the model the ability to call a tool, persist state across turns, or take an action in an external system. If a scenario requires looking something up, doing a calculation reliably, or carrying state, the answer is an agent with the right tools — not a longer system prompt.
Reflection Question: A requirement says the assistant must "check current inventory levels before confirming an order." Why can't a system prompt satisfy this, and what agent component does?
