Reactive or Agentic: Choose the Smallest Loop That Does the Job

For: architects and engineering leads deciding how much autonomy a task needs. The decision: which of three designs to build, before choosing a framework.

One finance team, three tasks, one proposed agent

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

A finance-operations team at a mid-sized distributor has three jobs it wants to automate. Each morning about 900 supplier emails need sorting into six queues. Several times a week a supplier asks to change the bank account that its payments go to. And at month end, an accrual balance sometimes refuses to reconcile with the ledger, for reasons nobody can name in advance.

The first proposal is one agent with every tool, “because agents are where this is going”. A design review asks a plainer question about each job: what decides the next step?

For the emails, nothing does. Read one message, pick one of six labels, hand it to code that files it. For the bank-detail change, the team already knows the order: extract the new details, compare them with the vendor master, call the supplier back on the number held on file, collect two approvals, then update. For the accrual gap, the answer depends on what each lookup finds. A ledger line may point to a purchase order, which may point to a goods receipt that was never matched, which may be explained by an email from three weeks ago.

Those are three different designs. The email job needs a single pass. The bank-detail job needs a workflow. Only the accrual job justifies an agent loop, and even that loop should read, not write.

The usual labels carry three assumptions that are wrong

“Reactive” and “agentic” are used as if they were opposite ends of one scale. They are not, and three common assumptions cause bad designs.

Reactive does not mean stateless or deterministic. The Reactive Manifesto (2014) defines reactive systems as responsive, resilient, elastic and message-driven. It says nothing about statelessness or repeatability, and real reactive services hold state and run concurrently. A single model call is also not deterministic: the same input can produce different outputs. In the agent literature, reactivity means responding to changes in the environment in good time (Wooldridge, 2009), which is a different property again. To avoid the clash, this article says single pass for a design that makes one model call per input.

An agent does not inherently have persistent memory. An agent loop carries working context within one run: the goal, the tool results so far, its own notes. That is what lets it decide the next step. Memory that survives into the next run is a separate store with its own rules for what may be written, how long it lives and how it is revoked. A loop with no persistent memory is still an agent. A workflow with a database behind it is not one.

A model that chooses a tool has not been given authority to run it. Choosing a tool and its arguments is a proposal. Whether the effect happens is decided by a check the model cannot edit. Agent loops do raise the stakes, because each pass can choose again, but the answer is the same at every pass: the choice is not the permission.

The dividing line that holds up in practice comes from Anthropic’s 2024 guidance. In a workflow, predefined code paths orchestrate the model and tools. In an agent, the model dynamically directs its own process. The question is who decides the next step.

The CAE reading: the least autonomy the task needs, with authority outside

In CAE terms, each shape is a way of arranging the Probabilistic Core inside the Deterministic Shell. In a single pass the shell makes the call and acts on the result. In a workflow the shell owns the order, and the model fills in steps. In a loop the model chooses its next step, so the shell must also own the counters, the budgets and the right to stop, as described in Loop Engineering.

All three share one rule. Anything that changes a system of record crosses the Commit Boundary, where identity, delegated authority, policy and evidence are checked by something other than the model. That is why moving from a workflow to a loop adds a cost without changing who is allowed to do what. A loop gets more room to investigate. It does not get more permission.

Six questions choose the shape

1. Can the path be written down? If an expert could list the steps before seeing the input, build a workflow, or a single pass if it is one step. Reach for a loop only when the path depends on what is found along the way.
2. Does a baseline single pass fail? Give one call the right context and measure it against labelled examples. Adding a loop to a task that one call already handles buys cost and variance.
3. Does each step depend on the result of the last? Independent look-ups can run in parallel inside a workflow. Genuine dependence is what a loop is for.
4. What does a wrong step cost, and can it be undone? Give an exploring loop read-only tools. Let it propose changes that a workflow or a person then commits.
5. Can you state progress and stop? Progress is a change in an external measure or new evidence, not an action’s own success signal. If you cannot write the stop rule, the loop is not ready.
6. What can you afford in time and tokens? Budget iterations, elapsed time and spend before the first run, and decide what happens when they run out.

The most useful design is often a hybrid: a workflow on the outside, with one bounded loop inside the single step that really cannot be scripted. In the example, the accrual job could be a workflow whose middle step is a capped investigation, followed by a human approval and an ordinary journal-posting step.

Cost, latency and recovery change with the shape

A loop pays for its flexibility on every pass. Suppose, as an assumption, that each pass sends the whole accumulated context again and that the context grows by 3,000 tokens a pass. Over eight passes the model reads 3,000 × (1 + 2 + … + 8) = 108,000 input tokens, against 3,000 for one call. If each call takes about three seconds, the loop takes about 24 seconds of sequential model time, and the single pass takes three. These are illustrative assumptions. Prompt caching and context trimming change the figures, and the pattern is what matters: loop cost grows faster than the number of steps, and latency adds up because the steps cannot be reordered. See The Arithmetic of Agent Cost for how to measure your own.

Each choice fails in its own way

• Agentic by default. A loop is used where one call or a workflow would do, and the team pays for latency, cost and variance it never needed.
• A workflow stretched over an open task. Branches multiply, edge cases fall through silently, and the script becomes the thing nobody dares to change. That is the signal that a bounded loop belongs in that step.
• A loop with write access. The model’s exploration and the system’s effects share one permission. Separate them: read-only to investigate, a proposal to act.
• No stop rule. The loop runs until a budget fails or a person notices. Write progress and limits before the first run.
• Memory added because agents “have memory”. Stored notes from a past run can steer a later one. Decide what is persisted, who may write it and how it is withdrawn.
• Evaluating only the answer. A loop that gets the right accrual explanation after forty look-ups is not the same system as one that gets it after nine.

Each role has a distinct choice to make

Executives decide which tasks may use open-ended loops at all, and what a stuck loop is allowed to cost before someone is called.

Architects design the routing: the test that assigns each task a shape, where counters and quotas live, and which steps remain deterministic whatever the model proposes.

Engineers implement and test the single-pass baseline first, then the workflow, and only then the loop, with read-only tools, trajectory tests and idempotent actions.

Key takeaways: earn the loop

• “Reactive” and “agentic” are not opposites. A reactive system can hold state and a model call is not deterministic, so name the shape by who decides the next step.
• Start with a single pass, then a workflow. Add a loop only where the path depends on what is found.
• An agent loop has working context within a run. Persistent memory is a separate decision with its own controls.
• A model’s choice of tool is a proposal. Authority is checked outside the model at the Commit Boundary, whatever the shape.
• Loops need progress signals, stop conditions and budgets, and they cost more in latency and tokens than the step count suggests.

Sources and further reading

• The Contextual Agentic Enterprise, Chapters 3 and 9.
• Anthropic (2024) “Building Effective AI Agents”, 19 December 2024. The page notes that some of the tooling it describes has since changed.
• Yao, S. et al. (2022) “ReAct: Synergizing Reasoning and Acting in Language Models”, arXiv:2210.03629.
• Bonér, J., Farley, D., Kuhn, R. and Thompson, M. (2014) “The Reactive Manifesto”, version 2.0.
• Wooldridge, M. (2009) An Introduction to MultiAgent Systems, 2nd edn. Wiley.

The book sets out the full decision

The book develops the comparison across deterministic, probabilistic and agentic systems, and the design patterns that follow from it, including how to place retrieval, tools, memory and human review around each. More about the book.

This article is part of CAE Field Notes, a series accompanying the book, The Contextual Agentic Enterprise.