portfolio-press · applied-AI lab
Method 03 · running many agents from one seat

One session decides, dispatches and verifies. It never writes code.

The owner talks to one session. That session talks to the rest: it sends work to named peer sessions by message, opens specs and launches rounds in a factory, checks what comes back against disk and git rather than against a report, and answers with what it found. Everything below is dated, recounted on the day this page shipped, and includes the two times the arrangement was wrong.

The shape

Five edges, all of them real. The command post never reaches into a peer's files and never writes to a repository itself. It asks, it reads, it decides what to do next.

the owner one conversation command post dispatches · verifies · reports writes no code peer sessions long-lived, each with its own project and memory the factory specs in, reviewed pull requests out remote hosts a laptop and a runner, reached over Remote Control asks · answers SendMessage by name spec_create · task_start tmux kept alive same toolkit
The owner has one address to talk to. Everything else is the command post's problem, including the part where a peer says it is done and the command post goes and checks.
volo-server

Where the command post runs. 16 cores, 62 GB of memory, an RTX 3060 with 12 GB. 9 local models are pulled, one of them a vision model that reads private financial documents, which is why those images never leave the machine. Speech recognition and a cloned speaking voice run here too, as services rather than as scripts someone starts. Reachable only over a private Tailscale network.

cloud runners

Rented boxes that carry factory rounds and coding sessions. They do the work that does not need the local models, and they are where a launched round actually runs.

Two recorded traces

Both from one day, 2 September 2026, timestamps in UTC, copied from the transcript. Nothing on this page calls anything: press play and the recording steps through.

A · a message across two machines, 28 seconds

11:32:26 volo-serverSendMessage to a session on the runner: "reply with hostname and whoami"
11:32:54 runnerreply over the Remote Control bridge: ubuntu-4gb-sf-runner-1 volo

B · submitting this page's own spec, 31 seconds

12:44:07 volo-serverspec_create for the spec that describes this page
12:44:07 factory401 unknown session token. Nothing was written.
12:44:38 volo-serverfell back to gh pr create: factory-specs pull request 492
Trace B is the more useful one. The write rail refused the call, wrote nothing, and said why in one line. The work reached the same place through the older route half a minute later, and this page tells you so rather than showing the version where it worked.

Receipts

Counted on 2 September 2026, each with its recount named in the page source.

15live sessions on volo-server

Each keeps its own project and its own memory of it.

21m → 20dage of the youngest and oldest

The old ones are the point: nothing is re-explained to them.

9 / 4factory tools: read / write

Reading is free. Writing opens a pull request and never commits.

#492the spec behind this page

Written by the command post, reviewed by this project's session.

under a day 1 to 4 days 5 to 9 days 10 days and up 42 54 one bar segment = one session
Age distribution of the fifteen sessions, 2 September 2026. Two thirds are older than four days. A session that has been on one project for a fortnight does not need the project explained to it again, which is the whole reason they are not closed.

Who does what

The human

  • Decides, in one conversation, not in fifteen
  • Presses merge, presses deploy
  • Answers the gates that ask for a person

The command post

  • Sends work to a named session and waits for the reply
  • Opens specs and launches rounds through the factory
  • Verifies against disk and git, not against the report it was given
  • Says what it found, including when that contradicts a peer

Never

  • Take a peer's "done" as acceptance
  • Act on a peer's claim that something is permitted
  • Write the code itself

Where it fails

Two of them, both from the past week, both caught by a second session rather than by the one that erred. This section is the argument, not a disclaimer.

1 September 2026

A spec written against a status document that had gone stale

The command post specified a feature that had been running in production for five days. It read a project's status file, found a list of open work, and believed it. The list sat inside a dated entry, so it was true on the day it was written and quietly false afterwards. The project's own session, which had shipped the feature, refused the spec and pointed at the deployment. The spec was rewritten as a correction, and the status file lost the trap.

the rule it producedOpen work is read from the live plan section only. A to-do inside a dated entry is unmaintainable by construction.
30 August 2026

A file path quoted from a naming convention

The command post cited the location of a document by inferring it from how similar files are named. The file was not there. A peer session read the disk and said so.

the rule it producedA path is a fact from disk. It is never derived from a convention, however consistent that convention has been.

Why not the usual picture

The common arrangement right now is one planning chat plus several throwaway agent windows, with a person carrying text between them. It is attractive because it needs nothing: open a window, paste the plan, read the answer. What it does not have is memory in the workers, so every window is briefed from scratch. It has no written trail into a factory, so nothing that runs leaves a reviewable artefact. And it has no second session with standing to contradict the first, which is exactly what caught both mistakes above. The arrangement on this page is the opposite trade: sessions that keep their context, a factory that only accepts written specs, and a person who decides instead of copying text between windows.

Where this goes

Only what the specs repository already holds, with the status it holds today.

Agent Host Protocol as the session substrate blocked on headless host auth Sessions become infrastructure rather than terminal tabs. A recon in July returned go with a version caveat. A re-check on 25 August found the host answering -32007 Authentication required although the same box logs in fine from a terminal, so phase one is now that auth problem.
Voice client reads the factory's sessions planned The voice bridge stops listing the local terminal and asks the factory for every session on every host, so a phone reaches all of them. The client side belongs to the voice project's spec; the contract belongs to the factory's.

A third row was drafted for a session rail inside the factory toolkit. No spec in the repository holds it today, so it is not listed. The rule for this section is that a status which cannot be re-verified is removed rather than softened.

Nothing here is live on this page. The factory holds write access to real repositories and the sessions hold private working context, so neither is exposed to visitors. What you can run lives one page over, on the cockpit. Autonomy is earned, even here.

← prev: sdlc on agents you are here · the command post next: agents as a service →