The idea in one line

Drop a frontier model into an empty room and it is pure reasoning with nothing to reason about. No hands to act, no memory of yesterday, no way to know if it was right. The harness is the room you build around it: the wiring that gives the model tools, state, and a feedback signal. More and more, that wiring is where teams actually win or lose.

This post sets up the language we will use across the whole series. We will cover what people mean by recursive self-improvement, what a harness really is once you treat it as software, the handful of patterns that turn up in nearly every capable agent, and the argument nobody has settled yet: how much of the next leap comes from the wrapper versus the model underneath.

Recursive self-improvement, briefly

This is not a new fantasy. In 1965, I. J. Good sketched an "ultraintelligent machine" that could beat people at every kind of thinking and then build a successor sharper than itself. Decades later, in 2008, Eliezer Yudkowsky put a name on that feedback loop: recursive self-improvement, or RSI, an AI turning its current smarts on the very machinery that makes it smart.

People often imagine RSI as a model editing its own weights in place. The more grounded version is less dramatic and more useful: the model gets better at the pipeline that trains it and the system that ships it, and those gains roll forward into a stronger next version that does more valuable work. Frontier labs have already said out loud that AI is speeding up their own research.

Notice which two words are quietly carrying that sentence: shipping system. The distance between a freshly pretrained model and something genuinely useful is enormous, and you close most of that distance not with more pretraining but with the software you wrap around the model. Claude Code and Codex make the case plainly. Take the same model, put it inside a serious harness, and its real-world ceiling jumps.

So what is a harness?

Strip away the buzzwords and a harness is just the software layer that sits between a raw model and the messy world. Its job is to run the show: decide how the model plans, hand it tools and let it take actions, feed it the right slice of context at the right time, keep the important stuff around after the conversation ends, and grade the output so the whole thing can take another lap.

The old shorthand for an agent was "LLM plus memory plus tools plus planning plus action." A harness is all of that, plus the unglamorous parts that never made it into the diagram: the loop design, the evaluation, the permission boundaries, the state that has to survive a crash. This is why "prompt engineering" undersells it. A modern harness is closer to runtime and systems work, because it governs how the model watches, acts, remembers, second-guesses itself, and gets better over a long stretch of work.

The operating-system analogy

If you want one mental model, use this: a harness is an operating system for a model. The thing an OS does well is bury a mountain of complexity behind a small, predictable interface. A good harness earns its keep the same way, soaking up the ugly orchestration so the model only ever sees something clean it can reason about. And the way OS conventions hardened into standards over the years, expect harness configs, tool schemas, and protocols to settle into shared conventions too.

That points at a design rule worth tattooing somewhere: stay simple, stay generic. Simple things transfer. Simple things also let you piggyback on everything the model already absorbed in pretraining. Make your tools resemble the ordinary software primitives the model saw a million times while training, and it will use them well on day one.

Pattern 1: The loop

Every agent worth the name is built around a loop the model lives inside. The shape is familiar: set a goal, make a plan, do the thing, look at what happened or run the test, adjust, go again, and keep going until the goal is actually met. A good loop also knows when to pause and ask a human, instead of guessing when the task or a preference is unclear.

Karpathy's autoresearch repo is a tidy, stripped-down example of one. The mental shift it forces is the whole point of this section: the model is no longer just replying to a prompt, it is running inside a runtime that reads back its own attempts, spots where it went wrong, and course-corrects. The loop is the unit of design, not the prompt.

Pattern 2: Files as memory

Give an agent a long task and it will produce far more state than any context window can hold: run logs, diffs, summaries, stack traces, and the whole trail of things it already tried. Stuffing all of that back into the prompt is a fight you lose as tasks get longer.

The fix is almost too plain to feel clever: put the durable stuff on disk. Do not haul the entire job around in context. Write it to files and pull back only the piece you need right now.

Why does something this basic hold up so well? Because reading, writing, and editing files, usually straight through a shell, is a skill every capable model already has, hammered in during pretraining. So "memory is just files" is not a hack bolted on the side. It is a memory system that quietly improves every time the base model gets better with a terminal. That upgrade is free.

Pattern 3: Sub-agents and background jobs

One agent thread is a chokepoint the moment you want to test several ideas at once, run things in parallel, or wall off a gnarly subtask so it does not muddy the main thread. So you let the harness fork off sub-agents and run background jobs.

Now the parent is basically a lightweight process manager: it kicks off work, tails the logs, kills the runs that go bad, and folds the good results back in. The rule that makes this safe is to keep the parallelism out in the open and easy to inspect. If a sub-agent only ever spoke into a throwaway chat buffer, its work evaporates the second the context turns over. Persist it as files, logs, and status records and the system can pick up after an interruption and reason over its own history. That is Pattern 3 quietly depending on Pattern 2: durability is what makes going wide safe.

This is the exact shape of how we work at Entelligence AI. The moment an incident fires, we fan out a set of agents to hunt the root cause at the same time, each one writing what it finds where the rest of the loop can pick it up, and then we merge those threads into one fix. Parallel, inspectable, and written down. If you want to watch it happen, come find us at https://entelligence.ai/

Case study: the coding-agent harness

Coding agents are where all three patterns grew up fastest, and the interface has more or less converged across Claude Code, Codex, OpenCode, and the Cursor family. They run the same kind of loop and reach for the same kinds of tools. Roughly, an agent needs to be able to:

• find and read code (search the tree, open files, skim many at once)

• change code safely (write new files, do exact-match edits, apply structured patches)

• run things in a shell

• talk to the dev toolchain (a language server, plus git for status, diffs, and commits)

• pull in outside context (things like MCP tools and reusable skills)

• reach the web (search, fetch a page, drive a browser)

• handle artifacts (read docs and images, produce HTML or images)

• schedule background work and delegate to other agents (spawn them, wait on them, resume, list, or shut them down)

Read that list as the three patterns wearing work clothes. Finding, reading, editing, and shelling out is Pattern 2. The scheduling and background pieces power Pattern 1's longer loops. The delegation pieces are Pattern 3. The comparison the field keeps reaching for holds up: an agent with this kit is to a codebase what a developer with a good IDE is. Same primitives, same debug-and-retry rhythm.

The real question: wrapper or model?

If the harness is this powerful, how much of the path to RSI is harness work and how much is just a stronger model? No one can call this cleanly, but here is a near-term bet that feels right.

First, harness work drifts toward meta-methodology. Instead of hand-writing clever rules, teams start tuning the machinery that produces good answers in the first place. The harness stops being a pile of special cases and becomes a thing you optimize, with more general mechanisms and fewer bespoke hacks. That shift is exactly what Posts 2 through 4 dig into.

Second, the two sides pull each other up. Solid harnesses power the auto-research loops that make models better, and better models keep harnesses from rotting into sprawling rule-piles, which is what keeps the whole thing maintainable.

And in the long run? A lot of today's harness tricks will probably get absorbed into the model itself. But the seam where the model meets external context and tools is not going anywhere.

We have seen a gentler version of this movie already. Prompt engineering was once a grab-bag of manual tricks, and most of them faded as instruction tuning and reasoning got good. What did not fade was the underlying job: saying what you want, what the constraints are, what context matters, and how success gets judged. Bet on the same arc for harnesses. The fiddly bits melt into the model, and the structural bits stick around.

Takeaways

• A harness is the OS-like layer that turns raw model horsepower into a working agent. It now owns the loop, the evaluation, the permissions, and the persistent state, not just the prompt.

• The same three patterns show up everywhere: a loop, files as memory, and sub-agents or background jobs you can actually inspect. They stack, and durability is what makes the loop and the parallelism trustworthy.

• The interesting frontier is treating the harness itself as something to optimize on purpose, which is where the rest of this series heads.

• The model still does most of the heavy lifting. As Post 4 gets into, a self-improving harness only pays off when the base model is strong enough to improve the mechanism in the first place.

None of this is abstract for us. It is the same thinking baked into what we build at Entelligence AI: a harness that reads the whole diff, weighs every change against the incidents you have already lived through, watches production in real time, and closes the loop so the same class of bug does not ship a second time. And we do not just sell it, we run on it. Our own team ships behind this loop every day, so the patterns above are the ones we actually live with.

If any of this lands, go see it for yourself. Swing by https://entelligence.ai/ and take it for a spin, or just come say hi.

Based on Lilian Weng's essay "Harness Engineering for Self-Improvement" (Jul 2026): https://lilianweng.github.io/posts/2026-07-04-harness/