LangChain for AI Agents practice questions

Worked examples for LangChain for AI Agents

1. Question 1

   A LangChain agent supports a logistics company's customer-service desk. A customer asks, "Where is shipment 48213 right now, and has it cleared customs?" That status lives in the carrier's operational system and changes minute to minute, while the company's indexed document corpus contains only shipping policies and service-level agreements. Which mechanism should the agent use to answer this question, and why?

   1. A. Tool-calling — expose the carrier's shipment-status lookup as a tool the model can invoke with the tracking number, because the answer is live state that must be fetched at request time.Correct answer

      Correct: tool-calling is the mechanism by which a model requests invocation of an external capability with structured arguments, which is what a live, parameterised status lookup requires (LangChain conceptual guide — Tool calling).

   2. B. Retrieval-augmented generation over the indexed shipping-policy and SLA documents, because retrieval is how an agent obtains any information its base model lacks.

      Treats RAG as the universal channel for all unknown information. Retrieval can only surface what is already in the indexed corpus; the corpus holds policies, not the live per-shipment status, so retrieval would return topically related but useless passages.

   3. C. Retrieval-augmented generation, because the retrieval step also performs the lookup against the carrier's operational system on the agent's behalf.

      Confuses RAG with tool-calling by assuming retrieval invokes external capabilities. Retrieval fetches documents from an index to ground an answer; it does not call an operational system or take an action against it.

   4. D. Neither mechanism is needed — supplying the tracking number in the prompt lets the model reason out the shipment's current location from its training data.

      Assumes a language model can infer live external state. Training data is static and contains no record of this shipment, so the model would fabricate a plausible-sounding location.

   Explanation

   Tool-calling is the mechanism for having a model request an external capability with structured arguments — querying a system, running a computation, or performing an action — and a per-shipment status that changes minute to minute can only be obtained by invoking the carrier system at request time. Retrieval-augmented generation is for grounding an answer in existing documents, so pointing it at a policy corpus that never contained shipment status returns irrelevant passages, and retrieval does not invoke operational systems the way a tool does. Relying on the model's own knowledge is worse still, because live external state is absent from training data and the model would invent it. (LangChain conceptual guide — Tool calling.)

2. Question 2

   A team deploys a LangChain agent with three tools. During a support request, the agent calls two different tools in sequence and then returns a written answer to the user, at which point the executor stops running. What **caused the execution loop to terminate** in this run?

   1. A. The executor stops automatically once every tool registered with the agent has been invoked at least once

      Misconception that termination is tied to exhausting the tool list. Tools are options the model may choose from, not a checklist; an agent can finish having used one tool, all of them, or none.

   2. B. The executor runs a fixed number of developer-configured stages and halts when the last stage completes

      Confuses an agent with a fixed pipeline or chain. In an agentic loop the number of iterations is decided by the model at runtime from what it observes, not pre-declared as a stage list.

   3. C. The tools signalled completion by returning a terminal status that the executor treats as the stop condition

      Misconception that tools control termination. A tool returns an observation that is fed back to the model; the decision to stop or continue belongs to the model, not to the tool's return value.

   4. D. The model returned a final response instead of requesting another tool call, so the executor had no further action to runCorrect answer

      Correct: the loop is driven by what the model produces each turn. When the model emits a final answer rather than a tool invocation, there is nothing left for the executor to execute or observe, so it exits and returns that answer.

   Explanation

   An agent executor repeats a reason → act → observe cycle: the model proposes an action, the executor runs the corresponding tool, and the result is fed back as an observation for the next round. That cycle ends precisely when the model stops proposing actions and instead produces a final response — control over stopping sits with the model, not with the tool set. Termination is therefore not triggered by having used every available tool, by reaching the end of a pre-declared sequence of stages (that describes a fixed chain, not an agent), nor by a status value returned from a tool, since tool output is only an observation handed back to the model.

3. Question 3

   A team is reviewing how their LangChain agent's execution loop ends. They want to distinguish the loop's **natural termination condition** from the operational safeguards they layer on top of it, because a loop that only ever ends through a safeguard is a symptom of a badly specified agent. Which TWO statements about how and why an agent's execution loop stops are accurate?

   1. A. The loop terminates naturally when the model responds with content only — no tool call — which the executor treats as the agent's final answer.Correct answer

      Correct: the model itself signals completion by returning a plain response instead of requesting another tool, and the executor returns that as the result.

   2. B. The loop stops as soon as every tool registered with the agent has been invoked at least once, since the agent has then exhausted its available capabilities.

      Assumes tool coverage drives termination. The agent may legitimately use one tool repeatedly, or never touch some tools at all; termination depends on the model judging the goal met, not on the tool inventory.

   3. C. Guards such as an iteration cap or a wall-clock limit exist as safety nets against a non-converging loop, and hitting one is an abnormal stop rather than the agent deciding it is finished.Correct answer

      Correct: these limits bound cost and prevent an agent that keeps proposing tool calls from looping forever, but they cut the loop off rather than represent successful completion.

   4. D. The loop stops after a fixed number of reason–act–observe cycles that the developer specifies as part of the agent's definition, one cycle per planned stage.

      Confuses the agent loop with a fixed multi-stage pipeline. The number of iterations is determined at run time by the model's choices; a developer-set maximum is an upper bound, not a planned per-stage count.

   5. E. The loop stops as soon as any tool returns an error, because a failed observation makes the accumulated context unusable for further reasoning.

      Assumes tool errors are fatal to the loop. An error message can be passed back as just another observation, letting the model retry with corrected arguments or switch to a different tool.

   Explanation

   The defining exit condition of an agent's execution loop is the model's own decision: on some iteration it returns a plain response with no tool call, and the executor surfaces that as the final answer. Everything else — maximum iterations, time budgets — is a guard that bounds cost and protects against a model that never converges, so reaching one is an abnormal termination, not success. Termination is not tied to exhausting the tool list (a tool may be reused or never used), not a developer-planned count of stages (the iteration count emerges at run time), and not triggered by a tool error, since an error can be fed back as an observation the model reasons over and recovers from.

4. Question 4

   A team is designing an agent that must call a database tool, then a summarization tool, and finally reply. A developer proposes writing the loop themselves: application code would call the model once to get a plan, then execute every step of that plan in order without consulting the model again. The team lead argues that using an **agent executor** gives a materially different runtime behaviour, and wants the difference stated precisely for the design review. Which statement best describes what the agent executor contributes at run time that the developer's one-shot plan-then-execute approach does not?

   1. A. It returns control to the model after every tool result, so each subsequent action is chosen with the actual outcomes of earlier steps in hand rather than fixed in advance.Correct answer

      Correct. The executor drives an iterative reason → act → observe cycle: the model proposes an action, the executor runs the tool, feeds the observation back, and re-invokes the model, so later decisions are informed by real results instead of a pre-committed plan.

   2. B. It compiles the registered tools into a single optimized call so that the model only has to be invoked once per user request.

      Misconception that the executor's purpose is to collapse tool usage into one model invocation. The executor's defining behaviour is the opposite: it invokes the model repeatedly, once per iteration, because each choice depends on results not yet available.

   3. C. It guarantees that the tools execute in the exact order the developer registered them, enforcing a deterministic pipeline over the tool set.

      Confuses an agent with a fixed chain. Registration order does not constrain execution order; the model selects each tool per iteration, and tools may be skipped, reordered, or reused.

   4. D. It runs all registered tools first to gather context, then invokes the model a single time to reason over the pooled results.

      Inverts the act/reason ordering. Tools do not run before reasoning and are not all run indiscriminately; a tool executes only after the model has proposed that specific call on that iteration.

   Explanation

   The distinguishing property of an agent executor is that control alternates between the model and tool execution: the model reasons and proposes an action, the executor performs it, and the resulting observation is returned to the model before the next decision is made. That feedback edge is what makes the trajectory adaptive rather than pre-committed, so a plan produced before any tool has run is not equivalent. Collapsing everything into a single model call removes the feedback entirely; treating registration order as an execution pipeline describes a fixed chain, not an agent; and running every tool up front reverses the reason-then-act ordering that each iteration follows.

5. Question 5

   A team has already built a LangChain **chain** for document processing: every request runs the same developer-defined sequence of steps — clean the text, summarize it, then format the result. They now want to build an **agent** instead, so that the application can consult a search tool, a calculator, or neither, depending on what the user asks, without the team hard-coding that decision in advance. Which statement best describes the conceptual difference between a chain and an agent in LangChain?

   1. A. Chains are what make an application autonomous — the more links a chain contains, the more freedom the chat model has to choose its own steps, so an agent is simply a very long chain.

      Misassigns autonomy to the chain. A chain is a composition of steps in an order the developer fixes; adding more steps lengthens the fixed sequence but never transfers step-selection to the model.

   2. B. An agent differs from a chain only by having memory attached; in both, which tool runs at each step is still decided by the developer before the run begins.

      Conflates memory with control flow. Memory carries context across steps and turns, but what makes something an agent is that the model chooses the next action at runtime — a chain can have memory and still be a fixed sequence.

   3. C. A chain composes steps in an order the developer defines before the run, whereas in an agent the chat model decides at runtime which tool to invoke next and when to stop, so control flow is model-driven.Correct answer

      Correct: chains are compositions of steps wired in a predetermined order, while an agent uses the model as the reasoning engine that selects actions and terminates the loop (LangChain Conceptual guide — Chains, Agents/tool calling).

   4. D. An agent's autonomy comes from the tools themselves: each tool inspects the user's request and decides whether to fire, so the chat model plays no part in selecting tools.

      Misconception that tools are self-triggering. Tools are passive callable actions described to the model; the model requests a tool call, and the surrounding runtime executes it — tools do not choose themselves.

   Explanation

   In LangChain, a chain is a composition of steps whose order is fixed by the developer when the application is written, so the same path executes on every request. An agent instead puts the chat model in charge of control flow: given the prompt and the descriptions of available tools, the model decides at each turn which tool to request — or that it is finished — so the sequence is determined at runtime rather than in advance. Autonomy is therefore a property of who chooses the next step, not of chain length, and it is not conferred by attaching memory, which only carries context. Tools remain passive callable actions that never decide on their own to run; the model requests them and the runtime executes them.

6. Question 6

   A developer builds a LangChain agent and gives it a web-search tool and a calculator tool. When the agent runs, its runtime repeatedly hands the model the conversation so far, runs whatever tool the model asks for, and appends the tool's result before invoking the model again. The developer never writes code that says which tool runs second, or third. Which statement best describes how the **runtime's control flow** determines the number and order of tool calls?

   1. A. The runtime runs every registered tool once, in the order the tools were listed, and then asks the model to summarize all of the collected results.

      Misconception that tools are executed eagerly and exhaustively before reasoning. The model chooses which tool (if any) to invoke on each iteration based on the observations so far, and a tool may be called many times or never.

   2. B. Each iteration the model reasons over the accumulated messages and either requests a tool call or produces a final answer; the runtime runs any requested tool, appends the observation, and repeats until the model answers or a configured stopping limit is hit.Correct answer

      This is the reason → act → observe loop: the model's next action is conditioned on prior observations, and the loop terminates when the model emits a final answer with no tool request (or a guard such as a maximum-iteration or time limit fires).

   3. C. The runtime performs a single forward pass: the model emits one plan containing all tool calls up front, the tools are executed, and the raw results are returned to the user without a further model step.

      Misconception that an agent is a one-shot pipeline. The defining feature of an agent loop is that tool results are fed back into the model, which reasons again and may issue further calls before producing a final answer.

   4. D. The number of iterations is fixed by the developer as an explicit sequence of stages, and the runtime advances through those stages regardless of what the tools return.

      Confuses an agent with a fixed chain or workflow. In a chain the developer hard-codes the steps; in an agent the model decides the control flow at runtime, so the iteration count varies with the observations.

   Explanation

   LangChain's conceptual guide describes an agent as a system in which a language model chooses the sequence of actions to take, in contrast to a chain where the sequence is hard-coded by the developer. The runtime therefore drives an iterative reason → act → observe cycle: the model inspects the accumulated messages, optionally requests a tool call, the runtime runs that tool and appends its output as an observation, and the model is invoked again with the enlarged context. The loop ends when the model responds without requesting a tool — that response is the final answer — or when a safety guard such as a maximum number of iterations stops it. Descriptions that run all tools eagerly, that treat the agent as a single forward pass with no feedback of results, or that fix the stage sequence in advance all remove exactly the model-driven, observation-conditioned control flow that makes it an agent rather than a chain.

7. Question 7

   A developer new to LangChain asks why an agent needs a memory component at all, pointing out that during a chat the assistant clearly "remembers" what was said two turns ago. A reviewer explains that this apparent recollection is a property of how the application invokes the **chat model**, not of the model itself, and that understanding this is the reason memory has to be designed rather than assumed. Which statement correctly describes the chat model's role with respect to remembering earlier turns?

   1. A. The chat model maintains an internal session per user once a conversation begins, and the memory component simply names that session so the right one is resumed.

      Assumes the model holds server-side conversation state that the application merely points at. Continuity comes from the application resending the messages, not from a session the model keeps.

   2. B. Each answered turn incrementally updates the model's weights, so the model gradually learns the user and memory only speeds up that learning.

      Confuses inference with training. Answering a prompt does not modify model weights; nothing about a conversation changes the model, which is precisely why context must be supplied externally.

   3. C. The chat model is stateless between invocations — it answers only from the messages supplied in that call — so continuity exists because the application re-supplies prior turns, and any stored facts, as part of every request.Correct answer

      Correct. A chat model takes a list of messages as input and returns a message; it carries nothing forward on its own, so recollection is produced by the surrounding application assembling history and retrieved state into each invocation.

   4. D. Remembering earlier turns is a capability of the model provider that is switched on per conversation, so memory design only matters for models whose provider lacks it.

      Treats conversational continuity as a provider feature toggle rather than an application concern, which misplaces responsibility for assembling and managing what the model sees on each call.

   Explanation

   A chat model takes a sequence of messages as input and returns a message as output; it retains nothing between calls, so what looks like memory is the application re-assembling prior turns — and any facts fetched from a persistent store — into the messages sent with each new request. That statelessness is exactly why memory is a design responsibility: the model keeps no per-user session to resume, answering a turn does not alter the model's weights the way training would, and conversational continuity is not a provider setting to enable but a consequence of what the calling application chooses to include in the context of every invocation.

8. Question 8

   An insurance company's LangChain agent supports claims adjusters. An adjuster sends the request: **"Approve claim 8842 if our handling rules permit it."** Whether approval is permitted for this claim depends on eligibility rules written in the company's indexed claims-handling manual, which the base model has never seen. Recording the approval itself changes the claim's state in the claims system. Which statement describes the correct division of work between retrieval and tool-calling for this single request?

   1. A. Retrieval supplies the manual's eligibility rules as grounding so the agent can determine whether approval is permitted, and only if it is does a tool call carry out the state change in the claims system.Correct answer

      Correct. Retrieval-augmented generation grounds the reasoning in documents the model never saw, and tool-calling is the mechanism that enacts the resulting decision against an external system — the retrieved text informs the choice but cannot execute it (LangChain conceptual guide, retrieval and tool-calling).

   2. B. One retrieval over the manual is sufficient: once the agent has retrieved the passage stating that a claim of this kind may be approved, the approval has effectively been made.

      Misconception that retrieved text describing an action performs that action. Retrieval only puts words about approval into the prompt; the claim's state in the claims system is unchanged until a capability is actually invoked.

   3. C. Tool-calling alone is sufficient, because invoking the approval capability inherently supplies the eligibility rules the decision requires.

      Misconception that tool-calling removes the need for grounding. A capability that records an approval carries out the write; it does not tell the model what the manual says about whether approval was warranted in the first place.

   4. D. The agent should record the approval first and then retrieve the manual, so that the retrieved passage can be attached to the case file as justification for the decision already taken.

      Treats grounding as post-hoc rationalisation of an already-executed side effect. Retrieval exists to inform the decision; running it after a state-changing tool call means the rules never constrained whether the action should have happened at all.

   Explanation

   This request contains two conceptually different needs in a dependent order. Deciding whether approval is allowed is a knowledge question answerable only from the indexed manual, which is exactly what retrieval-augmented generation is for: it grounds the model's reasoning in documents outside its training data. Recording the approval is a change to an external system, which only a tool call can perform, since retrieval reads an index and never writes to a system of record. Treating the retrieved passage as if it enacted the approval, expecting the approval capability to supply the rules, or acting first and retrieving afterwards each collapse one of those two needs into the wrong mechanism.