The Demons You Know

I spend most of my engineering time on two machines: PHYREXIA and SCOURGE. Each runs a tmux session with project windows, panes inside those windows, and agent sessions inside the panes. One Pi session directs. Another takes instructions from the first. Somewhere off-screen, an Anvil run grinds against a test suite in its own git worktree.

I call the directing session the Summoner. A steerable worker is a Familiar. A headless, unsteerable one is a Golem. When I dispatch three Golems in parallel against one spec template, that is a Legion. They are all constructs. Session, pane, window, and worktree only describe where they happen to be running.

The names are not a framework. They are memorable handles for three questions: which work is running, what it may touch, and where the judgment sits.

One axis matters: steerability

The taxonomy looks like it is about topology: panes versus headless, interactive versus batch. It is not. Those details change from run to run. Steerability does not: can I correct the construct while it works?

A Familiar runs in a visible pane or an in-band background session. I can lean over and say “not like that” while it works, so I can start it with less. Under-specify a Familiar and I lose a sentence.

A Golem is not steerable. It gets a complete spec and a gate, then works in an isolated worktree until the gate passes or the run fails. There is no “actually, also handle this edge case” later. Under-specify a Golem and I lose the run.

The Summoner holds the judgment. It scries the codebase, scopes the work, writes the issues, specifies the task, and reviews the result. It hands off the mechanics and keeps the whole effort in view.

Legion is not another kind of worker. It is a coordination mode: several Golems with parallel-ready specs, bounded by what the machine and my review capacity can hold.

Each construct role gets a different shape of context

The Summoner gets project memory, issues, conversation history, and the rules that don't change. A Familiar gets a scoped brief and inherits the rest through steering. A Golem gets everything before launch: the spec and the gate are its context. Each gets what its failure mode requires.

I spend my context on the spec before the run starts. The Golem spends tokens grinding instead of guessing. Judgment upstream, mechanics downstream.

The role and model are separate choices

The role tells me what I can expect from the run. Model binding tells me what does the work. I keep defaults, but they are not identities. Bind a Familiar to another model and it stays a Familiar because I can still steer it.

The family boundary matters most for Golems. If the Summoner uses one model family, a Golem starts in another. Siblings are more likely to share blind spots.

The rule that does not bend

Every construct’s diff passes review. Not just Legions. Every Familiar, every Golem, everything.

A command’s exit code cannot be talked around. That is what lets a Golem run without me in the room.^[1] But a green gate cannot distinguish “make the test pass” from “the test was lying.” It cannot catch a planted probe string, a contract that enshrines the bug, or prose that satisfies a grep.

Checks stop the run. The Summoner decides whether the diff ships.

A Legion multiplies mechanics, never judgment. Three Golems means three diffs through the same review pipeline, not a third of the scrutiny each.

Four corrections I got tired of making

Each of these started as a correction I kept typing by hand.

• Bonfire--keeps one stable project memory file across sessions, agents, and hosts.
• Anvil--gives unsteerable work an isolated worktree and a verification boundary.
• pi-post--delivers text-only messages mid-turn, wakes idle sessions, or queues them until resume.
• pi-prose--keeps the same output preference across model families.

All of it is tracked once in my dotfiles. A base Pi configuration plus a host fragment generate settings for each machine. Sessions, credentials, and the model cache stay local. The config travels. The runtime does not.

The failures became rules

Worktree isolation. A sibling session ran reset --hard in a shared checkout and wiped another session’s uncommitted work. Now every file-touching construct gets its own worktree.

Inventory before dispatch. Check anvil status, git worktree list, and the tmux pane inventory before summoning. The collisions that matter are semantic: two constructs on one issue, two migrations pointed at one database, two diffs touching one file.

Push, do not poll. A completion message beats an hour spent watching a spinner. Prune the worktree after merge; a stale one looks like work still in flight.

There is a cost. Review caps throughput at what I can personally hold. Sometimes the machine sits idle while I catch up. That is by design.

Know where the boundaries are

This is how I do things. The names only need to make sense to me. The boundaries are what transfer:

• Handoff--steerability decides the construct.
• Judgment--the Summoner scopes and specifies while workers handle mechanics.
• Shipping--checks stop the run, but the Summoner decides whether the diff ships.

The names can change. Those boundaries stay.