Worked examples — Agent architectures and reasoning loops

The parent note gave you the machinery — the reasoning loop, ReAct, memory. This page does one thing: it drags that machinery through every kind of situation it can meet, one worked example per situation, so you never hit a case you haven't seen.

Before any example, we agree on what "the loop" means concretely, in plain words.

That $c_{t+1}=c_t+(\dots )$ is the whole engine. Every example below is just this line, run until a stop condition fires.

---

The scenario matrix

Every reasoning-loop problem lands in one of these cells. The rest of the page fills each cell with a fully worked example.

#	Cell class	What makes it special	Example
A	Happy path, multi-tool	Goal met before budget; each step chains cleanly	Ex 1
B	Zero-tool degenerate	Agent should answer directly, no tool call at all	Ex 2
C	Failure + recovery	A tool errors; self-correction via Reflexion	Ex 3
D	Budget exhausted	Goal not met, $t\ge T_{\max }$ fires; graceful stop	Ex 4
E	Context overflow / limiting	$c_t$ too big; must summarize (limiting behaviour of memory)	Ex 5
F	Infinite loop trap	Same action repeats forever without the budget guard	Ex 6
G	Real-world word problem	Compound question needs decomposition + comparison	Ex 7
H	Exam-style twist	Tool returns ambiguous / conflicting data; agent must reconcile	Ex 8

The pattern that solves every cell is the flowchart below. Read it as one turn of the loop, top to bottom:

Walking the boxes, one by one:

• Observe: build context — the agent gathers the user message, memory, and any prior observations into $c_t$. This is where a turn begins.
• Reason: thought plus action — the model reads $c_t$ and produces a thought (its plain-words plan) and a proposed action $a_t$.
• Which stop check — the diamond is a decision: before doing anything, ask which of the stop conditions applies.
  • goal met → Emit final answer — the action is a final answer; the loop ends happily (cells A, B, C, G, H).
  • budget hit → Stop with best effort — $t\ge T_{\max }$; exit and return the best partial result (cell D).
  • context full → Summarize then continue — $L_t>L_{\max }$; shrink memory, then loop again (cell E).
  • none → Act: run tool — no stop condition fired, so actually run the tool.
• Act: run tool — execute $a_t$, producing an observation $o_t$.
• Update context — glue $(\text{thought},a_t,o_t)$ onto $c_t$ to make $c_{t+1}$, then arrow back up to Observe: the cycle repeats.

Every example below is just a specific walk through these boxes.

---

Cell A — Happy path, multi-tool

Steps.

1. $c_1$ = the user question. Thought: "Two unknowns: author, then their death century. Get author first." Action $a_1=\text{search("author of Hamlet")}$. Why this step? A compound question is split into atomic sub-goals; you cannot search "century of death" until you know whose death.
2. $o_1=$ "William Shakespeare". Update: $c_2=c_1+({\text{thought}}_1,a_1,o_1)$. Why this step? The observation is glued on so step 2's reasoning can see the name.
3. Thought: "Now find Shakespeare's death year." Action $a_2=\text{search("Shakespeare death year")}$. $o_2=$ "1616". Why this step? Chaining: the answer of step 1 becomes the subject of step 2.
4. Thought: "1616 is in the 1600s → the 17th century." Action $a_3=\text{respond(...)}$. Goal met at $t=3$. Why this step? Converting a year to a century is arithmetic the model does internally — no tool needed, so it answers.

Verify (century formula, done once, cleanly): The century of a year $Y$ is $\lfloor \frac{Y-1}{100}\rfloor +1$, where $\lfloor \cdot \rfloor$ means "round down to the nearest whole number". Here $Y=1616$, so $Y-1=1615$ and $\frac{1615}{100}=16.15$, which rounds down to $16$. Then $16+1=17$. So 1616 falls in the 17th century ✓. Steps used $=3\le T_{\max }=6$ ✓. (Forecast answer: 3 steps.)

---

Cell B — Zero-tool degenerate input

Steps.

1. $c_1$ = the question. Thought: "This is simple arithmetic I can do directly; a tool call wastes a step." Action $a_1=\text{respond("144")}$. Goal met at $t=1$. Why this step? The degenerate case of the loop is a single pass: observe → reason → answer. Calling a tool here is a real failure mode (over-tooling) — every tool call costs latency and tokens.

Verify: $12\times 12=144$ ✓. Steps used $=1$; the loop degenerated to a straight line with no observation $o$ ever produced ✓.

---

Cell C — Failure and recovery (Reflexion)

First, the syntax point that this example turns on, stated plainly:

Steps.

1. Thought: "Sum then divide." Action $a_1=\text{execute\_code("sum([4,8,15]) / len[4,8,15]")}$ — note the wrong square brackets on len. Why this step? The mean needs two quantities from the same list — a total and a count — combined in one arithmetic expression. Running it as one code snippet is cleaner than two separate tool calls (which would return two numbers the agent must still divide by hand), and code is exact where the model's own mental arithmetic on longer lists could slip. So "compute in code" beats both "respond directly" and "call two separate tools".
2. $o_1=$ TypeError: 'builtin_function_or_method' object is not subscriptable — triggered by the len[...] square-bracket mistake explained above. Why this observation matters? The error text is the learning signal — it is glued into $c_2$.
3. Reflexion thought: "len[...] uses square brackets — that's indexing, not a call. I must call it as len([...]) with round brackets." Action $a_2=\text{execute\_code("sum([4,8,15]) / len([4,8,15])")}$. Why this step? Self-critique reads $o_1$ from context and edits the plan — this is exactly the trial-and-error idea, but the "reward" is the presence/absence of an error string, not a number.
4. $o_2=$ 9.0. Thought: "Success." Action $a_3=\text{respond("9")}$. Goal met at $t=3$.

Verify: $\frac{4+8+15}{3}=\frac{27}{3}=9$ ✓. Steps $=3$ (one wasted on the error, then recovery) ✓.

---

Cell D — Budget exhausted (goal NOT met)

Steps.

1. Action $a_1=\text{search("grains of sand on Earth")}$. $o_1=$ "Estimated $\approx 7.5\times 10^{18}$; no exact figure exists." Why this step? The agent can't know in advance that the question is unanswerable; the rational first move is to try the most direct search and see what comes back — you diagnose impossibility from evidence, not by assuming it.
2. Thought: "That's an estimate, not exact. Try again." $a_2=\text{search("exact grains of sand count")}$. $o_2=$ "No exact count is possible." Why this step? One "estimate only" result is not proof no exact figure exists — maybe a better query finds one. Re-searching with a sharper phrase ("exact ... count") is a reasonable second attempt before concluding the goal is impossible.
3. Thought: "Still no exact number." $a_3=\text{search(...)}$. $o_3=$ same. Now $t=3=T_{\max }$. Why this step forces a stop? The budget check $t\ge T_{\max }$ fires before step 4. The loop must exit even though the goal is unmet.
4. Forced exit: $a_{\text{final}}=\text{respond("No exact number exists; best estimate }\approx 7.5\times 10^{18}\text{ grains.")}$ Why this phrasing? On a forced exit you owe the user the most useful partial result, not silence. The response states honestly that no exact answer exists and hands over the best estimate gathered in step 1 — turning a failed goal into a helpful reply.

Verify: Loop terminated by budget, not goal. Steps taken $=3=T_{\max }$ ✓. The graceful failure returns the best estimate instead of hanging — this is the correct behaviour of cell D.

---

Cell E — Context overflow (limiting behaviour of memory)

Steps (with a figure).

Figure caption (read this even if the image fails to load): Horizontal axis = step $t$ (equivalently, how many messages have arrived). Vertical axis = context length $L_t$. The dashed plum line is the ceiling $L_{\max }=30$; anything above it does not fit. The burnt-orange line is raw concatenation ($L_t=t$): it rises one unit per step and at $t=31$ pierces the ceiling (orange dot + arrow) — that is the overflow moment. The teal line is the compacted strategy: each time it would cross the ceiling it summarizes 11 messages into 1 and drops back down (teal arrow: "summarize → drop to 20"), then climbs again, staying under the dashed line forever. Takeaway: raw growth is unbounded and breaks the window; compaction keeps $L_t\le L_{\max }$ for all $t$.

1. Growing $c_t$: length $L_t$ = number of messages $=t$. As $t$ climbs, $L_t$ rises linearly (the orange line). Why watch $L_t$? The window imposes a hard ceiling $L_{\max }=30$. The limiting behaviour is: as $t\to \infty$, raw concatenation eventually exceeds $L_{\max }$.
2. At $t=31$, check $L_{31}=31>30=L_{\max }$. Overflow branch fires. Why this branch? Look at the figure: the burnt-orange raw line pierces the ceiling at the orange dot. We cannot append blindly.
3. Summarize: replace messages 1–11 with one summary message. New length $=31-11+1=21$... continue accumulating so that by message 40 the count is $40-11+1=30$. The teal line shows this drop-and-climb. Why summarize instead of discard? Discarding loses retrievable facts; a summary keeps the gist (long-term memory) while freeing token budget — the teal "compacted" line in the figure stays under the ceiling forever.

Verify: After summarizing 11 messages into 1, the 40-message chat holds length $=40-11+1=30\le L_{\max }=30$ ✓. The compacted length is bounded (never exceeds $L_{\max }$), so the loop can run indefinitely ✓.

---

Cell F — Infinite-loop trap

Steps.

1. Thought: "Search for a prime in that range." Action $a_1=\text{search("prime between 8 and 10")}$. $o_1=$ "No results." Why this step? The agent has no reason yet to suspect the question is unsatisfiable — the natural first move is to try the direct search. The trap only reveals itself after this attempt returns nothing and the agent must decide what to do next.
2. Thought: "That found nothing; try the same search again." Action $a_2=\text{search("prime between 8 and 10")}$ — identical action, identical observation $o_2=$ "No results." Why this is the trap? The context grew (a thought and an observation were appended), but it carried no new information: $a_2=a_1$ and $o_2=o_1$. The reasoning input is effectively unchanged, so the next output is the same again. This is the loop's "period-2 repeat" — like $\tan \theta$ repeating every $180°$, the state cycles back onto itself.
3. Thought: "Still nothing; try the same search again." Action $a_3=\text{search("prime between 8 and 10")}$, $o_3=$ "No results". Then $a_4=a_3$, $o_4=o_3$, and so on — the trace never terminates on its own. This is the failure: each turn adds text but the $(\text{action},\text{observation})$ pair never changes, so no stop condition of type "goal met" can ever fire. Why does it never break by itself? "Goal met" needs a final-answer action, but the agent keeps choosing a search; and the answer it wants (a prime in that gap) does not exist, so no observation can ever satisfy it. Only an external guard can end it.
4. Two guards break the trap:
   • Budget: once $t\ge T_{\max }$ (here $6$), the loop is forced to exit (this is cell D's mechanism reused). It then responds honestly: "No prime exists strictly between 8 and 10."
   • Repeat detector: if $a_t=a_{t-1}$ and $o_t=o_{t-1}$, declare "no progress" and stop immediately — cheaper than waiting for the budget.

Verify: The true fact — there is no prime strictly between 8 and 10 (9 = 3² is not prime; 10 = 2·5 is not prime; 8 = 2³ is not prime) — means the goal is unsatisfiable, so only a guard can end the loop ✓. Number of primes strictly between 8 and 10 is $0$ ✓.

---

Cell G — Real-world compound word problem

Steps.

1. Thought: "First resolve which city is Japan's capital." Action $a_1=\text{search("capital of Japan")}$. $o_1=$ "Tokyo." Why this step? Atomic sub-goal 1 — you must resolve the referent ("the capital of Japan") before you can look up its attribute (population). You cannot search "population of the capital of Japan" directly because the tool wants a concrete place name, not a nested description.
2. Thought: "Now get Tokyo's population." Action $a_2=\text{search("population Tokyo metro")}$. $o_2=$ "≈ 37 million." Why this step? The subject "Tokyo" only became known in step 1, so this search depends on the previous observation — classic chaining, exactly like Cell A.
3. Thought: "I also need London's population for the comparison." Action $a_3=\text{search("population Greater London")}$. $o_3=$ "≈ 9 million." Why this step? The comparison needs a second independent number. London's population has no dependence on Tokyo's, so it earns its own dedicated search rather than being folded into the previous call.
4. Thought: "Compare: is $37>3\times 9=27$? Yes." Action $a_4=\text{respond("Yes — Tokyo ( 37M) exceeds 3× London ( 27M).")}$ Goal met at $t=4$. Why internal, not a tool? The comparison $37>27$ is arithmetic the model does itself (this is Cell B's zero-tool logic embedded inside a bigger task).

Verify: $3\times 9=27$; $37>27$ → Yes ✓. Searches used $=3$, total steps $=4\le 6$ ✓. (Forecast answer: 3 searches, answer "Yes".)

---

Cell H — Exam twist: conflicting tool outputs

Steps.

1. Thought: "Consult the most authoritative source first." Action $a_1=\text{search\_encyclopedia("Eiffel Tower opening")}$. $o_1=$ "1889 (opened for the World's Fair)." Why this source first? For a factual date you consult the most authoritative source available first — a curated encyclopedia has editorial checking, so its answer is your strong prior. Only after that do you sample weaker sources to see whether they agree.
2. Thought: "Cross-check with a second, independent source." Action $a_2=\text{search\_web("Eiffel Tower year")}$. $o_2=$ "1887" (this page is describing when construction started). Why a second source? Cross-checking is the reconciliation strategy for the twist cell — one source alone can be wrong.
3. Reconciliation thought: "Conflict: 1889 vs 1887. The blog's 1887 is the construction start; the opening was 1889. Two reasons favour 1889: the higher-reliability source, and the semantically-correct field (opening ≠ start)." Action $a_3=\text{respond("1889.")}$ Goal met at $t=3$. Why 1889 and not an average? Two independent reasons agree: source reliability and the distinction between started and opened. Facts are adjudicated by provenance and meaning, never averaged.

Verify: The Eiffel Tower opened 1889; construction began 1887, a gap of $1889-1887=2$ years. The agent chose 1889 ✓. (Forecast answer: 1889, chosen by source reliability + start-vs-open distinction.)

---

Recall

Recall Every stop condition

Name the three ways any reasoning loop can terminate. Three loop stop conditions ::: Goal met (final-answer action), step budget hit ($t\ge T_{\max }$), context overflow ($L_t>L_{\max }$).

Recall The degenerate case

When should the loop make zero tool calls? Zero-tool case ::: When the model can answer directly (simple arithmetic/known facts); calling a tool wastes steps and can introduce errors.

Recall Why a budget is mandatory

What breaks if you remove $T_{\max }$? Removing the budget ::: Unsatisfiable or looping goals never terminate — the loop is no longer total; it can hang forever (cell F).

Recall Overflow handling

What do you do when $c_t$ exceeds the context window ($L_t>L_{\max }$)? Context overflow fix ::: Summarize old messages into one message (keeping the gist as long-term memory) rather than blindly discarding, so the length stays bounded under $L_{\max }$ and the loop can run indefinitely.

See also: Tool Use and Function Calling · Chain-of-Thought Prompting · Prompt Engineering · Multi-Agent Systems