Agents improve themselves, but who verifies the harness that rewrites itself?

🔗 Learn more about me, my work and how to stay in touch: maeste.it: personal bio, projects and social links.

A week where I come back to my hobby horse, but from an angle I hadn’t tried yet: the continuous self-improvement of agents. It’s a delicate topic, one you can look at from at least two points of view, and in the deep dive I deliberately keep them apart. On one side the model, with weights that stop being frozen at training time and start evolving during use, the way Qwen is experimenting. On the other the harness and memory, which improve from the outside, and where I see three different roads: Prime Intellect, Meta and Qwen again. In between I also put something research has shown does not work, self-reflection. The conclusion is the one I’ve been carrying for months and that here gets uncomfortable: you can only delegate the autonomy you can verify cheaply, and the case where verifying is hardest is exactly the harness that rewrites itself. In the links you’ll find Muse Code, ByteDance’s 10 trillion parameters, DiffusionGemma and AnyDoc. Happy reading.

Podcast:

• Saturday saw the release of episode 66 of Risorse Artificiali, “AI makes 10 mathematical discoveries in one week”, with Alessandro Maserati: what’s left when AI solves the proofs, security, prompting in 2026 and the economics of tokens. Listen

There are two ways to make an agent better, and they work on completely different time scales. One goes through the weights and is measured in weeks. The other goes through the harness and is measured in turns. It’s the same dichotomy as the survey with Schmidhuber I linked three weeks ago, where self-improvement is formalized as an operator that updates either the weights or the scaffold. And the scaffold, as I said back then, is my harness called by another name.

On one side there’s the model, and the model has several ways to evolve. The first, perhaps the most natural one that comes to mind, is the evolution of the weights. Today it happens during training, but more and more it’s being tried continuously: it means taking snapshots of what works and applying small evolutions with methods like LoRA. Dwarkesh Patel has just laid out eight predictions for the era of continual learning, and one sticks with me: if the weights update every day from working sessions, safety evals run before release stop making sense.

I found it more interesting, though, to read in recent weeks how Qwen is approaching the same problem with self-evolving techniques based on feedback. It’s interesting research, already applied in Qwen3.8-Max, and the results look very promising: in the oh-my-cli case the model worked sixteen days autonomously, producing 265 commits and 127 PRs, and in a 365-day e-commerce benchmark it learned to negotiate lower prices round after round. It certainly needs much deeper study, and it’s not clear to me how far these continuous feedback techniques, which evolve the weights with small variations collected during inference sessions, can really scale. For now they’ve been tried on 3.8-Max but in a lab version. Let’s see whether they can be brought to actual inference.

On the other side there’s the approach of evolving agents in a completely different way, that is from the outside, not from the model. If we take for granted that the model is the basis of an agent’s intelligence, it’s also true that the basis of its behavior is shaped by the harness. Evolving the harness, and the memory attached to the harness, which in some way is part of it depending on where you decide to draw the line, can be extremely promising. We’re seeing it these weeks in three projects, in three different ways. Prime Intellect uses a /refine command that reads the trajectory and applies the smallest CRUD change that improves the harness: 95.5% on ARC-AGI-3 with Opus 5, above the human expert baseline. Meta with Muse Code co-trains harness and model, with Spark 1.1 generating environments and grading the candidates for Spark 1.2. Qwen, once again, produces the harness by itself.

Then there’s memory, and there too at least four different paradigms, each one worth understanding and reasoning about on its own: crystallizing traces into executable skills the way MSCE does, encoding it as a program to be queried with grep like PRO-LONG, which is worth 18 points on ARC-AGI-3, letting the agent decide what to remember as in Claude 5’s auto-memory, or pre-structuring it into a deterministic graph with no LLM like Zero-Mem.

I also want to point you to something research has shown does not work. A paper came out titled “Sample More, Reflect Less” which shows very clearly, albeit on small models from 1.5 to 7 billion parameters, that an agent’s self-reflection, that is asking the agent itself to refine its own results, doesn’t lead to significant gains. Self-Refine and Reflexion lose to plain repeated sampling at equal token budget. It’s a bit like asking a student to reread their exam paper hoping they’ll find every mistake, especially if they weren’t well prepared in the first place.

This shouldn’t be confused with reflection done with different models, which does give good results. But very often, especially in the big labs, you see a tendency to settle in and always use the same model. Larger models are probably more capable of correcting themselves, and this research matters precisely because it shows that on small models it doesn’t work: by extension we can infer that even when it works on the large ones, it works because they weren’t fully stress-tested across everything they could explore. In other words: if on the first pass we fully explore the solution space the model is capable of exploring, reflection won’t give us any improvement.

Within the continuous improvement of harnesses, and of agents in general, I like to stress that there are two different perspectives from which to look at possible improvement: the HOW and the WHAT. I take the distinction from Daniel Miessler. The HOW is the operational instructions, the step by step: the smarter the model, the more useless micro-instructions become, and that’s why post-training on how to behave can become important, precisely to discard them and let reasoning, and therefore reasoning tokens, focus more efficiently and effectively. The WHAT instead is the harness’s business: context, intent, identity, quality criteria and above all verification criteria, all those things that create the loop and close it. Miessler puts it well: the HOW rots with the Bitter Lesson, because sooner or later the labs train it into the model. The WHAT doesn’t: your context is something no lab can post-train for you.

And I want to come back to loops, because one of the fundamental things in an agent’s self-improvement is being in a space of verifiable results. That verification must above all be cheap, so it can run at high frequency, and it must not be easily gamed, because believe it or not models absolutely love to cheat, and if they can they will. Finally, and no less important, focus on short loops, short meaning a number of steps that isn’t large, let’s say under ten before each verification. This allows a tighter loop closure and a higher rate of continuous improvement. It’s Addy Osmani‘s back pressure I was talking about two weeks ago: you can only delegate the autonomy you can verify cheaply and at high frequency. And this is where the real tension shows, because the case where back pressure is hardest to apply is exactly the harness that rewrites itself.

A partial answer, though, I already gave a few weeks ago, and it’s the governance rule I’m working on with Lince: the evaluator and permission control must stay outside the loop that evolves the harness. If you let the program modify itself inside the loop, you break the abstraction boundaries and open the door to reward hacking. It holds for the harness exactly as it holds for the weights.

Asynchronous background agents active for the whole session, a local event log of every call and tool run, and Spark 1.2 co-trained with the harness.

It’s the most direct connection to today’s deep dive, where Muse Code is one of the three ways the harness improves itself. Here I’ll add the piece that didn’t fit there: background agents stay active throughout the session instead of being spawned and killed per task, and every model call, every tool run and every approval ends up in a local event log. Meta too is jumping into the world of harnesses, by now an asset as important as the model.

According to the Financial Times, citing three informed sources, ByteDance is reportedly training a model of roughly 10 trillion parameters, more than three times Kimi K3.

10T is an incredible number, but given that the scaling law looks perfectly intact and more parameters means more intelligence, this model could become a breaking point. Or refute it. Take it with a pinch of salt, though: the news bounces from one aggregator to another, and at the bottom of it there are anonymous insiders.

About 20 tokens per forward pass and 1,500 per second on a single H100, refining blocks of 256 tokens in parallel. Built on Gemma 4 MoE.

A paper absolutely worth reading. While the quality of the answers doesn’t yet match autoregressive models, the speed is impressive, and Google’s researchers went beyond plain text generation, keeping reasoning too in a diffusion model. We’ve talked many times about the need to go beyond the autoregressive paradigm: this isn’t necessarily the only direction, but it’s certainly one to explore.

Open source Rust library from Firecrawl that converts 14 formats to markdown, scoring 81 quality points out of 100 against 70 for the best alternative, with a 4.4 millisecond median.

Markdown is the format of choice for models, and a project that converts practically any format to MD without spending a single token changes the rules of the game. Until now this job has been done with a dedicated model, maybe a small one, with the token costs that come with it. Here instead it’s pure Rust: no ML model, no external service. The benchmark is done in-house, but the direction looks right to me.