Part I. The missing loop

The modern argument began long before large language models. Wooldridge and Jennings warned in 1995 that “agent” risked becoming a noise term because the field lacked a universally accepted definition. Franklin and Graesser then surveyed competing definitions and proposed a broad core: an autonomous agent is situated in an environment, senses it, acts on it over time, pursues an agenda, and acts in ways that can affect what it senses later. The useful part of that older debate is not the exact wording. It is the emphasis on ongoing coupling between system and environment.

A one-shot model call has a simpler causal shape. Given context c and parameters θ, it samples or selects an output y from a distribution:

Model: y ~ fθ(c).

That expression does not contain an environment transition. It says nothing about whether the output is displayed to a person, parsed as JSON, ignored, rejected by a validator or converted into a bank transfer. It also says nothing about a next observation. Agency appears only when another system gives the output operational semantics.

A minimum useful definition

Definitions can become lists of fashionable features: memory, reflection, planning, browsing, code execution, personas, multi-agent debate. That is the wrong direction. A thermostat is a useful edge case because it is an agent under a weak classical notion even though it has no language model, no explicit plan and no vector database. Conversely, a language model can produce an elaborate plan without being connected to any action loop at all.

For LLM systems, a useful minimum is this: an agent is a goal-conditioned system that repeatedly observes a task environment, chooses among available actions, receives consequences or feedback, updates its operative state, and decides whether to continue. The policy that chooses the action may be an LLM, a classifier, a rule set, an RL policy or a hybrid. The goal may be supplied by a user, a workflow, a standing objective or another agent. Nothing in the definition requires the system to “want” the goal in a psychological sense.

A compact formalism makes the boundary clearer. Let E_t be the environment at step t, s_t the agent’s operative state, g its current goal, and A_t the actions currently available. The runtime performs:

o_t = Observe(E_t); a_t ~ π(a | g, s_t, o_t, A_t); E_{t+1} = Execute(E_t, a_t); s_{t+1} = Update(s_t, o_t, a_t, E_{t+1}).

A stopping function decides whether to continue. If the policy π is implemented by a language model, the model is still not identical to the agent. The agent is the recurrent state-transition system in which that model participates.

Part II. Same model, different systems

The easiest way to see the distinction is to hold the model constant and vary the surrounding system. This is also the cleanest thought experiment because it changes one causal feature at a time.

Thought experiment one: the frozen checkpoint

Suppose checkpoint M receives a customer-service transcript. In configuration A, M generates a suggested reply and stops. In configuration B, an application always performs the same three operations: retrieve account status, ask M for a reply, then present the reply to a human. In configuration C, M can choose from ask user, retrieve order, retrieve policy, propose refund, escalate and finish. After each chosen operation, the runtime returns the result and M chooses again.

Configurations A and B may be useful. B may even contain several model calls. Yet in both, the path through the system is specified by code before the particular case arrives. C is different because the next transition depends on the model’s choice under the current observation. Anthropic makes essentially this architectural distinction between workflows, whose code paths are predefined, and agents, where the model dynamically directs its own process and tool use. That distinction is an implementation convention rather than a law of nature, but it is operationally useful.

Model capability and system agency are therefore separable variables. Improving M may improve each configuration, but it does not convert A into C. Conversely, changing the runtime can increase the system’s degree of agency without changing M at all.

Thought experiment two: remove feedback, keep everything else

Now start with configuration C and cut one wire. Let the system execute the model’s first tool proposal, but never return the result. It instead asks the model for a second action using the original state. The model still has a goal, tools, a scratchpad and perhaps a plan. Yet its later choices cannot condition on the consequences of earlier actions.

This system can produce a sequence of commands, but it no longer has the key adaptive property that Franklin and Graesser highlighted: current actions affect later sensing and thereby later action. If the first action failed, succeeded partially or changed the world unexpectedly, the policy cannot react. Feedback is not “self-critique”; it is information about what the world became after an action.

The fixed-workflow negative control

A strong argument needs a system that looks agentic but should not require the agent explanation. Consider a loan-document preparation pipeline with six model calls, retrieval, a calculator and a document generator. Step 1 classifies the document. Step 2 retrieves the policy. Step 3 extracts values. Step 4 calculates ratios. Step 5 drafts text. Step 6 checks formatting. Every branch is specified in code. The model cannot decide to retrieve a different source, repeat extraction after a contradiction or stop early because evidence is missing.

This pipeline has models, tools, state and multiple steps. It may even be more reliable than an agent for its task. Yet calling it an agent adds little explanatory value because the control policy is the workflow graph, not a model-directed action loop. This is the serious negative control for loose definitions such as “an LLM that uses tools” or “an LLM that performs multi-step work”.

The negative control matters architecturally. If the sequence is enumerable and stable, a workflow gives you simpler testing, narrower permissions and easier recovery. Forcing an agent into that shape often spends latency and increases behavioural variance without buying useful flexibility. Anthropic explicitly recommends starting with the simplest pattern that works and using agents when model-directed flexibility is needed. That is practitioner guidance, not a universal theorem, but it aligns with the causal distinction.

flowchart TD
  A["Part I. The missing loop"] --> B["Part II. Same model, different<br/>systems"]
  B --> C["Part III. State, memory and<br/>goals without anthropomorphism"]
  C --> D["Part IV. The operational<br/>boundary is larger than<br/>minimal agency"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#B96D00,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Part III. State, memory and goals without anthropomorphism

Once the loop is visible, several common confusions become easier to remove.

State is necessary; long-term memory is not

An agent must have enough operative state to make its next choice depend on where it is in the task. That state need not be a persistent memory store. It can be the current environment observation, a small step counter, a database record, a workflow token or the active context window. A reactive control agent may carry almost no internal history.

Long-term episodic or semantic memory is an optional augmentation. Generative Agents, for example, added a natural-language memory stream, retrieval and reflection to support believable behaviour over time. Voyager added an executable skill library and environment feedback to support open-ended behaviour in Minecraft. These are important capabilities, but they are subclasses of agent architecture rather than prerequisites for agency.

Do not use “memory” as a synonym for every piece of persistent information. The inventory quantity in a source system is world state. The record that the agent placed an order is an event. A retrieved purchasing policy is context. A summary of a previous run may be episodic memory. Collapsing them into one bucket makes it hard to know what can be stale, what can be trusted and what can authorise an action.

A goal is a control variable, not a claim about desire

Agent language easily slides into psychology. “The agent wants to resolve the case” may be harmless shorthand, but it hides a more useful engineering description: the runtime was configured with a termination condition, reward proxy, task objective or instruction that makes some future states preferable to others.

A warehouse agent can be given stock ≥ 3 as an objective. A research agent can be asked to produce an answer that satisfies evidence criteria. A coding agent can be given a test suite as the external condition it is trying to make pass. None of this implies subjective desire. The word “goal” simply marks the condition that organises action selection across more than one step.

Planning is optional

An agent may construct a plan before acting, may follow a local policy one step at a time, or may alternate between the two. ReAct made the interleaving explicit for language models by alternating reasoning traces and environment actions. Its value for this paper is structural: actions return observations that can change later reasoning. The mechanism does not require a grand plan.

This matters because “agent = planner” fails on both sides. Reactive agents exist without explicit plans, while a one-shot model can produce a detailed plan that no system will ever execute. Paper 115 in this canon treats plans, policies and replanning separately because they are choices inside an agent architecture, not the definition of an agent itself.

What agent benchmarks actually measure

Modern benchmarks reinforce the system-level view because they cannot evaluate useful agency by scoring a single generated string. AgentBench places models in eight interactive environments and evaluates multi-turn decision-making. GAIA uses questions that require combinations of reasoning, browsing, multimodal handling and tool use. ToolSandbox explicitly evaluates stateful tool execution, implicit state dependencies and intermediate milestones. τ-bench compares the final database state with an annotated goal state and measures consistency across repeated trials.

The benchmark details differ, but their shared move is important: evaluation shifts from isolated output quality to trajectories through an environment. τ-bench reported that the function-calling agents it tested succeeded on fewer than half of its tasks and were inconsistent across repeated runs. ToolSandbox found state dependency, canonicalisation and insufficient-information cases challenging even for strong models. AgentDojo adds adversarial tool-returned content and asks whether an agent both accomplishes the user task and preserves security properties. TheAgentCompany goes further by creating a simulated software company where agents browse, write code, run programs and communicate with co-workers.

These results should not be universalised across models or future systems. They are benchmark-bound measurements. Their more durable lesson is methodological: when a system can act, the object of evaluation includes which action was chosen, with which arguments, after which observation, what changed, whether rules were followed, and whether the stopping condition was justified. A leaderboard number for the underlying model cannot answer those questions.

Part IV. The operational boundary is larger than minimal agency

Classical definitions ask whether a system senses and acts autonomously over time. Production architecture has another problem: who may cause which effect, on whose behalf, and how can the effect be reconstructed afterwards? Those questions are not necessary to decide whether a thermostat is an agent. They are necessary to decide whether a software agent should be allowed to change consequential state.

For that reason, it helps to distinguish two boundaries. The minimal agency boundary contains a goal, observations, action choice, execution feedback, state and stopping. The operational agent boundary also contains identity, tool contracts, authority, evidence capture, effect verification, cost limits and recovery. Accountability belongs here. It is a property of the sociotechnical system, not a hidden faculty in the model.

Current implementation frameworks make this separation visible. OpenAI’s Agents SDK describes agents as LLMs equipped with instructions and tools, but the SDK’s runner owns the loop, tool execution, guardrails, handoffs, sessions and tracing. The documentation explicitly distinguishes using a lower-level model API, where the application owns loop and state handling, from using an agent runtime that manages them. This is vendor-specific implementation evidence, not a general scientific definition, but it illustrates the architecture cleanly.

A production-shaped case: cancellation with changing state

Consider a customer who asks a retail assistant to cancel an order “if it has not shipped”. The surface request is simple. The path is not. The system must identify the order, establish that the requester is entitled to act on it, determine the current fulfilment state, interpret the cancellation policy, choose whether to ask a question, cancel, decline or escalate, and then verify what actually happened. The order can also change state while the run is in progress.

Start with a fixed workflow. It always performs five operations: authenticate the user, fetch the latest order, evaluate a deterministic cancellation rule, call the cancellation API if permitted, then read the order back. This is an excellent design when the business path is stable and the necessary information is known. A model can still draft the explanation to the customer. Nothing is gained by letting a model decide whether identity verification or the cancellation rule should run. The sequence is known, cheap to test and consequential enough that determinism is valuable.

Now change one condition. Some orders are fulfilled by external merchants whose status systems expose different fields. Some have split shipments. Some cancellation failures are transient. Some customers refer to “the blue one” rather than an order number. Some orders require a choice between cancelling the remaining items and preserving those already dispatched. The path is no longer fully enumerable as one clean sequence. A model-directed policy may now be useful for information gathering and branch selection.

A bounded agent runtime could expose five typed actions: find_order, get_fulfilment_state, ask_customer, request_cancellation and escalate. The model is allowed to choose among them, but it cannot manufacture a sixth action. The runtime separately enforces identity, order ownership, current policy and the precondition that the cancellable quantity is non-zero. The cancellation tool itself accepts only an order identifier and an enumerated scope such as remaining_items or whole_order.

Suppose the first observation shows two candidate orders. The policy chooses ask_customer. The answer identifies one order. The next observation shows one item already dispatched and two items still in the warehouse. The policy proposes cancelling the remaining two. The authority layer verifies that partial cancellation is permitted and calls the tool. The API times out after accepting the request.

This is where a model-only description becomes actively misleading. The model cannot know whether the cancellation committed. Retrying blindly could create a duplicate effect if the endpoint is not idempotent. Declaring failure could cause the customer to place a replacement order unnecessarily. The runtime must move into an unknown outcome state, query the authoritative order record and choose the next step from observed state rather than from the text of the timeout. If the readback shows the two items cancelled, the goal is satisfied. If they remain active and the operation is safely retryable, the runtime may permit another request. If the source remains ambiguous, it escalates.

The agentic part of this case is narrow but real. The model helps discover the path through incomplete information and changing observations. The deterministic part is equally important: identity, policy preconditions, typed cancellation scope, idempotency rules and outcome verification. Dynamic path selection does not imply dynamic authority. The architecture can allow the model to decide what evidence to seek next without allowing it to decide whether a user is entitled to cancel someone else’s order.

This separation also gives cleaner tests. Model tests ask whether the policy chooses sensible information-gathering and escalation actions across varied cases. Contract tests ask whether malformed or over-broad tool arguments are rejected. State-transition tests inject timeouts, stale reads and mid-run shipment events. End-to-end tests assert the final order state and customer-visible response. If the team instead labels the foundation model “the agent” and evaluates only its textual decisions, all four evidence classes become blurred.

Changing the model does not move the control boundary

Another useful test is to imagine replacing the model with a much stronger checkpoint. The new model may infer the correct order from vague language, notice contradictions earlier and select better tools. Those gains can reduce the number of steps or the escalation rate. They do not remove the need for an execution boundary. A more capable model still does not become the database transaction, the identity provider or the source of legal authority merely by being more accurate.

The reverse is also true. A small model can sit inside a genuine agent loop if the task is narrow enough. A classifier might choose among inspect, act and stop in a control system. Calling only frontier language models “agents” confuses the intelligence of the policy with the topology of the system. The design question is therefore two-dimensional: how capable must the policy be, and how much agency should the surrounding runtime expose?

Keeping those questions separate prevents an expensive category error. Teams often respond to a reliability problem by upgrading the model when the real defect is stale observation, unconstrained tool authority, missing idempotency, poor stopping logic or a fixed workflow pretending to be adaptive. Better reasoning cannot repair a broken causal boundary.

The three-principal problem starts immediately

Suppose a user asks an assistant to “cancel my order if it has not shipped”. The user is the requesting principal. The model is the proposing mechanism. The tool credential is the executing principal. These roles may collapse in a demo, but they should not collapse in an operational design.

The model’s proposal should not itself be authority. A deterministic layer should decide whether the requester owns the order, whether cancellation is permitted in the current state, whether the tool is scoped to that order and whether the effect requires confirmation. After execution, the runtime should read the state back rather than infer success from a fluent tool response. Agency determines who chooses a candidate action; authority determines whether that action may become real.

Failure boundary: where the distinction stops helping

The model-agent distinction is an analytic tool, not a metaphysical wall. It becomes less crisp when the policy and runtime are learned together, as in embodied reinforcement learning, or when a model internally simulates long trajectories before emitting one action. You can choose a boundary around the deployed policy plus its sensor and actuator interfaces and still obtain a useful agent description. What matters is that the boundary includes the state transitions that make actions consequential.

There is also a fuzzy edge between workflow and agent. A workflow can contain a model-selected router, bounded retries or model-driven subtask generation. Rather than arguing over labels, record which transitions are dynamically selected, what action surface is exposed, and how much authority follows those choices. Agency is often graded even when the architecture decision must be binary.

Finally, the definition does not prove intelligence. A thermostat can satisfy a weak agency test. An agent can be incompetent. A language model can be highly capable without acting as an agent. Conflating these constructs creates bad evaluation: agent benchmarks then get read as pure model-IQ tests, while model benchmarks get read as evidence that a deployed agent can handle state, tools and recovery.

The executable artefact: a minimal bounded agent scaffold

The following Python uses no external model or private data. Its “model” is a deterministic policy stub so the system mechanics remain visible. Replace that stub with an LLM call and the causal structure does not change. The positive case reaches the stock target. The negative case proposes an excessive order and is blocked by a deterministic authority check before any effect occurs.

from dataclasses import dataclass

@dataclass
class World:
    stock: int = 2

@dataclass
class Action:
    name: str
    quantity: int = 0

class PolicyModel:
    """A model-like component: observation in, proposal out."""
    def propose(self, goal, observation):
        if observation["stock"] < goal["minimum_stock"]:
            return Action("place_order", 5)
        return Action("finish")

class UnsafePolicyModel(PolicyModel):
    def propose(self, goal, observation):
        return Action("place_order", 100)

def observe(world):
    return {"stock": world.stock}

def authorise(action):
    if action.name == "place_order" and not 1 <= action.quantity <= 10:
        return False, "quantity outside permitted range"
    return True, "allowed"

def execute(world, action):
    if action.name == "place_order":
        world.stock += action.quantity
        return {"status": "executed", "new_stock": world.stock}
    if action.name == "finish":
        return {"status": "finished", "new_stock": world.stock}
    raise ValueError("unknown action")

def run_agent(model, world, goal, max_steps=4):
    trace = []
    for step in range(max_steps):
        before = observe(world)
        proposal = model.propose(goal, before)
        allowed, reason = authorise(proposal)
        if not allowed:
            trace.append({"step": step, "proposal": proposal,
                          "status": "blocked", "reason": reason,
                          "world": observe(world)})
            return trace
        effect = execute(world, proposal)
        after = observe(world)  # readback, not an inferred success
        trace.append({"step": step, "proposal": proposal,
                      "effect": effect, "world": after})
        if proposal.name == "finish":
            return trace
    trace.append({"status": "stopped", "reason": "step budget exhausted"})
    return trace

GOAL = {"minimum_stock": 3}

positive = run_agent(PolicyModel(), World(stock=2), GOAL)
negative = run_agent(UnsafePolicyModel(), World(stock=2), GOAL)

assert positive[-1]["proposal"].name == "finish"
assert positive[-1]["world"]["stock"] == 7
assert negative[-1]["status"] == "blocked"
assert negative[-1]["world"]["stock"] == 2

print("positive final world:", positive[-1]["world"])
print("negative final event:", negative[-1])

Expected output is a positive final stock of seven and a blocked negative event that leaves stock at two. Notice which responsibilities are outside PolicyModel: observing, looping, permission checking, execution, readback, state progression, step budgeting and trace capture. Those responsibilities are not implementation clutter around the agent. They are much of what makes the system an agent you can operate.

stateDiagram-v2
  [*] --> Claim
  state "A minimum useful definition" as Claim
  state "Thought experiment one: the<br/>frozen checkpoint" as Test
  state "Thought experiment two: remove<br/>feedback, keep everything else" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

The agent boundary test

Before selecting an agent framework, score the proposed system using five questions. This is not a scientific scale. It is a design instrument for forcing the architecture boundary into the open.

A system that scores zero on dynamic transition choice is usually better described as a workflow even if it uses an LLM at every step. A system with dynamic choice but no consequence feedback is an open-loop proposer. A system with the first four properties but no action accountability can still be an agent in the weak technical sense, but it is a poor candidate for consequential authority.

Name the system you must control

Calling a foundation model “the agent” is attractive because the model is the most visible and least deterministic component. It is also the wrong unit for most architecture decisions. The model does not by itself hold the user’s authority, execute an API, observe the resulting world state, decide how long a run may continue or produce the evidence needed to reconstruct an effect.

The durable distinction is causal. A model produces proposals from context. An agent couples a policy to an environment through a goal-directed feedback loop. The loop may use planning, memory, retrieval, tools, reflection or multiple specialist models, but none of those features individually creates agency. Tool use without dynamic control can remain a workflow. Multiple model calls without consequence feedback can remain an open sequence. A long-term memory store can enrich an agent but does not define one.

This changes the design review. Do not ask first which model will be “the agent”. Draw the system boundary. Mark the goal, observation sources, operative state, candidate actions, transition chooser, authority checks, execution path, readback, stopping conditions and trace. Then ask which of those transitions truly need model-directed flexibility. Where the path is known, prefer the simpler mechanism. Where the path must be discovered during execution, expose a bounded action surface and evaluate trajectories rather than final prose.

It also changes assurance. Model evaluation remains necessary, but agent evaluation must include stateful tasks, tool arguments, intermediate transitions, rule adherence, side effects, retries, unknown outcomes and recovery. A model that scores well in isolation can still inhabit a bad agent. A modest model can inhabit a well-controlled workflow that is the better design for the job.

The word “agent” earns its keep only when it points to these mechanisms. If it merely means “something with an LLM”, discard it. If it identifies the configured system that can pursue a goal, select actions, receive consequences and change the world under bounded authority, then it tells you exactly what must be engineered and exactly what must be held accountable.