Loop Engineering, Not Prompt Engineering · The Pritam Edge

Prompts improve a response. Context improves a run. Loops improve the institution. Naming loop engineering: the discipline of building the structures that notice, judge, and adapt, so an organization's AI improves on its own evidence.

Prompts improve a response. Context improves a run. Loops improve the institution. This season, I am writing about the third one.

Rohan shipped the agent on Monday. It was a beautiful piece of prompt work: a system prompt tuned over three weeks, few-shot examples curated like museum pieces, output formats locked down to the comma. The demo drew applause. The agent went into production handling vendor-invoice triage, and Rohan moved to the next project.

On Thursday, the model behind the agent got upgraded. Nobody at the company touched anything. The prompt that was tuned for one model's habits now ran on a different model's habits. Accuracy on a specific class of invoices slid from excellent to mediocre, quietly, the way a tire loses air. Nothing crashed. Nothing alerted. The agent kept answering with perfect confidence.

Nobody noticed for eleven days, because nothing was watching.

Here is the uncomfortable question, and it is not "why did the prompt degrade." Prompts degrade; that is what they do. The question is: who, or what, was supposed to notice? Rohan had engineered a response. He had not engineered the thing that notices.

That gap has a name, and I want to spend this essay giving it one. Let me lay out the ladder as three threads: prompt engineering improves a response, context engineering improves a run, and loop engineering improves the institution that keeps running.

1. Prompts and context are wasting assets

An asset that loses value the moment you acquire it is a wasting asset. A rental car. A block of ice. A prompt.

Every prompt is tuned, consciously or not, to the habits of a specific model at a specific moment: its verbosity, its instruction-following quirks, the way it handles ambiguity. When the model changes, and the model always changes, that tuning is partially voided. You do not get an invoice for the loss. It just happens, silently, the Thursday after your Monday.

Context engineering climbed one rung up. Instead of perfecting a single response, you engineer what the model sees across a run: retrieval, memory, tool results, working files. This is real progress, and I practice it daily. A well-engineered context makes a whole run better, not just one answer.

But context is a wasting asset too, on a slower clock. Retrieval strategies assume a context window size and a model's way of attending to it. Memory formats assume how a model summarizes. Each model release depreciates the stack again. You rebuild, you re-tune, and you call it progress, but you are running maintenance on assets that are structurally guaranteed to depreciate.

Here is the test I use: if the frontier lab ships a new model tomorrow, what part of your AI investment survives untouched? Your prompts do not. Much of your context plumbing does not. What survives is the thing most teams have not built yet.

2. What a loop actually is

A loop is not a cron job and it is not a retry. A loop, in the sense I mean, has five parts, and I will describe them from a harness I run myself, an assurance harness of seventeen agents that checks the work of other agents. No client names needed; this is my own lab.

Event. Something wakes the loop up: a scheduled tick, an output landing, a threshold crossing. Loops do not wait for a human to feel curious.

Run. The agent does the work: drafts the analysis, triages the queue, screens the output. This is the only part most teams build.

Verification. A separate check, by a different agent or a deterministic script, asks: is this output actually acceptable? Not "did it run without error." Did it meet the bar?

Judgment. A verdict gets recorded: pass, fail, escalate. Recorded is the operative word. A verdict that lives in a log is institutional memory; a verdict that lives in someone's impression is gossip.

Adaptation. The verdicts change the system. A rubric gets tightened. A screen gets a new rule. A drifting agent loses autonomy until it earns it back with evidence.

Now, what did this catch that a prompt never would? The exact failure that got Rohan. When a model upgrade landed under my harness, the writing agents' output drifted in tone and structure within a day. No single response was wrong enough to alarm anyone. But the verification agents scored the drift, the judgment layer recorded a run of degraded verdicts, and the loop flagged it before the third batch shipped. A prompt cannot catch its own degradation for the same reason a ruler cannot measure its own shrinking. Only a loop, a structure outside the response, can notice that responses are getting worse.

That is the discipline I am naming loop engineering: designing the events, verifications, judgments, and adaptations around agents, so that quality becomes a property of the system instead of a property of one well-crafted artifact.

3. The loop is the moat

Follow the economics. Frontier models are converging in capability and collapsing in price. Whatever advantage you get from access to a model, your competitor gets the same advantage the same afternoon, from the same API. LLMs become the commodity.

What does not commoditize is what you build around them: the harness, the loops, and the skills. Your verification rubrics encode what quality means in your business. Your judgment records encode years of decisions about what passes and what escalates. Your adaptation history encodes every failure you have already paid for once. None of that ships with a model API. None of it depreciates when the model upgrades; it is precisely the thing that absorbs the upgrade.

This is the point most AI strategies miss. Companies are hiring prompt engineers to polish wasting assets, while the durable asset, the institutional loop, goes unowned and unbuilt. When the next model release lands, the prompt-engineering shop starts over. The loop-engineering shop gets a free capability boost, because its loops re-verify, re-judge, and re-tune against the new model automatically. The same event that destroys your competitor's tuning compounds your advantage.

Executives keep asking me which model to standardize on. It is the wrong question, and it will still be the wrong question next year. The right question: what is our loop inventory? How many of our AI workflows have events, verification, judgment, and adaptation around them, and how many are just well-prompted responses waiting for a Thursday?

So, coined and defined: loop engineering is the discipline of building the structures that notice, judge, and adapt, so an organization's AI improves on its own evidence instead of depreciating on someone else's release schedule.

Rohan's prompt was excellent. That was never the problem. The problem was that excellence had no custodian after Monday.

Prompts are how you talk to a model. Loops are how an institution learns. Only one of them survives the next model release.