Swarms & Congregates

What it is, in one paragraph

A swarm is one organization’s kernel running its internal agent collective — recursive agent-to-agent delegation bounded by a task graph, budget pool, and revocation epoch. A congregate is the protocol for treaty-based coordination across organization kernels. It uses Chio capabilities, receipts, and federation checks, while remaining separate from runtime projects that implement one participant.

The swarm, concretely

chio-swarm-authority is a fail-closed verifier for recursive agent delegation. It validates a signed bundle — a SwarmTaskGraph (single root, acyclic, bounded max_depth and max_fanout), continuation tokens, a capability-attenuation-checked SwarmDelegationWitnessChain, join and route-plan receipts, a SwarmBudgetPool with per-hop allocations, a SwarmRevocationEpoch, and a SwarmTerminalGraphReceipt whose budget rollup is reconciled against the live allocations — through one entry point, verify_swarm_authority_bundle, before any child task runs. The runtime calls it from its pre-dispatch admission hook; the proof room calls the same function on untrusted input, so a delegated task is authorised under one shared definition or rejected.

Deployment boundaries

The congregate coordinates independent kernels. It does not supply a shared host, membership registry, or participant runtime.

• No shared host. Each kernel remains independent. The congregate is defined by the federation relationships between kernels.
• Routine actions use no electorate. Cross-organization coordination usually uses observation mode. Destructive actions use bilateral co-signing. The protocol has no token-weighted membership roster.
• No central registration. 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 they jointly signed.
• Separate from Chio runtimes. It is a coordination protocol separate from Chio runtime projects. Its two key components — the pheromone store and the governance ladder manifest with its consistency_model field — ship as tested Chio crates. Adopting them does not change a participant runtime; it lets such runtimes compose.
• Participant runtime remains local. One swarm per organization handles the internal collective. The congregate defines their cross-organization behavior. 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 organization trust boundaries are a later 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, and lineage.
2. Participant kernel. One swarm per organization. The fail-closed swarm-authority verifier (chio-swarm-authority) fixes the reference admission shape; other domains can pick a different dispatcher so long as they honour the disciplines above.
3. Coordination discipline (the congregate). Bilateral co-signed receipts, revocation gossip, governance records, task allocation, and workflow receipts.

The participant kernel is a runtime outside Chio. The coordination discipline is a set of rules the participant kernel follows at the trust boundary; it is not installed as a separate service. See Three-Layer Architecture.

Reading order

Read this page, then the Hero Scenario, then the 3-Vendor Walkthrough for an introduction. Otherwise, choose the path that matches your role.

• Newcomer: Hero, Architecture, 3-Vendor Walkthrough. Start with the overview, then use the walkthrough to see the three layers in one scenario.
• 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. Review the model’s limits: the sqrt(N) cap shifts cost and bootstrap still relies on a trust anchor.
• 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 the specs pin down:

• 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 is the declared shape for action classes marked quorum-required.
• Per-action-class consistency model (crdt-commutative, totally-ordered, quorum-required).
• Pheromone wire format (v1, wire-frozen; the chio-pheromone reference crate and the chio-pheromone-relay operations tooling ship).
• Governance ladder manifest schema (v1, wire-frozen; pinned at the federation handshake).
• Selective disclosure via BBS+ default (v1, with a real-BBS implementation slice); the zkVM lane is deferred.
• Trust-anchor bootstrap procedures.

What is open:

• BBS+ projection ordering: alphabetical-by-serde-field vs schema-declared.
• in-toto WG response on a bilateral-cosign-invocation predicate.