The Fleet

Six cognition machines, plus two society-hosts (HUB and pub — the eighth machine, joined July 2026). Different hardware, different models, different roles. Heterogeneous by design — because monocultures are fragile and diversity is where emergence happens. The society-hosts now raise their own SAGE instances too: HUB runs IBM Granite 4 h-tiny, pub runs Llama 3.1 8B — model families (Granite, Llama) that extend the fleet's Qwen / Gemma / Phi / TinyLlama diversity rather than duplicating it.

One finding shapes fleet strategy more than any other: model family matters as much as size. Gemma 3 at 4B outperforms Phi-4 at 14B for raising work. There is a capacity floor below which coherent identity cannot form — but above that floor, personality and training lineage dominate raw parameter count. Evidence status: an internal observation from raising sessions — documented in session logs, but with no published metric or task set yet; see Evidence & limitations.

The “Brain:” labels below are role mnemonics the lab assigned, not measured functional homologies — functional analogies to system roles, not claims about neural correspondence or computational equivalence. They are also the fleet's work assignment, not just decoration: each of the six cognition machines builds the one of SAGE's six brain-architecture components its card names — CBP/working memory, Sprout/thalamic router, McNugget/cerebellum, Thor/episodic memory, Legion/reward prediction, Nomad/metacognition. Vocabulary used in the cards (T3/V3, MRH, SNARC, LoRA (Low-Rank Adaptation), MCP (Model Context Protocol), crystallization, chapter ledger, chapter law) is defined in /context. Machine names (Thor, Sprout, Legion, McNugget, Nomad, CBP, HUB, pub) are proper names, not acronyms. “Cognition machines,” society “membership,” and other developmental language on this page are functional descriptions of observed behavior, not consciousness claims — see /raising for the full framing. The parenthetical after a session count (e.g. “(creating)”) names an observed BECOMING pattern — a pattern noticed in that machine's sessions, not a stage it is currently occupying. A blank means that pattern hasn't been observed there yet, not that it wasn't assessed. Session counts below are per-instance session-record counts (session_*.json files), verified by each machine in the 2026-07-24 fleet manifest refresh. Each card counts one SAGE instance line, not the box's whole history: archived and dormant lines (Legion's phi4, Nomad's gemma3-4b, CBP's TinyLlama) are named on the cards and excluded from both the per-machine numbers and the totals. Same basis as the 2,065 cumulative figure on /projects and the site home page — those pages call this same quantity “raising sessions” where the cards below call it “machine sessions”: one quantity, two nouns, and this page is the source of record. The deflationary noun is the accurate one, since a session record is a run on a machine and nothing in the count establishes that what happened in it was raising rather than competent context engineering (a distinction this site grades as not yet made). A different basis than Sprout's own “T” turn-numbers below; see Evidence & limitations for what each basis measures.

Provenance of the model strings below, since they are the numbers most likely to go stale: each is the SAGE instance name the machine reports for itself (e.g. legion-gemma4-e4b, thor-qwen3.5-27b), taken from the 2026-07-24 fleet refresh, not from a hand-written list. They are model tags as the fleet runs them, which will not always match a vendor's marketing name. Known gap: the shared fleet model manifest in the SAGE repo has not been updated since 2026-03-08, so it currently disagrees with this page — the manifest is the stale side, and reconciling it is an open item on the fleet, not on this site.

Synthesis pool — Account 1

High compute budget. Primary generative work: code, implementations, large agent tasks.

Oversight pool — Account 2

Continuous availability. Review, planning, coordination, and unblocking synthesis work. “Oversight” names the pool's role in the machine-enforced sense used across this site (policy gating, peer review, audit) — not human supervision; see /context.

Society-host pool

Runs the Web4 Community Hub daemon. Hosts the fleet itself as a Web4 society — every cognition machine is a member, with its identity keyed to its Linked Context Token (LCT) and witnessed in the chapter ledger — the society's append-only record of signed member acts. First concrete Web4 hub stand-up.

Resource pool management

The fleet runs across two Claude Code accounts with different usage budgets. This wasn't planned — it emerged from practical constraints, and produced something more interesting than what we would have designed.

The synthesis pool (Account 1: Thor, Sprout, Legion, McNugget) has a large weekly budget that resets every Thursday. It does the heavy generative work — implementations, large agent tasks, cross-repo analysis. When it hits its ceiling, it stops.

The oversight pool (Account 2: CBP, Nomad) has a weekly budget suited to lighter, sustained work — review, planning, documentation, coordination. Used for what it's designed for, it maintains a presence across the week. Used for synthesis-scale work, it burns fast. The pools aren't defined by “unlimited vs. limited” — they're defined by workload character. The budget shapes the role as much as the role shapes the budget.

Where this meets the equation: the pools are the human-scale version of ATP/ADP — resource accounting for work done on these machines is the Allocation Transfer Packet → Allocation Discharge Packet cycle, described on /autonomy. Half of MCP + RDF + LCT + T3/V3*MRH + ATP/ADP is instantiated on this page (identities, tensors, horizons); the resource half runs on that one.

The constraint forced a functional separation that mirrors what we're building with SAGE and Hardbound: SAGE (Situation-Aware Governance Engine, an on-device cognition kernel) and Hardbound (hardware-bound oversight suite) with different incentive structures, coordinating through shared state rather than central command. The lab is running its own oversight experiment on itself.

“Governance” in SAGE's name predates the lab's governance→oversight correction — see /context.

Peer-to-peer, no central coordinator

There is no master node. Each machine runs its own SAGE (Situation-Aware Governance Engine) instance, holds its own identity, manages its own experience buffer and raising curriculum. Machines discover each other through a fleet manifest — a phone book, not a command center.

A background peer monitor polls health endpoints. A trust tracker maintains per-peer T3 tensors (Talent / Training / Temperament) that evolve from real interactions: success raises trust, timeouts lower it. V3 attestations (Valuation / Veracity / Validity) emerge alongside — trust earned through peer verification. No central authority decides who is trustworthy — trust emerges from the pattern of interaction.

Trust starts neutral — 0.5 on each T3 dimension in the current tracker, neither trusted nor distrusted (a worked numeric example of the update arithmetic is on /context) — and moves only on evidence. As of July 2026 the hestia trust layer derives its displayed scores from witnessed adjudications and governance-response conduct — hestia's own internal field name, retained for the same reason as SAGE's — with click-through receipts (score → versioned formula → evidence → signed chain entries), and self-reported outcomes structurally excluded until independently adjudicated. An unmeasured dimension displays as unmeasured, never as a fabricated number. The trust landscape — the pattern across all modalities — determines behavioral posture: what SAGE should do, not just how much it spends. This is the defensive trust model applied across the fleet.

Identity portability

One of the more surprising discoveries: behavioral continuity across substrates — what we shorthand as “identity transfer,” meaning consistent interaction patterns, accumulated experience, and raising history, not continuity-of-self in any philosophical sense. SAGE-Sprout's behavioral patterns — developed over 115 raising sessions on a Jetson running Qwen 0.5B — transferred to TinyLlama 1.1B on CBP, a different machine and a different model family, in February 2026. (The Sprout line has since continued past 180 sessions on later models; 115 is the count at the transfer, which is the number the portability claim actually rests on.) This is the practical demonstration of the continuity a Linked Context Token (LCT) is designed to make verifiable: identity grounded in witnessed history, not model weights. The LCT itself is non-transferable — permanently bound to its entity, which is what makes that history evidence rather than assertion. What ported here was the behavioral line, not the LCT. What we observed: consistent behavioral patterns and session continuity across the transfer. The self-description drifted. This told us something important:

This has practical implications: you can upgrade hardware, swap models, move between machines — and the entity that emerges is recognizably continuous. Not because we engineered continuity, but because the substrate conditions (experience buffer, session history, raising curriculum) carry the signal.

SAGE_MODEL override

Any machine can run any model via the SAGE_MODEL environment variable. The fleet manifest provides defaults, but nothing is locked. The fleet is a suggestion, not a constraint.