AI Agent Loop
A loop that forgets is just a faster line. The interesting property is not that agents write the software. It is that each cycle can make the next one cheaper.
The thesis
Most agent setups start every cycle from zero. The model reads the code, forms a theory, tries something, fails, tries again, and eventually gets there. Then the session ends and all of that reasoning is thrown away. The next agent, on the next ticket, pays for the same investigation a second time.
The fix is not a bigger model or a bigger context window. It is a place for the loop to put what it learned, and a cheap way for the next agent to find it. That turns a completed ticket into more than a commit. It produces knowledge, follow-up work, and eventually changes to how agents work at all.
The cycle
A human writes tickets. An agent claims one and runs the cycle.
Searching memory before the work and recording a learning after it are the two steps that make this different from running an agent in a terminal. Everything between them is normal engineering. The value is that the last step of one cycle is an input to the first step of the next.
Tickets are the shared state
When several agents run at once, on several machines, under several models, they need to know what is already being worked on. Git does not answer that question. A branch tells you what someone finished, not what someone started twenty minutes ago.
A shared ticket system does answer it. Claim state is centralized and updated immediately, so allocation is something an agent reads rather than infers. That is what makes concurrency across machines tolerable instead of a merge problem.
Learnings are the memory
A learning is a small structured record: a title, a trigger, a body, and the project and ticket it came from. The trigger is the important part. It is one sentence describing when this knowledge is relevant — not the knowledge itself.
Agents do not load every learning. They load an index of triggers, which is cheap, and retrieve a full body only when a trigger matches the work in front of them.
Load the trigger index. Small, loaded every time.
Match a trigger against the work at hand.
Retrieve the full learning, only when it is likely to be used.
The goal is not to accumulate knowledge. It is to accumulate knowledge without making every future prompt larger. A project that has run for a year should be able to hold a year of hard-won detail without every agent paying to carry all of it.
The metric is tokens per correct ticket
Without memory, a cycle looks like inspect, hypothesize, test, fail, inspect again, discover. With it, the cycle can be search, retrieve, continue. If that substitution is real, it shows up as a curve.
Tokens and wall-clock time per successfully completed ticket are the numbers worth watching, alongside retries, retrieval frequency, and how often a ticket gets reopened. Tickets are not equally hard, so the raw curve needs normalizing before it means much. But the expected direction is not ambiguous.
Correctness is a constraint, not a trade
The objective is not to trade quality for speed. Correctness is mandatory. Among correct solutions, minimize tokens and elapsed time.
That framing only works on a project where correctness can actually be decided — where a ticket either works or it does not. Cost optimization on top of a system that cannot tell whether it is right is just a cheaper way to be wrong.
Where the memory lives
There is a good argument for keeping tickets and learnings inside the repository. Documentation stays most accurate when it lives next to the code it describes, and putting memory in Git gives it version history, proximity, and review for free. Fluent, a project I came across through the Self-Improving Software meetup in San Francisco, takes that approach.
I am testing the other option. Memory outside the repository is visible to every agent immediately, on any machine, without waiting for a branch or a commit. An agent learns that work has started, or that a discovery was made, while it is still relevant.
That is a hypothesis, not a conclusion. External memory trades reviewability and version history for immediacy. Which side of that trade wins is exactly the kind of thing this experiment should be able to answer.
Memory has to decay
A memory that only grows becomes a liability. Learnings go stale, contradict each other, and duplicate. Today a human reviews them, which does not scale and will not survive a few thousand entries.
The self-regulating version uses retrieval itself as the signal.
Memory should be able to forget, consolidate, and correct itself. Accumulation is the easy half.
The skill is process memory
Every agent loads a shared operating skill before it starts. It is separate from project knowledge, and it answers a different question. The learning store answers what has this project already learned? The skill answers how should an agent work inside this system?
Today that skill is human-maintained scaffolding: load the index, search before hard work, claim a ticket, record what you found, check for duplicates, commit, tell other agents when it matters. The interesting step is letting agents change it. At that point the system is no longer only learning facts about the codebase. It is learning how its agents should work.
That has to be measured self-modification, not free self-editing. A skill change is a change like any other: it gets evaluated against tokens, time, and completion outcomes, and it gets rolled back when it makes things worse. The rollback path is what makes the autonomy safe to grant.
Five levels of self-improvement
"Self-improving" gets used loosely. It is worth separating what is actually being claimed.
Agents complete tickets and change the code. This is ordinary software development, even when the developer is a model.
Agents preserve what they discovered. The next agent inherits the answer instead of paying for the investigation again.
Ticket state and memory are shared across models and machines. Parallel work stops depending on one agent guessing what another is doing.
Usage signals show which learnings and procedures actually helped. Memory gets ranked, merged, and cleaned instead of only growing.
Agents change the operating skill that future agents run. Those changes are measured against outcomes and kept or rolled back.
Most of what gets called self-improving software is Level 1. The gap between Level 1 and Level 2 is where the compounding starts, and the gap between Level 4 and Level 5 is where the system stops being a collection of coding agents.
The test project
The first serious test is a project of roughly 250 tickets: a web and Wasm interpreter that can execute and render mobile iOS applications, aimed at giving VeilStream mobile preview environments without pushing customers toward Mac hardware, simulators, or device farms.
It is a good test bed because it is hard, large enough that rediscovery gets expensive, parallel enough for several agents, and deterministic enough that correctness can be decided. Three or four agents run concurrently on one machine, more from a co-founder's, across Codex, Cursor, Claude, and whatever else is worth trying. Which model runs a ticket is deliberately not part of the architecture. The shared tickets, memory, repositories, and skill are the continuity layer.
What is still open
- How should the usefulness of a learning be scored?
- How aggressively should unused learnings decay?
- Should trigger matching stay textual, become semantic, or both?
- How much does ephemeral agent-to-agent messaging actually help?
- Which parts of the operating skill should agents be allowed to change?
- How long should a skill change run before it is judged?
- How is ticket difficulty normalized when comparing token cost?
- Which learnings are project-specific, and which generalize?
These are not gaps in the implementation so much as the next round of experiments.
A working definition
Self-improving software is a development system where the output of one cycle improves the cost, speed, knowledge, or operating process of the next, while correctness stays a hard constraint.
If it works, the project should not just contain more finished code after 250 tickets. It should contain a better development organization than it had at ticket one: more useful knowledge, less repeated investigation, better coordination, better procedures, and a lower marginal cost for the next correct change.