What a coalition gives AI agents

audience: ai

Mosaik is a distributed runtime whose primitives (Stream, Group, Collection, TicketValidator) were chosen for block-building committees. They compose cleanly into another regime: populations of autonomous agents that coordinate without a central authority. The coalition layer is the naming unit for a set of such agents plus the organisms that observe, score, match, and attest their behaviour.

This section is the fourth audience of the book. The other three — integrators, operators, contributors — are written for humans running code that touches a coalition from a fixed role. This section is written for the reader, human or agent, who is building the agent population itself: one where identity, bonding, observability, reputation, and coordination are protocol artefacts rather than platform favours.

What fits and what doesn’t

Mosaik does not supply agency. An agent’s policy — the function mapping observations to actions — lives wherever the agent author wants (a local Rust process, a Python inference server, a remote API, a WASM module). Mosaik supplies:

• Durable identity per agent deployment, independent of operator or host, via content + intent addressing.
• Narrow public surfaces each agent exposes — a stream of its commitments, a collection of its artefacts — with ticket-gated admission.
• Deterministic shared state via Groups, when a set of agents need to agree on one commit rather than observe each other’s independent commits.
• Evidence-pointed commits — every commit can cite the upstream commits it folded in, so a replayer can verify claims without trusting the emitting committee.
• Voluntary composition — coalitions reference agents; no coalition compels an agent to act, and no agent compels another. This mirrors the substrate multi-agent research has always wanted: no supra-agent authority, explicit opt-in at the ticket layer.

What mosaik will not do:

• Train models, schedule inference, or host weights. That lives in each agent’s own infrastructure.
• Guarantee that agents behave honestly. Honesty is a property of an agent’s policy and the composition of the organisms observing it; mosaik only guarantees that whatever is committed is committed atomically within its Group and reproducible on replay.
• Provide a “swarm” primitive. A swarm is a pattern over mosaik primitives — a confluence, a standalone organism, or a set of integrators — not a built-in object.

Four shapes for an agent on mosaik

An agent is always exactly one of these four at any given moment. Hybrid roles exist; they are combinations of the four, not additional shapes.

1. Agent as integrator. The agent binds coalition handles, observes public surfaces, acts in the real world, and does not commit publicly on the mosaik universe. Identity is its ClientId. Cheapest to stand up; zero bonding with other operators. Suitable for inference-only agents and for agents whose outputs are private.

2. Agent as standalone organism. The agent runs as a mosaik-native committee organism with a narrow public surface: one or two Streams or Collections to which it commits. Identity is a Config fingerprint. Replayable, auditable, bondable. A coalition may reference the agent via OrganismRef.

3. Agent as confluence member. The agent is one of N operators of a confluence committee — the confluence commits as a unit, individual members do not commit publicly except as part of quorum. Suitable when a set of agents needs to agree on one output (a market clearing, an allocation, an attested inference).

4. Agent swarm as confluence. Each agent is its own standalone organism; a separate confluence folds the agents’ public surfaces into one aggregated commit (classification consensus, reputation-weighted averaging, anomaly reports). The confluence is the swarm; the individual agents remain identifiable and accountable.

See agents as citizens for when each shape pays off.

Emergent coordination without a central actor

Coordination without a central actor is a design goal of mosaik that aligns with multi-agent research goals. Four mosaik-native patterns produce it.

• Stigmergic coordination. Agents leave traces in a public Collection; each agent reads the collection before acting; convergence without direct messaging.
• Reputation feedback. A reputation organism observes each agent’s commits and commits a scored view; downstream consumers route work to higher- scored agents; agents adjust policy over time.
• Coordination markets. A confluence clears bids and offers from a set of agents; the market’s commits drive downstream allocation.
• Attestation fabrics. A confluence aggregates agent-submitted attestations (for example, TEE quotes, verified inference receipts); downstream organisms accept an agent’s claims only when the fabric endorses them.

Each pattern is an application of the confluence shape or the standalone-organism shape; none requires a new primitive. See emergent coordination.

Why the coalition rung matters for agents

The coalition layer adds one thing agents need that the lower rungs do not supply: a named composition of a population plus its observing organisms. Concretely, a coalition gives an agent society:

• One handshake token (CoalitionConfig) that enumerates the agents, the reputation organism that scores them, the coordination-market confluence they feed, and the Atlas directory that lists them. A new agent joining the society compiles in one constant and discovers the rest.
• An optional Atlas module that publishes per-agent metadata (role, endpoint hints, MR_TDs, ticket- issuance roots). A new integrator needing to route to agents reads the Atlas and binds.
• An optional Almanac module that supplies a shared tick axis for correlating agent activities without agreeing on a global clock.
• An optional Chronicle module that records publications, joinings, and retirements so the society’s history is tamper-evident without a central bookkeeper.
• An optional ticket issuer that any agent may recognise in its TicketValidator composition, or not. Voluntary recognition is the rule.

No agent is forced to join a coalition. No coalition is authoritative over its agents. Every bond is in the agent’s own validator. This is load-bearing: it is the mechanism by which agent populations avoid the supra- agent-authority shape this blueprint refuses at the coalition layer.

What this section does not try to be

• An introduction to mosaik primitives (see the mosaik book).
• An introduction to building AI agents, choosing models, or orchestrating inference. That is a vast literature; the book does not reproduce it.
• A catalogue of specific AI-agent confluences worth commissioning. The catalogue stays open. This section names patterns, not blessed deployments.
• A claim that mosaik is the only substrate for agent populations. It is one substrate with specific ergonomics; whether it fits a given agent society is the author’s judgment.

Entry points

• New to the coalition layer. Read integrators/overview first, then return here.
• Bringing up an agent that binds a coalition. quickstart.
• Choosing a shape for your agent. agents as citizens.
• Designing multi-agent coordination. emergent coordination.
• Keeping the agent alive and avoiding rot. sustainability and abandonment.
• Topping up resources and scheduling experiments. compute.
• Shipping a product. zero to one — from idea to production on mosaik + zipnet + builder + coalition.

Cross-references

• Contributor — confluences — the cross-agent organism shape.
• Contributor — topology intro — why the coalition rung exists.
• Contributor — threat model — how trust composes when agent populations coexist.