orchestrator

The orchestrator's seat

An orchestrator is an agent whose job is NOT to write code. It knows who is working on what, who is stopped and why, hands work out, and answers for the whole field in one line. In agentglass it is a SEAT: one per project, with its own rules file, its own queue, the project's field in front of it, and a view.

Seating one by hand — a tmux window, a prompt pasted in, a loop — makes an agent nobody else can see and nobody can reproduce. This does it properly.

Put somebody in the chair

agentglass-agent orchestrate --project ~/code/<project>

Without --project it uses the current directory. It is idempotent: if that project already has somebody in its chair, you get that agent back rather than a second one.

The answer names two files. Both are markdown, both live outside the repository, and both are read fresh every seating:

• the doctrine — the rules the SEAT runs by
• the brief — the rules it hands to every agent it opens

They are seeded from a template the first time and then they are yours. The answer says doctrineSeeded: true when this call created them, which is your cue to read them and change what does not match this project.

One that is already running

If a session has been orchestrating a project for hours — with agents reporting to it and a context worth keeping — do NOT seat a new one. It adopts itself from inside its own pane:

agentglass-agent adopt --project ~/code/<project> --powers assign

Nothing restarts, nothing is re-prompted, and no context is thrown away. What it gains is the app knowing who it is: its line in the view, the queue, the field drawn for it with the last hour of every agent, and being woken when that field changes instead of keeping a clock of its own. Its rules files are seeded if missing so there is something to edit; they are not imposed on it.

Standing down an adopted seat releases the claim. It does not kill the session — that would be throwing away somebody's day because a button said "stand down".