many sub-agents on one fixed work order, in the background, under Ultra

A troupe is for a job too big for one agent to do reliably: reviewing forty files and checking every finding, researching a list of questions, making the same change in many places, comparing several options. One agent working through that by itself loses track, skips parts or stops early. With a troupe, the model writes a work order and DGC runs it exactly as written: every item gets its own agent, every finding gets its checkers, and nothing is skipped.

Troupes are offered under Ultra (the effort menu's Ultra, or /ultra). The model decides when a job calls for one.

1. The model starts a troupe with a title, the items to work through, and either a template or its own stages. 2. In auto mode it just runs. In other modes you see a card first, "Start a troupe?", with the plan in words, the items and what Allow does. Plan mode never starts one. 3. It runs in the background and the chat stays free. In the editor, a row above the prompt box shows the stage it is on, with Stop; its chevron opens every stage's progress. In the terminal, a line marks each stage as it finishes; /troupes lists them and /troupes stop ID|all stops one. 4. When it ends, the chat wakes and the model reports the results. In a one-shot dgc -p run, the troupe runs to its end inside the call, and the model answers with its results.

• review: one explorer per item reports problems; then three verifiers each try to prove every problem wrong, and only the problems most of them agree are real are kept.
• research: a researcher per question answers it with sources; a critic checks each answer.
• change: a worker per place makes the change in its own isolated checkout, which is merged back as a sub-task's is; a verifier then checks each change.
• compare: an explorer works out each option; three judges compare them all and pick the best.

A work order can instead give up to four stages of its own. Each stage names its agent kind, a prompt with {item}, the JSON every agent ends with (returns), and optionally votes (several agents per item, independently), keep (only results whose field has a value; with votes, how many must agree), split (a list in each result becomes the next stage's items) and over: "all" (one agent sees every item at once).

• explorer, researcher, critic read only (files, search, the web), with no shell. They run beside your files, so a hundred of them cost no checkouts.
• verifier reads the same and also has a read-only shell in a sealed box (bubblewrap on Linux, Seatbelt on a Mac), to run the commands, tests and queries that would prove a finding wrong. In the box the project is read only (at /mnt; on a Mac at its own path), the only writable place is a private /tmp (on a Mac, a private $TMPDIR), credential files a Pip snapshot leaves out (.env*, keys, .git, .ssh, ...) are hidden, your home, /run and their sockets (Docker's included) are empty or closed, and there is no network, except the project's read-only database when one is set. On a Mac it is a little weaker: a command can see which other programs are running, and one it detaches can outlive it, still inside the box. Where the box can't run (stock Ubuntu 23.10+ AppArmor: dgc pips execution --fix), a verifier has no shell and is told so. A verifier that can't check something answers unsure, which counts neither way; what nobody could check is kept and marked unchecked.
• A read-only database account, for checks on live data: make a read-only role yourself (dgc readonly-db guide prints the Postgres SQL; DGC never creates or changes a role), then dgc readonly-db set in the project and paste its postgresql:// address (it is kept as a plugin's sign-in is, the system keychain or an owner-only file, and never goes on a command line). It must be on this computer: a verifier's box reaches it through one forwarded port and nothing else, as $DGC_READONLY_DATABASE_URL. A worker gets the same variable, to prefer for reads. dgc readonly-db show and clear too. Without one, a verifier's box has no database at all.
• worker writes, always in an isolated checkout of its own, and its changes are merged back exactly as a sub-task's are. A named agent from .dgc/agents that may write is treated the same.
• They never ask you anything: a step that would ask is refused (in auto mode, everything their kind allows runs). A deny rule still applies, Troupe included: "deny": ["Troupe"] turns troupes off.

On a model served on this machine, one agent runs at a time; on a remote or cloud model, as many as sub-agents may (Ultra: 8). The turn's token cap (Settings, General) counts every troupe agent, and a troupe stops starting new agents when it is reached. A troupe starts at most 400 agents.

Each run keeps a journal in ~/.dgc/troupes/<id>/: its work order (plan.json), every agent's result as it lands (results.jsonl), the last stage's results (results.json) and the report the model was given (report.md). A stopped or interrupted troupe can be run again with its id: only the agents that had not finished run again.

Troupes are one chat's work: a new chat, /clear or closing DGC stops them, and a troupe never reports into a chat other than the one that started it.

Ask for a troupe on a schedule ("every Monday at 9, review last week's changes for bugs and double-check what you find") and the model schedules it instead of running it: it becomes a routine of your Primary Pip, or of the Personal Pip you name. Outside auto mode you see Schedule a troupe? first, with when it runs, what it works through each time and which Pip reports; Always allow saves Troupe(routine), which is separate from the rules that allow running one now.

When it is due, the troupe runs as a job of its own, with your model, on a snapshot of the project's committed code: one troupe routine at a time, for at most an hour. Each time it works through the files changed since it last ran (the first time, the last seven days), the tracked files matching a pattern, or a fixed list. The Pip then tells you what it found in its chat; the full results are in ~/.dgc/troupes/. Its tokens show in the Pip's usage.

A scheduled troupe only reads: review, research, compare, or stages without a worker. Rename it, change its time or turn it off in the Pip's Settings, Routines; to change what it does, ask for a new one. Pips must be running on this computer for it to run.