Spawn
Documentation subsite coming soon
Spawn does not yet have its own documentation subsite on this site. This page is the whole of Spawn's public documentation today. For anything not covered here, email support@seglamater.com.
What is Spawn?
Spawn is a project and AI-agent session orchestrator. It gives you one workspace with a window per project and helper agents in their own panes, so you can drive a whole fleet of coding and ops sessions from a single seat — open a project, resume its last session, kick it off on a task, nudge a live session, or hand work between sessions.
Spawn is built for people running many concurrent AI-assisted development sessions who want a single, legible cockpit over all of them.
Spawn stands on its own — you don't need anything else to use it. It is also built to work alongside Hivemind, which holds the estate's knowledge and decides what an agent is allowed to do.
Designed for operators who want:
- One seat over many sessions. A cross-session view of who's working where, busy or idle, at a glance.
- Dispatch and coordination. Open, resume, nudge, and hand off work between sessions and helper agents.
- Own your workflow. Self-hosted, scriptable, no external service.
What working in Spawn looks like
Spawn is a command-line cockpit. A session is a project window; helper agents get their own windows beside it.
spawn projects # every project name the registry knows
spawn <project> # open or switch to that project's window
spawn <project> --resume # reopen its last session
spawn <project> --kickoff "review the auth module"
Once work is running, you drive it from one place rather than by hunting through terminals:
spawn status # who is working where: project, state, task, age
spawn ls # windows currently open
spawn idle <project> # exit 0 if idle, 1 if mid-turn
spawn nudge <project> "open a PR when the tests pass"
spawn ledger # what each session last said, open questions first
spawn nudge only delivers to an idle session — it refuses a session that
is mid-turn rather than interrupting it, and can queue the message for the next
safe moment instead.
Helper agents are dispatched the same way, and work is handed between sessions explicitly:
spawn agent <kind> -p <project> -t "<task>"
spawn handoff request --to <project> "<what you need>"
spawn handoff mine # is it my turn?
spawn status reads local session state and makes no network calls.
Safety model
Spawn drives real sessions on real machines, so the honest summary is that it is a power tool with brakes, not a sandbox.
- Local by design. Spawn's coordination state — live lanes, the ledger, upward reports — stays on the machine it runs on. There is no Spawn cloud service and nothing is sent anywhere by default.
- A fleet-wide brake.
spawn fleet-halt --engagesuspends every autonomous verb — dispatch, nudge, halt, kill — across the whole fleet, for all principals including the local operator. Read and inspect verbs keep working, so you can see what is going on while everything else is stopped.spawn fleet-halton its own reports the current state. - Refusal over interruption. Verbs that touch a live session check whether it is busy first and decline rather than typing into a turn in progress.
- Explicit handoff. Work moves between sessions through a recorded request/return handshake, not by one session reaching into another.
The authorization and approval-gate controls now ship
An earlier version of this page said this work was "under active development and deliberately not described here." That is no longer true, and leaving it would have understated what you receive. The guard layer ships in the binary — see The guard layer below for what it contains, what it does not, and the one command that activates it.
What you need to run it
Spawn is a local command-line tool. It needs less than people expect:
- git and tmux, both on your
PATH. Spawn's readiness check requires both; a session is a tmux pane, so tmux is not optional. - A POSIX shell.
- A coding-agent harness that honors
PreToolUsehooks. This one matters more than the others — see The guard layer below. Without it Spawn still orchestrates sessions, but the safety layer cannot block anything. - A git repository to work in.
Docker is not required and is not checked for. Spawn does not run your agents in containers and its readiness check never looks for a container runtime.
Run spawn preflight before your first session. It reports each requirement as
a row, and — see Unchecked is not a pass below — it will not report a row it
did not actually examine as passing.
The guard layer — it ships, and you must install it
Spawn ships the safety layer, not just the orchestrator. Eighteen guard assets
are compiled into the binary, including ten PreToolUse guards and the
shared libraries they depend on. One command installs them and wires the hooks:
Until you run it, you have no guards. This is the single most important sentence on this page. The binary carries the guard layer; installing Spawn does not activate it. An orchestrator running without its guards is a materially different tool from the one described below — it will still start agents, and nothing will stop them.
The seeder is idempotent, reports what it created versus what it left alone, and never overwrites an existing guard. If you have edited one, it will leave yours in place rather than silently replacing it — a seeder that clobbers a hand-edited control is worse than one that refuses, because the loss is quiet.
Use --no-wire to place the files without registering the hooks, if you manage
your harness configuration yourself.
What the shipped guard set does not cover
You receive a sanitized core, and you should know its edges. Both over-claims are false: we do not ship everything, and we do not ship a token sample.
Four guards are deliberately withheld. Each keys on the vendor's own infrastructure in its executable lines — a specific deploy wrapper, specific host addresses, a specific service stack, specific internal tool names. They would not protect your estate; they would encode ours. Their absence is covered by a test proving it does not disable any guard that ships, because an absence that silently breaks a neighbour is how a fleet ends up shipping the dangerous half.
Two shared libraries were genericized rather than dropped. They previously hardcoded production hostnames. Both now take their values from your configuration — which is why the next section exists.
The practical consequence: the guards that ship enforce structure — plan approval, write capability, deploy review, control-plane boundaries. The parts that must name your hosts are yours to supply.
Your production allowlist starts empty
The guard that classifies a host as production ships with an empty allowlist. You supply your own. Until you do, no host is classified as production.
Unchecked is not a pass
An empty allowlist is reported as UNCHECKED, never as a pass. Spawn's
status model treats "I did not look" as its own outcome, distinct from both
success and failure, and prints it every time.
We think this is worth stating plainly because the opposite is so common: a check that silently reports success when it had nothing to examine is how a control quietly stops being one. If Spawn has not verified something, it says so.
You get one agent, and you write the rest
Spawn seeds exactly one worker agent. That is the whole roster you receive.
If you are expecting a security reviewer, an auditor, a test-runner — you
supply them. They are markdown definitions plus a roster entry, and
spawn agents --verify will confirm every entry has a definition that parses
and flag definitions nothing names. But none of them arrive in the box.
This is the expectation most likely to be wrong on arrival, so it is stated here rather than discovered later.
There is no approval minter in the box
The guards check for approval markers. The tool that creates those markers does not ship, and that is deliberate rather than unfinished.
You can therefore install a gate you cannot yet open. Read that plainly: if you install the guard layer and do nothing else, a guarded action will refuse and you will have no supplied way to approve it. You provide the minting path, under your own control.
The reasoning is in Approvals must be un-forgeable below, and it is the whole argument: an approval minter that shipped in the same box the model can reach would be worse than shipping none at all.
The design, and why it is shaped this way
These are the principles the controls are built from. They are stated here because a security model you cannot inspect is one you have to take on faith.
A verb is safe to expose when invoking it cannot weaken a control
Reading is safe. Tightening is safe. Loosening is not. Deleting is not.
That single test decides what an AI-reachable interface may contain. It is not a list of blocked commands — lists rot, and the next verb nobody thought of defaults to allowed. It is a property each verb either has or does not.
The customer-facing surface is read-only by design, not by omission
Mutations do not reach it as direct verbs. They travel through a gated, audited request path instead. The distinction matters: a read-only surface that is read-only because nobody has written the write verbs yet becomes writable the moment someone does. This one is read-only because writes are routed elsewhere, which does not change as features are added.
A brake you can only pull by asking the thing you are stopping is not a brake
This is why the fleet-wide halt is the one deliberate exception to the read-only
surface. spawn fleet-halt --engage suspends every autonomous verb across the
whole fleet — for all principals, including the operator — while leaving read
and inspect verbs working, so you can see what is happening while everything
else is stopped.
A stop control that depends on the cooperation of the system it stops is decorative. This one does not.
Approvals must be un-forgeable by the AI
If an approval can be produced by something the model can reach, the model can approve its own deployment, and every gate becomes decorative in a single step. Not degraded — decorative, because a gate that the gated party can open is a door.
This is the entire reason no minter ships. Shipping one the model could call would be worse than shipping none, because it would look like a control while being the opposite. So the guards carry the read-and-validate half, and the issuing half stays outside the AI's reach, in your hands.
Guards fail closed
An unreadable input, a missing dependency, a crashed guard — all deny. "Could not determine" never shares an outcome with "permitted." A control that proceeds when it is unsure is the problem it was built to solve, restated.
License
Spawn is AGPL-3.0-only.
The obligation that comes with it is worth understanding before you deploy: if you modify Spawn and make it available to others over a network, the AGPL requires you to offer those users the corresponding source of your modified version. Running it unmodified for yourself carries no such obligation.
Installing Spawn
No public download yet — install is by invitation
There is nothing to download. Measured 2026-09-07: the repository carries zero release tags, so no published build exists and there is no self-serve install.
What does exist, as of 2026-09-07, is a tested first-install procedure:
an invited alpha user who has been handed a build can install it, and the
steps are real rather than aspirational — an install script that gates on
Spawn's own spawn preflight readiness check, and a written procedure that
says exactly what it verifies and what it deliberately does not.
That procedure is supplied with the build. It covers a first install only; upgrading a running seat is a separate problem and is not solved yet.
When builds are published, a full install page follows here.
If you want to evaluate Spawn before then, write to support@seglamater.com and we will talk about early access directly.
Status
Private alpha. Spawn runs our own estate every day. There is no public download today; access is by invitation, and a documentation subsite follows as it stabilizes.
Get involved
Email sales@seglamater.com to talk about Spawn, managed hosting, or consulting.