AI agents

ReAct (Reasoning and Acting) structures an agent loop so that every action is preceded by an explicit thought trace. Instead of calling a tool blindly, the model first writes out what it knows and what it needs, then acts, then observes the result and reasons again before the next step. This interleaving makes the agent's decision path auditable and allows errors to be caught mid-loop rather than discovered only at the final output.

The key production insight is that the reasoning step is not decoration: it forces the model to commit to a plan before each action, which reduces hallucinated tool calls and makes failures easier to diagnose from traces.

Sources

• ReAct: Synergizing Reasoning and Acting in Language ModelsarXiv
• Building effective agentsAnthropic

CodeAct replaces the conventional JSON tool-call format with executable Python code as the agent's action language. Rather than emitting a structured payload that a harness then dispatches, the model writes a snippet the runtime runs directly. This collapses the gap between reasoning and execution: the agent can compose multiple operations in one block, inspect intermediate results with print statements, and handle branches that a fixed schema cannot express.

In practice CodeAct agents outperform JSON-call equivalents on multi-step tasks, because code is a richer, more composable action space that the model was already trained to produce and reason about.

Sources

• Executable Code Actions Elicit Better LLM AgentsarXiv

Reflexion adds a self-critique step after each attempt: the agent reads its own output, reasons about what went wrong, and then retries with that verbal feedback incorporated. This is reinforcement without weight updates, using the model's own language as the gradient signal. The approach is especially effective for coding and reasoning tasks where the correctness of an answer can be evaluated and fed back in natural language.

The practical value is a substantial reduction in first-pass failures on hard tasks. Reflexion allows a single agent to self-correct across a small number of retries before surfacing the result, often matching accuracy that previously required much larger models.

Sources

• Reflexion: Language Agents with Verbal Reinforcement LearningarXiv

Plan-and-Execute separates planning from execution into two distinct phases. A planner model (or a dedicated planning call) decomposes the goal into an ordered list of subtasks before any action is taken. A separate executor then works through those steps in sequence, without revisiting the plan unless it explicitly fails. This avoids the drift that accumulates when planning and acting are interleaved, because the intent is locked in up front.

For long, predictable workflows this pattern produces more consistent and auditable behavior than a fully reactive loop, and it makes cost estimation easier since the step count is known before execution starts.

Sources

• Plan-and-Solve PromptingarXiv
• Building effective agentsAnthropic

Tree of Thoughts (ToT) generalizes chain-of-thought by treating reasoning as a search problem over a tree of partial solutions rather than a single linear sequence. At each step, the model generates several candidate continuations, evaluates each one, and expands only the most promising branches, pruning the rest. This is search, not just prompting, and it lets the model recover from early wrong turns that a greedy linear approach would be committed to.

ToT is most valuable for problems with a clear correctness signal, such as mathematical puzzles or planning tasks, where a beam-search style exploration dramatically outperforms a single-path forward pass.

Sources

• Tree of Thoughts: Deliberate Problem Solving with Large Language ModelsarXiv

Anthropic's most-cited practical heuristic: before building an autonomous agent, ask whether the task can be expressed as a fixed sequence of steps with deterministic control flow. If it can, a workflow is almost always faster to ship, cheaper to run, and easier to debug than an agent. Reserve true autonomy for tasks where the path cannot be known in advance and where the cost of occasional wrong turns is acceptable.

The temptation to reach for agents early is real, but most production tasks that teams initially frame as open-ended turn out to have implicit structure that a workflow captures cleanly. Starting with a workflow also gives you a performance baseline to justify the added complexity of an agent if you eventually need one.

Sources

• Building effective agentsAnthropic

Each step in an agent loop has some probability of going wrong. Because steps are sequential and dependent, those probabilities multiply: a ten-step chain where each step succeeds 95% of the time has only a 60% chance of completing cleanly end-to-end. The longer the chain, the more sharply overall reliability decays. This is compounding error, and it is the single strongest argument for keeping agent loops short.

The practical response is a combination of: reducing step count wherever possible, inserting explicit checkpoints where the agent verifies its own state, building in retry logic on individual steps before the whole task is abandoned, and designing tasks so that a partial failure is recoverable rather than catastrophic.

Sources

• Building effective agentsAnthropic

Computer use gives an agent the ability to control a real graphical interface: it takes screenshots to observe state, then issues mouse clicks and keyboard input to act. This is the fallback for any system that has no API and no structured output, from legacy desktop software to web applications protected behind login flows. The agent sees the screen the way a human would and operates it the same way.

The cost is that GUI-based interaction is fragile: layouts change, latency is high, and failures are hard to detect because a screenshot of a broken state can look superficially correct. Computer use should be scoped narrowly, sandboxed tightly, and reserved for cases where no better interface exists.

Sources

• Computer use (beta)Anthropic

When an agent can write and run code, that code must execute in an isolated environment that cannot reach production systems, modify the host filesystem, or make unintended network calls. A sandbox is not an optional hardening step; it is the prerequisite that makes code execution a viable tool at all. Without it, a single misbehaving prompt can cause irreversible damage.

Effective sandboxes enforce least privilege: the runtime has exactly the permissions the task requires and nothing more. Typical constraints include read-only mounts, network allow-lists, CPU and memory limits, and a hard timeout. The tighter the sandbox, the more confidently you can let the agent act.

Sources

• Building effective agentsAnthropic

The Model Context Protocol (MCP) is an open standard, originally published by Anthropic, that defines a single, consistent interface for connecting an AI model to external tools and data sources. Instead of writing a bespoke integration for every tool, you build or install one MCP server per data source, and any MCP-compatible client (Claude, an open-source agent framework, or your own code) can use it immediately. The protocol handles capability discovery, structured inputs and outputs, and transport, so the integration work is done once.

MCP matters for production because it removes the combinatorial explosion of N-agents times M-tools integrations, replaces it with N plus M, and turns the growing ecosystem of community-built servers into a library you can draw on rather than code you have to maintain.

Sources

• Model Context Protocol: IntroductionMCP

Anthropic's guidance on tool security comes down to least privilege: every action an agent takes should be scoped to the minimum permissions the specific task requires. Run code in containers that cannot reach production, call APIs through service accounts with narrow roles, and never give an agent credentials it does not need for the current step. Applying this consistently means that when an agent does go wrong, the blast radius is contained.

The principle extends beyond code execution to any irreversible action: file writes, database mutations, external API calls. Treat each category of action as a separate sandbox boundary, and require explicit escalation when the task genuinely needs broader permissions.

Sources

• Building effective agentsAnthropic

Every production agent must have hard, non-negotiable upper bounds on iteration count, token consumption, wall-clock time, and API spend. These are not soft guidelines; they are kill switches. An agent that enters a retry loop, gets confused by unexpected tool output, or interprets an ambiguous goal too broadly will consume resources without limit unless something stops it.

Set the caps conservatively at first, measure where normal runs land, and tighten from there. A loop that never trips its cap is probably set too loosely. When the cap does fire, log it as a first-class event, not a silent timeout, because repeated cap-hits are the signal that the agent's planning or error handling needs work.

Sources

• Building effective agentsAnthropic

Scratchpad memory is the working memory of the current task: everything the agent has reasoned about, the intermediate results it has gathered, and its current plan. It lives entirely inside the active context window. This is the memory that ReAct-style agents use when they write out their thoughts before each action, and it is the first and cheapest form of memory to reach for.

Because it is bounded by the context window, scratchpad memory is inherently ephemeral. It does not persist across sessions and cannot grow arbitrarily. Long tasks require compaction or checkpointing strategies to avoid running the scratchpad out of space before the task completes.

Sources

• Building effective agentsAnthropic

Episodic memory lets an agent recall what it did in past sessions by retrieving relevant records from a persistent store, typically a vector database. When a new task starts, the agent queries its history for similar past situations and surfaces what it learned or decided then, giving it effective long-term context without loading everything into the context window at once.

The quality of episodic recall depends heavily on what was stored and how it was indexed. Storing raw transcripts is wasteful; storing distilled summaries of outcomes, decisions, and key facts is more useful and more efficient to retrieve. The retrieval step itself introduces latency and can surface irrelevant memories, so production implementations need to tune both the embedding strategy and the retrieval threshold.

As a long agent run accumulates context, earlier turns become less relevant but still consume tokens. Memory compaction addresses this by periodically summarizing older conversation segments into a compressed representation that preserves the essential facts while dropping verbatim detail. The result is a context window that stays useful and within limits as the task grows.

The risk is lossy compression: a summary can drop a detail that turns out to matter later. Effective compaction strategies are conservative, summarizing only segments that are clearly stale, and they may retain raw tool outputs for high-stakes steps even when summarizing the surrounding reasoning.

Sources

• Building effective agentsAnthropic

The goal of context management is not to maximize the information in the window but to maximize the signal. Retaining every prior turn in full is rarely the right choice: the cost grows linearly and older turns become noise. Deliberate compaction means actively deciding what to keep, what to summarize, and what to drop, rather than relying on the model to ignore irrelevant content.

A useful heuristic is to distinguish between working context (what the agent is actively doing now, kept in full) and historical context (what was done earlier, summarized to key facts). Compacting historical context while keeping working context intact lets most tasks run within a reasonable window without losing the thread.

A checkpoint is a serialized snapshot of an agent's complete state at a point in its run: the current plan, completed steps, tool outputs, and any accumulated memory. Persisting checkpoints means that if the run fails due to a network error, a rate limit, or a process crash, execution can resume from the last good state rather than starting over.

Checkpoints also enable human review: an operator can inspect the agent's state mid-run, approve or correct it, and let execution continue. This is the foundation of human-in-the-loop workflows for long-running or high-stakes tasks, where a full restart would be too expensive or too risky.

Sources

• Building effective agentsAnthropic

In the supervisor pattern, a lead orchestrator agent receives the top-level goal, decides which specialist agent to invoke for each subtask, routes the work, and then synthesizes the results. Each specialist has a narrow, well-defined scope: a researcher, a coder, a critic. The supervisor does not do the work itself; it coordinates and integrates.

The pattern scales well because specialists can be developed and tested in isolation, and the supervisor's routing logic is relatively simple to inspect and debug. The main failure mode is a supervisor that routes incorrectly or merges partial results inconsistently, so both the routing prompt and the output-merging logic need careful attention.

Sources

• Building effective agentsAnthropic

Human-in-the-loop is the practice of pausing an agent's execution before any high-stakes or irreversible action and waiting for explicit human approval before continuing. The pause can be triggered by rule (any external write, any spend over a threshold) or by the agent itself flagging that it is uncertain. The human can approve, reject, or redirect, and execution resumes accordingly.

This is the primary safety mechanism for agents operating in production environments where mistakes are costly. It does not eliminate automation: routine steps run fully autonomously, and only the subset of actions that cross a defined risk threshold require a human checkpoint. Designing those thresholds carefully is the engineering work.

Sources

• Building effective agentsAnthropic

LangGraph models an agent as an explicit state graph where nodes are processing steps and edges are transitions, including conditional branches and cycles. Because the graph is a first-class data structure, you can inspect it, checkpoint any node, resume from any saved state, and add human-in-the-loop pauses at specific edges without restructuring your code. This makes it one of the few frameworks where long-running, stateful agent tasks are practical in production.

LangGraph supports single-agent, multi-agent, and hierarchical topologies within the same graph model, so a supervisor-and-specialists architecture maps directly to its primitives. The low-level graph API gives more control than higher-level frameworks, at the cost of more explicit wiring.

Sources

• LangGraphLangChain

CrewAI organizes multi-agent work around the metaphor of a crew: each agent is given a role, a backstory, and a set of tools, and a crew definition specifies how agents collaborate to complete a shared goal. This role-based framing makes it easy to reason about which agent should do what and to adjust behavior by editing the role description rather than restructuring code.

CrewAI is well-suited to tasks that decompose naturally into human-role analogues (researcher, writer, reviewer) and where the collaboration pattern is fixed. For tasks requiring highly dynamic routing or stateful long-running loops, LangGraph's explicit graph model offers more control. The two tools target different points on the control-vs-convenience tradeoff.

Sources

• CrewAI documentationCrewAI

When evaluating a multi-agent system, judge the final state rather than trying to prescribe the exact path the agent took to get there. Agents find valid solutions that a human author of test cases would not have anticipated, and an evaluator that checks intermediate steps will fail those valid runs. The right question is whether the outcome meets the success criteria, not whether the agent took the expected route.

Anthropics guidance on agent evals centers on this distinction: define what done looks like in the final environment state, write a grader that checks that state, and let the agent choose its path. This also produces more robust evals, since they do not need to be updated every time the agent improves its strategy.

Sources

• Demystifying evals for AI agentsAnthropic

Not all agent actions carry the same risk. Reads and searches are typically safe to run autonomously. Writes, deletes, external API calls with side effects, and any spend above a meaningful threshold are a different category. The practice is to enumerate those high-stakes action types up front, insert an approval gate before each, and make that gate the responsibility of the orchestration layer rather than of individual agent code.

Approval does not have to mean synchronous human review for every action: low-risk variants of a high-stakes action type can be auto-approved based on configurable rules, while genuinely risky or irreversible steps always require a human decision. The key is that the policy is explicit and enforced by the system, not left to the agent's discretion.

Sources

• Building effective agentsAnthropic