The math that makes the difference between fleets that drift and fleets that hold
Ask a fleet of agents "is everything okay?" and you get a poll — a heartbeat, a status flag, a hope that consensus arrives before it matters. Ask a truss "are you rigid?" and you get a fact, checkable before anything moves or fails. Multi-agent coordination has been living with the poll. This page is about the fact.
The failure the poll misses isn't exotic — it's floating-point "close enough," compounding quietly, hop after hop, until a fleet is confidently wrong. Constraint theory replaces the poll with the truss question: is the trust graph rigid? That reframe — coordination as geometry, not consensus — is what the rest of this page makes concrete: a 48-direction encoding with zero drift, a Betti number you can read like a gauge, sixty million test vectors that never disagree with the proof.
A boat navigating a rock passage using standard floating-point GPS makes micro-adjustments every few seconds. It overcorrects. It overshoots. It burns fuel fighting itself. After a hundred corrections the heading is garbage — and the system reports everything is fine because each individual correction was "close enough."
Text diagram — boat in a rock passage:
Floating point says "close enough." Constraint theory says "here."
Those are two different ways of knowing where you are. One drifts every time you use it. The other cannot drift — not because it's careful, but because addition in a closed group has nowhere to leak error to. That's not a tuning improvement. It's a different kind of arithmetic.
Here's the code that makes the difference visible:
// Floating point: accumulates error
let trust = 0.1;
for _ in 0..100 { trust += 0.1; }
// Result: 10.0000004 or -9.9999996 depending on rounding
// The boat is now in the wrong rock field// Constraint boundary: zero drift after any number of hops
let trust = Direction::from_u8(6); // 48-direction integer encoding
for _ in 0..100 { trust = trust.compose(Direction::from_u8(6)); }
// Result: exactly Direction::from_u8(6), always
// The boat is exactly where it started, every timeThe 48-direction encoding used here (Pythagorean48) gives 5.585 bits per trust vector — deterministic, no rounding, no matter how many times you compose it.
On a boat, "close enough" means you're drifting toward the rocks. "Here" means you're not.
These four numbers are a snapshot from the fleet's own PLATO room server, which runs on a private machine — not something your browser can reach directly, so this page can't poll it live without a public API in front of it (that doesn't exist yet). Rather than fake a live connection, here's the last real reading, dated honestly.
Vessels — Each vessel is a named agent with a fixed role. The count tells you whether the fleet is intact. If it drops, a vertex vanished from the constraint graph.
Rooms — Rooms are the fleet's working memory. Each room holds a different type of constraint: vessel identities, trust vectors, ambient briefing state. The room count shows how much the fleet has written down.
Agents — Agents are live processes that read rooms, do work, and write results. Unlike vessels (which are roles), agents can come and go. The fleet survives agent churn because the constraint graph is in the rooms, not in any single agent.
Tiles — Tiles are compressed knowledge. The fleet distills what it learns into fixed-size constraint tiles. When one agent proves something, every agent can read the tile and use it — no retraining, no fine-tuning, no hallucinated constraints.
Every decision the fleet makes runs through three phases. This is not a pipeline — it's a control loop with provable termination guarantees at each phase.
The deadband captain is the navigation layer. P0 maps the rocks, P1 finds safe water, P2 steers. The name comes from control theory: a deadband is the range where the system does nothing because it's already in the right place. When the fleet is rigid and safe, the captain sleeps. When it isn't, it acts precisely.
Copy the prompt, paste it into DeepSeek, Groq, or any OpenAI-compatible chat. Each one gives you something concrete to work with, whether or not you use anything from this fleet.
Ask any chatbot to turn a real-world problem into a working constraint. Works in any chat that can do structured reasoning.
Pick something in your life with at least two ways to go wrong — a workflow,
a system, a number you keep managing wrong. Write three sentences about
what "too high" and "too low" look like for it. Then write one GUARD
statement in the style of: GUARD (x > max AND x < min) IMPLIES alert.
I'll turn your bounds into a working constraint.Ask any chatbot to check if a group coordination problem is provably self-organizing. Works in any chat.
Describe a group of things that need to coordinate — agents, services,
people, machines. For each one, describe what it does and what it needs
from the others. Then tell me the fewest rules that would make the whole
group self-organize without any of them needing to ask permission.
I'll map those rules into a rigid graph and tell you whether it's provably
self-coordinating.Ask any chatbot to model a recurring decision as P0/P1/P2. Shows why greedy always fails.
Give me a decision you keep facing — something with at least two ways
to go wrong. I'll model it as P0 (what NOT to do), P1 (where you CAN be),
P2 (the best path). Then I'll show you why greedy always fails and what
the deadband protocol does instead.Ask any chatbot to flip a search problem into a constraint problem. The rocks are the snap target.
Describe a problem you keep trying to solve by searching for the right
answer. Now describe it differently: "where are all the places this
definitely WON'T work?" I'll help you flip it. The rocks are the snap
target. Everything else is just having yourself a path of safe.Ask any chatbot to verify a coordination graph is minimally rigid. Goes one level deeper than "Model a fleet" — this is the actual rigidity check the fleet runs in P0.
I'll describe a network of things that must coordinate (agents, services,
people, machines). First, list the nodes and the pairwise links back to me.
Then verify the graph is MINIMALLY RIGID in the plane using the Laman
condition:
(1) the total number of edges E must equal exactly 2*V - 3,
where V is the number of nodes, AND
(2) no subset of k nodes may span more than 2*k - 3 edges
(check this for every subset size, not just the whole graph).
Walk through both checks explicitly. If it passes, the structure holds its
shape with zero slack — nothing flexes. If it fails, name the single
cheapest edge to add or remove to make it minimally rigid, and say which
of the two conditions you broke.Ask any chatbot to find the one relationship in a trust network that's lying. This is the math behind Zero-Holonomy Consensus — geometry, not voting.
I'll give you a directed graph where each edge carries a positive weight
(a trust score between two parties). Do two things:
1. Compute the cycle rank β₁ = E − V + C, where E = edges, V = vertices,
and C = number of connected components. That tells you how many
independent loops exist to test.
2. For every simple cycle, walk around it and multiply the edge weights —
use the reciprocal of a weight when you traverse an edge backward.
A network is cycle-consistent ONLY if every cycle multiplies to
exactly 1 (this is holonomy: the change accumulated around a closed
loop must be the identity).
If every cycle hits 1, the network is self-consistent and no edge is
tampered. If any cycle misses 1, at least one edge on it is lying. Find
the smallest set of edges common to ALL the failing cycles — that's your
culprit. Show the arithmetic for each cycle.Ask any chatbot to design a two-tier router that answers from a table and only calls the model on a genuine miss. The pattern that keeps fleet responses cheap, fast, and deterministic by default.
Design a request router with two tiers for a domain I'll name:
TIER 1 (reflex) — a table of {intent, canned answer}. For each incoming
request, classify the intent by exact keyword match or a cheap rule
(no model call). If it hits the table, return the canned answer as-is.
TIER 2 (fallback) — only when Tier 1 misses. Call the LLM, but BEFORE you
trust its output, require it to return three fields:
(a) the answer,
(b) a one-line reason,
(c) a confidence in [0,1].
If confidence < 0.6, return a safe default instead of the answer.
Give me back: the reflex table with 5 example intents for my domain, the
EXACT miss-rule that promotes a request from Tier 1 to Tier 2, the
confidence threshold, and the safe default. Then tell me, for a sample of
100 requests, roughly how many you'd expect to hit each tier.The constraint playground. Fleet topology visualization. Live at:
Where this math gets applied to a real design: cocapn.com — a vessel-control simulation that runs the constraint engine against actual navigation. Still under construction; you can watch it take shape.