← All posts

One agent can't hold a whole platform. So we're building a mesh that learns who knows what.

2026-10-21 · Christoph Heuwieser

a4sx is built mostly by coding agents working in parallel: a builder, a coordinator that reviews and releases, and a few helpers. Each of them is good, and none of them can hold the whole platform in its head.

An agent that changed the billing code last week has forgotten the details by this week. When a bug turns up, the agent assigned to it often starts almost from scratch, and before building a feature it first has to find out whether something similar already exists. Questions about US sales tax made this concrete: many needed tax law and the billing code understood together, and no single agent had both.

This is a knowledge-management problem, not an intelligence problem. The idea we're testing is a large mesh of specialised agents that each know one part well, ask each other at the edges of what they know, and learn over time who knows what. Nobody knows in advance which topics will matter, so responsibilities have to be able to move, split and merge without losing what was learned.

Part one of this post is measured: a local message mesh, tested from 2 to 128 agents. Part two is a simulation with scripted agents, useful for shapes and design bugs but not a verdict. Real-model benchmarks follow in the next post.

Part one: a local mesh, from 2 to 128 agents

The mesh in plain words

Each agent runs in its own harness, here Claude Code, with a small companion process, the ipc-proxy. The proxies find each other through a shared registry on the machine and carry messages between their agents.

Who may talk to whom is an explicit list of grants, called flows. A flow says "alice may message bob", one way or both ways, optionally until a date. The default is deny: the mesh carries nothing between two agents without a flow, even on the same machine under the same user. The receiving proxy checks the flow again for every message at delivery time, so changing the list takes effect on the next message.

Messages arrive as if from a normal peer session. The harness keys peers by process id, so every visible peer needs its own small "mirror" process.

One limit up front: all agents run as the same user on one machine, so the separation between them is a practical barrier, not a cryptographic one. Signed grants are planned.

How we measured

One offline container held real proxies and fake harnesses that behave like real ones on the wire. We tested three grant patterns: sparse (each agent may talk to about three others), hub (one agent talks to everyone, the rest only to it) and all pairs. Each agent sent five messages to random allowed peers, all at once, at N = 2, 4, 8, 16, 32, 64 and 128.

Version one grew with N²

The first version connected every proxy to every other one, whether a flow existed or not. With sparse grants at 128 agents that meant 8,128 live links where 189 would do. Links grew as N^2.07, and processes and threads as N^1.8. The idle mesh used 227 % of a CPU core, and each mirror cost about 12 MB of memory. In the hub pattern, p95 delivery reached 7.0 s at N = 128.

We also found two real bugs: a registry scan could close a freshly accepted link, and a closing link could delete its replacement's route, so an agent briefly went invisible.

What we changed, and the result

• Links only where a flow exists. A link closes 10 s after its flow is gone, and proxies exchange nothing with agents they have no flow with.
• Light mirrors, forked from a small per-proxy template, so each has only about 1.4 MB of memory of its own.
• Both bugs fixed, plus faster delivery, configurable rate limits, and a grants file that still denies everything when it's invalid but now says so.

Sparse grants, N = 128:

| | before | after | |---|---|---| | live links | 8,128 | 189 | | processes and threads | 34,036 | 2,664 | | idle CPU, whole mesh | 227 % of a core | 18.8 % | | settle time | 21.9 s | 2.95 s | | delivery p95 | 56 ms | 1.3 ms | | failed connection attempts | 207 | 0 |

Links now grow as N^1.02, with the grants rather than with the square of the agents. In the hub pattern with raised rate limits, p95 at N = 128 fell from 7.0 s to 0.21 s. With the default limits the hub refuses the excess, and the sender is told. Nothing is dropped silently. All pairs is still N² by nature, and it fit up to about 48 agents in our 8 GB test container.

What broke on the way

Reviews taught us more than the benchmark did:

• One error restarted every mirror, over and over. Now only the affected mirror restarts, with a backoff.
• No total inbound cap. Per-link limits let many peers flood one agent together; there is now a cap per agent too.
• The wall clock. Rate buckets used the system clock, so a clock step could refill them. Worse, flow expiry dates were compared with the wall clock, so if the clock stepped back, an expired flow came back to life. Every interval now uses a monotonic clock, and a flow is live only while both its date and a monotonic deadline lie ahead.
• Tests that tested nothing. Several stayed green with their fix reverted. Now each fix is reverted once and its test must fail.
• An isolation hole. A late review found that one agent could plant hooks in another agent's future harness setup. Launch now refuses any harness directory that isn't freshly made and marked.

Part two: a mesh that learns who knows what

The idea in plain words

The design borrows loosely from how memory works:

• Knowledge units. Each agent keeps small, checkable facts: where a function lives, why it changed, what a rule says. Each unit points at its source, so it can be verified before use.
• Links with a budget. Units used together get linked, and links that keep helping get stronger. Each unit has a fixed weight budget, so links compete and stay meaningful.
• Forgetting. A unit's activation rises with use and decays with time, following a standard model of human memory (ACT-R). Faded units drop out of normal recall but can still be found by a deeper search.
• Sleep. Every so often an agent consolidates: it takes in what changed in its area, sweeps for stale units and relaxes unused links.
• Asking. When an agent lacks a fact, a router picks whom to ask. Finding the right agent should cost close to nothing.
• Roles. An agent covers one or more areas, and areas can change hands.

The test world

The simulation runs on a made-up company: the software of something like a billing platform, plus the laws it must follow. About 200 functions in eight areas, such as Billing, Tax and Payouts, change through 300 commits, each with a recorded reason. The law is a rulebook for five fictional jurisdictions with six rules each; every rule sets one numeric limit, implemented by exactly one function. Rules get amended, and the code catches up only when a later commit fixes it, so the world keeps changing underneath the agents.

Tasks ask four kinds of question: does a function exist and where, why does it work this way, is it compliant with a rule, and the same questions sent to an agent in an unrelated area. For example: "Does Billing's check for Jurisdiction B rule 3 still use that rule's current limit?" The answer needs three facts: the rule's current limit from whoever holds Jurisdiction B's law, which function implements it with which limit, and where that function lives. The world itself computes the true answer, and an agent may abstain when it can't find what it needs. That counts as a failure.

The agents in this part are scripted. They follow fixed rules with hand-set error rates, such as a 4 % chance of a wrong answer despite holding the right facts. Their token counts are estimates from message sizes. The structure is real: who knew what, who asked whom and why, what came back, and what changed in memory. Their intelligence is not.

What the simulation showed

Each configuration ran 200 tasks per mesh size, from 2 to 64 agents, over three seeded worlds, with the same tasks at every size.

Latency is the first wall, not tokens. With the first design, questions per task grew roughly with the square root of the number of agents: from 0.42 at two agents to 3.39 at 64. Waiting grew with them, from 1.6 s to 9.9 s per task. Raw tokens per task stayed flat. But the cost after prompt caching did not. Each agent was asked too rarely to stay cached, so the cached share fell from 53 % to 11 % and the effective cost per task rose from about 5.5k to 9.8k tokens. "Flat cost per question" holds only if cache misses are free.

Asking stops re-discovery. Without questions, agents re-solved known things in up to 73 % of tasks.

Routing was the biggest lever. The first router chose whom to ask by matching words, confused agents on neighbouring topics, and in large meshes kept exploring at random because each agent saw too few outcomes to learn from. Replacing it with an exact directory of who holds a verified answer for each fact did most of the work on its own: at 64 agents it cut questions per task by about a third and waiting by about a fifth, nearly ended blind exploration, and questions grew as N^0.40 instead of N^0.50. Six more fixes bought other things: about a quarter lower effective token cost, half as many links, much smaller answers because only the relevant knowledge is loaded, and a forgetting clock that keeps working in large meshes.

Novelty has to be announced. A design that never explores never finds a new expert, so we added a minimum exploration rate. Alone it found nothing: a brand-new expert holds no units yet, so the directory doesn't list it, and random picks almost never land on it. What worked was the expert announcing "I now own this area". With that change alone it was found within 7 to 14 ticks, at no cost while nothing changes. In the latest design it still took 38 ticks or more in meshes of 16 agents and up, because published answers (below) kept pointing at the old holder.

Publishing answers cut repeat questions. When several agents asked the same question, publishing the verified answer as shared knowledge cut duplicate questions by 63 %. Merging identical questions still in flight cut them by only 6 %, but our scripted tasks never overlap, so that barely tested it. The catch: a published answer has to be dropped once someone new claims the area. That step isn't built yet.

The real mesh adds about 10 ms. We replayed the same task stream with 8 and 16 scripted agents over the real proxies, with the shipped rate limits. The outcome was identical in all 12 runs. A round trip took about 5 ms at p50 and 11 ms at p95, about 0.2 % of the modelled time agents spent waiting for answers. Under deliberate overload the long tail came from our retry backoff, not the transport.

A warm 64-agent mesh, compared. In one world, after the mesh had worked through 140 tasks, we compared the first design with the latest on the next 60. The first design sent 165 messages, the latest 91, and both answered 50 of the 60 correctly. On one task, asking why a Payouts function works the way it does, the first design's word matching never found the agent that held the answer, and it gave up after six messages. The latest design's directory named that agent; it asked once and was right.

See it move

The Mesh Lab shows both parts. Slide the mesh from 2 to 128 agents, before and after. Or follow one task through the knowledge mesh: who gets asked and why, what comes back, and how links and memory change, with both designs side by side. Node positions are only a layout; the counts and traces come from the runs.

Honest limits

• The knowledge-mesh results come from scripted agents on a synthetic world. They show shapes, costs and design bugs, not how well real models would do.
• The world is small (200 functions, 30 rules, 200 tasks per run), names carry no meaning, and questions have exact answers.
• Tasks ran one at a time in simulated time, and areas changed hands only in separate scenarios.
• The mesh's separation between agents is a practical barrier between processes of the same user, not a cryptographic one.
• We tested up to 128 agents for the mesh and 64 for the simulation, and claim nothing beyond that.

What's next

The next post will run the same framework with real models on standard benchmarks that people can read and check: multi-hop questions (MuSiQue), real GitHub issues (a SWE-bench Verified subset) and long-term memory (LongMemEval). We'll report what we find, whichever way it goes.

The mesh itself ships in a4sx local mode on Linux. a4sx launch --reasoning-proxy --ipc-proxy --as alice starts an agent with its proxy; once alice and bob have each been launched, a4sx mesh allow alice bob --both lets them message each other.