What is an agent?

After this chapter, you will be able to explain what makes an application an AI agent, distinguish agents from chatbots and deterministic workflows, and use the core vocabulary the rest of the playbook builds on.

An AI agent is an application component that uses a model to reason about a request and take bounded actions toward a goal. In the Microsoft ecosystem, an agent is not just a prompt or a single model call: Microsoft Foundry describes agents as AI applications that can reason over requests and take autonomous actions, while Microsoft Agent Framework (MAF) describes agents as LLM-backed components that process inputs, call tools or MCP servers, and generate responses (Foundry agents overview, MAF overview).

The important idea is bounded discretion. You give the agent a goal, instructions, and a limited set of capabilities. The model then helps decide the next step from context. That is useful when you cannot write one fixed branch for every possible request, but it also means you must design the boundaries, test the behavior, and decide where human or programmatic control is required.

An agent is often confused with a chatbot. A chatbot is usually the conversational interface: the user sends a message and receives text. An agent may use chat, but agency is about task-solving behavior. An agent can call tools, access external data, make multi-step decisions, or even run without a chat interface in the background (Foundry agents overview).

Pattern	Best mental model	Use it when
Chatbot	A conversational surface for exchanging messages.	The main job is to answer or collect information in a conversation.
Agent	A goal-directed component that can reason and act with bounded autonomy.	The task needs dynamic decisions, tool use, or multi-step planning.
Workflow or automation	An explicitly defined sequence or graph of steps.	The path is known, control matters, and ordinary code can express the process.

The agent-versus-workflow distinction is especially important in MAF. A deterministic workflow has a predefined flow; an agent's next steps are selected with model reasoning based on context and available tools. MAF documentation recommends agents for open-ended or conversational tasks with autonomous tool use, and workflows for well-defined steps, explicit execution order, and coordination among agents or functions (MAF overview, MAF workflows).

You can understand most agent systems through a simple loop: perceive → reason → act.

• Perceive: the agent receives a user message, event, conversation state, retrieved data, or tool result.
• Reason: the model interprets the goal, instructions, context, and available tools to decide what should happen next.
• Act: the agent responds to the user, calls a tool, asks for clarification, requests approval, or hands work to another component.

MAF gives this loop a structured runtime: it coordinates user interaction, model inference, and tool execution. The loop is deterministic as a framework structure, not as a guarantee that model outputs or business results are always deterministic (MAF agents). You still need iteration limits, validation, observability, and safety controls for real systems; Azure Architecture guidance specifically calls out the risk of infinite tool-call loops (AI agent design patterns).

Tools are what let an agent do more than generate text. A tool is a controlled capability exposed by your application or provider: looking up data, calling a service, executing domain logic, searching files, using MCP, or requesting a hosted capability. MAF documents tool categories such as function tools, code interpreter, file search, web search, hosted and local MCP tools, and provider-specific tools (MAF tools).

Tool use is powerful because it connects model reasoning to real capabilities. It is also where many risks appear. A model choosing a tool is not the same as your system approving an action. Keep tools narrow, name them clearly, validate inputs and outputs, and use approval or human-in-the-loop patterns when side effects matter (MAF tools).

Autonomy means the agent has some discretion over the next step. It does not mean the agent is independent, safe by default, or free to do anything. The goal comes from the user request and instructions. The action space comes from the tools, identity, security boundaries, workflow boundaries, and approval rules you provide. Microsoft explicitly notes that builders remain responsible for testing, responsible AI mitigations, and safety decisions for their use case (MAF overview).

MAF uses a small vocabulary throughout the rest of this playbook:

Term	Meaning in this playbook	Covered later
Agent	The behavior boundary: an invokable component that uses a model, instructions, and optional tools to work toward a goal.	→ Chapter 3
Instructions	The agent's role, goals, constraints, and behavioral guidance; useful, but not a replacement for controls.	→ Chapter 3
Chat client	The model/provider boundary that lets an agent use an inference service while keeping behavior separate from provider details.	→ Chapter 4
Tools	Curated capabilities the agent can request during execution, such as functions, search, MCP servers, or provider tools.	→ Chapter 5
Workflow	An explicitly defined process or graph that coordinates agents, functions, events, and human interaction when the path needs control.	→ Chapter 6
Orchestration	The coordination layer that decides how agents, tools, functions, workflows, and humans are sequenced or combined.	→ Chapters 6 and 7
Multi-agent	A system that coordinates multiple specialized agents when one agent is too broad, overloaded, or constrained.	→ Chapter 7

Use an agent when the task benefits from model-driven decisions: the request is open-ended, the user may ask follow-up questions, the system must choose among tools, or the next step depends on context you cannot fully enumerate. MAF's overview recommends agents for open-ended or conversational tasks, autonomous tool use and planning, or a single LLM-backed component with tools (MAF overview).

Do not start with an agent just because the application uses AI. Start with the lowest complexity that reliably meets the requirement. Azure Architecture guidance places direct model calls, single agents, and multi-agent systems on a complexity spectrum, and recommends adding orchestration only when simpler approaches are not enough (AI agent design patterns).

Reach for	When it fits	Why
Normal code	You can write a function that handles the task reliably.	It is cheaper, easier to test, and deterministic. MAF states: if you can write a function, do that instead of using an AI agent (MAF overview).
Direct model call	The work is single-pass classification, summarization, translation, extraction, or drafting with no tool logic.	You get model capability without adding agent state, planning, or tool execution.
Single agent	The task is open-ended and needs bounded tool use or planning, but one role can own the work.	It keeps the system understandable while allowing dynamic steps.
Workflow	The steps are known, order matters, or you need explicit routing, validation, checkpointing, or human review.	The process path is controlled instead of delegated to model planning (MAF workflows).
Multi-agent orchestration	One agent becomes unreliable because the work spans domains, security boundaries, parallel specializations, or tool sets.	Specialization can help, but it adds coordination overhead, latency, cost, and new failure modes (AI agent design patterns).

Common pitfalls:

• Using an agent for deterministic work: if the path is fixed, ordinary code or a workflow is usually clearer.
• Treating chat as agency: a chat UI does not make a system an agent unless it can reason and act toward a goal.
• Overloading one agent with too many tools: broad tool sets make selection harder and increase risk.
• Adding multiple agents too early: more agents are not automatically better; start with the simplest reliable design.
• Confusing instructions with safeguards: instructions guide behavior, but validation, tool scoping, approvals, telemetry, and tests provide control.
• Ignoring side effects: any tool that changes data, sends messages, spends money, or triggers external work needs explicit boundaries and review.

• An agent is a goal-directed component that combines model reasoning, instructions, tools, and runtime boundaries.
• Chat is an interface; agency is the ability to reason and act toward a task.
• Workflows are not inferior to agents. Use workflows when the path is known and control matters.
• The perceive → reason → act loop explains how agents move through context, model decisions, and tool-backed actions.
• Autonomy must be bounded by tool scope, validation, approval, observability, and testing.

Next, Chapter 2, Agentic patterns and the MAF map, connects these ideas to the main patterns you will use when designing with MAF.