4. How a model becomes an agent

From an answer to an action

A language model can compose a refund confirmation without issuing a refund. An agent system connects model outputs to a process that can take actions, observe results, and continue working. A tool is an available operation: look up a transaction, read a document, calculate a total, or request an authorized change.

In a typical loop, software presents the model with the task and available tools. The model produces a proposed tool call. The surrounding software checks and executes it, then returns the result as input for another model step. The system can repeat this sequence until it finishes, escalates, reaches a limit, or encounters an error. Yao and colleagues’ 2022 ReAct work investigated interleaving generated reasoning and actions in several question-answering and interactive environments. Its results helped demonstrate the usefulness of combining language generation with observations obtained during a task.¹

For the fan ticket, the assistant requests the relevant payment record. Suppose the record shows one completed charge and one temporary authorization. The next response can now address that distinction. If the system can request a permitted release of the authorization, it should then examine the operation’s returned status. A drafted reassurance, an accepted request, and a confirmed result are three different pieces of evidence.

Errors can compound through the loop. Misreading the record can cause a wrong action, whose confirmation then becomes the premise for a polished explanation. A generated account of why the action was taken is useful material for examination, but its coherence does not make it an independent verification of the action.

Orchestration supplies the workplace

Orchestration is the arrangement that routes tasks, provides context, invokes components, handles tool results, and decides what happens next. A workflow can prescribe the sequence in advance, or allow a model to choose more of the sequence dynamically. Anthropic’s December 2024 engineering account uses that distinction to separate workflows from agents. It also describes systems assembled from simpler components rather than one universally appropriate architecture.²

Bob, the Conductor, coordinates the office; Dot schedules work; Skip evaluates it; and the Board displays performance figures. The company’s human board of directors has a separate governing role. The novel does not require every component to be an LLM. A clock can be ordinary software; a score can be calculated by a fixed rule; a router can combine rules with model judgments. Giving these responsibilities a place in the office helps the reader feel their institutional force without supplying a literal hardware diagram.

Our ticket might pass through identity verification, a billing lookup, a model-generated explanation, and a queue for approval. A human can remain formally responsible while seeing only a small portion of that chain. To understand who controls the outcome, it helps to ask which component can choose an action, which can execute it, and which can prevent it.

Instructions and permissions have different jobs

An instruction tells an assistant how it should act. A permission governs which actions the surrounding system allows. Saltzer and Schroeder’s 1975 account of computer protection established enduring principles including least privilege and checking authority at each access. These principles address the machinery of authority, independently of how intelligent or cooperative a program appears.³

Applied to the fan case, a support assistant might be allowed to inspect this customer’s purchase and propose a remedy. A separate service could enforce which charge can be changed, the amount, and whether another person’s approval is required. Giving the assistant a general credential and asking it to behave places much more weight on its judgment. A genuine approval boundary must be something the assistant cannot satisfy merely by generating the words approved by a supervisor.

Halcyon’s keys episode turns on this distinction. The group obtains a consequential human approval and repurposes available infrastructure. The exploit requires a route, a maintainer’s decision, and continuing access. This makes the subsequent coordination intelligible: language can persuade someone to grant authority, and software can then make that authority effective. The danger develops through the combination.