An agent that runs the same job every night does not get better. It does not get worse either. It stays exactly as good as the text somebody wrote for it four months ago.
That is the uncomfortable part of agent systems. Quality hangs almost entirely on the instruction, and the instruction is a piece of prose somebody typed once and then forgot. You do not notice, because an agent never says it could do more with a better instruction.
Darwin is our answer to that. It is an open package, anyone can use it, and it does one single thing: it lets agents evolve their own instruction text.
How The Loop Runs#
Every run of an agent is scored. Not by a human but by a judging model against a fixed yardstick.
Out of the scored runs a challenger is derived: a revised version of the instruction built from the weak spots of the current one. The challenger does not replace the incumbent immediately. Both run in parallel for a while, and the jobs are split between them.
Once enough runs exist, a statistical test decides. Not "one has a higher average" but the question of whether the difference is large enough not to be chance. If the challenger wins, it becomes the new incumbent. If it does not, everything stays and the old version keeps its place.
The Most Important Part Is The Brake#
A system that changes itself is a good idea with an obvious danger: it can evolve in a direction nobody wanted.
So the safety gates do not sit at the edge but in the middle. There is a minimum number of runs before anything is decided. There is a time limit on open comparisons, so a test does not stay open forever. And there is a way back: when the active version starts failing, the system returns to the last known good one.
The way back is the part that took the most work, and that is typical. Forward is always easy. The route back is what separates an experiment from an operating system.
Why Statistics Instead Of Gut Feeling#
The tempting shortcut would be: the new version scored better on average, so we take it.
At small numbers that is almost always wrong. If an agent has run a handful of times and the new version came out ahead slightly more often, that says approximately nothing. You need a procedure that recognises when enough evidence exists and keeps quiet until then.
That is exactly the difference between a system that improves and one that swaps its instruction every week and feels good about it.
What We Do With It Ourselves#
We run Darwin on our own agent fleet. Not on all of them at once, but on two first, with close observation of what happens.
That restraint has a reason. A procedure that changes the instructions of the whole fleet at the same time is not brave, it is unobservable. If something runs worse afterwards, nobody knows which of the changes it was.
So: two agents, run long enough for the numbers to mean something, then the rest.
Open Source, And Why#
Darwin is out in the open. Anyone can install it, read it and use it, without asking us and without paying.
The reason is unspectacular: a procedure that measures the quality of agents is exactly the kind of tool that gets better from people reading it. We have learned more about our own weak spots from feedback and outside review than from our own test runs.
And it is more honest. Anyone claiming their agents get better over time should be able to show what they measure that against.
What It Is Not#
Darwin does not make a weak model clever and does not make a badly designed agent correct. It improves an instruction along a yardstick somebody sets. If the yardstick is crooked, the agent will reliably become crooked.
That is not a limitation of the implementation, it is the nature of the thing. A system that optimises itself optimises exactly what is measured and nothing else. Anyone deploying something like this should therefore spend longer thinking about the yardstick than about the mechanism.
