The word "agent" is doing too much work.
It covers a stateless API call dressed up with a for-loop, a production reasoning engine that autonomously coordinates a dozen tools over six hours, and everything in between. If you use the same word for all of them, you cannot diagnose failures, write accurate specs, or have a useful conversation with an engineer in the room.
The first move is to replace the word with a diagram.
An agent is a loop with five working pieces.
The model proposes what happens next. Every turn, it reads the current context and emits either a tool call or a response. That's the only thing it does. It does not remember. It does not act. It proposes.
The context window carries state from turn to turn. It is the agent's working desk — everything the model can see right now. System instruction, injected memory, prior turns, tool-call results, the current message. What fits on the desk determines what the agent knows. What falls off the desk is forgotten.
The tool-call surface is how the model touches the world. Read a file. Write a row. Call an API. Send a message. Every external interaction is a tool call. The set of tools available to the model bounds what the agent can do at least as much as the model itself does.
The memory layer persists what should outlive a single context window. The desk gets cleared eventually. Memory is the filing cabinet — a vector store, a database row, a MEMORY.md file, a summary injection. Without it, the agent relearns the same things across sessions.
The stopping condition decides when the loop ends. It is a designed object: a token budget, a wall-clock timeout, a no-progress guard, a goal predicate that says "the JTBD is done." If you have not designed the stopping condition, the loop runs until something breaks.
Over this five-component loop sits a budget meter — cost accumulating turn by turn. The meter is not a component of the loop, but it is the signal that tells you the loop is misbehaving.
Every production failure traces back to one of the five components or to a missing budget meter. Not most failures. Every failure. The loop is a small enough system that exhaustive accounting is possible. If you can point to the component, you can fix it. If you cannot point to it, you are guessing.
Why it matters now
The 2024–2026 shift from "single-prompt features" to "autonomous loops" did not arrive with new vocabulary. Teams kept using "AI feature" and "agent" interchangeably and then wondered why their staging environment caught zero of the production failures.
Naming the five components is the cheapest possible upgrade. It makes the failure conversation precise enough to act on. "The agent hallucinated" is a complaint. "The tool-call surface had no confirmation gate on the irreversible action, so when the model misfired it wrote to production" is a diagnosis with a fix.
The vocabulary also separates the things you can control from the things you cannot. You cannot make the model smarter today. You can tighten the toolbelt, instrument the context bands, and design the stopping condition. Those three moves will improve a live system faster than a model upgrade.
This is the practical value of the five-component frame: it shifts the conversation from "the AI is broken" — which has no actionable resolution — to "the memory layer is not persisting across sessions, so the agent repeats the same retrieval work every time it starts" — which has one. Precision is not pedantry. It is the precondition for a fix.
A source you should trust
- Anthropic, "Building effective agents" (2024). The clearest operator-grade treatment of the loop available. Anthropic distinguishes "workflows" (deterministic pipelines with model nodes) from "agents" (loops with genuine planning) along exactly the axis a PM needs to hold during vendor conversations. Read the first third; the loop diagram in that section is the canonical reference.
- Karpathy, "LLM OS" talk (2023). The model-as-CPU, context-as-RAM, tools-as-syscalls metaphor. Parts of it have aged as context windows scaled, but it is still the best single scaffold for explaining the loop to a non-engineer. Useful for alignment conversations with leadership.
- Yao et al., "ReAct" (2022). The foundational paper on interleaved reasoning and tool use — the pattern every production agent loop is built on. Read the abstract and the first three pages.
A recipe
A ten-minute whiteboard exercise to run with an engineering partner on any system you are scoping:
- Draw five boxes and label them: model, context window, tool-call surface, memory layer, stopping condition.
- Draw a budget meter hovering over the loop.
- For each box, write one sentence: what populates it, what changes it, what reads from it.
- For each arrow between boxes, write the failure mode if the arrow drops a message or returns garbage.
- Circle the component a vendor would have to obscure to make their demo look cleaner than their production system.
That circled component is your first evaluation target. Whatever the vendor glosses over is where the failure lives.
This exercise takes ten minutes. It has consistently surfaced more useful evaluation questions than any RFP checklist or feature comparison matrix. The diagram is the checklist.
The smell of it going wrong
- Anyone in the room says "the agent just decides" without being able to point at the model and context window.
- The system has no explicit stopping condition; "it finishes when it's done" is a wish expressed in code.
- The memory layer is absent from the diagram, so the same expensive mistake recurs every session.
- The budget meter is not wired to an alert; cost surfaces as a surprise in next month's invoice.
- The architecture review produces a block diagram of services but no loop diagram. The services are not the agent; the loop is the agent.
A judgment call from real work
The PL subagent pattern — a parent Claude Code session spawning isolated worktree children to work on parallel issues — is a direct instantiation of this loop at production scale. When we first drew the pattern, the memory layer was implicit: each child wrote files and the parent read them. The stopping condition was implicit: children ran until the parent said stop.
The quota-429 incident clarified both gaps simultaneously. Thirty parallel subagents sharing one quota pool hit the rate limit mid-work. The parent had no per-child token cap and no deadman switch. Progress from all thirty runs was lost before the first commit landed.
Drawing the explicit loop diagram before that batch would have surfaced both missing components in under ten minutes. The memory layer question ("how does each child signal progress?") and the stopping condition question ("what caps each child's spend?") are visible the moment you draw the loop. They are invisible if you skip the diagram and start scaffolding code.
The diagram is not documentation after the fact. It is the design tool.
The broader lesson is that complex systems become manageable when they have a small enough vocabulary to reason about exhaustively. Five components is that vocabulary for agent loops. It fits on a whiteboard. It fits in a ten-minute conversation. It does not require an architecture degree to use.
Whenever someone asks you to evaluate, spec, or debug an agent system, draw the loop first. Everything else follows.
Rules from this lesson
- Never use the word "agent" without being able to point at all five components of the loop.
- The stopping condition is a designed object, not an emergent property; spec it before you build it.
- Every arrow in the loop has a failure mode; name it before the failure ships.
- The budget meter is the cheapest production observability you can add; wire it to an alert on day one.