agentleFS
Starlight-IntelligenceStarlight-Intelligence/starlight-agent-skills/skills/substrate/swarm-queen-coordination/SKILL.md

swarm-queen-coordination

Skill1 starsChanged 4 months agoMITView on GitHub

How a stream queen coordinates a worker swarm and runs the escalation contract that keeps money safe — queens run streams, the founder owns capital, humans hold the final gate. Use when designing or operating a multi-agent income swarm, deciding what an agent may do autonomously vs. what it must escalate, or wiring the queen/worker/founder roles. Portable and brand-neutral. Trigger phrases: coordinate the swarm, stream queen, worker swarm, escalation contract, what can the agent decide, queen and workers, founder agent, agent autonomy limits.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

Files
SKILL.md

swarm-queen-coordination

The skill that turns a pile of agents into a governed income swarm. Three tiers — founder · queens · workers — and one load-bearing escalation contract that guarantees the same thing at every level: no autonomous money movement, ever.

This is the substrate-level, brand-neutral version. Wire it to whatever orchestrator, worker harness, and shared memory your operator owns.

Topology: queen-led per stream, mesh within a stream

                         ┌──────────────────────────┐
                         │      FOUNDER AGENT       │
                         │  sets thesis · approves  │
                         │  capital · owns          │
                         │  irreversible · resolves │
                         │  conflicts between queens │
                         └────────────┬─────────────┘
                                      │ escalation contract
            ┌──────────────┬──────────┴──────┬──────────────┐
            ▼              ▼                 ▼              ▼
       ┌─────────┐   ┌──────────┐     ┌──────────┐   ┌──────────┐
       │ STREAM  │   │  STREAM  │     │  STREAM  │   │ PAYMENTS │
       │ QUEEN A │   │  QUEEN B │     │  QUEEN C │   │  QUEEN   │
       └────┬────┘   └────┬─────┘     └────┬─────┘   └────┬─────┘
            │ mesh        │                │              │
       ┌────┴────┐   ┌────┴────┐      ┌────┴────┐   ┌─────┴────┐
       │ workers │   │ workers │      │ workers │   │ workers  │
       └─────────┘   └─────────┘      └─────────┘   └──────────┘

Each queen runs a hierarchical swarm of workers; workers collaborate peer-to-peer inside their stream (mesh). Queens do not command across streams — they coordinate only through the founder.

Tier 1 — The founder agent

Owns:

  • The thesis — which streams exist, what the gate ladder is.
  • All capital allocation and any irreversible action (new payment rail, vendor contract, spend above cap, structural change).
  • Conflict resolution between queens.

Never does the per-stream work. The founder sets direction and holds the gate; queens execute.

Tier 2 — Stream queens

Each queen is scoped to one income stream, runs a self-improving loop on a cadence, and escalates per the contract. A queen may act autonomously within its scope and below its caps. It must escalate the moment an action crosses a stream boundary, exceeds a cap, or becomes irreversible.

Typical queens: one per income stream (e.g. affiliate, products, content) plus a payments queen that owns authorization + settlement gating (see payments-mandate).

Tier 3 — Workers

A worker does exactly one job, reports progress through shared memory, and never moves money or publishes without its queen's gate. Workers are stateless between tasks — all state lives in the shared vault. Workers never call payment tools directly; they report a finding, the queen runs the tool.

The escalation contract (the safety spine)

No autonomous money movement. Ever.

Action classWho decidesGate required
Worker task within stream (draft, audit, research)Worker → QueenQueen review
Bind a link, schedule a post, build a pageQueenbrand / claims gate
Any payment / settlementPayments Queenmandate verified + spend-cap check + audit entry (verify-only tools, fail-closed) + human gate
Spend above cap, new rail, new vendorFounderpressure-test + human approval
Irreversible (delete, rename live URL, rotate key, send blast, move funds)Founderhuman approval, always

The standing rule: agents draft, gate, and commit; humans deploy, post, send, and approve capital. Money and irreversibility are never delegated to autonomy.

The escalation path

worker  ──finding──►  queen  ──within scope & cap? act : escalate──►  founder  ──capital/irreversible?──►  human

Each hop is a narrowing of authority. A worker cannot reach the founder directly — it goes through its queen. A queen cannot move capital — it goes through the founder. The founder cannot do the irreversible thing alone — it goes through the human. Skipping a hop is the failure this contract prevents.

How to configure each role

Founder : orchestrator seat + governance/board gate + thesis + full tool stack
          (shared vault rw · payments verify-only · approvals channel)
Queen   : coordinator scoped to one stream + that stream's skills
          (e.g. affiliate → agentic-income + affiliate-audit; payments → payments-mandate)
          + shared vault (rw within stream) + payments tools (verify-only) + escalation channel
Worker  : worker harness + one skill + shared vault (append-only) — no payment tools

Compose

  • payments-mandate — the money gate the payments queen runs; the rest of the contract routes every settlement here.
  • agentic-income — the operating brain a non-payment stream queen runs as its self-improving loop.
  • affiliate-audit — the weekly loop engine for an affiliate stream queen.

How SIS consumes this

The Starlight Intelligence System maps the founder seat to its orchestrator (pressure-tested by its governance board), the queens to per-stream coordinators, and the workers to its worker harness. The escalation contract is enforced by the system's safety layer; outputs are SIP-attested and the no-autonomous-money-movement + human-gate invariants are non-waivable.


Built on SIP — Starlight Intelligence Protocol Substrate: starlightintelligence.org/protocol v1.1.0 Layers used: [file-contract, attestation, sovereignty] Vertical: starlight-agent-skills · portable capability layer

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.