Orchestrator
The orchestrator is mechabedo acting as an agent of its own. It operates sessions from outside them: it can see what one is doing, read it in detail, and reach it with a message sent now, queued behind the running turn, or interrupting it.
What to say is its decision. How to do the work never is.
A job
A job is a standing instruction attached to a scope of sessions, dispatched from the workbench's Agent tab.
Drawing the diagram…
Five reasons a job fires
Triggers are a set, not a choice: a job carries any non-empty combination.
| Trigger | Fires when |
|---|---|
completion | A session in scope finished a turn |
error | A session in scope halted: a tool blew up, the API refused, the process died mid-turn |
interval | On a clock, from one minute to twenty-four hours |
tool | A session finished a tool call, mid-turn |
question | A session put a question to the user and is holding its turn open on it |
A turn you stopped wakes nothing
A cancelled turn lands on idle, because a cancel is not a failure - so status alone would read it as a completion and a supervising job would carry on the work you just stopped. A cancel leaves the recovery budget alone as well.
A completion loop usually wants interval beside it: only a finished turn wakes a completion job, so the run that decides to leave a session alone would otherwise be the last one that ever fires.
Which sessions
A job's scope is a list of session ids, or all. You can also describe the workers instead of naming them - harness, status, a substring of the working directory, a limit and an order - and the server resolves that once, at dispatch. "The two most recent Claude Code sessions" is a selection; what the job stores is the result, because resolving later would mean a job that quietly changes what it supervises.
A selection matching nothing is refused, never a job silently watching everything.
Operation modes
A mode is a named, reusable filling of the job form, and its name is a command. Typing it on a prompt line is how one is aimed.
Several on one line make one agent carrying every duty, so the useful question is not which mode but one from where, and what else with it. That is what the categories answer:
| Category | Holds | How they combine |
|---|---|---|
| Lifecycle | How long it supervises, and what ends it | /forever, /nohalt and /conclude each answer what ends it - name one. /judge names no ending and rides with any of them |
| Duties | What it has the session do when a turn lands | Stack as many as you like. Each is one line of the brief, in catalog order |
| Grants | What it may do itself, beyond sending text | Each hands it a tool. /auto only modifies /spawn |
| Questions | Who answers whom | /answer and /askuser compose; they never touch the same card |
| Triggers | What wakes it besides a finished turn | /schedule is the safety net under a completion-only agent; /watch is a second eye |
| Actions | Not an agent at all | /inject contributes nothing to a chain |
Chains worth starting from. Change one rather than composing from nothing:
| Chain | What you get |
|---|---|
/commit /nextup /askuser /forever | Work with me, without end: commit, propose what is next, wait for your yes, repeat |
/commit /nextup /forever | The same with nobody at the desk |
/commit /document /nohalt | Finish the job: commit and document each piece, then retire once the session's finish checks out |
/tasklist /nohalt | Write down what the work is made of and hand it out one task at a time |
/spawn /auto /forever | Fan adjacent work out to sessions of its own, each on its own judgment |
/answer /nohalt | Never block on you: it answers what the session asks, from the brief |
/watch prompt:"..." /forever | Catch it circling, mid-turn, rather than after a tidy summary of nothing |
| Command | What a job made from it does |
|---|---|
/nohalt | Keep it going until it is really done. Continues an API error, a failed tool call, a cut-off answer, a turn that stopped short of the work, and a claim of done its transcript does not bear out. Ten attempts, the last seven backing off, then a fresh session with a compressed handover, up to three times |
/forever | The same, minus the exit: a turn claiming completion is sent back to look again, harden or extend, and a session that keeps halting moves to a fresh one without limit. roll after it rolls the session's context into a fresh one |
/judge | Let the gate read a halt and decide between recovering and leaving it |
/watch | Judge the tool calls as they happen, and cut in where needed |
/tasklist | Hand out one task at a time, and write the list if asked |
/schedule | Queue one message every interval |
/conclude | Ask for a short report without deliberation, then disable itself |
/commit | When the work lands, have the session commit exactly once, with a message drawn from that turn |
/document | When the work lands, have the session bring the documentation up to date for exactly what changed and nothing else |
/nextup | Work out what naturally comes next, and put that to the session |
/regenerate | Put back what a finished turn wrote, fork at the prompt that started it, and send that prompt again |
/spawn | Open a session of its own for adjacent work. /spawn codex picks the harness, /spawn loadout:"my loadout" the loadout |
/inject | Stand a saved prompt on this session and every session opened from it |
/answer | Answer the questions this session puts to the user, in your place, from what the job and the session have already settled |
/askuser | Every message this agent would send the session is shown to you first, on the session's own card, and goes out only if you approve it |
A mode that takes words offers them in the / menu once you type its name and a space, and the line under the menu reads the token back. /spawn offers a harness, then queue or interrupt, and says that the rest of the line is the spawned session's goal. /watch offers parallel or blocking and reminds you of prompt:"...". /nohalt offers force.
On mechabedo's own agent, a regenerated session continues the same conversation, tool results included, minus the last turn. Other harnesses get a fresh session carrying a transcript of the conversation before it.
Anything neither the job nor the session settles is skipped, not guessed
That is the rule /answer runs on, and it is why it is the exact opposite of /askuser rather than a conflict with it.
/askuser makes you the throttle
Nothing reaches the session while a proposal is unanswered. Declining one, or leaving it, ends the loop - the session runs no further turn, so nothing wakes the agent again. Run a pass on the Agent tab to pick it back up. Recovering a halted session is the one thing it still does without asking.
The shipped modes are code. Yours are stored in the server's configuration and merge over them by command, yours winning - so saving a built-in's command writes an override, and deleting your row is the reset. The catalog is the Enhance page's Mechabedo Operation Modes row.
A mode is a template. Picking one fills the form; the job exists once it is saved, and editing the mode afterwards changes what the tab offers next rather than what any existing job does.
Let the session write the chain
Sixteen commands is a lot to pick from, and the loop you want is usually a sentence: do it, commit, work out what is next, ask me, keep going. That sentence is the chain /commit /nextup /askuser /forever, so tell the session itself and let it write one.
A session carrying the Plus kit has two tools for it. It reads the modes under their categories with plan_preview_mechagent, along with the rules and the chains above, shows you the agent a chain would make - when it wakes, what it does at each firing, what it may do on its own, whether it can ever finish - and arms it with confirm_queue_mechagent once you say yes. The preview creates nothing, and the agent it arms is an ordinary one: it appears on the Agent tab with the rest, and you end it there or from the composer.
It also warns where a chain resolves into something nobody meant: two lifecycles at once, a /conclude that loses its script in a chain, or an /auto with no /spawn to modify.
The catalog on the Agent tab is folded away for the same reason, and unfolds when you would rather pick.
Jobs and workflows are different things
Both are mechabedo driving sessions it does not live inside, and both are worth keeping apart.
| Job | Workflow | |
|---|---|---|
| Starts when | A session did something, or a clock fired | You typed a prompt on an armed line |
| Shape | One decision per firing | An ordered sequence of stages |
| You are | Outside it | Inside it, answering its questions |
| Lives | Until you cancel it | For the length of one run |
A job supervises. A workflow is a run you are taking part in.
/forever and /nohalt survive a restart
A job carrying either is written down and comes back after a relaunch or an update, re-aimed at its session once that session is reopened. Any other job lives in memory and a restart ends it, so arm it again after one.
Scheduled prompts
The Agent tab opens on Up next: everything about to reach this session, soonest first. Messages queued behind the running turn come first, then scheduled ones with the time they go. The next one counts down live, a strip over the list shows the coming 24 hours, and each entry has its cancel button on the row. Sent ones fold away under Sent.
To send a message later, type it into the line under the list. Focusing it opens the rest:
- When: a preset (
30m,1h,2h,4h, or the next round hour), or type a delay:2h,90m,1h30, a clock time such as18:30(its next occurrence), or a date and time such as2026-10-15 09:00. Up to 24 hours ahead. The arrow keys, or the minus and plus beside the field, move it by 5 minutes; withShift, by an hour. - Interrupt stops the running turn and goes first. Without it, the message waits behind the turn, and goes at once to an idle session.
- Repeat sends it again every delay until you cancel it. It needs a delay such as
2h, not a clock time.
The line under the controls says when it will go. Ctrl+Enter schedules it. You can also ask the chat: "send run the tests to that session at 18:30".
Kept by the running app
A scheduled prompt is held by mechabedo's server, so quitting or restarting the app before its time drops it.
Underneath it is an ordinary job, a one-step script on the interval trigger that waits a full interval before its first pass. A new job you make in the form with a Timer runs its first pass at once, unless you switch First pass now off.
What a run leaves behind
Every firing is one of mechabedo's own sessions, archived like any other under the harness name mechabedo. So why a job did what it did is readable long after the process that did it is gone.
Orchestrator records never notify, so a job cannot wake itself.
Where they are managed
| Surface | Actions |
|---|---|
| The workbench's Agent tab | Scheduled prompts and jobs scoped to this session, and the form that makes one |
| Home's Harness status card | The whole fleet under Agents, with run-now and cancel, and a robot on each session one supervises |
| The workbench's stop button | Names which session-scoped agents are watching, and ends them in one click |
Next
- Workflows - the other way mechabedo drives a session
- The workbench - the Agent tab
- Chat - dispatching one from a conversation