Game design in loop harnesses
Recently, I've been using a lot more AI than before, especially as fable-like intelligence becomes more accessible with models like OpenAI's Astra and Deepseek 4.1 flash. One core method I've been using for incremental optimization is loops. They're great, but get stale quickly. So my journey for designing an innovation loop started.
My initial plan was simple - run subagents that solve different problems in parallel. Give five of them the same repo and the same goal, and whoever comes back with the best result wins. Technically that works, but what actually happened is that all five came back with basically the same solution, just with slightly different variable names.
Looking back that makes sense - they all start from the same context and the same codebase, so they all have the same idea about what a good first move is, and then they all make it. Letting them talk to each other made it worse, because now they agree on the average idea and the average idea is the one I already had. Telling them to be different works for exactly one turn. What they didn't have was a reason. Nobody loses anything by doing the obvious thing, so everybody does the obvious thing. That's when it started to look like a game design problem. If five people in a room keep giving you the same answer, you don't ask harder, you change what they get paid for. Make them rivals. Give them a score they can only raise by finding something the others haven't, let them see each other's results every round, and see what happens. So that's what I built.
Every agent becomes a company. After each round, every company gets its rank, the gap to the leader, and what the other four shipped. The leader's approach gets merged into everyone's shared base, so copying it gets you nothing, and if you're behind the only way up is a mechanism nobody else is on. I put a stock price on top because I wanted something I could read at a glance, and because "you're fourth and the gap is 12 percent" sounded like a stronger message than "please try something else". Underneath it all sits a referee that freezes the benchmark contract up front, runs every measurement itself, and only merges what actually qualifies.
Then I tested it, and it didn't work.
I ran five pilots, each one a real repo with a real performance target - an event aggregator, a C++ scene library, a parser, a calculator, a learning simulator. All of them are code I wrote by hand at some point in the past, so none of the agents had seen them before, and none of them had a benchmark until I wrote one. Each pilot ran two arms with the same time allowance and the same referee: a normal goal loop with one agent and a helper, and the market loop with five companies. The pattern was clear by round two.
The single agent found the big fix in its first round, every time. In the parser it was a hand-written scanner replacing a regex - 8x, in under six minutes. In the calculator it was a direct character scanner, 7x in four minutes. In the scene library it was compacting the transform state and building the matrix directly, in three and a half.
The market's first round looked the same every time too, just not in the way I'd hoped. Five companies, and in four of the five pilots they handed in the same idea. In the parser it was four near-identical tweaks to the existing regex, with one company noting in passing that a scanner rewrite "should be evaluated as an alternative" and nobody building it. In the calculator it was three copies of the same regex fusion and two copies of the same parser cursor. In the scene library the five submissions were really two ideas, and the release the market shipped came out slower than baseline on one workload when the referee measured it. In the learning simulator four of the five picked the same bottleneck before the overlap rule pushed three of them off it, and the round shipped nothing.
The market got to the rewrite in round two in every one of those pilots, and twice it then edged past the control's first round - but at two to three times the wall clock, and where I have the token counts, three to twelve times the tokens. The event aggregator was the one exception. Both arms found the same hash-aggregation fix in the first round, within a couple of minutes of each other, and nothing got adopted after that on either side. Here's where each arm ended up:
And what it cost to get there, in tokens, for the three pilots that recorded them:
So the rivals didn't diverge, and the mechanism I built to make them diverge didn't help. Rank is one number, it carries almost no information about what's unexplored, and it can't push until somebody leads. By the time somebody leads, the obvious fix is taken. When the simulator's first round delivered nothing, everyone entered round two with the same rank and the same price and nothing to react to. And the rule that told overlapping companies to pivot actively hurt in the one place it mattered. In that second round three companies independently found the government-scan fix the control had already shipped. The overlap rule sent two of them off to try something else, and the one that kept it got blocked by a memory guardrail. The rule was optimizing for novelty, not for being right. The stock price, meanwhile, did nothing the rank wasn't already doing.
There was a failure mode I hadn't thought about too. When five agents need five different mechanisms, some of them go and optimize something measurable that isn't the goal. In the simulator, three companies cut allocations by 20 to 30 percent and every one of them was slower. The combination of them was slower than the original. The single agent just went for runtime.
What did work, in every single run, was the referee. It caught a latency regression the market's own screening missed. It rejected a combined candidate that passed all its tests and ran slower. It noticed the host drifting 25 percent mid-experiment and refused to count small wins on top of that. It corrected a self-reported 5.13x down to a measured 4.92x. None of that needs companies or prices - instead have a manager that keeps the subagents in check and ensures only validated results go in. Turns out reviewing code before you merge it keeps quality high.
Where does that leave the original problem. I'm back to square one, and still looking for a good solution, but I'm now fairly sure incentives aren't it. If I want five agents on five different ideas, I should probably just assign the ideas and let the referee sort out which ones hold.
So this was a bust. Still, it was a good experience - hypothesizing a solution to a problem I ran into during another experiment. Probably don't use it, it's expensive for what you get out of it. It might do better in long-context tails, but I have no good data on that. I'll come back to it though.
The skill is called market-loop if you want to take a look.