← All posts

Our agent mesh tied a single agent. So we're teaching it to organise itself.

2026-10-22 · Christoph Heuwieser

In the last post we promised real-model results for the agent mesh we're building for a4sx. Here they are, and they are humbling: on 52 real bug fixes, a mesh of four Claude Code sessions did no better than a single session, and a fresh session per bug beat both on cost. This post is about why that happened, why we expected it more than we feared it, and what we're building instead: a mesh that organises itself, more like an organism than an org chart.

The short version:

• On 52 SWE-bench Verified issues, a fresh session per issue fixed 42, one warm session fixed 41, and a warm four-node mesh fixed 41. The fresh sessions were 5 to 9 times cheaper per fix.
• The mesh's weak point was not its messaging but how it shared the work: one node got 71 % of the issues, and 27 % went to the wrong owner.
• Bug fixes in a well-known codebase don't need remembered knowledge. So we built a workload that does, and there a single warm session forgets: it compacted its context eight times in 120 tasks, and in the second half it passed none of the checks that need an earlier fact.
• We designed a mesh that assigns work at once, rebalances while it sleeps and lets each cell decide whether it is a specialist or a generalist. In a simulation that costs no model tokens, it balances itself and recovers from shocks well, but it doesn't grow experts on its own yet.
• Then we tested each piece on real sessions in the Claude Code harness, one factor at a time. Passing knowledge between cells lost nothing. Compaction is where it gets lost: after two compactions, a session remembered 2 of 18 details from its early work. With a work log or notes, it remembered all 36.

A note on models. Every real run here used the Claude Code harness, but the model behind it was whatever our model router served at the time: for the bug-fix pilot a mix of Claude Opus 5.5 and gpt-5.6-luna, for the memory baseline a mix of Claude Opus 5 and gpt-5.6-luna, and for the single-factor tests gpt-5.6-luna throughout.

Real sessions, real bugs

Each node of the mesh is a real Claude Code session in its own offline container, and nodes ask each other through the local message mesh from the last post. We compared three set-ups on 52 django issues from SWE-bench Verified, in the order the issues were filed, graded by the official harness:

• a fresh session for every issue;
• one warm session that works through all issues and keeps its context;
• a warm mesh of four sessions, each owning part of the codebase, that ask each other when an issue crosses into someone else's part.

All three fixed about the same number of bugs: 42, 41 and 41. The fresh sessions were by far the cheapest, because a warm session re-reads its whole context on every turn, often 120,000 to 450,000 tokens, while a fresh session reads only what one bug needs.

The mesh also showed us where its design was weak:

• One node, the owner of django's database layer, got 71 % of all issues. Nothing moved work away from it.
• 27 % of the issues were routed to the wrong owner, because routing went by the words in the issue, not by where the fix landed.
• Ownership was advisory. In 6 of 16 cases a node edited another node's code without asking.
• Nodes rarely asked each other, 0.19 times per issue. With a shell and the source code at hand, reading is cheaper than asking.

That last point is the real lesson. Independent bug fixes in a codebase the model already knows well don't need anything the agent remembers. Whatever the mesh knows, the code says too.

Two smaller findings are worth passing on. First, a warm session that falls back to a different model can be forced to compact on the spot: the same conversation counted 1.72 times as many tokens on the fallback model, which pushed it over its window. Second, Claude Code writes its own memory files by default. We had not switched that off in this first run, so the warm sessions were not purely working from their context. Our later runs switch it off and check it at launch.

A workload that needs memory

So we built a workload where remembering is the whole point. A synthetic team works in threads, about a million tokens of them. Decisions, exceptions and conventions are mentioned in passing, only in the dialogue. Later tasks depend on them.

Fresh sessions can't solve those tasks: in a calibration run they passed none of the 63 checks that need an earlier fact, while sessions given the facts passed all 63. That is what we wanted, a test that only memory can pass.

Here a single warm session runs into its limit. It holds only its context, so every time the context fills up it compacts. Over the 120 tasks that happened eight times, each time cutting it from 200,000 to 380,000 tokens down to under 45,000. Every 20 tasks we asked it eight detail questions about earlier work: it answered 9 of 48 in total, and never more than 4 of 8 at once. It passed 5 of the 63 checks that need an earlier fact, all of them in the first half; in the second half it passed none, the same as fresh sessions. It also did worse on the tasks themselves than fresh sessions, 83 of 120 against 105, and used more tokens doing it.

This is the situation the mesh is meant for. Our goal is not to beat a fresh agent on a fresh task. We expect to lose there, and that's fine. The goal is a mesh that beats a single warm agent once there is more to remember than one context can hold.

The mesh as an organism

The four-node mesh failed at sharing work because a central rule decided who owned what, by package, once. We now think ownership has to emerge and keep moving. The new design has four parts:

• Assign at once, with some randomness. A new task goes to a cell straight away, without a search first. The draw favours cells that have worked on something similar and are near where the topic already lives, and avoids busy cells. Some randomness stays in the draw on purpose: we don't know in advance which knowledge a future task will need, so it pays to spread ownership and experience instead of piling them on whoever was first.
• Sleep. Whenever a cell isn't working, it sleeps, in phases. It compares its own load with the rest of the mesh, tags what newer knowledge has replaced, works out what kind of cell it is, consolidates, and clears out what was replaced. The model is loosely the way a brain clears used-up proteins in sleep. Knowledge is retired only when something newer replaces it, never because it is old. Forgetting by age hurt in every earlier run.
• Handing work over. A cell that holds too much can hand an item over. It finds the receiver with the same draw that assigned the work in the first place, and the move happens only if the expected saving beats the cost of the handover.
• Specialists and generalists. While asleep, each cell looks at its last 40 tasks and decides whether it is a specialist or a generalist. Generalists take new kinds of work. Specialists keep the areas that have matured.

What a simulation without model tokens shows

Before spending tokens on real sessions, we ran the design in a scripted simulator: about 3,000 runs at 4, 8 and 16 cells, with no model calls at all. It can test the mechanics: whether load evens out, whether ownership settles, whether roles form. It can't say how well real sessions remember. Its memory losses are assumptions, not measurements.

What worked in round one, without tuning:

• Load balances itself. The busiest cell carries 1.3 to 1.6 times the average, against 1.7 to 2.6 times with fixed owners.
• It recovers. After a sudden hotspot, load evens out again within about a task. With fixed owners, a 16-cell mesh never recovered. A new topic gets an owner on its first task.
• It is safe. Ownership was never lost or duplicated, not even with 30 % of messages lost or cells crashing mid-handover.

What did not work in round one:

• Experts don't form at the default settings. Nearly every cell calls itself a generalist.
• Handovers almost never happen. The rule that weighs saving against cost was set too strictly, and it blocked every one.
• Randomness spreads work, not knowledge. In this simulation a fact lives only where it was read, so random assignment scatters facts instead of copying them. Only answers and handovers copy knowledge.

With less randomness and a few other changes, experts do form. The price is slower recovery: after a hotspot, up to 39 tasks instead of one. Experts against resilience is the central trade-off.

We also tried a hormone-like signal. A small monitor watches the whole mesh and sends slow, fading signals to all cells: under stress, spread the work; when an area has no owner, explore; when the mix of roles is off, rethink your role. Each cell adjusts its own settings a little. The hope is to get experts in calm periods and resilience under stress, without anyone tuning the knobs by hand.

Round two: when work makes the knowledge

Everything in round one was about finding knowledge that already exists. Real work is different: doing a task creates knowledge, such as what was tried, what failed and why a choice was made. So in round two every simulated task produces knowledge held by the cell that did it, later tasks depend on it through links the mesh can't see in advance, and cells get better at the areas they work in. Again no model tokens, again assumed priors, about 22,000 runs.

• Randomness is insurance, not speed. Some randomness in assignment spreads experience: more areas end up with two skilled cells. It never raised quality, however unpredictable we made the links between tasks, and it cost 3 to 22 % more tokens. But when the busiest cell drops out, a mesh with a little randomness loses about half as much quality as one without.
• Apprentices beat dice. Sending a share of tasks to a newcomer while the owner checks the result spreads experience at a lower price than sending them to a random cell.
• Knowing who did what matters most. An exact record of which cell worked on what was worth up to 43 points of quality when tasks depend on each other unpredictably. A mesh where cells only ask their direct neighbours collapsed in that case.
• Handovers are safe but rare. With a fixed rule they now happen. Across about 1,300 handovers, including stress tests with lost and delayed messages, not a single item was lost or duplicated. They still seldom pay: balancing the work is a job for assignment, and a handover is the occasional correction.
• Hormones: only stress matters. The signal that reacts to unusual load evens out the work at a small cost when it fires only in real surges. The other signals did nothing measurable.
• Warm against warm. When memory is only the context, the simulated mesh beat a single warm session by a wide margin, about 0.5 to 0.8 against 0.1 to 0.2 on tasks that need earlier work, at about a third of the tokens per correct task. Most of that comes from splitting the context across cells. When the single session keeps notes, it ties the mesh and is cheaper, until its notes grow too large to search well.

A third round tried mechanisms borrowed from the brain. They mostly lost to simpler baselines; what kept a mesh resilient was knowledge that lives on outside a cell's context.

These are the mechanics, under our assumptions. So next we checked the assumptions on real sessions.

Real sessions, one factor at a time

Before running a whole mesh again, we tested each way knowledge moves on its own. Every test used real sessions in the Claude Code harness and the same team threads from the memory workload, followed by detail questions: exact values, tenant ids and the incident behind each decision. A session read four threads, and then:

• Asked directly, it answered 36 of 36. A fresh session that never saw the threads answered 0 of 36, so the questions can't be guessed.
• A fresh session with only a work log pointing at the threads went back, re-read them and answered 36 of 36.
• A successor that saw the reader's notes once, about 5,000 characters for four threads, answered 36 of 36.
• A handover pack for one area, sent to a session already busy with four threads of its own, came through 18 of 18, and the receiver lost nothing of its own areas, also 18 of 18. A handover cost about 450,000 tokens.

So handing knowledge from cell to cell is not where it gets lost. The simulator had assumed it was: it priced notes at about 80 % and gave handovers and re-reading their own losses. On real sessions at this size, none of that loss showed up.

Compaction is where knowledge goes

Then we isolated the factor that hurt the single warm session over the long run: compaction. Sessions read six threads with a small context window, so each compacted two or three times along the way, and then answered questions about all six.

• Context only: from the three earliest threads it remembered 2 of 18 details; from the three latest, 14 of 18.
• With a work log, the same kind of session answered 36 of 36. It went back to the old threads to answer, which cost about 370,000 tokens.
• With notes it updated after every thread, it also answered 36 of 36, and answering cost a tenth as much. The note-keeping itself cost 600,000 to 850,000 tokens over the six threads.

This changes what the mesh is for. Its cells don't need a better way to talk to each other. They need knowledge that lives outside their context, and a mesh that keeps track of who did what. The simulator pointed the same way: the exact record of which cell worked on what was its biggest lever, and in the third round what kept a mesh resilient was knowledge that outlives a cell's context.

These are small tests: at most six sessions per test, synthetic team threads with very distinctive facts, and no coding. They tell us which factor matters, not how large the effect is in a real codebase.

Next we run whole meshes on the memory workload again, now with a work log or notes in every cell, against a single warm session that gets the same tools. That is the comparison that counts: once both sides keep their knowledge outside the context, does splitting the work across cells still win?

Browse the marketplace → Save your own sessions →