Organizations teams and swarms

Organizations, teams & swarms

GenOS is not limited to running one agent across several branches. It also models how multiple agents divide a problem, exchange signals, vote, specialize, and pass evidence between one another.

Three distinct layers

Layer	Purpose	Maturity
Benchmark fleet	Assign specialists to tasks by capability, budget, and priority	Operational in benchmark scripts
Studio Fleet & Swarm	Observe agents, roles, parents, worlds, strategy contracts, proposals, and quorum	Implemented UI and services
Biomimetic organizations	Explore stigmergy, consensus, flocking, quorum, and distributed networks	Local research models

This distinction prevents a coordination simulation from being presented as a production distributed orchestrator.

Organization as a coordination policy

The core defines fifteen strategies: stigmergy, democratic consensus, emergent architecture, polyethism, Boids, fish-school search, slime mould, Grey Wolf Optimizer, mycorrhizal routing, dynamic differentiation, quorum sensing, leader election, distributed tentacles, huddle rotation, and coupled oscillators.

The biological vocabulary is not the claim. Each strategy represents a different answer to four engineering questions:

1. Who selects the next action?
2. What information is shared, and at what cost?
3. How does the group avoid premature convergence?
4. How does a collective decision remain attributable to evidence?

These fifteen Rust organization modes are separate from the backend orchestrator's complete 77-strategy registry. The latter combines execution, diagnosis, exploration, replay, collective, memory, and resilience policies into a versioned contract for each agent.

Fleet: assign the right agent to the right benchmark

The benchmark fleet reads a portfolio and backlog, scores specialists against required capabilities, assigns the top two candidates, applies budgets, and emits a plan and trace. Runs can be synchronized with Studio:

./benchmarks/run-fleet.sh --studio

This turns a directory of scripts into a governed campaign: priorities, owners, expected artifacts, and final decisions are versioned.

Studio: inspect the collective

The Fleet view filters agents by fleet, type, role, parent, or world and exposes strategy contracts and activity. Swarm Control Center shows active nodes, messages, proposals, and yes/no votes. Quorum weights can incorporate the fleet's historical Brier calibration.

Model policies can also be scoped to an organization and project. The organization therefore controls both collaboration topology and permitted inference resources.

Agent Trinity: three real parallel runtimes

Trinity Mode takes one mission and deploys three backend agents in a shared mission fleet:

World	Role	Interpretation of the mission
1 — Basic	Basic Implementation	Implement the raw need directly
2 — Planned	Planned Implementation	Implement according to the interview plan
3 — AI-Corrected	AI-Corrected Implementation	Implement with an explicit self-correction framing

POST /api/deploy/trinity persists the three agents and their trinity_worlds, creates a separate 77-strategy contract for each interpretation, emits TRINITY_WORLD_SPAWNED telemetry, and starts each mission asynchronously through the runtime adapter. Studio's Trinity view deploys the mission and polls GET /api/deploy/trinity for runtime-owned status.

one mission
   ├─ World 1: direct interpretation ─ strategy contract ─ runtime
   ├─ World 2: planned interpretation ─ strategy contract ─ runtime
   └─ World 3: self-correcting interpretation ─ strategy contract ─ runtime
                                    ↓
                        Fleet / Swarm telemetry

The current deployment flow proves creation, persistence, runtime dispatch, and observation of three agents. It does not by itself implement automatic cross-world adjudication, replay of a winner, or workspace merge; those require the wider evaluation and promotion workflow.

See the Trinity backend and Studio view.

Dynamic A-Team contract

genos_a_team_preview describes a team derived from a complex objective: the project is divided into subsystems, specialist roles are assigned, and a mandatory telemetry_observer follows the orchestration. The contract also asks the team to enforce declared GenOS invariants.

At present, the repository contains the JSON tool schema and documentation, but no execution handler for genos_a_team_preview in the maintained MCP server. It is therefore a preview and planning contract, not proof that a complete autonomous team is provisioned on distributed production infrastructure.

See the A-Team schema.

Biomimetic research surface

The Rust modules provide concrete primitives for studying:

• shared blackboards and pheromones for stigmergy;
• forager, builder, and nurse roles;
• autonomous arms exchanging compact file pointers;
• energy rotation inspired by penguin huddles;
• mycorrhizal resource networks and specialized castes;
• synchronization, quorum, and collective exploration.

These simulations compare organization policies under constraints. They do not yet establish network-partition tolerance, distributed transactions, or production swarm self-healing.

The GenOS method applied to teams

objective
  ├─ team A: centralized strategy
  ├─ team B: specialist quorum
  └─ team C: stigmergic exploration
          ↓
traces + costs + outcomes + disagreements
          ↓
shared evaluation → replay → promotion

The collective structure becomes an experimental variable, alongside the model and genome. See the organization source, benchmark fleet, and Local AI & model routing.