Part one of Building the Recursive Enterprise: RSI needs an upfront budget and a measurable return, but the experience gained through early adoption is itself part of that return.
I recently wrote about returning to hands-on coding in the agentic AI era. Over the past year, working with AI agents has brought me back into development more intensively than I expected.
That experience has made me optimistic about recursive self-improvement, or RSI. It has also made me cautious about one assumption surrounding it: that giving an AI more tokens, more agents and more time will necessarily produce a proportionally better result.
More computation can improve an answer. But RSI still needs a budget, an evaluator and a stopping condition.
At the same time, waiting for the technology to mature has its own cost. Businesses that begin now are not merely buying AI-generated output. They are accumulating the experience, evaluations and workflows that will make the next generation of models more valuable.
The challenge is to start early without confusing activity with improvement.
What do I mean by RSI?
The strongest definition of RSI is an AI system autonomously improving the machinery responsible for creating a more capable successor. Anthropic, for example, describes full RSI as a system capable of designing and developing its own successor, while acknowledging that current systems have not yet reached that point.
That is an important definition, but it is not the only practically useful one.
I am less concerned about the word “self.” In an agentic system, what exactly counts as the self?
An agent might use several models, call external tools, retrieve documents, ask another agent for criticism and learn from a human decision. If the resulting system performs better during the next cycle, does it matter that one isolated model did not complete every step alone?
For this series, I use RSI in a broader, organizational sense:
AI, people, tools, data and workflows using evaluated experience from one cycle to improve the next.
Consider an AI that proposes three solutions: A, B and C. It ranks A highest, but a human chooses B because it is cheaper, easier to maintain or better aligned with the company’s strategy.
The system should not merely record that B was selected. It should retain why B was selected, what happened after implementation and whether the decision produced the expected result.
Problem
→ options A, B and C
→ original recommendation
→ human decision
→ reason for the decision
→ observed result
→ better recommendation next timeThe underlying model weights may not have changed. But the overall system has learned something that can improve its future work.
The temptation to tokenmaxx
One of the attractions of agentic AI is that we no longer need to accept the first answer. We can ask the model to research further, generate alternatives, critique its work, run tests and repeat the process.
This creates a loop:
Attempt
→ evaluate
→ revise
→ test
→ repeatThe first few rounds may produce substantial improvements. The agent might correct a misunderstanding, discover a better architecture or identify an important risk.
Later rounds may produce progressively smaller gains.
This is where tokenmaxxing becomes a problem: giving the system more tokens, agents and iterations without a clear way to determine whether the additional work is worthwhile.
The cost is not only the API bill. It also includes:
- time and latency;
- external searches and tool calls;
- local infrastructure usage;
- human review;
- additional outputs requiring evaluation;
- and the risk of introducing new errors while trying to correct old ones.
An AI can work harder without creating proportionally more value.
A 0.1% improvement might be worth billions
Imagine that an agentic system uses a billion tokens to produce a 0.1% improvement.
That sounds wasteful, but the percentage alone tells us very little.
A 0.1% improvement in an internal document-formatting tool probably does not justify a huge research budget. A 0.1% improvement in semiconductor yield, logistics, fraud detection or drug discovery might be extraordinarily valuable.
A small improvement could also move a company from second place to market leadership. In a winner-takes-most market, the economic value may far exceed the cost of the computation.
The relevant question is not simply:
How many tokens did it use?
It is:
What economic or strategic value did the additional computation create?
Every project should therefore have an upfront budget. That budget may be fixed, value-tiered or adaptive, but it should exist before an agent begins an open-ended improvement loop.
A routine task should receive a small budget. A strategically important problem may justify a much larger one. An agent could also reach a checkpoint, present evidence of progress and request additional resources.
What it should not have is an unlimited budget based on the assumption that more reasoning must eventually produce a better result.
Improvement requires evidence
The harder problem is deciding whether the new result is genuinely better.
If an agent is told to increase the percentage of software tests that pass, it could achieve that by deleting difficult tests. If it is asked to reduce delivery time, it could skip reviews. If it is asked to reduce customer-support handling time, it could close tickets before resolving them.
The visible metric improves while the real system becomes worse.
A useful recursive loop therefore needs four things:
- An objective: What outcome are we trying to improve?
- An evaluator: How will we know whether the result is better?
- A budget: How much are we prepared to spend finding out?
- A stopping condition: When is the result good enough?
The agent proposing an improvement should not control the entire evaluation process. Depending on the task, evaluation might require independent tests, customer behaviour, operational data, another model or human judgment.
Generating alternatives is becoming cheap. Establishing reliable evidence is increasingly the bottleneck.
The cost of waiting
None of this is an argument for delaying adoption.
Models, coding tools and agent harnesses are changing extremely quickly. It is tempting to wait for the next model, the next hardware generation or the next reduction in token prices.
But buying access to a better model later does not instantly provide the organizational experience required to use it well.
A company still needs to learn:
- which problems are suitable for AI;
- how much context is enough;
- what information must remain private;
- where human review adds value;
- how to compare probabilistic results;
- how to design reusable evaluations;
- and how to move between models without rebuilding everything.
That knowledge develops through use.
The most valuable thing to retain is not a folder full of raw AI outputs. It is a trace of evaluated experience:
Problem
+ attempted solution
+ evaluation
+ correction
+ outcome
+ costOver time, these records become regression tests, routing rules, examples, evaluation datasets and organizational memory. They make it easier to test a new model or agent harness against real work rather than relying on impressive demonstrations.
The latest foundation model may be available to every competitor. Your accumulated experience of applying it to your business is not.
The 80/20 approach
No individual or SME has enough time or suitable projects to test every combination of model, coding agent, prompt, tool and workflow.
My preferred approach is approximately 80/20:
- Spend 80% of the effort using models and workflows that already produce practical value.
- Spend 20% experimenting with new models, harnesses and ways of working.
The exact percentage is not important. The principle is.
Do not reorganize the whole company around every new model release. But do not allow today’s preferred stack to prevent you from understanding tomorrow’s better option.
Early AI investment may not produce an immediate net productivity gain. Some of the return comes from learning what does not work, changing the workflow and building the evaluation infrastructure needed for future systems.
That learning is not a side effect of adoption. It is part of the investment.
Start the loop now
RSI does not need to begin with an AI autonomously designing its successor. For most businesses, it can begin with one valuable, repeatable workflow:
Establish a baseline
→ use AI to perform the task
→ evaluate the result
→ record corrections and costs
→ improve the workflow
→ repeatStart early, but budget upfront. Give the system room to explore, but require evidence before expanding the budget. Preserve not only what it produced, but why it was accepted or rejected and what happened afterward.
The aim is neither to wait for perfect AI nor to give imperfect AI unlimited resources.
It is to enter the RSI curve early, make every cycle measurable and ensure that what you learn in one round makes the next round better.
In Part 2, I will look at what the transition from Waterfall to Agile, DevOps and agentic coding can teach us about building these improvement loops.
Further reading
- Anthropic: Recursive self-improvement
- Why I Returned to Coding in the Agentic AI Era
- Quotamaxxing, Not Tokenmaxxing
Building the Recursive Enterprise
How businesses can enter the RSI curve early without surrendering cost control, judgment or sensitive data.
- Recursive AI Needs a Budget—but Waiting Has a Cost
- From Waterfall to Agentic AI — coming soon
- Sovereign AI Does Not Mean Running Everything Locally — coming soon
Leave a Comment