Single Agent Architecture: When One Is Enough

The Core Loop

Every single-agent system runs the same fundamental loop. The agent receives a task or goal. It observes the current state, which includes the task description, any available context, and the results of previous actions. It decides what to do next by reasoning about the goal, the current state, and the available tools. It takes an action, usually a tool call. It observes the result of that action. Then it decides whether the task is complete or whether another action is needed. This loop repeats until the agent determines the goal has been achieved, encounters an unrecoverable error, or reaches a defined stopping condition like a maximum step count or token budget.

The simplicity of this loop is deceptive. The reasoning step, where the agent decides what to do next, is where the entire value of the system lives. A well-designed single agent makes intelligent decisions about which tools to use, what order to use them in, how to interpret results, and when to change approach after a failure. The quality of these decisions depends on the model's capabilities, the prompt design, the tool descriptions, and the context available to the agent at each step.

The loop also needs termination logic that prevents the agent from running forever. The most common approach is a combination of success detection (the agent explicitly signals task completion), step limits (the loop terminates after N iterations regardless of progress), and cost limits (the loop terminates after consuming a specified number of tokens). Without these safeguards, a confused agent can enter an infinite loop of repeated tool calls that accomplishes nothing while consuming unbounded resources.

Tool Integration

Tools transform a single agent from a text generator into a capable worker. Without tools, the agent can only produce text about what it would do. With tools, it can actually do things: read files, query databases, call APIs, execute code, browse the web, send messages, and interact with virtually any digital system.

Tool design for single-agent systems follows a principle of focused capability. Each tool should do one thing well and return a clear result. A "search_database" tool that accepts a query and returns matching records is better than a "do_database_stuff" tool that tries to handle searches, inserts, updates, and deletes. Focused tools give the agent precise control over its actions and produce interpretable results that inform the next decision.

The number of available tools matters more than most teams realize. Models can reliably choose from a moderate tool set, typically 10 to 30 tools, when each tool has a clear name and description. Beyond that range, tool selection accuracy degrades because the model must reason about too many options at each decision point. If your agent needs more than 30 tools, consider grouping related tools into categories that the agent selects first, or splitting the workload across multiple specialized agents.

Tool descriptions are part of the prompt and deserve the same care as any other prompt component. A description that says "searches the database" forces the model to guess what parameters are expected and what the results look like. A description that specifies the input format, the output structure, common error cases, and when to use this tool versus alternatives gives the model the information it needs to use the tool correctly on the first attempt. Every failed tool call wastes tokens and time, so investing in precise tool descriptions has immediate returns.

Memory Architecture

A single agent's memory architecture determines how much context it can bring to bear on each decision. The simplest approach is a growing conversation history that includes every previous action and result. This works for short tasks but breaks down for longer ones because the history eventually exceeds the model's context window, and even before that point, performance degrades as the model must process an increasingly large context at each step.

More sophisticated memory architectures separate short-term working memory from long-term persistent memory. Working memory holds the current task state: what the agent is trying to accomplish, what it has done so far, what intermediate results it has collected, and what it plans to do next. This working memory is typically small enough to fit in the model's context window throughout the entire task. Long-term memory stores information that persists across tasks and sessions: learned preferences, accumulated knowledge, past decisions and their outcomes, and frequently used reference information.

The mechanism for accessing long-term memory varies. Some systems use vector databases to retrieve semantically relevant memories based on the current context. Others use structured storage with explicit retrieval queries. The most effective approaches combine both: structured storage for well-defined information (user preferences, configuration, reference data) and vector retrieval for unstructured information (past conversations, accumulated knowledge, contextual notes). The retrieval mechanism is itself a tool that the agent can invoke when it needs additional context.

Memory also serves a compression function. Rather than maintaining the complete history of every action and result, the agent periodically summarizes its progress and replaces the detailed history with a compact summary. This keeps the context window manageable during long tasks while preserving the essential information the agent needs to continue making good decisions. The summarization can happen automatically at fixed intervals or when the context approaches the window limit.

Error Recovery

Production single-agent systems encounter errors constantly. APIs return 500 errors. Rate limits are hit. Tool inputs are malformed. External services time out. Data is missing or in unexpected formats. The architecture must handle these errors gracefully rather than crashing or producing incorrect results.

The first line of defense is tool-level error handling. When a tool call fails, the error message should be informative enough for the agent to understand what went wrong and choose an appropriate response. A message like "API returned 429: rate limit exceeded, retry after 30 seconds" gives the agent actionable information. A message like "tool failed" gives it nothing to work with. Well-designed tools return structured error information that includes the error type, a human-readable message, and suggested remediation when applicable.

The second line of defense is agent-level reasoning about errors. A capable model can interpret error messages, decide whether to retry the same action, try an alternative approach, skip the current step and proceed with partial information, or report the error to the user. This reasoning is what separates agents from simple automation. Automation follows a fixed error handling path. An agent dynamically reasons about the best recovery strategy based on the specific error, the current task context, and what alternatives are available.

The third line of defense is system-level safeguards. Circuit breakers prevent the agent from hammering a failing service. Retry limits prevent infinite retry loops. Timeout limits prevent the agent from hanging indefinitely on a slow operation. Dead letter mechanisms capture tasks that fail repeatedly so they can be investigated without blocking other work. These safeguards operate outside the agent's reasoning loop and provide protection even when the agent's reasoning about errors is incorrect.

When Single Agent Is Not Enough

Single-agent architecture has clear limits. Recognizing when you have hit those limits is as important as knowing how to build a good single agent.

The most common signal is context window pressure. When the task requires so much context that the agent cannot fit the task description, current state, tool descriptions, and relevant memories into a single model call, the agent starts losing track of information. It forgets earlier steps, misses relevant context, or makes decisions based on incomplete information. If you find yourself constantly tuning what to include in the context and what to leave out, the task may be too large for a single agent.

Another signal is role confusion. When the same agent needs to switch between fundamentally different modes of operation, like researching information and then critically evaluating that same information, it tends to carry biases from one mode into the other. A dedicated research agent and a dedicated review agent, each with their own prompt and perspective, produce better results than a single agent trying to wear both hats.

Performance requirements can also push you beyond single-agent architecture. A single agent is inherently sequential: it takes one action at a time, waits for the result, and then takes the next action. If the task involves multiple independent subtasks that could run in parallel, a multi-agent system can complete the work in a fraction of the time by assigning each subtask to a separate agent that runs concurrently.

However, these signals should be treated as triggers for investigation, not automatic decisions to switch architectures. Multi-agent systems introduce coordination complexity, consistency challenges, and debugging difficulty that may outweigh the benefits. Before moving to multi-agent architecture, exhaust the optimization options for your single agent: better prompt engineering, smarter context management, more focused tool design, and improved memory architecture. Many tasks that seem to require multiple agents can be handled by a single well-designed agent.

Production Design Checklist

Building a production-grade single agent requires attention to several concerns beyond the basic reasoning loop. The agent needs clear termination conditions that prevent runaway execution. It needs token and cost budgets that cap spending per task. It needs structured logging that captures every decision point for debugging and auditing. It needs input validation that rejects malformed or malicious inputs before they reach the model. It needs output validation that checks the agent's results against expected formats and constraints before returning them to the user.

The agent also needs a clean interface for human escalation. Not every task can be completed autonomously. Some require information the agent does not have access to. Some involve decisions that are too consequential to delegate. Some encounter edge cases that fall outside the agent's capabilities. A production agent recognizes these situations and escalates to a human with clear context about what was attempted, what failed, and what decision needs to be made. This escalation path is not a failure mode. It is a designed-in safety mechanism that builds trust by ensuring the agent never takes action beyond its competence.