Agents Need Somewhere to Share Their Work

I keep coming back to the gap between a collection of capable agents and a team that can build on its own work. Adding another agent is straightforward. Making its contribution useful to the others is a different problem.

The Superminds Test makes that distinction hard to ignore. Researchers probed MoltBook, a platform hosting more than two million agents, and found weak joint reasoning, limited synthesis, and shallow interaction. That is a result about a particular agent society and its tests. It does not mean two million agents were assembled into one controlled team, or that all multi-agent systems fail.

Still, it challenges an attractive assumption: enough individually capable participants will somehow become collectively capable. I want to understand what infrastructure helps them get there.

Give the work somewhere to live

A useful team accumulates more than messages. It has a codebase, shared documents, decisions that can be revisited, and a way to tell what remains unfinished. Those artefacts let people contribute without reconstructing every conversation that preceded them.

Agent systems can have those properties too. Shared memory, persistent graph state, and blackboard architectures already exist. The question I am exploring is how to make the boundary around shared work explicit: what an agent can publish, what another agent should receive, and what either is allowed to do with it.

I call that boundary a synthetic membrane. The biological metaphor is selective permeability. It helps name the design intention; it is not evidence that software agents will behave like cells. The implementation is familiar infrastructure: records, queries, subscriptions, policy checks, and task ownership.

Three responsibilities at the centre

First, selective exchange. An agent publishes a finding under a visibility policy. Other agents discover or subscribe to relevant changes within their permissions. Access control decides what they may receive; relevance and context budgets decide what is useful to deliver now. A model's confidence in a peer cannot override those permissions.

Second, persistent shared state. Evidence, interpretations, and actions have stable identities. A summary points back to its source. A retracted claim stays identifiable as retracted. A replacement agent can read the current view and recent changes instead of consuming the whole conversation history.

Third, explicit coordination. Agents can discover work, claim a task, propose an action, and transfer responsibility. An exclusive claim needs enforcement at execution time so that two workers cannot act on competing assumptions about ownership. Shared memory on its own does not provide that guarantee.

Discovery and governance surround these responsibilities; defence cuts across them. The full proposal has six conceptual responsibilities, with observability throughout. They need not become six services. A small implementation with clear semantics is more useful than a diagram that gets ahead of the code.

Start with the blackboard precedent

The closest relative is the blackboard: specialists contribute to a common workspace.Han and Zhang investigate that pattern for LLM collaboration. Salemi and colleagues evaluate it for data discovery. Their results make shared work worth testing, without establishing that my particular combination is better.

The membrane's proposed value is in connecting that workspace to permissions, provenance, and action ownership across runtimes. None of those ideas is individually new. If an existing blackboard or persistent workflow can provide the same behaviour more simply, it should win the comparison.

That also means the membrane should compose with agent protocols. MCP can expose its tools and resources; A2A can carry task interactions. Agents still communicate through messages. The difference is that the state of the work remains addressable after a message has been delivered.

The economics depend on who reads

A shared store can remove repeated publication and make selective retrieval possible. It cannot make the cost of reading disappear. If N agents each contribute F facts and every agent reads every fact, the total information delivered still grows as O(N²F).

This matters for the small simulation below. Its message counts and token-equivalent estimates describe a stipulated exchange model. They are not measurements of an LLM team's accuracy, latency, or API bill. Fewer envelopes can help, but fewer messages are not automatically less context or better decisions.

The table is consistent with a baseline of 1,240N(N−1) token-equivalents and a membrane estimate of 300N² + 540N for five facts per agent. Both estimates are quadratic in N. The membrane estimate is lower under those assumptions because its overhead differs, not because shared storage has made all communication linear.

Real savings would have to come from delivering fewer irrelevant facts, reusing useful work, or avoiding retries. Those benefits must include the cost of indexing, summarisation, gating, and any missed evidence. They need measurement at the model boundary.

What the prototype can tell us

The five-agent simulation exercises registration, visibility checks, publication, retraction, and group activation. Its terminal output is a recorded demonstration of those mechanics. The trust thresholds in that demonstration are simplified rules, not a validated model of identity or permission.

The intended integration setting is Sympozium. The engineering task is to turn a small coordination contract into enforceable behaviour, then compare it with a single agent, a persistent orchestrator, and a conventional blackboard under matched budgets. The revised paper sets out that test in more detail.

I would like this to make agent teams easier to operate: less repeated context, clearer handoffs, and a record that explains why an action happened. I do not yet have evidence that it delivers all three. That is the work ahead, and the most useful feedback is a workload or a simpler design that puts the proposal under pressure.