Orchestrator and Workers
The two-tier model — who does what in a WTmag session.
There are two roles in a WTmag session. You don't have to use both, but the system is designed around the interaction between them.
You
You decide what to work on and when to step in. You can run wtmag create directly, or talk with an orchestrator that runs it for you. Either way, you're the one who attaches to workers, reviews the results, and cleans up. The orchestrator should never attach on your behalf — that's your call.
The orchestrator
An orchestrator is just an agent running in your main tmux session. You talk to it, it calls wtmag create for each task, and it tells you how to attach to workers.
The orchestrator loads a bundled skill that lets it work through things naturally: brainstorm an issue, flesh it out, point it at an existing ticket, or ask it to pull everything open for review. It understands your intent and runs the right commands without you having to context-switch.
The orchestrator should not attach to workers itself. That's your job. It tells you the worker ID and how to jump in, then steps back.
The worker
A worker is an agent running inside a worktree and a tmux session. It does the actual coding.
Issue workers try to get to a PR — implement, commit, push, open the PR, report the link back. Review workers read the diff and report findings without touching anything. Custom prompt workers do whatever you told them.
Each worker gets its own isolated worktree, its own tmux session or window, and its own running agent. Multiple workers can run in parallel without editing the same files.
How the brief gets to the agent
WTmag writes the full task to .wtmag/prompt.md in the worktree, ignores /.wtmag/ via the worktree-local Git exclude, then launches the agent with a one-line bootstrap: "read that file."
This keeps the command line short and the context intact. The agent starts with the real task — the full issue text, the PR diff, or your prompt — not a summary you pasted by hand.
Why two tiers
The two-tier model keeps you close to the work. The orchestrator handles the logistics — fetching context, creating worktrees, dispatching workers. You handle the judgment calls — when to jump in, what to review, when to clean up.
The gap between having a task and having an agent working on it used to involve several manual steps. The orchestrator collapses that into one command, or zero if you're just talking.