The Loop Is Not the System

The popular diagram explains how an agent runs. It says almost nothing about how an operation decides.

A diagram has been circulating that claims to explain every AI agent. It’s a good diagram. It also shows, by omission, why so many agent projects stall between pilot and operations.

It describes how an agent runs. It says almost nothing about how an operation decides. For a demo, that gap is invisible. For an airline in a disruption, a logistics network rerouting freight, or a plant deciding whether to hold a batch, that gap is the whole problem.

What the diagram gets right

The diagram maps the runtime loop accurately. Input arrives and is perceived. A reasoning engine thinks, a planning module breaks the goal into steps, and a tool layer acts. The results are observed, and the loop repeats until the goal is met.

Around that loop sit the familiar supports. Memory feeds the model short-term context and long-term patterns. Tools hang off the bottom: APIs, databases, code execution, external services. Guardrails run down the side, and an observability layer records traces, logs, and cost.

None of this is wrong. Every agent needs these parts, and engineering teams have to build them well. The trouble is what the diagram treats as the whole system.

What it leaves out

The diagram is model-first. Everything flows into the reasoning engine and out through the tools. Six things a real operation depends on have no place in it.

A representation of the operating world. “Perception” takes in raw input: text, API calls, sensor data. Nothing defines the entities the operation runs on, the state they are in, the constraints that bind them, or which source is authoritative. A model cannot know that a crew is about to time out, or that one system’s gate assignment overrides another’s, unless someone has made that world explicit.

Logic mapping. Every judgment goes to the LLM. Some decisions belong to hard rules that must never bend. Some belong to optimization, where the answer is a tradeoff a solver handles better than a language model. Some belong to a person. Sending all of them to the same engine is not intelligence; it is a failure to sort the work.

Decision rights. Guardrails appear as a sidebar of filters, rate limits, and approval gates. In an operation, authority is not an edge case. It is the center of the design. An agent may inform, recommend, draft, execute in bounds, escalate, or refuse, and which of those it may do should depend on the consequence of the decision.

Human authority. “Human-in-the-loop” appears twice, as a checkbox. Real human authority means defined accountability, review that changes outcomes, override that is easy to exercise, and escalation that reaches someone empowered to act. Otherwise the human is ceremonial.

Evidence. Observability here means traces, logs, metrics, and cost tracking. That tells an engineer what the system did. It does not tell an operator whether the system did better than the baseline, or how it behaves in the cases it was never shown. Evidence needs baselines, tested assumptions, and adversarial cases.

A reason to stop. The loop has one exit condition: the goal is achieved. That points to the most important omission of all.

The missing question: may I act?

The diagram’s decision points ask whether the agent can answer directly and whether the goal has been achieved. It never asks whether the agent is permitted to act, or whether its confidence is high enough to continue.

In an operation, those are the questions that matter most. Take an airline on an ordinary day. An agent can rebook a passenger whose connection slipped, because the consequence is small and the system is confident. In a weather disruption, the same rebooking becomes a recommendation for a person to approve, because confidence has fallen and the knock-on effects have grown. Cancelling a flight passes to a person entirely.

The agent’s loop is identical in both cases. What changed is its authority. A system that cannot represent that change will act when it should defer, or defer so often that no one uses it.

This is also why “I do not have enough information to make this determination” should be designed behavior, not a failure. An agent that knows when to stop is more valuable than one that always finishes.

Putting the loop in its place

The loop belongs inside a larger architecture, not at the top of it. The system gets more specific as it moves down, and authority narrows as consequence rises.

Read from the top: the operation is represented first, each decision is sorted to the right form of intelligence, and only then does the loop run, inside the authority it has been given. People keep the final say, and evidence feeds back into how the operation is represented and reasoned about.

The engineering in the popular diagram still has to be built, and built well. It just becomes one layer of the system rather than the system itself.

Decide first, then build the agent

The popular diagram is a fair description of an agent. It is not a description of a system an operation can trust. That system starts earlier, with how the operation actually decides: its rules, its tradeoffs, its exceptions, and the judgment that still lives in experienced people.

Make that reasoning explicit, sort each decision to the right form of intelligence, and bound the result with decision rights that narrow as consequence rises. Then build the loop inside it.

The model is not the system. Neither is the loop.