Agents & Tools

What a LangChain "agent" is#

A regular chain follows a fixed, predetermined sequence of steps every time: prompt → model → parser, always in that order, regardless of what the input turns out to be. An agent is different: it's an LLM given a set of available tools and let decide, at runtime, which tool (if any) to use, in what order, and when it has enough information to stop and give a final answer — the sequence of steps isn't fixed in advance; it's decided dynamically based on the specific request and what happens at each step.

A conceptual example#

Suppose an agent has two tools available: a calculator tool (evaluates a math expression) and a search tool (looks up current information from the web). Given the question "What's the population of Japan divided by the population of California?", the agent's reasoning might look like:

Question: What's the population of Japan divided by the population of California?

Thought: I need Japan's current population first. I don't know this reliably —
         I should search for it.
Action: search("current population of Japan")
Observation: "Japan's population is approximately 124 million."

Thought: Now I need California's current population.
Action: search("current population of California")
Observation: "California's population is approximately 39 million."

Thought: Now I can divide these two numbers.
Action: calculator("124000000 / 39000000")
Observation: "3.18"

Thought: I now have enough information to answer.
Final Answer: Japan's population is roughly 3.18 times that of California.

Given a different question — "What is 847 times 213?" — the same agent would skip straight to the calculator tool and never touch search at all, because that's what the specific question actually calls for. Nothing about which tools to use, or in what order, was hard-coded; the model decided both, per request, based on what it read and what each tool returned.

The reasoning loop: think → act → observe#

This pattern — often called ReAct (Reason + Act) — repeats a three-part loop until the model decides it has enough information to answer:

1. Think — the model reasons (often out loud, in intermediate text) about what it still needs and which available tool could get it.
2. Act — the model outputs a structured request to call a specific tool with specific arguments (the same underlying mechanism as the function/tool calling covered in this site's Prompt Engineering tutorials).
3. Observe — the actual tool is executed by the application (not the model), and its real result is fed back into the model's context.

This loop repeats — think, act, observe, think, act, observe — until the model's "think" step concludes it has what it needs and produces a final answer instead of another tool call. This is what lets an agent handle open-ended, multi-step questions that a single fixed chain can't: the number and order of steps genuinely depends on the specific question and the intermediate results, not a predetermined script.

Common mistakes#

• Reaching for an agent when a fixed chain would do — if the sequence of steps is always the same regardless of input, that's a chain, and an agent adds unpredictability, latency, and cost for no real benefit.
• Giving an agent too many overlapping or vaguely-described tools — the model's tool choice becomes unreliable when it can't clearly tell which tool actually fits a given request.
• Trusting an agent's tool calls without validating or sandboxing them in application code — since the model decides the calls dynamically, application code (not the model) is still responsible for enforcing what a tool is actually allowed to do (for example, not letting a "database" tool run arbitrary writes).