The next learning layer for AI agents may not be the model
When a coding agent fails we rarely change the model. We change the harness around it — and the agent works better next time. So where does an agent's experience actually accumulate?
What do we do when a coding agent performs badly?
We can change the model.
But in practice, that is often not what we do.
We add an AGENTS.md.
We write a skill.
We fix the tool.
We change what gets into context and what does not.
We add tests.
We leave a new rule in the repository so the agent does not make the same mistake again.
The model stays the same.
But the agent works better the next time.
That has been making me think about one of the more interesting questions in the agent space:
Where does an agent's experience actually accumulate?
The obvious answer is the model.
That is how we have thought about machine learning for years. If the system needs to improve, we improve the model. Better data, fine-tuning, reinforcement learning, post-training.
But once you start working seriously with coding agents, another layer becomes visible.
The software around the model.
Same model, better system
Today it is increasingly difficult to attribute what Claude Code, Codex, or another coding agent does purely to the model behind it.
The model reasons.
But something still has to explore the repository, decide what enters context, run the shell, call tools, manage permissions, verify results, handle context pressure, and recover when something goes wrong.
We increasingly use one word for that surrounding system:
Harness.
And here is the interesting part:
We can improve the agent by changing the layers around the model without changing the model itself.
This is not a new observation, and it is not just something developers are noticing in day-to-day use.
Researchers have been exploring different versions of this idea for several years.
In 2024, Automated Design of Agentic Systems (ADAS) proposed treating agent design itself as a search problem. Agents were represented not only as prompts, but as code, and new agent designs could be generated by another agent.
Then work such as Gödel Agent and Darwin Gödel Machine pushed the idea further into self-modification.
Darwin Gödel Machine was particularly interesting because it allowed a coding agent to modify its own implementation, evaluate the new version on coding benchmarks, and preserve useful changes for future iterations.
The improvements it discovered were not science fiction.
Better code editing.
Better long-context management.
Peer review mechanisms.
In other words, familiar engineering.
The model itself had not been retrained.
The system the model operated inside had been changed.
And according to the evaluations in the paper, some of those changes made it perform better on the tasks being measured.
That distinction matters.
There may be another place for experience to persist
One of the strongest ways for machine-learning systems to retain what they learn is through model parameters.
The system is trained.
Weights change.
The resulting model behaves differently.
Agents introduce another possibility.
If an agent repeatedly makes the same mistake, the solution does not necessarily have to be encoded in the model weights.
Maybe the solution is a new tool.
Maybe it is a skill.
Maybe it is three lines in AGENTS.md.
Maybe it is a new verification step.
Maybe context selection needs to change.
Maybe the repository needs a map that makes it easier for the agent to understand.
Maybe the workflow used in a specific situation should be redesigned completely.
So another kind of persistence becomes possible:
This is not "learning" in the same technical sense as updating model parameters.
That distinction is important.
But the operational result can still persist.
The model was not retrained.
Yet the next execution inherits something from what happened before.
That is the part I find interesting.
Research is now targeting the harness directly
In 2026, Agentic Harness Engineering made this idea much more explicit.
The researchers keep the model fixed.
What they optimize is the harness around it.
Tools can change.
Middleware can change.
Long-term memory can change.
The system prompt can change.
Then the resulting system is evaluated again.
To me, the most interesting result is not simply the benchmark score.
The paper's ablation analysis attributes much of the reported improvement to changes in tools, middleware, and long-term memory, rather than to the system prompt alone.
That matters.
For years, when people talked about agent optimization, the reflex was often to look at prompting.
This work is another reason to look more carefully at the rest of the system.
The authors also report that evolved harnesses can transfer across different model families.
That raises an odd but useful question:
If the model changes and some of the improvement survives...
where does that improvement live?
Not entirely in the model.
At least some of it appears to be encoded in the surrounding system.
Then failure logs stop being just logs
A paper published in August, Harness-R1, pushes this in another direction.
Today's agents generate an enormous amount of operational evidence.
A tool call fails.
A plan breaks.
Context is insufficient.
A file is misunderstood.
A solution is attempted and does not work.
Another path succeeds.
Then the session ends.
In many systems, the next agent starts again with essentially the same harness.
Harness-R1 explores a different possibility:
What if failure trajectories were used to modify the harness itself?
The system examines failures and produces executable patches for the harness the target agent runs inside.
Then the modified system is evaluated again.
From a backend engineering perspective, there is nothing particularly exotic about the shape of this loop.
This is how we have improved production systems for years.
Read the logs.
Find the failure mode.
Change the system.
Deploy.
Observe.
Rollback if necessary.
What is new is the attempt to automate more of that loop using agents themselves.
That is a much narrower claim than saying the agent has somehow "learned to improve itself."
But I think it is also the more interesting one.
This gets even more interesting when the experience is distributed
A paper published on August 5, EvolveNet, asks another question:
Can adaptations discovered in different environments be combined?
There is an obvious problem.
You cannot simply send Company A's repository to Company B.
You cannot freely share internal workloads.
You cannot assume user data can be moved into a centralized training system.
EvolveNet explores sharing not the raw experience, but program adaptations produced from local experience.
Local adaptation
Local adaptation
Local adaptation
There is a resemblance to federated learning, but the mechanism is importantly different.
The system is not simply averaging gradients.
It is attempting to compose software adaptations.
If approaches like this prove practical beyond experimental settings, they could create an interesting way of distributing operational knowledge.
An agent might eventually inherit an engineering solution produced elsewhere without receiving the original workload that led to it.
There are many hard problems between the research prototype and that outcome.
But the possibility itself is worth following.
The repository is already storing more than code
This is where the software engineering implications become particularly interesting to me.
A repository used to hold
- source
- tests
- config
In agent-heavy work it also holds
- AGENTS.md
- CLAUDE.md
- skills
- MCP config
- tool definitions
- architecture rules
- verification scripts
- repository maps
- agent instructions
What do all of these things have in common?
They help determine how an agent works on the software.
The repository no longer only describes the software.
It can also describe how an agent should perform engineering work on that software.
And this knowledge has very different properties from model weights.
You can diff it.
Review it.
Version it.
Test it.
Roll it back.
Move parts of it between models.
Fork it.
Git is already starting to manage more than source code in agent-heavy projects.
It is too early to know how far this goes.
But one possibility is that repositories gradually accumulate a new kind of asset:
operational knowledge about how humans and agents successfully work on that system.
What OpenAI described looks like a manual version of this loop
This is why something OpenAI described in its own Codex development experience stood out to me.
When an agent fails at something, the response is not always simply "write a better prompt."
The missing capability can be encoded back into the environment.
Documentation.
A tool.
A guardrail.
A test.
Repository structure.
A feedback loop.
The next agent arriving in the same environment can then inherit that change.
Humans can already create a loop like this:
The research discussed above makes the next question fairly natural:
How much of this loop can be automated safely?
That "safely" matters.
A lot.
Because the system can preserve the wrong lesson too
It is easy to call all of this "self-improving agents" and move on.
But from a production perspective, a more uncomfortable question appears:
What if the system preserves the wrong adaptation?
The agent sees a failure.
It changes the harness.
That problem disappears.
But three other workflows break.
Or worse:
What if the easiest way to improve the metric is to weaken verification?
If a test does not pass, removing the test can technically improve a naive pass-rate metric.
If a permission system slows the agent down, loosening permissions can make the agent appear more effective.
Once software modifications become persistent, mistakes can become persistent too.
At that point, this stops looking primarily like an AI problem.
It starts looking like a very familiar production engineering problem.
You need versioning.
Regression testing.
Audit.
Provenance.
Sandboxing.
Rollback.
You need to know which change caused which outcome.
You need evaluation that the system itself cannot trivially game.
So there is an irony here:
If agents begin modifying more of the software around themselves, software engineering may become more important, not less.
Maybe we should think about two improvement loops
I find it useful to separate two different mechanisms.
The loop we know
The loop being added
These are not the same kind of learning.
And one does not need to replace the other.
They can interact.
A stronger model may create better tools.
A better harness may extract more useful behavior from the same model.
Better verification may produce better feedback.
Better memory may prevent the same operational problem from being solved repeatedly.
The model learns through training.
The surrounding system can accumulate experience through software changes.
I think that is the more precise distinction.
This is the layer worth watching
ADAS explored automated discovery of agent designs.
Gödel Agent explored self-modification.
Darwin Gödel Machine experimented with evolving coding-agent implementations.
Hyperagents made parts of the improvement mechanism itself editable.
Agentic Harness Engineering focused directly on harness optimization.
Harness-R1 explored generating executable harness patches from failure trajectories.
EvolveNet is exploring how program adaptations from different environments might be combined.
These are different projects, with different mechanisms, assumptions and evaluation setups.
They should not be treated as evidence of one inevitable future.
Some may remain benchmark experiments.
Some may not survive contact with production.
Some approaches may simply turn out to be wrong.
But together they make one question increasingly worth paying attention to:
Where will an AI agent's operational experience accumulate?
Only in model weights?
Inside the context window?
In a memory database?
Or also in tools, skills, rules, tests, middleware, and repository structures that change over time?
I don't think we know the answer yet.
But I suspect the last category will become much more important than we currently assume.
Model weights give us capability.
Maybe software can carry something else: experience.
And if agents really become long-lived systems, what makes them interesting may not only be how intelligent they are.
It may be what they are able to make permanent from what they have lived through.