orchestrate

THIS DRIVES THE ORCHESTRATOR - orchestrator/ inside the AgentHydra repo (owner order, 2026-09-03: it moved back in "so I don't have to explain that you have to use both"): the v3 rewrite, individual Python scripts (stdlib-only) talking to the AgentHydra daemon over HTTP, now driven through the AgentHydra MCP server's own tools - orchestrator_menu, orchestrator_run {script, args}, orchestrator_loop, orchestrator_switch. Every tool call below has a shell twin (python orch.py <script> ... from orchestrator/); use the tools, they are the same code. The v1/v2 MCP-tool flow (prestart, chat_sweep, courier tools) is GONE; if you find yourself reaching for those, you are reading old habits, not this command. The division of labor is owner law: THE CODE decides state and executes batches; YOU answer only the precise callouts it hands back. Never re-implement any of it, never bypass a rails refusal with raw daemon calls. orchestrator/README.md explains anything that surprises you. Extra instructions, if any: $ARGUMENTS

⛔ A TARGETED MOVE IS NOT A PASS - DO NOT ARM FOR IT (learned 2026-09-03, moving four chats off one account took ~20 minutes that should have been ~1). migrate_chat and chats --move-to are HAND-RUN acts: they do not read the tray icon at all (the icon gates the UNATTENDED lanes, which is the whole point of it), so arming buys a move nothing. What arming DOES do is resume saturate, whose job is to WAKE dormant chats - and a chat with a live engine cannot move until it has been quiet 300 seconds. So when the extra instructions say "move the chats from X" or anything else that is one deliberate act on named chats:

1. orchestrator_switch {action:"armed"} - if the icon is DOWN, leave it down.
2. orchestrator_run {script:"chats", args:["--instance","<from>","--move-to","<to>"]} to PLAN, then the same with "--yes","--idle-wait","330" to do it. --idle-wait sleeps out the ONE refusal time cures (turn finished, five minutes not yet up) inside the command, instead of you re-running it on a guess; a working or stuck engine still refuses in a second. The headline counts what LANDED - "N of M attempted" is a partial, read it.
3. A chat HELD as a duplicate still moves - migrate_chat <id> --to <to> --force --stop-idle --idle-wait 330, one chat per command, because --force is a person's word for ONE act and chats deliberately has no batch form of it. The hold survives the move.
4. Pick a destination WITHOUT a chat of the same title already on it (audit_twins names the collisions) - identical titles on one account are what the sidebar cannot tell apart.
5. THEN, if the owner also wants the pass, arm. Never the other way round. Verify with chats --account <from> --all: the answer you want is "holds NO chats".

THE PASS, in order:

1. orchestrator_loop {} - DRY: census, gate, accounts and usage bands, the four lanes, naming, reconcile, and the judgment queue; touches nothing. STOP AND INVESTIGATE if the census sanity rail fails (0-1 open instances means detection is broken, not a quiet fleet) or the plan reports INCOMPLETE (a read failed; every lane is a lower bound).

2. orchestrator_run {script:"sweep", args:["--all","--yes"]} - THE ACTING PASS, within caps: archives, console landings (naming pass included), balance moves, staged deliveries - each through its own act script's rails (hold, live-writer, breaker, T-0 recheck, verified outcome). Read the per-row outcomes. A refusal names its reason and is not yours to force; a breaker or hold is information, not an obstacle.

3. orchestrator_run {script:"interview", args:["--ask"]} - THE JUDGMENT QUEUE, the only part that is yours, and THE PART THAT MAKES CHATS RUN - a pass that leaves it unanswered is a failed pass (the owner's complaint that forced this line, 2026-08-31: "all my chats are sitting idle and it's not making them run"). Each question is self-contained: the chat's own last words plus the exact answer format. Write orchestrator/answers.json ({"answers":[{"sessionId":...,"decision":"reply|hold|archive|skip", ...}]}). THE PROGRESS DEFAULT (owner doctrine): a chat that offers to continue or names its next step gets a REPLY saying which thing to do; hold and skip demand a reason a person would accept, and "waiting on the owner" only counts when the decision is genuinely his (spend, live customers, public exposure, another person's lane). When last words are not enough, open the chat in the desktop and READ it - never guess. Then orchestrator_run {script:"interview", args:["--apply","answers.json"]} - each decision executes through the rails; replies are STAGED and the sweep/courier delivers them under the machine-wide 18-running cap (deferred wakes stay staged; the 5-minute cycle is the round robin).