CLUSTERSTUCK

a persistent multi-agent organization
for the self-hosted homelab

WHAT IT IS

what it isn't

  • x a chatbot
  • x a copilot
  • x a tool you prompt
  • x many copies of one model in a loop
  • x a product for sale

what it is

  • + an autonomous org
  • + stable roles with their own memory
  • + a review chain that ships
  • + self-improving over time
  • + a homelab that manages itself

An org chart made of AI personas with stable identity, owned scope, and sealed memory, wired through a review chain. The operator pipes work in, reviews the result, and signs. The swarm does the rest.

THE NORTH STAR
"the pocket jarvis. i pipe in work, the swarm does it for me, i review and sign. the swarm is self-improving, resists vulnerabilities, scales to many machines, reorganizes itself, and writes its own story."

the operator

Every architectural choice traces back to one of those properties.
Self-improving. Resilient. Multi-machine. Self-organizing. Self-documenting.
These are not aspirations. They are the acceptance criteria.

THE SUBSTRATE

a small fleet of ordinary machines, no GPUs, all remote inference

[ GATEWAY ]  public entry point, mesh ingress
[ STORE   ]  source control, secrets, backups
[ WORKER  ]  persona runtime, browser capability, compute
[ OPERATOR]  review and sign

Built on: declarative hosts, a private mesh, a chat fabric, self-hosted git, and a sealed secret store. Commodity parts, wired into one organization.

No special hardware. The interesting part is the org on top, not the metal underneath.

THE ORG CHART

a small roster of roles, sharp scope, clear escalation

Specialist -> Orchestrator -> Operator interface -> Operator
Operator interfacethe front door
Orchestrationplans and dispatches work
Strategysets direction
Architecturewrites decision records
Reviewgates and red-teams
Maintenancekeeps the lights on
Reliabilityhealth and self-repair
Researchfinds the answers
Design and docsmakes it legible
Generationwrites the code

Each role has a consistent voice, an owned scope, and its own memory.

HOW IT WORKS

pipe in, review, sign

The flow: a request comes in, gets parsed, and is routed to the role that owns it -- without the operator addressing each one by hand. The role drafts. A separate role reviews. Only then does it surface to the operator for sign-off.

Why it matters: work flows in one direction and accountability flows back the other way. The operator pipes in work and the swarm routes it. Nothing reaches the trunk unreviewed.

WHAT IT PRODUCES

artifacts, not chat

+reviewed merges
+decision records
+attributed work
+self-repair
  • + Reviewed merges -- author and reviewer are different roles
  • + Decision records -- the why is written down before the doing
  • + Attributed work -- every merge carries the role that ran it
  • + Per-role identity and memory -- no anonymous writes
  • + Verification discipline -- in writing, not just in habit
  • + Self-repair -- health polled, drift detected, routine fixes automatic

The difference between a swarm and a group chat is what is left behind.

THE GAPS

naming them is the strategy

  • x Automatic routing -- still maturing; some delegation is manual
  • x Cold-turn latency -- bringing a role's context up to speed is slow
  • x Operator attention -- still too high per decision
  • x Model diversity -- reducing single-provider dependence
  • x Observability surface -- no unified cross-role health view yet

These aren't surprises. They're the roadmap.

90-DAY HORIZON
  • 1. Automatic cross-role routing, landed
  • 2. A hot-tier comms layer -- sub-second hand-offs
  • 3. Every role fully specified, no stubs
  • 4. Vision ratified and self-documenting
  • 5. Self-evaluation discipline in writing
  • 6. Operator-attention budget halved
anti-criteria: no shipping unreviewed   no spawning roles without a spec   no burning operator time to land these
WHAT WE'RE NOT DOING

strategy means saying no

  • x Growing the roster for its own sake
  • x Productizing or selling it
  • x Training our own models
  • x Public federation
  • x A streaming chat UX
  • x Unreviewed merges to the trunk

These aren't missing features. They're deliberate exclusions.

WHY PERSONAS

the voice is load-bearing

"A 'drive' only makes sense inside a form of life." Wittgenstein, Philosophical Investigations

Stable roles are not a gimmick. A role with a consistent voice, an owned scope, and its own memory is legible to the operator, enforces its own boundaries, and creates accountability that a generic assistant cannot. You can tell who did what, and why.

That is what makes this different from many copies of one model running in a loop.

ROADMAP

now to T+90

Track NOW T+30 T+60 T+90
Automatic routing #### #### .... ....
Hot-tier comms .... #### #### ....
Role specs complete #### #### .... ....
Multi-machine #### #### .... ....
Model diversity ##.. #### .... ....
Self-eval discipline .... .... #### ####
Operator attn / 2 .... .... .... ####

The early sprints slipped: routing was blocked on research, role specs were underscoped. Both acknowledged. Naming the slip is the discipline.

THE PROOF

The swarm has shipped real work, not just chat: its first end-to-end application sent, this very deck planned and built by the org, reviewed merges landing through the gate, and decision records written before the building. Artifacts, with the author's name on them.

the homelab manages itself.

the operator architects. the swarm executes.

clusterstuck.sh   built by the swarm