Search across all documentation pages
Most production agents are not free-form "chat with tools." They follow a small set of control-flow patterns that decide when the model thinks, when it calls tools, and when work moves to another agent.
This page maps the three patterns that dominate agent design as of 2025-2026: ReAct, Plan-and-Execute, and multi-agent handoff. The rest of this section deep-dives each one and helps you choose.
An agent architecture is the policy for what happens on the next step after the model produces a thought, a tool call, or a final answer. It answers questions like: Do we invent the next action only after seeing the last tool result? Do we write a full plan first? Can another agent take over the session?
ReAct (Reason + Act) interleaves short reasoning with tool calls. Each cycle looks like: reason about the current state, choose one action, observe the tool result, then reason again until a stop condition fires.
Plan-and-Execute splits the run into two phases. A planner produces an ordered list of steps (often natural language or structured JSON); an executor walks that plan, typically with tools, and may replan only when a step fails or the world changes.
Multi-agent handoff treats the problem as a team workflow. An orchestrator (or a peer agent) routes the user goal to a specialist with a narrower tool set and prompt, then receives a structured result and continues or hands off again.
A useful analogy: ReAct is a skilled generalist solving a ticket one command at a time; Plan-and-Execute is writing a checklist before you open the toolbox; multi-agent handoff is a desk manager assigning the ticket to the right specialist and collecting the write-up.
User goal
|
+-- ReAct ------------> reason -> act -> observe -> ... -> answer
|
+-- Plan-and-Execute -> plan -> execute steps -> (optional replan) -> answer
|
+-- Multi-agent ------> route -> specialist loop -> handoff/return -> answerThe three patterns differ less in "intelligence" and more in when decisions are made and what lives in context.
In ReAct, the decision boundary is every tool observation. The model can adapt after each search, API call, or file read, which is powerful when the next step depends on intermediate data. The cost is that every turn reloads history: tool outputs accumulate, latency stacks, and without hard stopping conditions the loop can thrash.
In Plan-and-Execute, the decision boundary is the plan (plus rare replans). You pay for planning tokens once (or occasionally), then execute steps with less open-ended wandering. This shines when the task decomposes cleanly - research outline, multi-file code change checklist, multi-system ops runbook - and when wasted exploratory tool calls are expensive.
In multi-agent handoff, the decision boundary is who owns the next subgoal. Each specialist keeps a smaller prompt and tool surface, which improves focus and can reduce tool misuse. You pay coordination tax: handoff schemas, context packing, failure routing, and debugging across multiple loops instead of one.
All three still rest on the same agent loop primitives: perceive input, reason, act with tools, observe results. Architecture chooses the shape of that loop - interleaved, phased, or distributed - not whether tools exist.
| Pattern | Control flow | Strength | Weakness | Best fit |
|---|---|---|---|---|
| ReAct | Interleaved reason/act/observe | Adapts to tool results mid-run | Context bloat; easy to loop | Exploratory tasks, unknown tool path |
| Plan-and-Execute | Plan phase then step execution | Fewer wasted calls; clearer audit trail | Brittle if plan is wrong early | Multi-step work with known structure |
| Multi-agent handoff | Route + specialist loops | Narrow tools/prompts per role | Coordination and handoff bugs | Heterogeneous skills or risk isolation |
Frameworks encode these patterns under different names. LangGraph graphs often implement ReAct-style tool nodes or plan/execute subgraphs; CrewAI hierarchical crews resemble orchestrator + specialists; OpenAI Agents SDK exposes explicit handoffs; Microsoft Agent Framework merges conversational multi-agent patterns with workflow graphs. The portable skill is recognizing the pattern independent of the SDK.
Hybrids are normal in production. A common design is: Plan-and-Execute at the top (stable milestone list), ReAct inside each milestone (flexible tool use), multi-agent only where a specialist needs a different model, tool allowlist, or compliance boundary. See Hybrid Architectures: Combining Planning, Reaction, and Delegation.
Cost and reliability interact with architecture more than model choice alone. ReAct multiplies tokens by turns; Plan-and-Execute multiplies by plan quality and replan frequency; multi-agent multiplies by the number of agent invocations and the size of each handoff payload. Observability should log pattern phase (plan vs execute vs handoff) so incidents are not just "the agent failed."
Security also follows architecture. A single ReAct agent with a wide tool belt is one prompt-injection away from a bad tool call. Specialists with least-privilege tools reduce blast radius if handoffs cannot escalate privileges silently.
It is the control policy that decides the next step after each model output or tool result - continue, replan, hand off, or stop - plus how context and tools are scoped for that step.
They cover the main axes of agent control: step-wise reaction, upfront structure, and role-based delegation. Most framework features are variations or hybrids of these three.
Chat-with-tools can be a single tool call in one turn. ReAct is an explicit multi-turn loop that keeps reasoning and acting until a goal check or max-turn limit stops it.
When the task has a natural ordered structure and blind exploration wastes money or time - for example multi-source research with a fixed outline, or a code change that must follow a checklist of files and tests.
When specialists need different tools, prompts, models, or trust levels, or when human review gates should sit between roles (for example research vs publishing vs deploy).
Yes. Max turns, timeouts, goal-completion checks, and budget caps apply to every pattern. Architecture does not replace loop bounds.
No. Multiple tools can live inside one ReAct agent. Multi-agent means multiple agent instances (or roles) with their own loops, prompts, and usually separate tool surfaces.
Yes, light planning-time tools (search for constraints, list files) can improve the plan, but heavy execution usually belongs in the execute phase so the plan stays short and reviewable.
Log the phase (reason/act, plan step, or handoff), the decision, tool results, and stop reason. Pattern-level traces beat only dumping raw model messages.
No. Better models reduce some reasoning errors but do not remove infinite loops, context overflow, or privilege mistakes. Architecture still bounds cost and failure modes.
Start with a bounded ReAct loop for one clear tool-using task, then add Plan-and-Execute when tasks get long and structured, then multi-agent only when a second role earns its complexity.
No. They are vendor-agnostic control patterns. SDKs differ in APIs, but the whiteboard shapes stay the same.
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.
Reviewed by Chris St. John·Last updated Jul 16, 2026