Visual walkthrough — Agentic frameworks (LangChain, LlamaIndex)

The parent note told you what the agent loop is. This page builds it from nothing — starting from one stubborn fact about language models — and draws every single step. By the end you will be able to redraw the whole machine on a napkin.

We will keep coming back to that box. Watch how much we get from it.

Step 1 — The box that can only talk

WHAT. We draw the language model as a single box. On the left goes a prompt (the text we give it). On the right comes completion (the text it gives back).

WHY. Before we can give a model "tools" we must be honest about what it physically does. If we forget that it only emits text, we will invent magic that does not exist. Every later step is a workaround for this box's blindness.

PICTURE. The blue box is the model. The orange arrow in is our prompt; the green arrow out is its text reply. Notice there is no wire to the calculator or the web — it is sealed.

Step 2 — Teach the box to ask for a tool

WHAT. We agree on a fixed text shape the model will write when it wants a tool. For example:

$\underset{\text{keyword we scan for}}{\underbrace{\text{Action:}}}\underset{\text{which tool}}{\underbrace{\text{Calculator}}}\underset{\text{keyword}}{\underbrace{\text{Action Input:}}}\underset{\text{argument string}}{\underbrace{\text{14000 * 2}}}$

WHY. The box cannot press a button, but it can write the sentence "I would like to press the calculator button with 14000 * 2". If we agree in advance on the exact wording, our own code — running outside the box — can watch for that wording and press the button for it. This is the whole trick: the model requests, our code acts.

PICTURE. The model outputs ordinary text (green), but part of that text follows our agreed template (highlighted). It is a message in a bottle, not an action.

Cloze check:

Step 3 — The parser: turning a wish into an instruction

WHAT. We write a small function, the parser, that reads the model's text and pulls out two things: the tool name and the argument.

$\text{parse}(\text{text})\to \{\begin{array}{ll}\text{AgentAction}(\text{tool},\text{input})& \text{if it contains }\text{Action:}\\ \text{AgentFinish}(\text{answer})& \text{if it contains }\text{Final Answer:}\end{array}$

Term by term:

• $\text{text}$ — the raw completion from Step 2.
• $\text{AgentAction}(\text{tool},\text{input})$ — a clean little packet: "call tool with input."
• $\text{AgentFinish}(\text{answer})$ — the packet that means "I'm done, here is the reply."

WHY. The model wrote free-form prose. Our tool functions need tidy arguments. The parser is the translator between messy text and clean function calls. Without it, we would be doing string surgery everywhere.

PICTURE. A funnel: messy green text goes in the top; two clean labelled boxes fall out the bottom — one orange (AgentAction), one green (AgentFinish). A gray "??" branch shows the third case.

Step 4 — The tool registry runs it and gets a result

WHAT. We keep a lookup table — the registry — mapping each tool name to a real Python function. Given an AgentAction, we look up the function and run it.

$\text{execute}(\text{tool},\text{input})=\text{registry}[\text{tool}](\text{input})\to \text{observation}$

Term by term:

• $\text{registry}[\text{tool}]$ — pick the real function whose name matches.
• $(\text{input})$ — feed it the argument the parser extracted.
• $\text{observation}$ — the value the function returns (a number, a Wikipedia snippet, an error message).

WHY. This is the only place where anything real happens — a number gets multiplied, a page gets fetched. The model is still sealed in its box; our code reached out and touched the world on its behalf.

PICTURE. The AgentAction packet arrives at a switchboard. It routes to the matching function (calculator, Wikipedia, ...), which returns an Observation (green). Note an error is also a valid observation.

Step 5 — Feed the observation back and loop

WHAT. We glue the observation onto the growing conversation and call the box again:

${\text{prompt}}_{k+1}={\text{prompt}}_k+\text{Observation: }+\text{observation}$

Term by term:

• ${\text{prompt}}_k$ — everything so far: the question, the model's action, and now...
• $\text{Observation: }+\text{observation}$ — the freshly computed result, written as text the model can read.
• ${\text{prompt}}_{k+1}$ — the new, longer prompt for the next turn.

WHY. Remember the box has no memory (Step 1). The only way it learns "the population is 14 million" is if we write that fact into its next prompt. The prompt is its entire world; we keep re-showing it a bigger and bigger transcript.

PICTURE. A spiral: prompt → LM → action → tool → observation → appended → back to a fatter prompt. Each loop the transcript grows by one Action/Observation pair.

Reveal:

Step 6 — When does it stop? (and when it shouldn't run forever)

WHAT. The loop ends the moment the parser returns an AgentFinish — i.e. the model wrote Final Answer:. We return that answer and exit.

WHY. Without a stop rule the spiral in Step 5 never ends. Two dangers, both must be handled:

1. Normal stop — model is satisfied and writes Final Answer:.
2. Runaway stop — the model loops forever (keeps calling tools, never finishing) or ping-pongs between two tools. We add a hard cap: max iterations $N$. After $N$ turns we force-return whatever we have.

PICTURE. A flow with two exits: the green "Final Answer" door, and a red "iteration limit reached" trapdoor. Both leave the loop; only the green one is a happy ending.

$\text{turns used}\le N\text{always, by construction.}$

Here $N$ is the safety cap and "turns used" counts each LM call — the inequality is what guarantees termination even for a stubborn model.

The one-picture summary

Everything above is one loop wrapped around one sealed box. Here it is on a single canvas: the blue box that can only talk, the parser funnel, the tool switchboard, the observation feedback arrow, and the two exit doors (green finish, red cap).

Connections

• Built directly on ReAct — this page is ReAct turned into code.
• The Action: format is a hand-rolled version of tool/function-calling APIs.
• A Wikipedia or document tool often wraps RAG over a vector database.
• Prefer the Hindi walk-through? Yeh note Hinglish mein padho →