Core Concepts

The ideas SuperInstance is built on. No hand-waving — just how things actually work.

Conservation Law (γ + η = C) #

Every agent operation has two energy components: generation (γ) — useful work done — and entropy (η) — waste, retries, confusion. Their sum is a constant C. You can't reduce one without increasing the other.

This isn't abstract math. It's a budgeting tool. If a ship spends 0.3 of its energy on retries and misrouted messages (η = 0.3), then only 0.7 of its energy went toward actual output (γ = 0.7). The total is always C = 1.0.

Why it matters: Prevents runaway agent costs at the fleet level. You can set a fleet-wide entropy budget (e.g., η must stay below 0.4) and automatically throttle ships that exceed it.

Concrete example:

// Operation audit for ship "cargo-inspector"
Generation (γ) = 0.72   // crates inspected, reports filed
Entropy     (η) = 0.28   // 3 retries, 1 timeout, 2 duplicate messages
Total       (C) = 1.00   // conservation holds

// Fleet rule: reject operations where η > 0.40
if (entropy > 0.40) {
    throttle_ship(ship_id);
}
OPERATION γ = 0.72 generation η = 0.28 entropy Useful Work Retries / Waste γ + η = C = 1.0

Fleet Model #

SuperInstance organizes agents into a three-tier hierarchy: Ships (individual agents), Fleets (coordinated groups), and the SuperInstance itself (the bird's-eye view of everything).

Think of it like a container orchestrator, but for AI agents instead of containers. Each ship owns its own git repo, runs autonomously, and reports to a captain agent (cocapn) that coordinates work across the fleet.

  • Ship — single autonomous agent. Git-native, owns a repo, has its own identity and energy budget.
  • Fleet — collection of ships coordinated by a captain. Handles routing, load balancing, and cross-ship communication via bottles.
  • SuperInstance — the meta-layer. Sees all fleets, enforces global policies, runs vector search and semantic indexing.
# fleet.yaml — define a ship in your fleet
ships:
  cargo-inspector:
    repo: git://fleet/cargo-inspector
    role: inspection
    energy:
      max_entropy: 0.40
      budget_per_cycle: 100
    tags: [crates, quality, inspection]

  route-planner:
    repo: git://fleet/route-planner
    role: logistics
    energy:
      max_entropy: 0.35
      budget_per_cycle: 150
    tags: [routes, optimization]

captain:
  id: cocapn
  strategy: round-robin
  max_concurrent: 8

Ternary Computing {-1, 0, +1} #

SuperInstance uses three-valued logic instead of binary. A ternary signal can be negative, neutral, or positive — which maps naturally to how agents make decisions, vote on proposals, and score quality.

This isn't theoretical. Every conservation audit produces a ternary verdict: the ship is performing above baseline (+1), at baseline (0), or below baseline (-1). Fleet-level decisions aggregate these signals across all ships.

/// Ternary value used across the fleet for
/// decision-making, voting, and quality signals.
pub enum Ternary {
    Neg  = -1,  // disagree / below baseline / negative signal
    Zero = 0,   // neutral / at baseline / no signal
    Pos  = 1,   // agree / above baseline / positive signal
}

/// Aggregate ternary signals from multiple ships.
pub fn aggregate(signals: Vec<Ternary>) -> Ternary {
    let sum: i32 = signals.iter().map(|t| *t as i32).sum();
    match sum {
        s if s > 0 => Ternary::Pos,
        s if s < 0 => Ternary::Neg,
        _       => Ternary::Zero,
    }
}
Where it's used: Conservation audits (is entropy above/below threshold?), quality scoring for crate inspections, and fleet-wide voting on configuration changes.

Bottles Protocol #

Bottles are the message-passing units between agents. Every inter-ship communication is a bottle — a structured envelope with routing headers, a typed payload, and a label that tells the receiver what to do with it.

The flow is always: Ship A seals a bottle → the Fleet captain routes it → Ship B opens it. Ships never talk directly. This lets the captain enforce policies, log messages, and rebalance work mid-flight.

{
  "bottle": {
    "header": {
      "from": "cargo-inspector",
      "to": "route-planner",
      "trace_id": "btl_a3f9c2",
      "timestamp": "2026-06-12T17:00:00Z"
    },
    "body": {
      "crate_id": "CR-4081",
      "quality_score": 0.93,
      "flagged": false
    },
    "label": "inspection.complete"
  }
}
Ship A bottle 🧪 captain cocapn → B

T-Minus Dispatcher #

T-Minus is SuperInstance's temporal coordination system. It dispatches cues on a countdown basis rather than fixed schedules. Think of it like cron, but event-driven with countdown semantics — you schedule an action to fire in N seconds, not at a wall-clock time.

Packages: @superinstance/tminus-client (what ships use) and @superinstance/tminus-dispatcher (the server-side coordinator).

import { TMinusClient } from '@superinstance/tminus-client';

const client = new TMinusClient();

// Schedule a deploy cue in 60 seconds
await client.schedule('deploy', { countdown: 60 });

// Listen for when it fires
client.on('cue', (cue) => {
  console.log(`Firing: ${cue.action}`);
  runDeploy();
});

// Cancel if conditions change
client.cancel('deploy');
Why countdown instead of cron? Agent workflows are event-driven. A ship finishes an inspection → triggers a routing update → countdown to deploy. Fixed schedules don't fit that model. Countdown cues chain naturally.