Part 1 of a three-part sequence on AI systems thinking.
The shift nobody announced
There was no press release for it, but the center of gravity in applied AI moved sometime in the last eighteen months. It moved from the prompt to the loop.
A prompt is a single turn: you ask, the model answers, the transaction closes. For two years that was the whole interaction model, and an entire industry of "prompt engineering" grew up around squeezing better single answers out of better single asks. It was a real skill. It is now a shrinking one, not because prompts stopped mattering, but because the unit of work got bigger.
The unit of work today is the loop: the model proposes an action, something executes it, the result feeds back in, and the model decides what to do next, repeating until a stopping condition is met. This is the pattern underneath every coding agent, every research agent, and every "do this multi-step thing for me" product that actually works. The technical literature has converged on a name for it, the agentic loop, often a ReAct loop for reason + act, where the model decides what action to take, that action gets executed, the result feeds back in, and the model decides what to do next.
That sounds like a small mechanical change. It is not. It is the difference between asking someone a question and giving someone a project.
In the prompt era, the workflow was simple: human asks, model answers, human decides what to do next. In the loop era, the workflow has state. A goal enters the system, the model reasons, calls a tool, observes the result, updates its plan, and either stops or continues. The loop can run for minutes, hours, or days. It can inspect files, make changes, run tests, call APIs, write logs, and recover from mistakes. That is a fundamentally different design problem.
Prompts were the first interface
Prompting was the first practical way to control language models. It gave people leverage quickly: summarize this, draft that, classify these, rewrite this email, generate this plan.
That interface made sense when AI was mostly a text-generation tool. The output was the product. You could judge the answer, copy what worked, discard what did not, and try again.
But prompts are brittle when the task becomes real work.
They usually do not carry durable memory. They do not naturally enforce permissions. They do not leave reliable audit trails. They do not know when to retry, escalate, stop, or ask for review. They are good at producing outputs, but weak at managing ongoing work.
That is why the interesting frontier is moving beyond prompts. The prompt still matters, but it is now the starting instruction inside a larger operating system.
Why the loop changes everything
A one-shot prompt has one primary failure mode: a bad answer. You read it, notice it is wrong, and try again. The human stays in the cockpit the entire time.
A loop has dozens of failure modes, and most of them happen while you are not looking. The model can take a wrong action, observe a misleading result, take three more actions based on that misreading, and confidently declare victory on the wrong hill. It can loop forever. It can stop too early. It can burn thousands of tokens reproducing the same mistake. The thing that makes loops powerful, autonomy across many steps, is exactly the thing that makes them risky.
Anthropic's own engineering teams describe how even a frontier model running in a loop across multiple context windows will underperform without a well-designed harness: it tries to do too much at once, or declares the job done prematurely.
So the moment you move from prompts to loops, three new questions appear that simply did not exist before:
What can the loop touch? A prompt touches nothing but the conversation. A loop touches files, shells, APIs, databases, other people's systems. Capability is now a design decision, not a given.
How does the loop stay on track? Across twenty or fifty steps, how do you keep context coherent, catch errors early, and stop the model from wandering? This is an engineering problem, and it turns out to be most of the problem. As one engineer who studied the Codex source put it: the loop is trivial; the infrastructure is everything. Building an agent is 5% calling the model in a loop and 95% context management, tool execution, sandboxing, and error handling.
What happens when the loop can reach real systems? The instant a loop has credentials and tools, it stops being a clever text generator and becomes an actor inside your infrastructure, with all the security consequences that implies.
Each of those questions is a systems question. None of them can be solved by a clever prompt alone.
The model is no longer the interesting part
This is the uncomfortable thing for a field that spent years treating model benchmarks as the only scoreboard. By 2026 the gap between frontier models narrowed to the point where raw benchmark differences are often within a few percentage points, which means the tool's architecture and workflow fit matter more than the model score in most practical scenarios.
When two models are 96% and 94% on the same eval, the 2% is not what determines whether your agent ships value. What determines it is everything around the model: the tools you gave it, the guardrails you wrapped it in, the way you managed its context, the logs you kept, and the recovery path when it failed.
The same lesson shows up in orchestration. A widely circulated 2026 benchmark of agent frameworks concluded bluntly that the framework debate is largely a distraction. The gap between a good agent system and a bad one is almost never the framework. It is the eval pipeline, the observability setup, and the failure recovery logic.
That is the thesis of this whole sequence, stated three different ways: the model is becoming a commodity, and the environment around the model is becoming the product.
Skills make loops reusable
The next step is making loops portable.
Prompt libraries were useful when the main artifact was a clever instruction. But as agents get more capable, the reusable artifact becomes a skill: a procedure, examples, tools, constraints, tests, and expected outputs.
That is why teaching Codex by demonstration, the OpenAI Developers example, PostHog's Skills Store, and qvr / Quiver matter. Teaching an agent by demonstration is not just a UX improvement. It points toward a broader pattern: agents learn best when procedures are captured as repeatable operating knowledge, not just one-off prompts.
A good skill is more than a saved prompt. It is a small operating manual for a specific kind of work. It says what tools are available, what inputs matter, what quality checks must pass, what not to do, and how to recover when the happy path fails.
That is the difference between "ask the model to write a migration" and "run the migration loop we trust."
The business implication
This changes how teams should think about AI adoption.
The winners will not be the people with the cleverest prompt collection. They will be the people who build the best loops: tight feedback, reusable skills, clean logs, safe permissions, and reliable recovery.
You can see the same pattern in AI-native GTM workflows, where the value is not a one-off prompt but an operating process a small team can keep running. The useful question is not "what should we ask ChatGPT?" The useful question is "what recurring work should become a supervised loop?"
That is the move from AI as a chat window to AI as an operating system for work.
At Third Wag, this is the distinction we care about most. Strategy is not a deck of possible prompts. A production AI system is a loop with tools, permissions, context, feedback, and a way to keep improving after the demo is over.
Where this sequence goes
If AI work is moving from prompts to loops, then the interesting engineering and the interesting risk both live in the loop's surroundings. This sequence walks outward from the model in three steps:
Part 1 — From Prompts to Loops (this essay). The concept: the unit of AI work is now a durable operating loop, not a one-shot prompt, and that shift relocates the hard problems from the model to its environment.
Part 2 — The Harness Is the Product. The architecture: the stack that surrounds a model in a working loop, including tools, permissions, memory, logs, evals, tests, human review, and recovery.
Part 3 — Least Agency: Zero Trust for AI Agents. The security consequence: what happens when the loop can touch real systems, why least privilege is not enough for agents, and why the new design principle is least agency.
The arc is concept, architecture, security. It is deliberately not an AI-hype arc. The bet underneath it is that the next several years of value will accrue to the people who think about AI as systems: bounded, observable, recoverable systems, not magic boxes you prompt and hope.
The prompt was the right abstraction for asking questions.
The loop is the right abstraction for getting work done.
And the moment you commit to the loop, you have signed up to build everything around it.
That "everything around it" has a name. It is the harness, and it is the subject of Part 2.