This episode builds the smallest useful agentic system, starting with one model response and ending with a controlled loop that can act, observe, continue, stop, retry, or escalate. An agentic loop is a repeating application process in which a model can choose a permitted action, receive the result, and use that new information to decide what comes next. A model with tool descriptions is therefore not a complete agent, because software around the model must still interpret requests, protect state, run tools, and decide who gets control next. Control flow means the rules that determine which step runs next, while an orchestrator is the application component that applies those rules across model calls and tool calls.

You can loosely picture the orchestrator as a traffic controller, although the analogy is limited because software must also validate data, enforce permissions, and retain an exact record of events. With the Messages API, where API stands for application programming interface, the application constructs each request and keeps the conversation information required for later turns. Application state is the information the application retains between steps, including relevant messages, requested actions, returned observations, permissions, retry counts, and workflow status. A state transition is simply a move from one known condition to another, such as waiting for the model, validating a tool request, executing a tool, or returning an answer.

The application sends Claude the relevant messages and available tool definitions, which identify each permitted tool and the input structure it accepts, then receives a response made from one or more content blocks. A content block is a structured part of a response, and it might contain ordinary text, a request to use a tool, or another supported kind of content. A tool request is typed when it names a particular tool and supplies inputs in the structure declared for that tool. That declared structure is called a schema, which describes expected fields and data shapes but does not prove that the supplied values are sensible or true.

This is the first important distinction: syntax concerns whether data has the expected form, while truth concerns whether it accurately represents the real situation. The response also carries a stop reason, which is a machine-readable indication of why the model finished generating that response. When the stop reason indicates tool use, the normal next step is for the application to inspect and possibly execute the requested tool rather than present the response as finished. When the stop reason indicates end turn, the application will normally stop the model loop and present the resulting response, subject to any remaining workflow rules. Text that merely sounds conclusive is not a dependable control signal, because the model can provide an explanation and then request a tool in the same response.

Searching prose for phrases such as task complete would make small variations in wording control application behavior, which is far too fragile for an operational state machine. A state machine is a defined collection of states and allowed transitions, so its decisions should come from structured signals and verified workflow facts rather than persuasive wording. Prompts and enforcement must remain separate because a prompt asks the model to behave a certain way, while enforcement is code or service policy that prevents disallowed behavior. A prompt can say never issue an excessive refund, but only a trusted service-side limit can reliably reject a refund outside the caller's authority.

The basic loop is easy to say aloud: send a request, inspect the response, validate any action, execute it, append the observation, and request the next decision. A fixed iteration limit can contain a runaway loop, but reaching that limit does not mean the underlying task succeeded. Stopping primarily because a counter reached its ceiling can interrupt a valid investigation or hide the fact that every attempt is failing in the same way. The essential memory unit in a tool-using turn is the action-observation pair, meaning the requested action and the environmental result that followed it. When Claude requests a tool, the application preserves the assistant content containing that request in the conversation history.

After execution, the application appends a user-side tool-result block that refers to the matching tool-use identifier. A tool-use identifier is the unique reference that connects a particular request to its particular result, even when several requests appear together. Without that link, the model might associate a customer record with the wrong lookup, treat an error as a success, or reason from an observation that belongs to another action. The full sequence should also live in a durable record, meaning a retained log outside the immediate conversation, so later review does not depend on the shortened information supplied to the model. Harbour Resolution is a fictional company that we will use to make this loop concrete rather than presenting it as a real deployment.

In this hypothetical case, a support worker sees a customer's message saying that one purchase appears to have been charged twice. The tempting mistake is to let the model interpret the complaint as proof and immediately call a refund tool. A better design first authenticates the caller, meaning it verifies the caller’s claimed identity, and then checks authorization, meaning it determines what that identity is allowed to see or do. Authentication and authorization answer different questions, so a valid login does not by itself grant permission to inspect every customer or issue money. After those checks, Claude can request a customer lookup using a stable customer identifier rather than relying on a possibly ambiguous name.

The application validates the request, invokes the customer service, and returns only the safe customer details needed for the next decision. Claude may then request a transaction list and compare records that could correspond to the complaint. Those transaction records are evidence, meaning observations returned by an authoritative system, while the conclusion that two similar entries are duplicates remains an inference drawn from that evidence. Evidence can support an inference without guaranteeing it, because similar charges might represent separate purchases, a pending authorization, or incomplete data. The better loop therefore allows Claude to request more relevant information, recommend escalation, or state that the available evidence does not establish a duplicate.

The worker would see a clear status and the known facts, not a confident refund claim manufactured to make the workflow feel complete. Even this design has limits because a lookup service can be stale, unavailable, or incomplete, so the final language must preserve uncertainty when the evidence does. If the customer confirms wanting a refund, that confirmation establishes the customer's expressed intent but does not constitute authorized approval for the business action. Authorized approval requires the designated person or policy-controlled service to verify that the action is permitted within the relevant limits. Confirmation and approval may occur close together in a user interface, but the architecture should record them as different events with different authority.

Claude chooses among the next actions that the application has permitted, instead of receiving a handwritten branch for every possible complaint. That flexibility is useful when language and evidence vary, but it does not mean every part of the process should become model-directed. A deterministic workflow follows explicit rules and produces the prescribed transition for the same relevant conditions. Deterministic logic is usually preferable when a process is fully known, the rules are stable, and creative interpretation adds little value. A hybrid design combines that predictable workflow with model judgment only where interpretation or flexible tool selection is genuinely useful. In a hypothetical employee-onboarding office, a coordinator might see a new starter whose account, equipment, and building access are all pending.

The tempting design is to ask the model to manage the entire process autonomously because the request arrived in natural language. A stronger hybrid lets fixed software authenticate the coordinator, retrieve the case, enforce role boundaries, and create required approval tasks. Within those boundaries, Claude can interpret the request, choose relevant read-only lookups that retrieve information without changing stored state, and draft a recommendation for the coordinator. The limitation is that hybrid systems still need explicit ownership of each transition, because placing deterministic and model-directed steps together does not automatically resolve ambiguous responsibility. Before any requested tool runs, the application should verify the tool name against its permitted set, validate the input schema, check authorization scope, and apply operational policy.

Authorization scope is the precise set of resources and actions granted to the current caller, rather than a general feeling that the request seems legitimate. Operational policy is the enforceable set of conditions governing when and how an action may run, including limits, required approvals, and prohibited states. The tool name and inputs must be treated as untrusted proposed action data, even when they were produced in response to a careful prompt. A structurally valid request can still be semantically invalid, where semantic validity means that the values make sense in the real business situation. A negative payment amount might fit a numeric schema while violating a domain rule, which is a business constraint enforced by the payment service.

The tool or underlying service should reject that request with a structured error, meaning a predictable set of fields the controller can inspect, rather than guess what the model intended. For actions that could create duplicate effects, the application should establish idempotency, meaning that safely repeating the same intended operation does not create the effect twice. An idempotency key is a stable request token that lets the service recognize a repeated operation as the same intended action. A transaction boundary defines which related changes must succeed or fail together so the system does not leave a half-completed financial operation. Server-side amount controls ensure that the trusted service, rather than the model or interface, enforces permitted values and limits.

The model should not be asked to remember whether a payment already occurred, because conversation memory is not a reliable financial ledger. In a hypothetical procurement office, a finance worker might see an invoice accompanied by a friendly message claiming that urgent payment has been approved. The tempting response is to trust the message, ask the model for confirmation, and send the payment request again if the screen appears slow. The better design checks the authenticated approver's authorization, validates the invoice against authoritative records, and submits the payment through an idempotent service with enforced limits. The worker's click can confirm an instruction, but an authorized approval record and server-side policy must determine whether payment may actually proceed.

Idempotency reduces duplicate effects, but it does not prove that the original invoice, recipient, amount, or approval was correct. A useful tool failure is returned as a structured error with a stable code, a safe explanation, an indication of whether retry might help, and any correctable fields. An invalid currency error suggests changing the input, whereas a temporary service unavailable error may justify trying the same valid request again. A bounded retry is a limited number of repeat attempts, and backoff means waiting progressively longer between attempts so a struggling service is not hammered continuously. Retrying malformed or forbidden input is usually pointless because time does not repair bad meaning or missing authority.

A tool adapter is application code that converts the agent’s standardized requests and results into the format used by the internal service that performs the work. The adapter should normalize failures, meaning it converts many implementation-specific exceptions into a small and consistent error contract. An error contract is the agreed structured shape used to report failures without exposing secrets, stack traces, or raw database exceptions to the model. In a hypothetical information-technology service desk, an analyst might see an account-unlock request that repeatedly returns the same policy-denied code. The tempting mistake is to let the agent retry because the requested action has not yet succeeded.

A better controller recognizes that the error is non-retryable, stops further calls, and directs the case to the authorized support path. That escalation cannot guarantee rapid resolution, but it prevents repeated execution from being mistaken for progress. The model context is the information included in the current request for the model to consider, and it should contain enough observation data for the next decision without becoming an unbounded backend dump. Verbose tool output consumes processing capacity, distracts from task-relevant facts, and can push earlier information out of the usable context. A task-relevant projection is a deliberately selected view of a larger result that keeps the fields needed for reasoning while omitting irrelevant or unsafe details.

The projection should retain identifiers and provenance, where provenance means information showing where a fact came from and how it can be traced during later review. The complete backend response can remain in a protected durable record even when the model receives only the safe projection. This arrangement improves focus and reviewability, but a projection can accidentally omit a decisive field, so the system should track which projection rules produced each view and manage changes to those rules carefully. In a hypothetical compliance review, an analyst might see a concise case summary while the full source records remain in a controlled evidence store. The tempting shortcut is to paste every record into the model context in case one field becomes useful.

The better design supplies the relevant claims, their source identifiers, and a way for permitted follow-up tools to retrieve more evidence when needed. Its limitation is that retrieval choices can shape the conclusion, so the system must distinguish what was actually observed from what the model inferred about missing material. Claude can sometimes request multiple independent read-only tools in one response, and the orchestrator need not always execute them one after another. Serial execution means one call finishes before the next begins, while parallel execution means independent calls can run during the same interval. Parallel calls are appropriate only when their permissions, inputs, dependencies, and failure handling do not require a particular order.

A dependency exists when a later call needs a value or successful state created by an earlier call, which makes ordered execution necessary. Results from parallel calls still need their original tool-use identifiers and deterministic aggregation, meaning a predictable method for assembling them regardless of completion timing. In a hypothetical logistics office, a dispatcher might see a delayed shipment after the order record has already supplied both an inventory reference and a carrier reference. The tempting approach is either to run every available logistics tool or to run the two relevant lookups serially without considering their independence. A better orchestrator can request inventory status and carrier status in parallel, then return each observation under the correct identifier.

If one lookup fails, the controller must preserve the successful evidence, classify the failure, and decide whether a retry, partial answer, or escalation is justified. Parallelism can reduce latency, which is the time a person waits for a result, but it also makes cancellation, partial failure, rate limits, which are service rules restricting how frequently calls may be made, and result ordering more complicated. An agent that invokes every available tool for every request creates unnecessary latency, cost, irrelevant context, and a larger attack surface. Attack surface means the number and reach of opportunities through which mistakes, malicious inputs, or compromised components could cause harm.

Tool choice may therefore be automatic within a permitted set, restricted to one specific tool, or disabled entirely for a given step. Automatic choice gives the model discretion among approved capabilities, restricted choice narrows the next action, and disabled choice guarantees that no tool is requested at that boundary. A sensitive workflow may intentionally expose only read-only tools to the model while reserving state-changing actions for deterministic code and explicit approval. The right boundary is based on the task and consequences, not on a general preference for maximum autonomy. Termination deserves separate design because a valid tool-use stop reason says the model wants another action, not that continued execution is always wise.

Suppose a lookup returns not found and Claude requests the identical lookup again with unchanged input. The application should detect the repeated call pattern, consult its retry policy, and avoid treating an unchanged request as fresh progress. If repetition cannot help, the adapter should return or preserve a clear terminal error, and the orchestrator should end safely or escalate. A terminal error is a failure state that the current loop cannot productively correct with another permitted attempt. A loop budget is a limit on calls, time, cost, or another resource that contains pathological behavior without claiming the task was completed. The important trade-off is that a tight budget can halt legitimate work, while a loose budget permits more waste or repeated exposure to failing components.

When the budget or another safety boundary stops the loop, the final response should say which facts remain unresolved rather than fabricate an answer. Escalation means transferring control to a person or another governed process because the agent cannot safely or authoritatively finish the task. A confirmed workflow state is an application-verified condition, such as an approval service recording an authorized decision, rather than the model merely saying that approval exists. The loop can therefore stop at end turn, a governed escalation, a confirmed workflow state, a terminal error, or a safety boundary, depending on the surrounding business rules. These application completion states extend the API's stop semantics without pretending that an API signal alone proves business success.

Model protocol is the structured exchange of messages, tool requests, results, and stop reasons, while business protocol is the organization's enforced sequence of permissions, validations, approvals, and records. A reliable agentic system joins those two protocols while continuing to separate prompts from enforcement, syntax from truth, authentication from authorization, evidence from inference, and confirmation from authorized approval. The core idea is simple: preserve every action and observation, let the model choose only within governed boundaries, and stop with an honest account of what the system actually knows.