The Agentic Loop

The Shift

There is a paradigm change underway in how humans work with AI, and it has a clean formulation:

"I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops." — Boris Cherney, creator of Claude Code ^[1]

The shift is from prompting (you write an instruction, the model responds once) to looping (you give the model a goal and a set of tools, and it runs a self-improving cycle — think → act → self-check → repeat — until the work passes a bar you defined). In the looping model, the human's job is no longer to produce the output; it is to define the goal, the success criteria, and the guardrails. The agent grades its own work.

A working definition, from someone who builds agents for a living:

"My working definition of an 'agent' is simple: a model running in a loop with access to tools." — Allen Hutchison ^[2]

This is not a marginal improvement on chat. It is a different category of system. A chat is words; an agent is a worker. The loop is what makes the difference.

What a Loop Actually Is

Three inputs define a loop, and the skill ecosystem is converging on this shape:

Input	What it means	Why it matters
Context	Anything the agent should know going in — preferences, prior runs, existing data, business facts	Without context, every run starts from scratch and the agent cannot get smarter over time
Goal	What you are trying to achieve, stated as an outcome not a procedure	A goal lets the agent pick a better path than the one you'd prescribe; an explicit task constrains it to your imagination
Success	What a good result looks like, stated as a testable rubric	Without a success criterion, the agent cannot know if it is done; with one, it can self-grade and iterate without you

The cycle itself: the agent thinks about what to do next, picks a tool, attempts the work, reads its own result, decides whether the result is good enough, and either presents the answer or goes back to thinking. The human is no longer responsible for the results; the agent is.

The Simple Loop Fallacy

The working definition — "a model running in a loop with access to tools" — is true but dangerously incomplete. If you implement your own agent, you will find that the simple statement hides most of the work:

"While some people will say that an agent is nothing more than a model running in a loop and using tools, if you implement your own agent you will find that there are a lot of details missing in that simple statement. Every model has its quirks — handling parallel tool calls, progressive context compression, input context window management — all come with frustrations. You'll spend 80% of your time on undifferentiated heavy lifting: the complex but repetitive plumbing every agent needs but that adds no unique value." — Allen Hutchison ^[3]

The loop is the headline. The reality is that the loop is 20% of the system and the plumbing — tool schemas, permission policies, memory architecture, context compaction, error recovery, observability — is 80%. This is why managed-agent harnesses (like CMA) and agent frameworks exist: they absorb the plumbing so the human can focus on the goal and the rubric.

The Stateless → Stateful Transformation

The deepest technical problem the loop solves is that LLM APIs are fundamentally stateless — each call has no memory of the previous one. A loop is what turns a stateless model into a stateful worker:

"Creating an agent that remembers your preferences, learns from interactions, and maintains context requires sophisticated external memory architecture. Frameworks provide battle-tested solutions, from simple conversation buffers to complex integrations with vector databases for semantic memory and knowledge graphs for entity relationships." — Allen Hutchison ^[4]

This is the core differentiator of a managed agent versus a chat. A chat is stateless; a loop with a memory store is stateful. Run #1 starts fresh. Run #10 reads what runs 1-9 learned. The loop is the mechanism; the memory store is what makes the loop compound across runs. Without persistent memory, the loop only self-improves within a single session; with it, the loop self-improves across sessions.

Human-in-the-Loop → Human-on-the-Loop

As agents acquire tools and autonomy, the human's role changes:

"We are transitioning from Human-in-the-Loop (where we manually approve every step) to Human-on-the-Loop (where we set the goals and guardrails, but let the system drive)." — Allen Hutchison ^[5]

The implication is a new responsibility: clarity. If the agent works overnight, you must be precise about the goal, explicit about the boundaries, and thoughtful about what happens when the agent is uncertain. The guardrail architecture that enables this — policy engines, always_ask permission gates, limited networking allowlists, read-only memory for untrusted material, iteration bounds — is not optional scaffolding. It is the mechanism that makes autonomy safe enough to use. Without it, you are forced into a binary choice: a capable agent that is dangerous, or a safe agent that is useless.

Concrete Patterns

The loop is an abstract shape, but it has several concrete implementations in the wild. Each one is the same cycle — set a bar, attempt, measure, keep-or-revert, repeat — applied to a different domain:

Pattern	Source	The cycle	Where it runs
Program-Train-Prepare	Karpathy / auto-research engineer ^[6]	Record baseline → form one hypothesis → make one change → score with a scoring file → keep if score beats baseline, revert if not → repeat in ~5-min loops, even overnight	Anywhere the agent has write access to an asset and a scoring file
Build-Test-Iterate	Claude Code prompting Pattern 4 ^[7]	Build X → run the tests/screenshot/lint → iterate until right. "Without feedback, Claude gets it ~80% right. With 2-3 self-iteration cycles, near-perfect."	A single Claude Code session
Outcome-Graded Loop	Claude Managed Agents ^[8]	Define an outcome with a rubric → agent runs → separate grader context window evaluates (satisfied / needs_revision / max_iterations / failed) → agent iterates against its own work	Anthropic's cloud, always-on, schedulable
Scientific-Method Loop	Lewis Jackson's self-improving trading agent ^[9]	One variable at a time → baseline → improve → hypothesis → test → keep or revert. "A feedback loop that actually changes its own behaviour."	Hermes Agent on a VPS, 24/7

The shared skeleton: a scoring function the agent can call on its own output, a baseline to beat, and a keep-or-revert decision at each cycle. The domain (code, trading strategies, research assets, news digests) is interchangeable; the loop shape is constant.

What Makes a Loop Compound

A single iteration of a loop is just a prompted task with a check. What makes the loop a paradigm shift rather than a tactic is that it can run unattended and improve across runs. Three properties are required for that:

A self-grading stop condition — the agent must be able to evaluate its own output against a rubric without a human in the critical path. This is what CMA outcomes provide, what Karpathy's scoring file provides, and what Claude Code's tests/screenshots provide.
Persistent memory across runs — the agent must remember what it learned last time. Without this, every run is run #1 and the loop cannot compound.
A schedule — the loop must be able to fire without a human typing a command. This is what CMA's scheduled deployments (POST /v1/deployments, native cron) and Hermes Agent's cron jobs provide.

When all three are present, the system is a worker, not a chat. It runs while you sleep. When any one is missing, the loop is still a loop, but it is a single-session tool that resets when the session ends.

Caveats and Open Questions

Cost predictability — a stuck loop burns tokens fast. The Launch Your Agent demo's failed Reddit-sourcing run cost ~$12 and 27M tokens in 28 minutes before hitting the max_iterations bound. The only spend lever in CMA is workspace-level; there is no per-agent spend cap inside the loop itself. How do you set effective per-agent cost guards when the loop is the thing spending the tokens?
The simple loop is the easy part — building the loop is 20% of the work. The plumbing (tool schemas, permission policies, memory architecture, context compaction, error recovery) is 80% and is where production agents actually fail. A loop without guardrails is a capable agent that is potentially dangerous; a loop with guardrails is a worker you can trust overnight.
Memory poisoning — a loop with read_write memory and untrusted input is a prompt-injection surface. A malicious input can write to the memory store and poison future runs. The mature pattern is read_only memory for reference material and isolated write stores for agent-generated content. This is not yet a solved problem.
When does a loop win over a workflow? — "Boring is beautiful. Workflows beat agents 9/10 times." ^[10] Most business processes need deterministic automation, not an autonomous loop. A loop is the right tool when the work is genuinely variable, requires judgment at each step, or benefits from self-grading against a rubric. For everything else, a script is cheaper, more reliable, and easier to debug.
Discovery and trust in multi-agent loops — as loops proliferate and agents call agents, the "Internet of Agents" problem appears: how do you find the right agent, and how do you trust it? The emerging protocol stack — MCP for tools, ACP for interfaces, A2A for collaboration — is the early answer, but behavioral verification and discovery are open problems.