Loop Engineering in 2026, Part 2: The Outer Loop, Shared Memory, and How Loops Compound

Part 1 built a single loop: a small program that prompts a coding agent, checks the result, and re-prompts until the work passes. That is the inner loop, and getting one trustworthy is the prerequisite for everything here. This part is about the layer above it, where the real leverage in 2026 turns out to live: not in any single run, but in the system that decides which runs should happen at all and learns from how they turn out.

That layer has a name now. People are calling it loop engineering, and the shift it represents is bigger than it sounds.

“

Prompt engineering optimizes a turn. Harness engineering optimizes a run. Loop engineering optimizes a system that decides what to do next and gets better while you sleep.

”

The term “agent harness” stays fuzzy because it covers almost everything that is not the model. The clean way to think about it is two layers: the inner loop from Part 1, and an outer loop wrapped around it. Most teams have poured their energy into the first and barely touched the second, which is exactly where the leverage now sits.

Two loops, not one

The inner loop is the agent runtime you already know, the thing Claude Code and Codex run. You hand an agent a task, it reads the relevant context, uses tools, does the work, checks the result, and keeps going until the task is done. Reason, act, observe, repeat. This is where almost all agent optimization has happened: better instructions, skills and tool definitions, decomposition, tighter tool use. The question this layer answers is narrow and useful.

But notice the assumption hiding in there. Somebody already decided that this was the task worth doing. The inner loop is a brilliant executor and a poor manager. It will happily finish the wrong work, beautifully. That gap is the outer loop.

The outer loop sits around the runtime and owns the decisions the agent cannot make for itself: what should trigger an agent in the first place, what state survives between sessions, how separate agents share what they learn, how outcomes get monitored, and how the whole system improves over time. Its question is a different kind of question.

A loop engineer is not writing prompts. They are designing an environment in which agents can run a full cycle on their own: notice something worth doing, investigate it, take action, record what happened, verify whether it actually worked, and use that result to decide what to do next. The inner loop helps an agent execute. The outer loop helps the system decide, learn, and compound. Hold that last word, because it is the whole point.

It helps to see this as a ladder the field has been climbing: prompt engineering, then context and harness engineering, and now loop engineering on top. Each level wraps the one below and asks a longer-horizon question.

What a loop engineer actually designs

Strip away the jargon and a loop is a repeatable cycle with six moves. Designing a good loop means making each of these reliable and giving the agent the tools and the memory to do them.

A single loop that does this well is already valuable. The genuinely interesting behavior shows up when several of them can learn from each other.

Why loops compound: a shared memory

One loop is an automation. Many loops that share what they learn become something closer to an organism. The mechanism is almost boringly simple: the loops do not talk to each other directly, they write to a shared artifact system, a common knowledge base of what the business is learning.

Picture a company running four loops, each with its own trigger, workflow, tools, and goal: support, SEO, product growth, and ads. They never call each other. They just read and write the same store.

Watch how a single fact travels. The support loop notices that five people this week asked how to export their work, so it writes a signal: export is hard to discover, and it happens to sit behind the Pro plan. Independently, the SEO loop sees that a particular landing page pulls strong traffic but converts poorly, and writes its own signal. Now the growth loop reads both, next to the product analytics, and reaches a conclusion neither source had alone: export friction is bigger than the raw numbers suggested, and the visitors arriving from that one SEO page are running straight into it. Meanwhile the ads loop spots a keyword with a high click-through rate and no organic page behind it, and drops that into the SEO loop’s queue.

“

The loops stopped being isolated scripts the moment they started reading from a shared record of what the business is learning. That shared memory is the compounding.

”

This matches what people building these systems in 2026 keep finding: each improvement documents a pattern that makes the next improvement easier, so the knowledge base itself becomes the asset. The loop you build once pays out every time it runs, and pays out more as the shared memory grows.

The architecture: artifacts, contracts, and logs

The shared memory is not magic, it is a disciplined file layout. Three parts carry almost all of it.

Artifacts are durable pieces of knowledge or work that loops read and write. The key discipline is that each artifact type has a clear definition of what it is and is not, a consistent schema, and lifecycle rules. A signal is not a stray note. It is a structured record of something worth paying attention to, with a timeline that grows as the situation develops.

Loop contracts are the second part. Every loop has a README in its domain folder that states its goal, its trigger and cadence, its workflow as numbered steps, its deduplication rules, and a timeline of important runs. The contract is what lets any fresh agent session pick up the loop and immediately understand what it is for and how it is supposed to behave. A support contract, for instance, says it runs hourly, pulls the last hour of tickets, replies or escalates, rolls recurring friction into an existing signal rather than spawning duplicates, and adds one line to its timeline.

Global logs are the third part, and the most underrated. Work does not stay neatly inside one loop. You investigate something by hand, review an agent’s output, make a call, and hand it to another agent to act on. A single LOG.md captures that cross-domain story. The pattern that works: before major work an agent reads the last five to ten entries, after major work it appends a concise summary, and entries link to the artifacts they touched. It gives every loop a cheap way to know what has been happening across the whole system.

The 2026 part: this stopped being a hack

Here is what actually changed this year, and why loop engineering is suddenly a job title rather than a clever weekend project. The primitives stopped being a personal pile of bash scripts and started shipping inside the products themselves. The scheduled triggers, the reusable skills, the sub-agents, and the persistent project memory that you used to wire together by hand are now first-class features in the coding agents most teams already run. When the plumbing becomes infrastructure, the practice graduates.

Two ideas from the current conversation are worth stealing. First, durable skills are how a loop keeps what it learns: a named, tested skill file holds the knowledge that should survive across runs, so a loop that calls a library of sharp skills compounds in a way that a loop full of ad-hoc prompts never will. Second, the outer loop can improve the inner one. An analysis pass that reads the traces of recent runs can rewrite the harness itself, the instructions, the tool set, the decomposition, so each cycle of the outer loop quietly makes the inner loop better at its job. That is a system editing its own scaffolding, which is the closest thing yet to an agent operation that improves without you in the seat.

Start with one loop

The mistake is to try to build the whole operating system at once. Build one loop end to end, the support inbox is a good first one, with a real contract, a real artifact it writes to, and a real verification step. Get it trustworthy, then add a second loop that writes to the same store, and let the shared memory start doing its work. A practical way to scaffold the first one is the loop-engineer template the SuperDesign team published, which lays out artifact structures, loop contracts, logs, and skills you can drop into a repo and grow from there.

The teams that get good at this will not just move faster because they use agents. Plenty of teams use agents. They will compound faster, because their systems are learning in the background, writing down what they discover, and using it to decide what to do next. That is the real promise of loop engineering, and it is why the skill worth building in 2026 is not a better prompt. It is a better loop.