Two different questions get asked together here, and they deserve separating. The first is which prompting patterns agents actually use. The second is which libraries implement them. The patterns have been stable for a while. The tooling has not.
This post covers the patterns and the tooling. The mechanics of what physically gets assembled into a request are covered separately in how an agent builds the prompt.
The Core Reasoning Patterns
| Pattern | Shape | Suits |
|---|---|---|
| ReAct | Reason, act, observe, repeat | General tool use — the default |
| Plan then execute | Produce a plan, then work through it | Multi-step tasks with known structure |
| Reflection | Produce, critique, revise | Quality-sensitive output |
| Decomposition | Split into sub-tasks, solve separately | Tasks exceeding one context window |
| Delegation | Route sub-tasks to specialised sub-agents | Distinct skill areas, large tool sets |
ReAct
The dominant pattern, and what most tool-calling agents run whether or not they name it. The model reasons about what is needed, requests a tool, receives the result as an observation, and repeats until it can answer.
Modern implementations rarely use the original prose format with explicit “Thought:” and “Action:” labels. Native tool-calling APIs handle the action step structurally, so the pattern survives as a loop shape rather than as a prompt template.
Where it struggles: long horizons. Each iteration adds to context, and the model can lose track of the overall goal across many steps — or loop, repeating a failing call.
Plan then execute
One call produces a plan; subsequent calls work through it. The separation gives you an inspectable artifact before anything runs, which is valuable when actions have consequences.
Where it struggles: plans made before any information is gathered are often wrong. Most production implementations allow replanning when a step fails, which reintroduces some of ReAct’s flexibility.
Reflection
The model produces output, then critiques it in a separate call, then revises. The critique step works better when it has something concrete to check against — test results, schema validation, a rubric — than when asked to self-assess in the abstract.
Where it struggles: cost and latency multiply. A self-critique with no external signal often just rephrases.
Decomposition and delegation
Decomposition splits work into independently solvable pieces. Delegation routes pieces to sub-agents with their own tool sets and instructions.
Delegation’s main practical benefit is context isolation. A sub-agent handling one narrow job sees only its own tools and its own history, which keeps the parent’s context clean and its tool set small — connecting directly to the selection-degradation problem in tool design.
Prompt-Level Techniques
| Technique | What it does | Note |
|---|---|---|
| Few-shot examples | Demonstrates desired output in the prompt | Effective, but consumes context every request |
| Structured output | Constrains responses to a schema | Removes parsing failures entirely |
| Role framing | Sets persona and expertise | Modest effect; often overrated |
| Explicit reasoning | Asks for working before the answer | Largely superseded by reasoning-capable models |
| Delimiting untrusted content | Marks retrieved text as data, not instructions | Reduces injection exposure; not a guarantee |
| Negative instruction | States what not to do | Often more effective than positive framing |
Two of these have shifted materially. Structured output moved from a prompting trick to an API feature — constraining generation against a schema is now standard, which eliminated a whole category of parsing errors. And explicit chain-of-thought prompting matters far less than it did, since models increasingly reason internally without being asked.
How Prompts Are Managed in Practice
The engineering patterns matter as much as the prompting ones, and they are where most teams are weakest.
| Practice | Why |
|---|---|
| Externalise from code | Prompts change far more often than surrounding logic |
| Template with variables | Separates stable structure from per-request values |
| Version explicitly | Behaviour changes with prompts; you need to know which was live |
| Keep the prefix stable | Prompt caching requires an exact prefix match |
| Log the assembled prompt | Debugging without it is guesswork |
| Evaluate before shipping | A prompt edit is a behaviour change with no compiler to catch it |
The last row is the discipline gap. Prompt edits ship without tests in a way code changes generally do not, and a small wording change can alter behaviour across every request. Evaluation sets — a fixed collection of inputs with expected properties — are what make prompt changes safe.
The Framework Landscape
Grouped by what they are actually for, since the category has fragmented.
| Framework | Model | Best suited to |
|---|---|---|
| LangGraph | Agents as directed graphs — nodes and edges with explicit state | Stateful, cyclic or branching workflows; production orchestration where checkpointing and rollback matter |
| LangChain | ReAct-style tool loop with a very large integration library | Rapid prototyping across providers; linear single-agent workflows |
| CrewAI | Role-based crews — agents with personas, goals and delegation as primitives | Fastest path to a working multi-agent prototype |
| AutoGen / AG2 | Workflows as conversations between agents | Agent debate, critique and iterative refinement |
| PydanticAI | Type-safe agents with validated inputs and outputs | Structured output pipelines; teams valuing type safety and debuggability |
| OpenAI Agents SDK | Minimal primitives — agents, handoffs, guardrails | Fastest setup; simple tool loops |
| Claude Agent SDK | Tool-use chains with isolated sub-agents | Anthropic-centred stacks |
| Google ADK | Vendor SDK | Google-centred stacks |
| Microsoft Agent Framework / Semantic Kernel | Plugin-based, enterprise software shaped | .NET, C#, Java teams; Azure deployments |
| LlamaIndex Workflows | Data and retrieval first | Retrieval-heavy applications |
| Mastra | TypeScript-native workflows | Stateful agents in TypeScript |
| Vercel AI SDK | TypeScript, front-end oriented | Streaming UI and web applications |
| Smolagents | Deliberately minimal | Research and the Hugging Face ecosystem |
Two structural observations about where this has landed.
The stack has split into layers. Orchestration frameworks, vendor SDKs, and observability tooling are increasingly separate purchases rather than one bundled choice. Observability platforms such as LangSmith and Langfuse are deliberately framework-agnostic, working equally with custom code.
Interoperability protocols are emerging. MCP for exposing tools to agents, and agent-to-agent protocols for delegation across systems, are now supported across several frameworks. This reduces framework lock-in for the tool layer specifically — tools defined once can be consumed by different agents.
How Frameworks Differ on Prompts
An underdiscussed selection criterion: how much of the prompt the framework writes for you.
| Approach | Trade-off |
|---|---|
| Framework supplies hidden default prompts | Fast to start; behaviour you did not write and may not be able to see |
| Framework supplies visible, editable defaults | Good balance — a starting point you can inspect |
| You write everything | Full control; more work, fewer surprises |
The first row causes real debugging difficulty. When an agent behaves oddly and the framework has injected instructions you cannot read, you are troubleshooting a prompt you never wrote. Whether you can see the final assembled prompt is worth testing during evaluation, before committing.
Do You Need a Framework?
A minimal agent loop is genuinely small — call the model, check for tool requests, execute, append, repeat. Many teams build this directly and are well served.
| Build directly when | Use a framework when |
|---|---|
| Few tools, linear flow | Multi-agent coordination is the core problem |
| You want full prompt visibility | You need durable state, checkpointing or resumption |
| Dependency footprint matters | You want ready-made integrations rather than writing connectors |
| The abstractions do not match your problem | The framework’s model genuinely matches your workflow shape |
A common and sensible path is prototyping in whichever framework is fastest to express the idea, then migrating production-critical paths to something with stronger state and observability guarantees once the architecture is validated.
Observability is worth choosing deliberately regardless of framework. Tracing what was sent, what came back, and which tools ran is what makes agent behaviour debuggable at all.
Key Takeaways
- ReAct is the default loop — reason, act, observe, repeat
- Plan-then-execute gives an inspectable artifact before actions run
- Reflection works better with an external signal than with abstract self-critique
- Delegation’s main benefit is context isolation, not just specialisation
- Structured output moved from prompting trick to API feature
- Explicit chain-of-thought matters less than it did with reasoning-capable models
- Externalise, version and evaluate prompts — a prompt edit is a behaviour change with no compiler
- Check whether a framework lets you see the final assembled prompt before committing
Frequently Asked Questions (FAQ)
Q: What is the ReAct pattern?
ReAct stands for Reason and Act. The model reasons about what is needed, requests a tool, receives the result as an observation, and repeats until it can answer. Most tool-calling agents run this loop, though native tool-calling APIs now handle the action step structurally rather than through prose formatting.
Q: What prompting patterns do AI agents use?
The main reasoning patterns are ReAct, plan-then-execute, reflection, decomposition and delegation. At the prompt level, agents commonly use few-shot examples, structured output constraints, delimiting of untrusted content and negative instruction.
Q: Which agent framework should I use?
It depends on the shape of your problem. Graph-based frameworks suit stateful branching workflows, role-based frameworks suit fast multi-agent prototyping, type-safe frameworks suit structured output pipelines, and vendor SDKs suit single-provider stacks. Match the framework’s mental model to your coordination problem rather than picking on popularity.
Q: Do I need a framework to build an agent?
No. A basic agent loop — call the model, execute requested tools, append results, repeat — is small enough to write directly, and many teams do. Frameworks earn their place when you need multi-agent coordination, durable state, checkpointing or a large library of ready-made integrations.
Q: What is the difference between plan-then-execute and ReAct?
ReAct interleaves reasoning and action one step at a time, deciding what to do next based on what it just learned. Plan-then-execute produces a full plan upfront and then works through it, which gives an inspectable artifact before anything runs but risks planning without information.
Q: Is chain-of-thought prompting still necessary?
Much less than it was. Models increasingly reason internally without being prompted to show working, so explicitly asking for step-by-step reasoning adds less than it once did. It remains useful when you want the reasoning visible for inspection.
Q: How should prompts be managed in production?
Externalise them from code, template the variable parts, version them explicitly, keep the static prefix stable for caching, log the fully assembled prompt for debugging, and maintain an evaluation set. A prompt edit changes behaviour with nothing to catch regressions automatically.
Q: Why does my framework’s agent behave in ways I did not configure?
Many frameworks inject their own default system instructions. If those are hidden, you are debugging a prompt you never wrote. Check whether the framework exposes the final assembled prompt — it is a practical selection criterion that is easy to overlook.
Related Reading: