Introduction to AI Agents practice questions

Worked examples for Introduction to AI Agents

1. Question 1

   An architecture team is deciding how to build two automations. The first is a month-end financial close: it always runs the same five steps in the same order — extract ledger entries, reconcile them, post adjustments, generate the report, archive it — and every run must be reproducible for auditors. The second is inbound bug triage: depending on what the report says, the system may need to search logs, query the deployment history, reproduce the issue, or ask the reporter a clarifying question, and which of those are needed cannot be known before the report is read. Which approach best fits these two tasks, and why? Which statement correctly applies the distinction between an **agent** and a **rule-based workflow**?

   1. A. Build both as agents, because an agent is strictly more capable than a rule-based workflow and can always reproduce a fixed sequence when instructed to.

      Treats an agent as a universal upgrade. Model-decided control flow buys flexibility at the cost of determinism, so for a task whose steps are fully known and must be auditable and reproducible, handing step selection to a model adds variability and expense with no benefit.

   2. B. Build the month-end close as a rule-based workflow and the bug triage as an agent, because an agent earns its cost only when the sequence of steps must be decided at runtime rather than fixed at design time.Correct answer

      Correct. An agent's defining property is that a model decides which tool to call next and when to stop, given a goal; a workflow encodes a path the developer already knows. The close has a known fixed path, so a workflow is the right fit; triage's path depends on what is discovered, so an agent is.

   3. C. Build both as rule-based workflows, because a language model in the control path can never be relied on to select a correct next step.

      Over-rejects agents entirely. The triage task's step sequence depends on information discovered at runtime, which is exactly the case a fixed if/then pipeline cannot express; an LLM choosing tools within a guarded, bounded loop is the standard answer to it.

   4. D. Decide by expected volume and latency: use a rule-based workflow for whichever task runs more often, and an agent for the lower-volume task, since agents are slower per invocation.

      Substitutes a throughput heuristic for the real criterion. Latency and cost are real operational concerns, but they do not determine which design is applicable — whether the control flow can be known in advance does.

   Explanation

   The line between an agent and a rule-based workflow is where control flow is decided: a workflow encodes a path the developer already knows, while an agent uses a model to choose the next tool call from a goal and to decide when the goal is met. A task with a fixed, fully known, audit-sensitive sequence therefore belongs in a workflow, and a task whose required steps only become apparent as information arrives belongs to an agent. Treating an agent as a strict upgrade ignores the determinism a workflow gives up; refusing agents outright leaves no way to express runtime-dependent branching; and choosing by invocation volume or latency answers an operational question rather than the design one (LangChain — Agents, https://python.langchain.com/docs/concepts/agents/).

2. Question 2

   A developer hand-writes the control loop for a tool-calling agent. On each iteration the loop sends messages to the language model, and if the model requests a tool it executes that tool. Because of a bug, the loop discards the tool's return value and sends the model only the original user message again on the next iteration. In testing, the agent requests the same `lookup_order` tool with the same arguments on every iteration and never produces a final answer; the run only stops when the loop's maximum-step cap is reached. Which statement best explains the role of the **observation step** in an agent's control loop and what is going wrong here?

   1. A. No change is needed to the messages, because the model retains the results of tools it called earlier and will use them on the next iteration automatically.

      Assumes the model has persistent memory across calls. Each model invocation is conditioned only on the messages it is sent; anything a prior tool returned exists for the model only if the loop puts it back into that context.

   2. B. Tool results affect only how the final answer is worded; the repetition is a sampling artifact and is fixed by raising the model's temperature so it varies its choice of tool.

      Misattributes a control-loop defect to decoding randomness. Raising temperature might make the model pick a different tool by chance, but the underlying problem is that no new information ever enters the context, so no setting makes the loop progress toward the goal.

   3. C. The tool implementation should be changed to return the name of the next tool to invoke, so that execution results drive which step the loop runs next.

      Swaps the component roles by making tools the decider. Tools are the actions an agent can take; the model is the reasoner that selects the next action. Hard-coding the next step inside a tool turns the system back into a fixed pipeline.

   4. D. Each tool's result must be appended to the conversation the model sees, so the next reasoning step is conditioned on new information; with the observation dropped, the model receives identical input every iteration and can neither progress nor reach its stopping condition.Correct answer

      Correct. The agent loop is reason → act → observe: the executed tool's output is fed back into the model's context, and the model then either calls another tool or returns a final answer. Discarding the observation makes every iteration's input identical, so the same call repeats until the step cap fires.

   Explanation

   An agent's control loop repeatedly calls the model, executes any tool the model requests, and appends that tool's result to the messages before calling the model again; the appended result is the observation that lets the next reasoning step build on what was learned. Dropping it leaves the model with byte-identical input each pass, so it reproduces the same tool request and never reaches the state where it can emit a final answer — the maximum-step cap is the guardrail catching a loop that cannot terminate on its own. The model does not carry state between invocations, so nothing is retained implicitly; the failure is structural rather than a sampling effect that temperature could address; and having a tool name the next tool would move the decision out of the reasoner and back into hard-coded control flow (LangChain — Agents, https://python.langchain.com/docs/concepts/agents/).

3. Question 3

   A team has three systems. System 1 is a customer-support chatbot that answers questions from a large prompt and conversation history but never calls an external system. System 2 is an order-processing pipeline whose developers wrote an explicit if/then sequence: validate the order, then charge the card, then email a receipt — always in that order. System 3 receives the goal "resolve this refund request", and on each turn a language model decides whether to look up the order, issue the refund, or reply to the customer, then feeds the result of that choice back into its next decision. Which system is an **AI agent**, and what makes it one?

   1. A. System 3, because a language model chooses which tool to call next and uses each result to inform its following decisionCorrect answer

      Correct. An agent uses an LLM to decide the control flow of an application: the model selects actions (tools), observes their results, and repeats until the goal is met, rather than following a path the developer fixed in advance.

   2. B. System 1, because an agent is a conversational model given a sufficiently large prompt and long conversation history

      Misconception that an agent is just a chatbot with a bigger prompt. Prompt size and memory do not create agency: this system converses but never takes an action on the outside world through a tool, so nothing it 'decides' has any effect beyond text.

   3. C. System 2, because the developers specified every step in advance, which is what agent autonomy means

      Misconception that a fixed rule-based workflow is an agent, and that autonomy means the developer hard-codes each step. A predetermined if/then path is the opposite of autonomy — the control flow is fixed at design time, and the model chooses nothing.

   4. D. All three, because any application built on a large language model is by definition an agent

      Misconception that 'uses an LLM' equals 'is an agent'. The distinguishing property is who decides the next step — a plain chatbot and a hard-coded pipeline both leave control flow outside the model.

   Explanation

   An agent is defined by the LLM deciding the control flow of the application: it reasons about a goal, selects which tool to invoke, observes the result, and loops until the goal is satisfied. A chatbot that only converses has no tool-based actions to choose among, and a hard-coded if/then pipeline has its sequence fixed by developers rather than chosen at run time — neither exhibits the autonomy that defines an agent. Merely being built on a language model is not sufficient, since the deciding factor is whether the model, not the code, determines the next step.

4. Question 4

   A developer builds an agent loop by hand. On every iteration the orchestration code sends the model a fresh request containing only two things: the user's original goal, and the result of the single most recent tool call. Everything earlier in the run — the previous thoughts, the previous tool calls, and their results — is discarded to keep each request small. In testing, the agent behaves strangely: it calls the `search_tickets` tool, gets useful rows back, then on a later iteration calls `search_tickets` again with nearly the same arguments, and can loop this way until the step cap fires. The tools themselves are stateless HTTP endpoints that work correctly when called directly. Which statement best explains the repetition and identifies where the run's **working state** must live?

   1. A. Each model call is stateless, so the accumulating trace of prior tool calls and their results is exactly what the loop must feed back as context; discarding it leaves the model with no evidence that a step was already taken, so it plans that same step again.Correct answer

      Correct. In a tool-calling agent the orchestration loop appends each action and its observation to the message history and re-sends the whole trace, which is what lets the next reasoning step build on earlier ones instead of restarting from the bare goal.

   2. B. The language model retains an internal memory of its earlier calls within the same run, so sending only the newest observation is sufficient; the repeated calls indicate a defect in the tool rather than in the orchestration loop.

      Assumes the model is stateful across invocations. Each model call is independent — the model has no recollection of prior calls beyond what the request itself contains — so trimming the history genuinely removes the agent's knowledge of what it already did.

   3. C. Tools are responsible for tracking which actions the agent has already performed, so each tool should record its own invocation history and refuse or short-circuit duplicate requests from the same run.

      Swaps the component roles: tools are the actions an agent can take on the outside world, not the place the agent's reasoning state is kept. Deduplicating inside a tool would suppress a symptom while the model still reasons without evidence of its prior steps.

   4. D. The orchestration loop's only responsibility is executing whatever tool the model requests; a run's conversation state belongs in an external long-term memory store, so nothing in the loop needs to change.

      Conflates a run's working context with long-term memory across sessions. Even with an external store, the current run's thoughts and observations must be assembled into the request the loop sends — carrying that trace forward is part of the loop's job.

   Explanation

   A tool-calling agent works by having the model choose an action, having the orchestration loop execute it, and then appending the observation to the message history before calling the model again — the growing trace of actions and results is the run's working state, and it is passed back in on every iteration because the model itself holds nothing between calls (LangChain, Agents — conceptual). Trimming the history to just the goal and the latest observation therefore erases the evidence that a step already succeeded, so the model reasons its way to the same step again. Blaming the tool assumes the model remembers earlier calls on its own; pushing invocation history into the tools misplaces state in the action layer rather than the reasoning context; and treating this as a job for an external long-term memory store confuses persistence across sessions with the context the loop must assemble for the current run.

5. Question 5

   An engineer is building a research assistant that must look up facts with a search tool before answering. They are deciding between plain **Chain-of-Thought** prompting and the **ReAct** pattern, and they also need to decide what stops the agent's loop. Which TWO statements are correct?

   1. A. ReAct interleaves reasoning steps with actions, feeding each tool result back as an observation that informs the next reasoning step.Correct answer

      Correct. ReAct's defining property is the reason → act → observe cycle: the model thinks, calls a tool, reads the returned observation, and reasons again with that new evidence in context.

   2. B. An autonomous agent loop still needs an explicit termination condition — such as a step or budget limit alongside the model's own stop signal — because the model may otherwise loop or repeat actions indefinitely.Correct answer

      Correct. Autonomy is bounded, not unconstrained: agent runtimes pair the model's decision to stop with hard limits like a maximum number of iterations so a non-converging loop cannot run away.

   3. C. Chain-of-Thought prompting lets the model call external tools between its intermediate reasoning steps, which is why it grounds answers in live data.

      Confuses Chain-of-Thought with ReAct. Chain-of-Thought produces intermediate reasoning as text only; with no action step it cannot reach external data, so its answers stay bounded by what the model already knows.

   4. D. ReAct improves on Chain-of-Thought by removing the reasoning steps entirely, so the model emits only a sequence of tool calls.

      The 'ReAct is pure tool calling' misconception. ReAct adds acting to reasoning rather than replacing it — the reasoning trace is what decides which tool to call next and how to interpret each observation.

   5. E. Adding guardrails such as tool allow-lists or human approval on sensitive actions means the system is no longer an agent, since agents are defined by unconstrained action.

      Equates autonomy with the absence of constraints. Agency is about the model deciding control flow; production agents routinely run under guardrails like restricted tool sets and human-in-the-loop approval and remain agents.

   Explanation

   Chain-of-Thought is reasoning expressed as intermediate text and involves no external actions, whereas ReAct interleaves that reasoning with tool calls and feeds each result back as an observation for the next reasoning turn — which is what lets an agent ground its answer in retrieved data. Because such a loop runs until the model decides it is finished, a well-built agent also enforces an independent stop condition such as a maximum iteration count or budget, so a model that fails to converge cannot spin forever. Claiming that plain Chain-of-Thought calls tools confuses the two patterns, claiming ReAct discards reasoning inverts what the pattern adds, and treating guardrails as disqualifying mistakes autonomy over control flow for freedom from all constraints.

6. Question 6

   A team builds a document-processing system. The application sends a user's goal to an LLM, which decides on each turn whether to call one of several registered tools (a search API, a PDF extractor, a database writer). The tool's result is fed back to the model, which then decides whether to call another tool or return a final answer. A separate loop in the application code keeps executing tool calls and passing results back until the model stops requesting tools. In this architecture, which statement correctly describes the roles of the **LLM**, the **tools**, and the **orchestration loop**?

   1. A. The LLM is the reasoner that selects the next action, the tools carry out actions against external systems, and the orchestration loop repeatedly executes the chosen tools and returns their results to the model until it stops requesting them.Correct answer

      Matches the standard agent decomposition: an LLM reasons and chooses tool calls, tools are the callable functions that act on the world, and the runtime loop executes those calls and feeds observations back until the model emits a final answer with no further tool calls.

   2. B. The orchestration loop is the reasoner that decides which tool is appropriate for each step, and the LLM's role is limited to formatting the final answer in natural language.

      Swaps the reasoner and control-loop roles. The loop is mechanical — it executes whatever the model asked for and passes results back; it contains no decision logic about which tool fits the goal. A system where the loop picks the steps is a rule-based workflow, not an agent.

   3. C. The tools determine the sequence of steps by declaring which tool must run next, while the LLM simply validates each tool's output before the loop continues.

      Misconception that tools drive control flow. Tools are passive capabilities: they are described to the model, invoked with arguments the model supplies, and return an observation. They do not choose the next step — that decision belongs to the model.

   4. D. The LLM plans the complete ordered sequence of tool calls before any tool runs, and the loop is only responsible for executing that fixed plan without sending results back to the model.

      Describes a static plan-then-execute pipeline, not the loop described in the stem. The defining feature here is that each tool result is returned to the model so its next decision is conditioned on what it just observed; a fixed pre-computed plan removes that feedback.

   Explanation

   An agent is a system that uses an LLM to decide the control flow of an application: the model is the reasoning component that chooses which tool to call with which arguments, tools are the functions that let it act on external systems, and the surrounding loop is plumbing that executes each requested call, appends the observation to the conversation, and re-invokes the model until it responds without a tool call. Putting the decision logic in the loop or in the tools describes a hard-coded workflow instead, since the path would be fixed by the developer rather than chosen by the model. Reducing the model to a formatter or a validator likewise strips out the autonomy that distinguishes an agent. Pre-computing a fixed sequence and never returning results to the model removes the observe-then-decide feedback that the described system depends on.

7. Question 7

   An architect is documenting an internal agent that is built from three parts: a large language model, a registry of callable tools (a database query tool and an email tool), and an **orchestration loop** that the application runs on every request. A reviewer asks the architect to state clearly which part plays which role. Which statement correctly maps the three parts to their roles in the agent?

   1. A. The language model is the reasoner that decides what to do next and which tool to call; the tools carry out the actions against external systems; the orchestration loop repeatedly feeds tool results back to the model until a stop condition is reached.Correct answer

      This is the standard decomposition: the model reasons and selects actions, tools execute them, and the loop repeats model call → tool execution → observation until the model returns a final answer or another termination condition fires.

   2. B. The orchestration loop is the reasoner: it analyses the goal and selects which tool to invoke at each step, while the language model is used only to phrase the final answer for the user.

      Swaps the roles of the model and the control loop. The loop is plumbing — it re-invokes the model and feeds results back — but the decision about which tool to call is made by the model, not by the loop.

   3. C. The language model performs the external actions itself, such as writing to the database and sending the email; the tools are just prompt templates and the orchestration loop only writes log entries.

      Treats tools as prompt text rather than executable functions. A language model produces text, including a request to call a tool; the actual side effect on an external system is carried out by the tool code the application runs.

   4. D. The tools decide which step comes next by scoring themselves against the user's goal, and the language model simply executes whichever tool wins that ranking.

      Gives tools the decision-making role. Tools are passive capabilities with descriptions and parameters; they are selected by the model's reasoning, they do not select themselves, and the model does not execute them.

   Explanation

   An agent is described as a system that uses a language model to decide the control flow of an application: the model is the reasoner that chooses actions, tools are the functions that let it act on external systems, and the loop repeatedly calls the model with the accumulated tool results until the model produces a final answer or a stop condition halts it. Casting the loop as the reasoner reverses that relationship, since the loop contributes no decisions of its own. Calling tools mere prompt templates ignores that tool calls are executed as real code with real side effects. Having tools rank and select themselves removes the model from the decision it is precisely there to make.

8. Question 8

   An engineer is reading the execution trace of a tool-calling agent built from a language model and two tools, `get_weather` and `send_alert`. On the first turn the model does not produce a final answer to the user. Instead its output is a structured request naming the tool `get_weather` together with the arguments `{"city": "Austin"}`. A moment later the trace shows the weather data arriving back into the model's message history, and the model then continues. Which statement correctly describes how **tool use** works in this agent?

   1. A. The model executes the tool's code internally as part of generating its response, so the surrounding runtime only relays the model's finished text to the user.

      Misconception that the LLM itself runs tool code. A language model only generates text or structured output; it has no execution environment, so an external runtime must actually call `get_weather` and hand the result back.

   2. B. The tools themselves determine which tool runs next by inspecting the previous tool's output; the model's only job is to format the final answer once the tools have finished.

      Swaps the component roles. Tools are passive capabilities that perform an action when invoked; deciding which action comes next is the LLM's reasoning job, not a property of the tools.

   3. C. The model chooses a tool and emits a structured call naming the tool and its arguments; the surrounding runtime executes that tool and returns the result to the model as an observation it can reason over on the next turn.Correct answer

      Correct. In a tool-calling agent the model is the decider — it selects the tool and arguments — while the framework performs the actual invocation and appends the result to the model's context for the following reasoning step (LangChain, Agents conceptual guide).

   4. D. Because both tools were bound to the model, every bound tool is invoked automatically on each turn and the model then picks whichever result it likes best.

      Confuses making tools available with invoking them. Binding tools only tells the model what it may call and how; on any given turn the model selects zero, one, or some subset of tools rather than all of them firing.

   Explanation

   Tool use in an agent is a two-party arrangement: the language model reasons about the goal and emits a structured tool call (tool name plus arguments), and the orchestration layer around it performs the invocation and feeds the result back as an observation the model can use in its next reasoning step. That is why the model has no execution environment of its own, why the tools cannot choose the next step for themselves, and why declaring tools to a model merely makes them selectable rather than automatically invoked on every turn.