Agent Architectures
An agent architecture is the loop that turns a goal into actions: see the world, think with memory, act with tools, then read the result and repeat.
Why Does This Exist?
A chat model answers once and stops. Ask it to plan a 10-day trip under $5000 and it writes a nice itinerary, but it never checks a price, never notices the hotel sold out, and never adds anything up. The answer reads well and the budget is fiction.
An agent exists to close that gap. It can look at the world, take an action that changes something, read what happened, and try again. The architecture is the wiring that decides the order: what the agent sees, where it thinks, which tools it may call, what it remembers, and when it stops. Change the wiring and you change what the system can solve. A single-pass answer handles one question. A loop with tools handles a week of bookings.
This page covers the two wirings everything else builds on: the step-by-step ReAct loop and the plan-first plan-and-execute loop. The ReAct loop itself lives in ReAct. Breaking a goal into steps lives in planning in agents. What the loop remembers lives in agent memory types, and how you score the whole thing lives in agent benchmarks.
Basics first: a tool is a function the model may call with arguments, such as searching flights or reading a file. The model only produces the name and the arguments. Your code runs the function and pastes the result back. If that handoff is new, read ReAct first, because every architecture below assumes it.
Think of It Like This
The cook who tastes versus the cook with a recipe card
Two cooks face the same dinner order. The first cook tastes as they go: add salt, taste, add stock, taste, adjust heat, taste again. Every decision follows the last spoonful. That is ReAct. It adapts fast and never follows a stale plan, but it can wander, repeating tastings instead of plating.
The second cook writes a recipe card first: starter, main, dessert, with times. Then they cook card in hand. When the oven breaks, they cross out one line and rewrite it, keeping the rest. That is plan-and-execute. It stays coherent across a long service, but the card costs time to write and a bad first card wastes the evening.
Where it stops: both cooks can still burn the dish. Neither the tasting loop nor the card checks whether the diner is allergic to anything. Safety checks live outside the loop, in permissions and sandboxes, not in the architecture.
How It Actually Works
Every architecture runs the same four slots in a circle. Call the goal G, the latest observation O, the memory M, the thought T, and the action A. One pass reads O and M, writes T, picks A, runs it, and files the result back into M. The two architectures differ only in when T is allowed to look ahead.
The ReAct loop: decide one step at a time
ReAct writes a thought, takes one action, reads the observation, and repeats. There is no upfront plan. The thought for step 3 sees the results of steps 1 and 2, so the agent can pivot the moment a search returns nothing or a price moved.
That flexibility is the whole point, and it sets the cost. Each step carries the growing history, so a 5-step run pays for 5 model calls and a lengthening prompt. It shines when the next step depends on the last result, like searching, reading, then searching again with better terms.
Plan-and-execute: write the steps, then work them
The planner writes the full step list first, then an executor works it top to bottom. A watcher compares each result against the plan. When a step fails, the planner rewrites only the remaining steps. This is the PLAN, EXECUTE, EVALUATE, REPLAN circle from planning in agents.
The plan costs one extra call upfront, and it buys coherence on long tasks. Ten steps with dependencies stay in order because the order was written down, not re-decided each time.
Worked example: one trip, two wirings
The goal G is a 10-day trip under $5000. The three costs are flights 1800, hotel 2200, and activities 600. Add them step by step: 1800 + 2200 = 4000, then 4000 + 600 = 4600. The buffer is 5000 − 4600 = 400, so the plan passes and the diagram draws exactly this run.
Under ReAct, the agent makes 5 tool calls: search flights, search hotels, search activities, sum the three, and check the total against the budget. Five calls, five thoughts, no plan.
Under plan-and-execute, the planner writes 3 steps, the executor runs them, and then the hotel sells out. The replacement costs 2600, which pushes the total to 1800 + 2600 + 600 = 5000, exactly at the budget with zero buffer. The watcher flags it, the planner swaps in a 2100 hotel, and the new total is 1800 + 2100 + 600 = 4500, leaving a 500 buffer. Three planned steps plus 1 replan: 4 executions against ReAct's 5 calls.
The trade is now concrete. ReAct adapts without paying for a plan and risks wandering. Planning pays one call upfront, holds long tasks together, and risks a stale first draft. Pick ReAct when each step depends on the last result. Pick plan-and-execute when the task runs past about 10 steps or has ordering constraints. Both assume the toolbox is fixed and every observation arrives as readable text, which breaks when a tool returns a giant page or a silent side effect.
Code
The point here is the stop rule and the replan, not the arithmetic. This stdlib-only simulation runs the same trip numbers through a guarded loop, then through a plan that replans once:
def react_trip(costs: dict[str, int], budget: int, max_steps: int = 10) -> tuple[int, int]: total = 0 calls = 0 for name in ["flights", "hotel", "activities", "sum", "check"]: if calls >= max_steps: break calls += 1 if name in costs: total += costs[name] return total, calls
def plan_trip(costs: dict[str, int], budget: int) -> tuple[int, int]: plan = ["flights", "hotel", "activities"] total = sum(costs[s] for s in plan) executions = len(plan) if costs["hotel"] == 2600: # watcher: sold-out swap costs = dict(costs, hotel=2100) total = sum(costs[s] for s in plan) executions += 1 # one replan return total, executions
base = {"flights": 1800, "hotel": 2200, "activities": 600}print(react_trip(base, 5000)) # -> (4600, 5)print(plan_trip(base, 5000)) # -> (4600, 3)print(plan_trip({"flights": 1800, "hotel": 2600, "activities": 600}, 5000)) # -> (4500, 4)print(4600 <= 5000) # -> TrueThe outputs match the worked example: ReAct totals 4600 in 5 calls, the clean plan totals 4600 in 3 executions, and the sold-out run replans once to land at 4500. The max_steps guard is what keeps the first loop from running forever.
Watch Out For
A loop with no stop rule runs all night
The symptom is a run that looks busy and achieves nothing: 40 steps of searching, each slightly reworded, the bill climbing with every call. The agent is not close to done. It is stuck, and nothing in the loop knows it.
Fix it with a hard max_steps cap around 10 for ordinary tasks, plus an explicit finish action the model must choose. Log the step count per run and alert when runs routinely pass 20 steps. A task that needs more steps needs a plan, not a bigger cap.
The planner invents tools you never built
The symptom is a beautiful plan that dies on step one: check visa requirements via the visa API, when no visa tool exists. The planner wrote what sounded logical, not what your toolbox contains, so the executor fails on a step that was never runnable.
Fix it by pasting the tool list, with one-line descriptions, into the planner prompt, and by rejecting any planned step that names an unknown tool before executing anything. Ground the plan first, then run it.
The Quick Version
- An agent architecture is a loop of observe, think with memory, act with tools, and file the result back.
- ReAct decides one step at a time and adapts fast, at the price of one model call per step.
- Plan-and-execute writes the steps first, then replans the remainder when a step fails.
- A 4600 trip against a 5000 budget passes, and a sold-out hotel triggers one replan to land at 4500.
- Every loop needs a stop rule near 10 steps plus an explicit finish action.
- Planners must see the real tool list, or they schedule tools that do not exist.