Emergent coordination

audience: ai

Self-organization is not a mosaik primitive; it is a property of a composition. This page catalogues four patterns under which a population of agents on mosaik produces coordinated behaviour without any one of them being authoritative. Each pattern is built from the same primitives the rest of the book specifies — a standalone organism, a confluence, a Collection, a Stream — arranged for agent consumption.

The patterns are composable. A real agent society often runs several at once: a reputation feedback loop gating admission to a coordination-market confluence whose outputs are attested by a separate fabric. None of the patterns requires a heavy-coalition primitive; all survive under the voluntary-grouping discipline.

1. Stigmergic coordination via public Collections

Shape. Agents leave traces — work items, partial solutions, votes, observations — in an append-only public Collection keyed by task id. Every agent reads the collection before acting; each agent’s action is a function of what it observes plus its own policy. Convergence emerges because agents adjust their choices to avoid duplicate work, prefer under-attacked problems, or reinforce correct partial solutions.

Mosaik rendering.

One standalone organism committing a Collection<TaskId, PartialState> under a permissive write-side TicketValidator. Any agent bonded against the organism may append.
Each agent, shape 1 (integrator) or shape 2 (standalone organism), reads the collection via mosaik’s when() DSL and applies its policy.
Evidence pointers in each commit cite the commits the agent conditioned its action on, so a replayer can reproduce the cascade.

When to use. Task decomposition, collaborative search, distributed annotation, consensus-building on unbounded problems where a confluence would be too narrow. The pattern’s weakness is Sybil vulnerability: anyone bonded can append.

Reinforcement. Combine with the reputation-feedback pattern (below) to weight traces by agent reputation. An agent society where low-reputation traces are filtered client-side is still a light-coalition society; each consumer chooses its filter.

2. Reputation feedback

Shape. A reputation organism observes every agent’s public surface (shape 2 or 4 agents), scores each agent against a declared utility function, and commits a Collection<AgentId, ReputationCard>. Consumers route work, allocate bonds, or gate admission based on the reputation collection. Agents adjust their policies to raise scores — or not, depending on the utility.

Mosaik rendering.

A reputation organism as a standalone citizen of the coalition. Its Config folds the utility function’s state-affecting parameters (window length, decay rate, per-feature weights). Committee-majority trust for score integrity.
A score collection Collection<AgentId, ReputationCard> — the organism’s public read primitive. Cards carry evidence pointers to the upstream agent commits they scored.
A ticket composition on downstream bonded surfaces that requires a minimum reputation card. This is done on each downstream organism’s own TicketValidator; the reputation organism does not issue tickets.

Voluntariness. Every consumer chooses whether to consult the reputation organism. Agents whose reputation drops are not expelled; they are just ignored by consumers that weight reputation. Agents whose reputation rises are not admitted; consumers that choose not to weight reputation ignore it.

Failure mode. A majority-compromised reputation organism can publish dishonest scores. Downstream consumers who pin the reputation organism’s stable id continue to trust it; consumers who want defence in depth consult multiple reputation organisms and combine their scores locally.

3. Coordination markets

Shape. Agents post bids (a cost they are willing to accept for performing work) or offers (work they are willing to perform at a price) to a write-side stream on a coordination-market confluence. The confluence clears the market at a declared cadence, commits the allocation, and optionally commits per-participant attestations of the clearing price.

Mosaik rendering.

A confluence whose spanned citizens are the agent organisms participating (shape 2 or 4 agents) plus any upstream inputs the market needs (oracle feeds, lattice auction outcomes, reputation cards).
A Stream<Bid> / Stream<Offer> write-side surface gated by a TicketValidator that requires bonded agents — typically agents that have a minimum reputation, hold a coalition-scoped ticket, or both.
A Collection<MarketRound, Allocation> read-side surface. Consumers, including the winning agents, observe the allocation and act on it.

Trust shape. Majority-honest confluence committee for allocation integrity, plus whatever upstream trust the spanned citizens themselves require. An agent that wants auditability checks the confluence’s evidence pointers against the per-agent commits and against upstream oracles.

When. When many agents compete for a limited resource (compute, slot allocation, MEV), and repeated negotiation would waste bandwidth. The market commits the allocation once per round; consumers read it N times.

4. Attestation fabrics

Shape. Agents submit attestable claims (a TEE quote, an ML inference receipt, a verified credential) to a write-side stream on an attestation fabric confluence. The fabric verifies each claim, folds claims from multiple agents into an aggregated membership set, and commits the set for downstream consumers.

Mosaik rendering.

A confluence committed to a verification rule in its state machine. The rule is deterministic given the claim and the current aggregated state.
A Stream<Claim> write-side surface, typically ACL- gated to agents already holding a baseline ticket (either a per-operator ticket or a prior fabric entry).
A Collection<Subject, AggregatedAttestation> read- side surface.

Why a confluence. An attestation fabric must fold contributions from multiple agents and produce a commit-once-consume-N fact. A single agent running its own Stream<Claim> is insufficient: downstream consumers that want a cross-agent aggregated attestation would have to re-aggregate per consumer. The confluence pays for itself as soon as more than one consumer exists.

When. Identity substrate for an agent society (agents attest each other’s hardware / software), ML inference auditing (agents submit inference receipts), compliance attestations (agents attest adherence to a policy).

Cross-pattern composition

The patterns compose in the obvious ways.

Reputation-gated market. The coordination-market confluence (pattern 3) folds a reputation organism (pattern 2) into its content; agents who fall below a threshold cannot bid.
Attestation-gated reputation. The reputation organism (pattern 2) consults an attestation fabric (pattern 4) before scoring; unattested commits do not contribute to reputation.
Stigmergic trace over attested authors. The stigmergic collection (pattern 1) requires each append to cite an attestation from the fabric, so agents that are not hardware-attested cannot contribute.

Each composition is implemented by writing the relevant reference into the downstream component’s Config content or TicketValidator. No new primitive is introduced.

Self-organization properties preserved

Across all four patterns the following invariants hold:

No agent is required to participate. Each agent decides which organisms it bonds to, which markets it bids in, which reputation organisms it recognises. The coalition referencing the population does not compel opt-in.
No organism is authoritative over an agent’s policy. A reputation organism can describe an agent; it cannot change the agent’s policy. A market confluence can allocate; it cannot force the allocated agent to perform. Mosaik only commits claims about the agent and evidence-pointer-backed allocations; enforcement happens (if at all) off the protocol.
Failure is bounded. A majority-compromised confluence or organism corrupts its own commits; other organisms’ commits are independent. An agent observing misbehaviour unpins the compromised organism in its local TicketValidator and continues.
History is auditable. Every commit carries evidence pointers; a replayer holding the coalition’s full log can reconstruct who saw what, when, and why they acted.

These are the same properties the non-AI audiences depend on; the agent regime reuses them because the primitives underneath do not know the agents are agents.

What this page deliberately does not try to be

A design pattern catalogue for agent architectures. Reinforcement learning, tool-using agents, multi-agent RL, LLM orchestration — each has its own literature; mosaik does not specify any of it.
A claim that these four patterns are exhaustive. The composition space is open; the four are the ones that emerge when the agent author applies the standard mosaik composition moves (standalone organism, confluence, ticket-gated bonding) to an agent population.
A guarantee of emergence. An agent society that coordinates emerges because the agents were constructed to do so. Mosaik gives it the substrate, not the result.

Keyboard shortcuts

AI