Building a Single Agent Is a Loop With a Goal
An agent is not intelligent. It is a loop. Building a single agent means wrapping a model in a loop that has a goal, and letting it run until the goal is met or the budget runs out. Everything people call "agentic" is that loop plus discipline about what goes into the model each turn.
You already have the pieces. In the last post you gave the model tools and the agentic loop. Now you close the loop into one autonomous unit that decides for itself when to call a tool, when to think, and when to stop.
The Moving Parts of a Single Agent
An agent is a program that pursues a goal by repeatedly calling a model to decide the next action. Agentic AI is just this idea taken seriously: the model is in the driver seat, not you.
Three roles run inside the loop. The planner decides what to do next, breaking the goal into steps. The executor carries a step out, usually by calling a tool and reading the result. The controller, sometimes called the coordinator, owns the loop itself: it feeds results back in, checks whether the goal is met, and enforces the stop condition so the thing does not run forever.
In a small agent all three are the same model prompted three ways. In a large one they are separate calls. The shape does not change: decide, act, observe, repeat.
ReAct Is the Workhorse Loop
The pattern behind most working agents is ReAct: reason, then act, then read the result, then reason again. The model writes a thought, picks a tool, sees what came back, and uses that observation to write its next thought. Reasoning and action interleave in one stream.
This is the backbone of autonomous workflows, and it wins because it is honest. The model does not plan in the dark. Every action produces a real observation, and the next decision is grounded in that observation instead of a guess. When a tool fails, ReAct sees the error on the next turn and routes around it. Start here. Reach for anything fancier only when ReAct visibly struggles.
Plan First or React Step by Step
There are two ways to structure the thinking, and they trade off.
Plan-and-Execute, also called the planner-executor split, does multi-step planning up front: the model writes the whole route as a list, then executes each step in order. It is cheaper, because you plan once instead of re-reasoning every turn, and easier to inspect, because the plan is written down. It is brittle when reality diverges from the plan.
Pure ReAct is the reactive opposite: no plan, just the next step, chosen fresh each turn from what it just saw. It is robust to surprises and expensive in tokens.
| Plan-and-Execute | Reactive (ReAct) | |
|---|---|---|
| When it decides | Whole route, up front | One step at a time |
| Cost | Lower, plans once | Higher, reasons each turn |
| Handles surprises | Poorly | Well |
| Best for | Stable, known tasks | Open, messy tasks |
Most solid agents blend them: plan a rough route, then react within each step.
Exploring More Than One Path
ReAct commits to one line of reasoning. Sometimes the first line is wrong and you want the agent to consider options before it acts.
Tree of Thoughts lets the agent branch: generate several candidate next steps, evaluate them, and pursue the promising ones, backtracking from dead ends like a search. Graph of Thoughts generalises this, letting branches merge and reference each other instead of only splitting. Both are forms of deliberation: spending extra compute to think wider before committing.
They are powerful and they are expensive. Every branch is more tokens. Use them for hard, high-value problems with clear ways to score a path. For everyday tasks they are a luxury you rarely need.
An Agent That Checks Its Own Work
The cheapest quality gain in agent design is making the model read its own output before returning it. This is Reflection: the agent critiques its answer, names what is weak, and revises. Done in a tight cycle it is a reflection loop, and the Self-Refine pattern is exactly this: draft, critique, improve, repeat until good enough.
A cousin is self-consistency: sample several independent answers and take the one they agree on, trusting the majority over any single run. Together these give an agent self-correction, the ability to catch its own mistakes mid-run instead of confidently shipping them. A reflection pass costs one extra model call and often saves a wrong answer. It is usually worth it.
Memory Is What Survives the Loop
An agent with no memory solves the same subproblem forever. Memory is what the loop carries between turns, and it comes in layers.
Working memory, the scratchpad, is what lives in the window right now: the goal, recent steps, the last few tool results. It is the agent's short-term memory, and it is literally the context the model sees this turn, the same context window you met in the foundations. It is small and it vanishes when the run ends.
Long-term memory persists across sessions and comes in two flavours. Episodic memory stores specific past events: what happened in run 47, what the user asked yesterday. Semantic memory stores distilled facts: the user prefers metric units, the database lives at this host. Episodic is a diary; semantic is a notebook of settled truths.
As a run grows, the scratchpad overflows the window. Memory compression is the fix: summarise old turns into a short digest and evict the raw text. This context management, deciding what to keep verbatim, what to compress, and what to drop, is what keeps a long run affordable instead of exploding in cost.
What You Let Into the Context Window Decides Everything
Here is the point the whole level builds to. An agent's quality is not set by its architecture diagram. It is set by what enters the context window each turn.
Context engineering is the discipline of deliberately curating that window: pulling in the right memory, the right retrieved facts, the right tool results, and ruthlessly keeping everything else out. It is eclipsing prompt engineering because the prompt is now the small part. The model is only as good as the context you assemble around it, and context window management, fitting the most relevant tokens into a fixed budget, is the real craft. A brilliant reasoning loop fed junk context produces junk. A plain ReAct loop fed clean, relevant context produces gold.
This is why two teams using the same model get wildly different agents. Same engine, different context. The model never changed. What they fed it did.
State Is What Lets It Resume
A single agent run can take minutes and dozens of steps. If it crashes on step 30, you do not want to restart from step one.
State management is tracking where the agent is: its plan, its progress, its memory. Held for one conversation, that is session state. Written to a store so it outlives the process, that is state persistence. Save that state at each step and you have checkpointing: the run can die and resume from the last good point instead of the beginning. For anything long or costly, checkpoints are not optional. They are how an agent survives contact with the real world.
The Loop Was Never the Hard Part
Wrapping a model in a loop with a goal is an afternoon of work. Any framework gives it to you. The loop is not where agents are won or lost.
They are won at the window. An agent is a model deciding, one turn at a time, from whatever you placed in front of it. Choose the architecture for how it thinks, choose the memory for what it knows, but understand that both collapse into the same act: deciding what the model sees this turn. Get that right and a simple agent is formidable. Get it wrong and no architecture saves you. The loop has a goal. Your job is to feed it well.
When one well-fed agent finally runs out of room, the reflex is to split it into a team. The next rung is about when that split is earned and when it is just expensive theatre.
Part of the Applied AI Engineering ladder. Previous: Giving Models Tools. Next: When One Agent Is Not Enough.