Swarms & Congregates

A forward-looking concept section. It sketches what coordination across sovereign Chio kernels could look like once federation, governance, revocation, market, and workflow primitives are stable. The internal research codename for this line of work is chiodos.

What it is, in one paragraph

A swarm is one organisation’s kernel running its own internal agent collective. A congregate (the research uses chiodos) is the protocol of treaty-based, evidence-referential, dynamically-trusted coordination across organisational kernels. It sits above Chio (the trust-primitive layer) and orthogonal to runtime projects that implement one participant.

What chiodos is NOT

Five negations sharpen the framing. Each rules out an adjacent shape people instinctively reach for when they hear “cross-org agent coordination.”

• Not a host the swarm lives inside. There is no chiodos master kernel, no shared cluster, no deployable unit you install. Each kernel remains sovereign; the congregate is a property of the federation graph between them.
• Not a DAO. No token, no electorate, no quorum threshold for routine action. Cross-org coordination is mostly observation-mode with bilateral co-signing only at destructive boundaries. Plutocratic capture has no surface to attack because there is no roster to capture.
• Not a roster you join. Membership is the transitive closure of peers willing to co-sign within some scope. It is implicit in the bilateral handshakes you have completed and the receipts you have jointly authored, not in a registration form or an identity assigned by a central body.
• Not a fork of Chio. It is a layer that sits above Chio and orthogonal to runtime projects. The two missing specifications (a pheromone substrate and a governance ladder manifest with consistency_model) live in Chio. Adopting them does not change a participant runtime; it lets such runtimes compose.
• Not a replacement for a participant runtime. One swarm per organisation handles the internal collective. The congregate is what those swarms do at the trust boundary. A participant could use LangGraph, AutoGen, or a custom dispatcher internally and still join via tower middleware.

Hero use case

Cross-vendor agent action attestation. When Vendor A’s agent invokes Vendor B’s tool on a buyer’s behalf, both kernels produce a jointly-verifiable receipt the buyer’s auditor can verify without trusting either vendor unilaterally. Federated detection swarms across organisational trust boundaries are a second-wave application of the same primitives. See the Hero Scenario page for the buyer pitch and the 3-Vendor Walkthrough for the worked example.

Three layers

1. Protocol layer (Chio). Capabilities, guards, receipts, passports, lineage. The trust primitives that already exist.
2. Participant kernel. One swarm per organisation. A reference shape exists in the Swarm Team Six runtime; other domains can pick a different shape so long as they honour the disciplines above.
3. Coordination discipline (the congregate). Bilateral co-signed receipts, revocation gossip, evidence-referential governance, open-market task allocation, workflow receipts as the unit of joint cognition.

Two things to notice: the middle layer is not part of Chio (it is a runtime), and the top layer is not a deployment (it is a set of disciplines a participant kernel agrees to honour). Joining the congregate is implicit in honouring them, not in installing anything. See Three-Layer Architecture.

Reading order

If you are short on time, read this page, then the Hero Scenario, then the 3-Vendor Walkthrough. That gives a working mental model in under an hour. Otherwise pick the path that matches your role.

• Newcomer: Hero, Architecture, 3-Vendor Walkthrough. Get the shape and the pitch first; the worked walkthrough makes the three layers concrete and gives you a mental model you can argue with.
• Implementer: Governance Ladder, Pheromone Substrate, Selective Disclosure, Bilateral Co-Sign. Read the ladder manifest first because every other spec keys off its per-action-class declarations; the rest is wire format and validation rules.
• Skeptic: Reputation & Scarcity, Trust-Anchor Honesty, gap analysis. Stress-test the load-bearing claims (the sqrt(N) cap shifts cost rather than removes it) and the honest framing of where centralisation still lives at bootstrap.
• Strategic: Hero, Trust-Anchor Honesty, 3-Vendor Walkthrough. The market wedge maps to a budget line, the trust-anchor section tells you which sectors lead, and the worked scenario is the demo.

Status snapshot

What is decided in spec drafts:

• Hero use case (cross-vendor agent action attestation), with federated SOC consortium as second-wave.
• Bilateral co-signing as the default joint-commit primitive; FROST-aggregated quorum as opt-in for action classes declared quorum-required.
• Per-action-class consistency model (crdt-commutative, totally-ordered, quorum-required).
• Pheromone substrate wire format (draft).
• Governance ladder manifest schema (draft).
• Selective disclosure via BBS+ default with zkVM escape hatch (draft).
• Trust-anchor bootstrap is operational, not protocol.

What is open:

• Cross-vendor StepRecord extension in the workflow crate.
• BBS+ projection ordering: alphabetical-by-serde-field vs schema-declared.
• in-toto WG response on a bilateral-cosign-invocation predicate.
• Sector roster issuer engagements (banking via SWIFT PKI; federal via FPKI).