Worklog #1 on Ultraresearch, my attempt at a research agent that does its own AI research: it writes, benchmarks, and verifies its own code on your machine or an SSH compute cluster, with UltraRSI and UltraEvolve as the two deployment modes I am building.
This is Worklog #1, and the start of a running series. From here on I plan to post regular updates and a changelog for Ultraresearch every day or two, laid out as a timeline you can follow as the system grows. I would rather write in the open, while the details are still fresh and my mind is not yet made up, than wait for a tidy story after the fact.
Like most people working in AI, I take Ilya Sutskever's views seriously. Lately he has been making a point I keep returning to again and again: that we are moving from the age of scaling to the age of research, pointing the same large computers at better ideas rather than simply at more of the same. What gives the claim its weight, for me, is what he pairs it with on generalization, sample efficiency, and the observation that these models still generalize dramatically worse than people, and that this is a very fundamental thing. I think he is right that the gap is fundamental, and I think it is the gap that matters most.
The current pretraining scaling recipe and the post-training axis with RL compute, for their part, already work. With modern autoresearch, you can put a language model in a loop and let it hill-climb through optimization, performance work, and architectural improvements across a surprising range of domains. You can also close the loop on the loop itself. As a recent example, Weco's first evidence of recursive self-improvement (L1 RSI) may be the clearest demonstration I know of: an inner loop that optimizes code against an eval, much like an ordinary autoresearch agent, wrapped in an outer loop that optimizes the inner agent's own harness.
What I do not want is for that machinery to remain the property of a few frontier labs as we cross into the age of research, and I am fairly convinced that this is the age we are crossing into. So for the past two or three months I have been quietly working on generalization, sample efficiency, and autoresearch, and somewhere along the way I became convinced that autoresearch, and specifically AI RSI autoresearch, is one of the more important things I could be spending time on. My reason for building Ultraresearch is not complicated: I wanted to go after the parts of my own research stack that felt missing, brittle, or too manual, and then have the system improve those parts on its own, continuously. I also began looking for more effective ways to apply improvement mechanisms to research problems. The harness I built for my own experiments kept growing until it became something worth naming.
What follows is a firsthand account of that system, a research agent for AI autoresearch, recursive self-improvement (RSI), and superoptimization, built at Self Play Labs. I built it, so I will describe it from the inside, and I will try to be honest about where the design is settled and where it is still an argument I am having with myself.
If I had to compress the ambition into a sentence, it is this: I want a system where a researcher does not merely propose ideas, but automates the code artifacts for its research, runs the experiment, verifies the result, submits it to an independent check, and carries whatever survives into the next run. That last clause is the entire point. Every run should come back stronger than the one before it, and the strength should accumulate rather than evaporate when the session closes.
The bet behind Ultraresearch is that RSI does not have to start with a model directly rewriting its own weights. It can start one layer above the model, in the research process wrapped around it. A fixed model, given enough context, tools, memory, benchmarks, and compute, can search over artifacts. A stronger harness can search over better searches. If the improvements are externally verified and deployed into the next run, the research process itself starts to compound.
That is what I mean by "just big agentic computers." Not a single huge training run, but a large amount of compute organized as many disciplined attempts: propose, implement, measure, verify, remember, and deploy.
In March 2026, Andrej Karpathy released autoresearch: put an agent in a loop, let it write and edit a nanoGPT codebase, define constraints and objectives clearly under PROGRAM.md, evaluate the result, and keep the changes that move the metric. Over the past few months, that idea has evolved into a different form of orchestration, incorporating longer-horizon capabilities and a more explicit goal-looping approach.
The idea is deceptively simple, and its appeal is that it turns research into a ratchet. Instead of producing text about what might work, the agent produces diffs, measurements, and commits, and only objective target improvements are allowed to stick.
Writing the minimal loop is easy. The difficulty, as usual, is in everything the loop quietly leans on:
The rough division of labor in the current architecture looks like this:
Pretraining plus post-training RL gives the model durable, general problem-solving priors. In-context learning plus long context gives it fast, task-specific adaptation. Durable continual learning may be added later, but one of the live questions is whether these first two components, when harnessed correctly, are already enough to reach very advanced research capability.
Written a little more precisely, training produces the weights, and adaptation happens in context at inference time:
The training phase bakes a general learning algorithm into , and each run then adapts that fixed model to the task at hand from the current context , without touching the weights. In this picture, the weights carry the general priors and learning algorithm of a capable researcher, while the context becomes the temporary working memory, experiment history, and adaptation state for the current task. As RL tasks become more diverse, we can hope that the same kind of transition we saw in pretraining, from memorization toward broader generalization, begins to happen along the post-training axis as well.
But for a genuinely meaningful and reliable acceleration loop, the critical problems are still out-of-distribution generalization and sample-efficient learning. If an autoresearch system only improves inside the narrow distribution it was already tuned for, it is still a very useful optimizer. If it can also autoresearch the autoresearch loop, it becomes a powerful superoptimizer. But that still does not guarantee that it is a good learner and generalizer, or that it can discover genuinely new horizons rather than overfit to the ones we already know how to score. At the same time, treating the current state of the field as an early RSI stage does not mean we cannot steer it in useful directions or extract real, valid results from it.
This is why I wanted Ultraresearch to become an agent system that can specialize across AI research, architecture research, compute kernels, and chip design: so that, starting now, we can begin exploring what is in front of us through disciplined experimentation rather than waiting for the entire breakthrough of generalization to be solved first.
The design decision I care about most is to treat RSI as a deployment mode with a precise contract rather than as an aspiration. Ultraresearch carries these deployment modes, and each mode is defined by four commitments: what is allowed to change securely, how a candidate is evaluated, which baseline it must beat, and what happens when it wins in a fully agentic way. Being specific here is not pedantry. A vague version of self-improvement is exactly the kind of system that looks impressive and quietly fools itself.
UltraEvolve applies evolutionary search to an external objective: optimizing a CPU or GPU kernel, improving a benchmarked implementation, discovering better algorithms, tuning a pipeline, or solving a specific problem inside a codebase.
The loop dynamically initializes a population of competing approaches, runs each candidate in an isolated worktree, evaluates it with benchmarks and an independent judge, mutates the strongest candidates, and crosses over branches that contain complementary improvements. Compute is allocated dynamically toward the most promising lineages, while weak or unproductive branches are terminated early. The process continues until performance plateaus or the compute budget is exhausted.
UltraRSI is a versioned deployment mode for recursive self-improvement, where the optimization target is the research machinery itself: the harness code, prompts, skills, search policy, evaluation policy, memory, and orchestration.
This is the mode that demands the most caution. Once an agent can modify the system that evaluates it, the easiest route to a higher score may be to weaken the evaluator rather than improve the underlying capability. Any system capable of manufacturing apparent progress eventually will, unless that path is ruled out by construction.
Let denote the currently deployed genome at iteration : the complete research harness inherited by every run. UltraRSI proposes a candidate through a small, bounded modification:
where is the set of admissible changes around the deployed genome.
Both the deployed baseline and the candidate are evaluated through full search runs over real tasks, rather than toy checks. Each evaluation is repeated across multiple seeds or executions to reduce variance and limit the influence of luck.
If is the verified outcome produced by genome on benchmark task under execution noise , define the development score as:
The candidate must exceed the currently deployed baseline by a predefined margin:
where . A tie is not sufficient. The candidate must produce a meaningful and reproducible improvement.
Candidates that clear this first gate are then evaluated on a held-out benchmark suite , which is never exposed during proposal, tuning, or development-time selection. The held-out gate is:
Deployment occurs only if the improvement survives every gate:
More explicitly:
When a candidate passes, it becomes the new deployed genome. Every subsequent run inherits this version, and the next improvement cycle begins from it. Recursive improvement is therefore not a free-running process of unrestricted self-modification. It is a sequence of versioned, benchmark-gated deployments:
with each transition requiring evidence that the new system is genuinely better than the one it replaces.
The central invariant is a strict separation between the mutable research system and the authority that determines whether a change is accepted:
where is the external verification procedure, is the deployment authority, and is the immutable evaluation record of the currently deployed baseline.
The candidate may modify the research machinery, but it may not modify the hidden benchmarks, the final verifier, the baseline measurements, the acceptance thresholds, or the rule that decides whether it replaces the deployed genome.
Equivalently, the system is permitted to solve:
but it is not permitted to alter the definition, measurement, or acceptance rule of within the same optimization step.
The benchmark boundary must remain outside whatever the candidate is allowed to touch, and the deployed baseline must remain fixed and visible throughout evaluation. The system cannot redefine success in the same motion that it edits itself.
This is the most credible form of recursive self-improvement available today, well before models directly rewrite their own weights. The immediate object of self-improvement is the machinery around the model, and the central discipline is ensuring that every deployed gain is external, reproducible, held-out validated, and strong enough to serve as the foundation for the next one.
Ultraresearch is a complete research environment for macOS, Linux, and Windows from day one. A single application holds the composer, workspace, artifacts, 20+ built-in skills, 5+ built-in plugins, memory, MCPs, subagent capabilities, the autoresearch graph, and the leaderboard, and the run fills those surfaces as it works, so that what you see is not only the final answer but the search that produced it. A handful of constraints shaped the rest of the design:
agentskills.io format, reads any skills/ folder you add, and loads language servers so agents navigate code through real symbols instead of guessing from text.The first release. UltraEvolve moves to an intent-based approach, where you state the intent and a single evolve strategy generalizes across the work, on top of the evolutionary search infrastructure, orchestrator providers, and persistent memory that ship in this build.
New
agentskills.io-compatible format, including autoformalization and literature search.Improved