A slogan took over agent engineering in mid-2026: stop prompting your agent, start designing the loop that prompts it. A recent paper takes that claim seriously and formalizes it — the loop specification, a reusable artifact of trigger, goal, verification, stopping rule, and memory that a human hands to an agent harness. We think it's a real and useful layer. We also think it's not the ceiling. The loop still asks a human to author the trigger, name the goal, and decide when the agent should exist at all. The layer after loops isn't a better-specified loop — it's a standing assistant that hires and fires agents against goals on its own, watching real-time signals like traffic, sales, and return rates, and deciding when a loop should spin up, change shape, or die. It will look less like a prompt template and more like ClickUp or Calendly with a P&L feed wired into it.
Every layer in agent tooling has followed the same pattern: something a human used to do by hand gets pushed down into infrastructure the human merely configures. Prompt engineering pushed "how do I phrase this" into the artifact. Context engineering pushed "what does the model need to see" into the pipeline. Harnesses like Claude Code and Codex pushed the perceive-act-observe cycle into plumbing you don't have to re-implement per task. Loop engineering, per the "Stop Hand-Holding Your Coding Agent" framing, pushes the next thing down: instead of prompting step by step, you author a bounded, reusable loop specification — trigger, goal, a five-level verification ladder, a stopping rule, memory — and hand it to the harness once.
That paper's corpus data is worth taking seriously on its own terms: across fifty real loops coded by hand, 70% verify in what they call the "autonomous zone" of the verification ladder, and 74% name their terminal states explicitly. Practice has matured fastest exactly where the discipline says it should — verification and stopping conditions. What's lagged is automated triggering and durable memory. That gap is the tell.
The loop still has a human standing at the trigger
A loop specification, as defined, still requires a person to decide three things up front: when should this fire, what is the goal, and does this loop still deserve to exist. Even a fully autonomous, well-verified loop is inert until someone writes the trigger and decides the goal is worth pursuing. The loop doesn't decide to exist. It doesn't decide to stop existing because the underlying business condition it was built for has changed. It doesn't decide that a different loop, or three loops working in sequence, or no loop at all, would serve the actual goal better this week than it did last week.
That's not a knock on loop specifications — it's a precise description of their scope, and the paper is honest about it: loop and prompt are "distinct tools with distinct uses," not a full replacement hierarchy. We'd extend that same honesty one level up. Loop and goal-management are also distinct tools with distinct uses, and right now almost nobody is building the second one.
What sits above the loop
Picture the actual job of a person running a growing team of agents six months from now. It isn't "write a better trigger." It's something closer to workforce management: which agents are working on which goals, are they still worth running, is the goal itself still correct given what happened in the business this week, and who — human or agent — should be picking up the next piece of work.
That's not a loop-authoring problem. That's a management problem, and the tools that solve management problems today don't look like prompt templates — they look like ClickUp, or Calendly, or a dashboard with a queue. We think that's exactly the right shape for what comes after loop engineering: not a human writing a sharper trigger condition, but a standing assistant — call it a goal manager — that:
- Holds goals, not prompts, as the primary object. "Reduce checkout abandonment," not "run this loop every four hours."
- Pulls real, live signals to decide what to do next. Traffic dipping on a product page, a return-rate spike on a SKU, a sales number missing a target — the same telemetry a human operator would actually watch, not a static trigger someone hand-wrote weeks ago.
- Hires and fires agents against those goals dynamically. Spin up an agent (or a loop) when a signal warrants it, change what it's doing when the signal changes, and retire it — not because a stopping rule inside one loop fired, but because the goal manager decided the goal itself no longer justifies the work.
- Looks like a scheduling and task tool, not a prompt console. The natural interface for "who's working on what, and why" is a calendar and a kanban board, not a text box.
The loop's five-part anatomy — trigger, goal, verification, stopping rule, memory — doesn't disappear in this picture. It becomes the unit the goal manager instantiates and retires, the way a manager doesn't replace the existence of tasks, they just decide which tasks exist right now and who's doing them. Loop engineering is real infrastructure for the how. Someone still has to decide the what and the when — and today that someone is a human staring at a dashboard, manually deciding a loop needs a new trigger. That's the part we think gets automated next.
Why "durable memory" and "automated triggering" are the tell
It's not a coincidence that the loop-specification corpus shows exactly those two dimensions lagging. Durable memory and automated triggering are the two pieces of a loop that reach outside the loop's own boundary — memory has to persist and stay meaningful across loops, and a trigger that's actually automated has to be listening to something in the world, not waiting on a human to invoke it. Those are management-layer concerns wearing loop-layer clothing. A loop specification can name a stopping rule, but it can't, by itself, decide that the goal behind it has quietly become the wrong goal because Q3 traffic patterns shifted. That decision needs something with visibility across loops and across live business data — which is a different object than a loop, even a very well-engineered one.
Not a replacement — the next floor
None of this argues loop engineering is wrong or premature; if anything the corpus evidence says it's working where it's been tried deliberately. The argument is the same shape as the loop paper's own argument against the "prompting is dead" headlines: don't collapse two distinct layers into one just because the newer one is more exciting to talk about. Prompting still matters inside a loop's actions. Loops still matter inside a goal manager's decisions about what work should exist. The mistake would be to stop at "engineer better loops" and assume that's the ceiling, when the actual ceiling is an assistant that treats goals — not prompts, not even loops — as the thing it's managing, and treats agents the way a good operations lead treats a team: hired against a need, evaluated against outcomes, and let go when the need changes.