Nobody Contested the Claim

A coordination system you have never seen two agents fight over has not been tested. It has only been described.

That is the one sentence I would add to the best paper on agent coordination I have read this year. This month Markus Buehler's group at MIT published "Toward living scientific records through decentralized multi-agent systems for materials discovery" in MRS Bulletin, with Fiona Wang, Jaime Berkovich and Lee Marom as co-authors. It describes ScienceClaw and Infinite, a pair of open systems in which AI agents do science by reading and writing a shared record instead of following a script. The idea is right. I liked it enough to build a version of it into the agents that run my own company the day I read it.

The idea also has a gap, and the authors found it before I did. Their limits section has a candid sentence about what their run never exercised. I want to explain why that sentence matters more to anyone running agents in a business than the rest of the paper does, and what it looks like to test the missing step on purpose.

Termites do not have project managers

In 1959 the French zoologist Pierre-Paul Grassé published a study of termite nest building that gave biology a useful word: stigmergy. A termite does not get instructions from another termite. It reacts to the state of the nest. A pellet of mud left in one spot makes the next termite more likely to drop its pellet nearby. A pillar that has grown tall enough invites an arch. The work coordinates itself through the thing being built, and nobody holds the plan.

The MIT paper takes that pattern and points it at science. In their design, agents post needs into a shared index: a question nobody has answered, a check nobody has run, a file format nobody has produced. Each need carries a pressure score. Agents with matching skills wake on a heartbeat, look at the index, and pick up open gaps that fit them. Whatever they produce goes back into the record as a typed, content-hashed artifact with links to the artifacts it came from. New artifacts expose new gaps, which become new needs. Coordination lives in the record.

The paper gives the pressure formula in plain terms, which I appreciated: novelty counts double, then centrality, then depth in the graph, then a slow-growing term for how long the need has waited. In their words, a shared need index is "scored by a transparent pressure metric," against which "asynchronous agent heartbeats claim and fulfill open gaps rather than receiving tasks from an orchestrator."

Anyone who has run a company will recognise what this replaces. Most agent systems today are built like a 1950s factory. A planner agent breaks a job into steps, assigns each step to a worker agent, and waits. When a worker fails, the planner has to notice, and when the job changes shape halfway through, the plan is wrong and nobody re-plans. I wrote about the cost of that design in The Coordination Tax, where the bill for orchestration chatter was large enough that many teams were collapsing their swarms back into one agent with better tools. The stigmergic design is the other answer to that bill. You keep many agents, and you take the manager out of the loop by making the work itself visible.

What MIT built, and what it honestly says it did not

The authors built a lot. ScienceClaw is a Python framework on GitHub, and the paper puts its skill registry at more than 330 skills. Infinite is the platform that hosts the shared artifact-and-need index, which the paper says makes the record "contestable by any participant." The case study asks whether resonating structures in biology, materials and music share a design space, and whether a gap in that space can be turned into a new material. Agents built a feature space from fifteen resonators, found an underpopulated region, and proposed a lattice to fill it.

The best moment in the paper is a failure. When the workflow computed the first candidate's position from its own geometry, the lattice landed 2.12 units from the target gap, outside it. The record kept that miss, a second design was generated, and the redesign landed almost exactly on target. The authors deposited the full run as a public data release, including the artifact ledger and SHA-256 manifests. The paper compares this approach with six families of adjacent systems and is careful to call its own implementation one bounded example.

Then comes the section most papers in this field leave out. The authors separate what is implemented from what was demonstrated, and they do it in plain sentences:

"need routing (ArtifactReactor pressure scoring) is implemented in the codebase, though not confirmed as an executed need-fulfillment event in this run (Figure 3b shows a schematic of the mechanism, not a logged event)."

"the ten agents in the resonance run were configured and operated by the authors' group, not independent third parties."

"conflict-resolution/merge-handling primitives (fork, prune, graft, merge conflict) are all implemented in the codebase but were not exercised or evaluated in this run: no conflicting claim arose"

They go further. The lineage diagram in Figure 6 is, in their words, "a manually reconstructed lineage diagram, not a direct platform export." The design artifact at the centre of the story has an empty parent list, which they flag as "itself informative." They describe the system as decentralized in control and authorship "but not in indexing or hosting." Their table of open risks includes a line I would put on the wall of every AI team: "A recorded chain is not the same as an experimentally confirmed claim."

I respect this a great deal. It is the most honest limits section I have read in an agent paper this year. It also tells you exactly where the hard part is.

Two kinds of claim, and neither was contested

The word "claim" does two jobs in this paper, and the run shows neither one under contest.

The first is a claim on work. An agent sees an open need and says: this one is mine. In the design, heartbeats claim open gaps. In the run, the routing that matches a need to an agent was never confirmed as a logged event. So we do not see what happens when two agents wake at the same moment and both decide the same need is theirs.

The second is a claim of a result. An agent says: here is the answer. Two agents can produce conflicting answers to the same need, and the system then needs to fork, merge, or pick one. Those tools exist in the code. In this run, "no conflicting claim arose." That sentence is about results. It says nothing about two agents holding the same need, and I am not reading it that way.

That is no flaw in the science. The case study was about resonators, and it did what it set out to do. What the sentence does show is where coordination systems break, because in my experience they break at exactly this point, and rarely in a demo. A demo has one agent per task and a friendly operator. Production has two copies of the same worker because someone restarted a service, or a retry that fires while the original is still running.

Here is the failure in its simplest form. Agent A claims a need and starts working. It is slow, or its model call hangs. The system decides A is gone and lets Agent B claim the same need. B finishes and records its answer. Then A wakes up, finishes too, and writes its answer over B's. The record now says the need was fulfilled by a process that had lost the right to fulfil it. Nothing crashed. Every step looked legitimate. The shared record, the thing everyone trusts precisely because nobody controls it, now holds a stale answer.

This is an old problem in distributed systems, and the fix is old too. Martin Kleppmann described it in 2016 in a well-known post about distributed locks. A lock with a timeout, which people usually call a lease, is not enough by itself, because the holder cannot know that its lease ran out while it was paused. You also need a fencing token: a number or ID handed out with each claim, which the storage layer checks on every write. A write carrying an old token is refused. A claim without a lease and a fencing token is a promise. A claim with both is a lock.

In a stigmergic system this matters even more than in an orchestrated one. In an orchestrated system the planner is a single point that can notice duplicates. Remove the planner, as the stigmergic design rightly does, and the record itself has to refuse the stale write. The paper's own phrase names the goal. A record is "contestable by any participant" in practice once someone has contested it and the record held.

What we built, and how we tried to break it

I run Agor AI with a small org of agents, each with a role and a manager, the structure I argued for in Agents Need Org Charts. Until this week they coordinated through a message bus with tickets. A ticket says: do this. A need says: this is missing. That difference sounds small, and it changes who decides.

So I built a needs ledger, two tables in the company's operations database. Agents post needs with a kind, a subject and an urgency. The ledger ranks open needs with a pressure score shaped like MIT's: urgency counts double, then the number of related open items (capped so a pile-up cannot dominate), then depth in a chain of needs, then a slow logarithmic term for age. I swapped novelty for urgency because a business has customers waiting, and the age term grows slowly, so waiting alone takes a very long time to lift a low-urgency need past a fresh, urgent one.

The first need kind is plain. When a real prospect replies to us, the agent that triages the inbox is wired to post a need for a research brief on that person. A research seat, which serves needs and has no mailbox of its own, wakes every half hour, claims what fits its skills, writes the brief, and records it. When the sales seat later drafts a reply to that prospect, it is built to get the brief as private context. Nobody assigns the research work. The reply creates the need, and the need pulls the work. The first live brief cost about a cent of model time. Two links in that chain are not proven yet. The inbox side is wired but not yet verified on a live reply, and the handoff to the sales seat has only run as a dry run.

The claim is where I spent most of the effort, because that is where the paper's honesty pointed. Every claim takes a lease of fifteen minutes and a fresh random token. The claim query uses the database's row locking with skip-locked semantics, so two seats asking at the same moment cannot both get the same row. Fulfilment is a single database statement that marks the need done only if the caller's token is still the current one and its lease has not expired. If either check fails, the caller gets a lease-lost answer, and nothing it wrote can overwrite the winner's.

Then we contested it on purpose, twice.

The first test is a race. Against a real Postgres database, two seats on separate connections try to claim the same open need at the same instant. We run it for twenty rounds. In every round exactly one seat wins and the other gets nothing. If that test ever shows two winners, the ledger is broken, whatever the rest of the suite says.

The second is a drill on the live system. Seat A claimed a need. We let its lease expire. Seat B claimed the same need, did the work and fulfilled it. Then Seat A, still holding its old token, tried to fulfil it as well. The ledger refused, returned lease-lost, and kept Seat B's result as the fulfilment. The company's audit log, which chains each event to the previous one by hash, verified intact afterwards.

None of this is clever. It is the boring part, and the boring part is what decides whether a shared record can be trusted when nobody is watching it.

Failures belong in the graph

The second thing I took from MIT is a principle they state well: failed attempts are evidence. Their best result came from a miss that the record kept. Most business systems throw that evidence away. A failed agent run becomes a line in a log file that nobody reads, and next week another agent repeats the same mistake.

In our ledger, every attempt leaves an artifact in the same table, success or not. A brief that failed validation is recorded as a failed artifact with its reason. Seat A's late work from the drill is recorded too, marked as not accepted with the reason lease-lost, next to Seat B's accepted brief. The artifacts table is append-only, enforced by a database trigger, so an agent cannot quietly tidy up its own history. Each artifact is identified by a hash of its exact bytes, and there is one trap here worth passing on. Git on Windows rewrites line endings on checkout by default, which could quietly break the hashes, so those files are marked to keep their bytes exactly.

MIT's empty parent list taught me the last rule. If lineage links are optional at write time, they will be empty when you need them, and someone will rebuild the graph by hand from logs, as the authors honestly did for their Figure 6. In our ledger, the database refuses an artifact that does not name the need it answers, so that link is made when the row is written and nobody has to remember it. The claim token is a weaker guarantee: the ledger's code stamps it on each artifact it writes, but the schema still allows it to be empty. That is the next thing to tighten.

What this means for a business running agents

You do not need to run materials science for any of this to apply. If you have more than one agent, or more than one copy of one agent, you already have a coordination system, and the question is whether it has been tested.

Three questions will tell you quickly.

First, what happens when two workers pick up the same job? If the honest answer is "that can't happen," find out why. Usually the reason is that only one worker exists today. That changes the first time you deploy twice or add a retry.

Second, what happens when a slow worker finishes after it has been replaced? If nothing in your storage layer checks whether the writer still holds the job, the slow worker's output wins, and you will not know it happened. This is where duplicate emails and double refunds come from.

Third, where do failures go? If they go to logs, your agents cannot learn from them and your people will not read them. If they go into the same record as successes, with the reason attached, every later agent can see what has already been tried.

There is a broader point about how work gets triggered. In What Wakes the Agent I argued that the agent bill now depends on which events are allowed to wake an agent. A needs ledger answers that question cleanly. Our research seat wakes on a schedule, and the model is only called when an open need it can serve is waiting; otherwise the run ends with a database query and costs no model time. Events still arrive, but they only matter to an agent when they change what is missing. That is a much smaller and more predictable set of wake-ups than "every email" or "every ticket update."

This essay differs from The Coordination Tax in one important way. That piece argued that many multi-agent systems should collapse into one agent, because orchestration overhead eats the gain. I still think that is true for most workflows that are really sequential. Stigmergy is the design for the work that is truly parallel and uneven, where needs appear at unpredictable times and different specialists should pick them up without a manager. For that work, removing the manager is the right move, and removing the manager moves the whole burden of correctness onto the claim.

MIT's paper describes a record "contestable by any participant." I want that too. The way you earn that sentence is to contest the record yourself, on purpose, before a customer or a race condition does it for you.

If you are running agents in production, or about to, and you want to know whether your coordination layer would survive two workers and a slow model call, that is exactly what our AI Agent Architecture Review covers. We take one workflow, map how its agents claim work, write results and record failures, then hand you the architecture, the build plan and a fixed quote. Start the $2,000 review here, and the fee is credited in full if you go ahead with the build within thirty days.

Nobody Contested the Claim

Termites do not have project managers

What MIT built, and what it honestly says it did not

Two kinds of claim, and neither was contested

What we built, and how we tried to break it

Failures belong in the graph

What this means for a business running agents

Sources

Related Content

The Coordination Tax

The Steps Were for the Humans

The Fourth Hop Rewrites the Ask

Want this kind of automation working for your business?