The Single-Agent Loop: Autonomy with a Boundary
The single-agent loop is the basic unit of autonomous workflow execution: one agent receives a task, chooses a next step, uses a tool, observes the result, and decides what follows. The question here is not whether one model can perform many kinds of work. It is how a single coherent loop adapts without losing its state, exceeding its authority, or continuing after the task should have stopped. Understanding that mechanism gives the reader a disciplined way to extend one agent—and to recognize when extension has become a structural problem.
The loop builds directly on the model, tools, and instructions already defined. It does not replace them with a hidden process. It makes their relationship temporal. The model interprets the current state; the tools change what the agent can know or do; the instructions shape which transitions are allowed; and the run ends when a defined condition is reached.
The run is a loop, not a single call
A request may look like one interaction to the user, but an agent run can contain several decisions. The agent first interprets the goal and determines what information is missing. It may call a data tool, inspect the returned context, refine the question, and call another tool. If the task involves an external action, the agent must decide not only what action appears appropriate but whether the available context and authority are sufficient to request it. Each result becomes part of the state from which the next decision is made.
The loop has a useful asymmetry. The model can choose among the capabilities exposed to it, but it does not create a new external authority merely by describing an action. A data tool may return a record; an action tool may update one. The result of either call changes the next decision, but the surrounding system still determines what the call is allowed to do. This is why the same model can be appropriate for two workflows with very different risk: the tools, instructions, and exits change the operating boundary.
Observation changes the next decision
Adaptation is not a mystical property added after the model answers. It comes from feeding the result of one step back into the decision process. Suppose a support agent searches a knowledge base and finds that the relevant policy requires an account identifier that the user did not provide. The result does not finish the task; it changes the next action to a request for missing information or a handback. If the search returns no matching policy, the agent may need to state that the available evidence is insufficient rather than inventing one. If an action tool returns an error, retrying the identical call may be less useful than checking its parameters, gathering more context, or stopping.
This feedback loop is what separates an agent from a script that simply calls a model at each predefined stage. The route can change in response to the environment. But flexibility also creates more possible failure paths. An agent may misread a tool result, treat an error as success, select a similar but inappropriate tool, or carry forward stale context. The architecture must therefore make observations legible and make the consequences of each transition explicit.
The supplied guides describe a run as continuing until a final output or structured completion is reached, an error occurs, or a maximum number of turns is exhausted. These are not implementation trivia. They are competing answers to the question of who owns the next move. A final output transfers the result back to the user. An error stops the system because the current route is no longer reliable. A turn limit stops persistence from becoming an unbounded expense or an infinite loop. The exact limits depend on the workflow, but the existence of limits does not.
The same distinction applies to action results. A successful tool response does not necessarily mean the user's goal is complete; it may only confirm that one stage finished. Conversely, a technically successful call can still leave the task unresolved if it returned an empty result or changed the wrong record. The run policy should therefore connect tool outcomes to workflow outcomes. It should say what evidence is enough to continue, what evidence is enough to finish, and what ambiguity requires a person. Without that mapping, the model is left to infer completion from language, even though completion is a property of the surrounding process.
The boundary is the exit condition
An autonomous system is defined as much by how it stops as by how it acts. A useful run can end with a completed result, but it can also end with a clear refusal, a request for missing information, a technical failure, or a human handback. These states should not be collapsed into one generic error message. They imply different repairs and different responsibilities.
Completion means the stated task has been satisfied according to an observable condition. For a retrieval task, that might mean the requested information was found and returned with its relevant context. For a support escalation, it might mean the issue was resolved or transferred with enough information for the next owner. A fluent response alone does not establish completion. The agent needs an output condition that corresponds to the workflow's goal.
Failure means the agent cannot proceed reliably under the current conditions. The tool may be unavailable, the records may conflict, or the instructions may not cover the request. A bounded retry can make sense when the failure is transient or a parameter can be corrected. Repeating an action without new information is not recovery; it is more of the same uncertainty. The loop should expose the difference so an operator can distinguish a temporary service problem from a design gap.
Human review is a deliberate exit for situations where the cost of an autonomous mistake is high or the agent has exceeded a failure threshold. The supplied guidance highlights sensitive or irreversible actions such as canceling an order, authorizing a large refund, or making a payment. It also recommends intervention when repeated attempts fail to establish user intent. In those cases, handing control to a person is not a failure of autonomy. It is the mechanism that keeps the system's authority proportional to its confidence and the consequence of the action.
A handback should carry the state needed to resume responsibly: what the user asked, which sources were consulted, which actions were attempted, what failed, and why the agent stopped. Otherwise a human receives only a vague apology and must repeat the investigation, while the system loses the evidence that could improve it. The human boundary is therefore both a safety mechanism and an operational interface. It defines a change of owner, not simply a message saying that the model is uncertain.
Growing capability before adding agents
A single agent can often gain useful capability without being split. Reusable tools make new data and actions available. Prompt templates let one operating routine adapt to different policies or user contexts. Specialized Skills can add domain knowledge, workflows, and integrations without forcing all expertise into one giant instruction. This incremental approach keeps the control loop visible and usually makes evaluation and maintenance easier than introducing several independent decision-makers immediately.
Modularity matters because the components change at different rates. A tool may need a new permission boundary; a policy may change its branches; a model may improve enough to reduce latency or cost; a Skill may be reused in another workflow. If those concerns are entangled in one monolithic prompt, a local change can alter unrelated behavior. Separating them does not guarantee stability, but it gives a team a smaller surface to test and a clearer explanation for a changed result.
Observability must follow the loop across those boundaries. Ordinary application logs can show that a request succeeded or failed, but agent debugging may require the prompt chain, model decision path, retrieved context, token consumption, tool calls, and the reason a run ended. The system is non-deterministic: the same input may not produce an identical route on every run. A stack trace can reveal where software stopped, but not necessarily why the agent chose a particular record, ignored a tool result, or continued after an ambiguous response. Capturing that decision context is therefore part of operating the agent, not an optional reporting layer.
The useful unit of observation is not only the final response but the transition that produced it. Teams can compare which tools were selected, how often retries occur, where runs stop, how much context is consumed, and which handbacks recur. Those signals do not by themselves explain a cause, but they narrow the search. A spike in retries may indicate an unreliable external service, an unclear parameter, or an instruction that sends the agent down the wrong path. Keeping the run visible lets the team test those possibilities instead of reacting to a vague quality score.
Context is an operating limit
Every additional tool result enlarges the material the agent must keep coherent. In a long run, stale calls and irrelevant outputs can crowd out the information needed for the next decision. The sources identify context-window overflow, degraded reasoning, and coordination failure as practical risks. Context management is therefore more than buying a larger model window. It is deciding what state remains active, what can be summarized or discarded, and what must persist outside the immediate interaction.
Several controls follow from that view. Tools can return only the relevant range, paginate large results, filter records, and truncate output with sensible defaults. The agent can edit away stale calls and results as the task evolves. Important information can persist in a file or other memory mechanism outside the active context and be retrieved when needed. Each choice has a cost: truncation can remove a crucial qualification, summaries can lose provenance, and persistent memory raises questions about freshness, access, and deletion. The point is not to eliminate those trade-offs but to make them visible.
A context problem often appears first as a reasoning problem. The agent seems less consistent, repeats a search, forgets a constraint, or merges evidence from unrelated parts of the task. The symptoms can be misleading because the model may still produce fluent prose while the decision path has degraded. An operator needs to compare the active context with the tool results and the intended task state: which constraint disappeared, which result was duplicated, and which stale instruction remained influential?
Adding another agent may make the symptom worse if it creates more messages and more context to transfer. Before splitting the system, inspect what each step receives, what it returns, and which information actually needs to survive the boundary. A compact state representation may repair the loop; a better tool response may remove irrelevant material; a persistent record may separate durable facts from transient conversation. If those changes cannot keep one agent coherent because the task contains incompatible bodies of expertise or independent investigations, then the evidence for a structural split is stronger.
When a split is a real architectural response
The guidance recommends maximizing a single agent before creating multiple agents. A split is justified when it solves a demonstrated boundary: conditional instructions have become unmanageable, tools remain confusing or overlapping after their interfaces are clarified, distinct domains require different expertise, or one context cannot remain coherent. The raw number of tools is not the diagnosis. The question is whether the agent can reliably distinguish and coordinate the capabilities it has.
This distinction protects teams from treating every poor result as proof that more agents are needed. A missing branch in the instructions is an instruction problem. An overly broad tool is an interface and authorization problem. A response that contains too much irrelevant material is a context-design problem. A single agent that must simultaneously perform several independent investigations, or coordinate genuinely distinct domains, may have reached a structural limit. Those cases can justify distributing work, but the distribution changes ownership, context, and observability; it is not a free increase in intelligence.
The diagnostic threshold is thus practical. First ask whether clearer instructions, better tool descriptions, modular Skills, bounded outputs, or improved tracing can repair the loop. If the same failure persists because the task contains competing responsibilities or incompatible contexts, then a new coordination boundary may be warranted. The next decision is not simply how to add agents. It is how control should move while preserving a clear owner for each result and a safe route out when the distributed system cannot agree.