By now you've built a graph, given it memory, and let a human step in when it matters. What you haven't done yet is step back and ask what shape your agent should actually take, because "agent" isn't one design, it's a handful of recurring patterns that show up over and over once you look at enough of them. Knowing the three main ones means you stop reinventing a pattern that already has a name and a known set of tradeoffs.
ReAct: reason, act, observe, repeat
ReAct (reason plus act) is the pattern you've already built without necessarily naming it. The agent node reasons about what to do, calls a tool if it needs to, looks at the result, and loops back to reasoning again until it decides it's done. It's the default shape for a reason: it's simple, it's general-purpose, and it handles anything you can describe as "figure out what tool to call next."
Agent -> decides to call a tool -> Tool -> result -> Agent -> decides it's done -> ENDMost agents that answer questions, look things up, or take a handful of independent actions are ReAct under the hood, even the ones with fancier names layered on top.
Reflection: critique your own output before shipping it
ReAct is great at deciding what to do next, but it has no built-in mechanism for asking "was that actually good?" Reflection adds exactly that: a second node that looks at the agent's draft output and critiques it against some standard, and a conditional edge that sends the draft back for another pass if the critique finds real problems.
A minimal reflection graph is just three nodes: Generate produces a draft, Critique scores it and explains what's wrong, and a conditional edge routes back to Generate (with the critique added to context) if the score is below your bar, or forward to END if it passes.
Planning: decide the whole route before taking the first step
ReAct and reflection both operate step by step, deciding the next action based on what just happened. Planning flips that around: before doing anything, the agent produces an explicit, ordered list of steps needed to reach the goal, then executes that plan, revising it only if something along the way makes the original plan unworkable.
This matters most for tasks with enough steps that pure step-by-step reasoning tends to wander or lose the thread: a research task with five sub-questions, a multi-stage data pipeline, anything where "what should I do fifth" genuinely depends on planning ahead rather than reacting to whatever just happened. A common structure is plan-and-execute: one node writes the plan, a loop executes it one step at a time, and a re-planning node fires only when a step's result contradicts what the plan assumed.
Picking one (or combining them)
| Pattern | Best for | Cost |
|---|---|---|
| ReAct | General tool use, question answering, anything reactive | Lowest, one loop per step |
| Reflection | Quality-sensitive single outputs: code, writing, structured extraction | Roughly 2x calls per task |
| Planning | Long, multi-step tasks where order matters | Higher upfront cost, fewer wasted steps |
These aren't mutually exclusive. A common production shape is a planner that lays out the steps, a ReAct loop that executes each one, and a reflection check on the final output before it ships. Each pattern is just a different arrangement of the same nodes, edges, and conditional routing you already know from earlier guides, there's no new primitive to learn here, only new ways to wire the ones you have.