Workflows
A workflow is a staged run mechabedo drives over one of your sessions. You arm a session's prompt line with one; the next prompt you type starts a run instead of a turn. mechabedo interviews you about what the prompt left open, writes an optimized prompt or a brief per agent, hands the work to that session, to a fleet it opens beside it or to a graph it writes, waits, and concludes.
The point is the gap between the prompt people actually type and the prompt the work deserves. A workflow closes it by asking, and by splitting the work when splitting it helps.
Arming a line
Open a session, go to the Workflows tab in the right pane, pick a workflow and turn the arm switch on. A notice appears above the prompt box saying the line is armed.
From then on:
- The first prompt you type starts a run, and the line disarms: an arm is for one prompt. The tab comes forward and shows the run.
- Anything you type while the run is underway is added to it as a note, not as a turn. Notes are folded into the next thing mechabedo writes, so "actually, keep it to the server side" mid-interview lands where it matters.
- Slash commands and
/injectpastes still work on an armed line. They are read off the line before the workflow sees it.
Arming is a live choice, not a setting. It belongs to the session on screen, the run it starts disarms it, and a reload disarms every line. Only the last workflow you picked is remembered, so the tab offers it first next time.
Tips
A workflow never sends your raw prompt through by accident. If the run is refused - no model on the Think tier, a run already underway on this session, a workflow using Run it as a graph on a session with no graph tools - the line stays in the box with the reason above it.
Stages
Every workflow, shipped or your own, is an ordered list of stages built from six kinds. This is the whole vocabulary; there is nothing a shipped workflow can do that the editor cannot.
| Stage | Effect | Knobs |
|---|---|---|
| Interview | mechabedo's Think tier writes questions; you answer them on a card | Parts, each with a focus, a heading, a steering brief and 1 to 4 rounds; skip when clear |
| Scavenge | Reads your prompt for every separate goal it holds | Max goals (1 to 24), a steering brief |
| Refine | Turns the prompt plus the answers into one optimized prompt, or one brief per agent | Output: prompt or briefs; a steering brief |
| Dispatch | Sends the work to this session, opens a fleet beside it, or writes a graph run under it | Target: this session, a fleet or a graph; for a fleet: count, loadout, peering, independent; for this session: run it as a graph; for a graph: loadout; confirm first; arm /document, except on a graph |
| Observe | Waits for the fleet and keeps each agent's closing report | Wait for all or the first; a timeout in minutes |
| Conclude | Reads the reports together and closes out | Deliver to this session or leave it on the record; a steering brief |
Interview focuses
A part's focus decides what the Think tier is told to ask about.
| Focus | What it asks |
|---|---|
scope | What is in and out, which subsystems are touched, what the prompt assumes without saying, and what would make the work wrong if guessed |
ship | What done looks like, how it is verified, whether tests or docs are expected, and what must not be touched |
fleet | How the work splits across parallel agents, which slices are independent, and which need a particular model |
goals | Confirms the scavenged goals, then asks the one question per goal that most changes how it is pursued |
custom | Whatever the part's brief says. A custom part must have one |
A round writes at most four questions and you get them as one card. Skip when clear lets mechabedo ask nothing when the prompt already answered everything; without it, the first round always asks at least the question that confirms its reading of your prompt.
A fleet part reads the dispatch stage after it and asks only what that dispatch actually leaves open. If the dispatch fixes the count, you are not asked how many agents; if its loadout is inherit, you are not asked which model each runs on.
The shipped workflows
They exist to be read, copied and pulled apart. Graph True Shot, True Shot, Documented Shot and Parallelized Shot deliberately share an opening: once you have been through one interview, you know the others. Graph Gatling opens the way Ultracode Gatling does. Graph Shot is first, so it is what the Workflows tab offers until you pick another.
Graph Shot
No interview: the prompt becomes an optimized prompt at once, and mechabedo writes a graph of dependency-ordered sessions from it under this session.
| # | Stage | Settings |
|---|---|---|
| 1 | Refine | to one prompt that states the parts of the work and the order between them |
| 2 | Dispatch | to a graph, loadout picked per node |
What you see: no cards. The graph's live view appears over your conversation as soon as the dispatch starts it, and the rest goes as in Graph True Shot below.
Graph True Shot
One interview on scope and shipping, one optimized prompt, and mechabedo writes a graph of dependency-ordered sessions from it under this session.
| # | Stage | Settings |
|---|---|---|
| 1 | Interview | scope (2 rounds), ship (1 round) |
| 2 | Refine | to one prompt that states the parts of the work and the order between them |
| 3 | Dispatch | to a graph, loadout picked per node |
What you see: the same cards as True Shot. Then mechabedo's Think tier writes the graph itself from the prompt, any scavenged goals and your answers, picks a loadout per node from your loadout list, and checks that the graph is valid; one that is not gets one automatic repair. The run starts at once with your session as its parent and draws itself over your conversation, while the Workflows tab still shows the workflow run. Your session is not asked to plan anything, so none of its context goes on planning and it needs no graph tools. When every node has settled, the run's report arrives in your session as the next prompt (Graph runs), with a What it was for section, because your session never saw the original prompt. The workflow's own record ends at the dispatch.
Use it when the work has parts that must happen in order, such as a schema before the code that reads it and a check after both, and is too big for one turn.
A graph is a dispatch target of its own, so your own workflows can end the same way. Its loadout is This session's, which every node inherits, mechabedo picks per node from your loadout list, or One loadout for every node. Show me the graph and ask before it starts puts the graph on a card first. /document is not offered on it.
Run it as a graph is the other way, a switch on a dispatch to this session: the optimized prompt lands in your session with a note asking it to run the work as a graph, and the agent splits it into nodes, starts them with graph_start and ends its turn. Between the dispatch and graph_start, a strip above the prompt box says the session is planning the graph and how long it has been at it. When the graph starts, its live view replaces the strip. If the turn ends without a graph, the strip says so: the agent may have decided the parts do not depend on each other and worked it directly. Ask again sends the request once more, and a graph started later is still linked to the run.
The switch needs the graph tools: a session whose kit has the Graph runs category off is refused, and the Workflows tab warns you before you arm it. Switch the category on for that kit on the Enhance page, then open a new session, because a running session keeps the tools it started with.
Graph Gatling
The prompt is scavenged for every goal it holds, each goal gets one focused question, and mechabedo writes one graph that keeps every goal as its own part.
| # | Stage | Settings |
|---|---|---|
| 1 | Scavenge | up to 12 goals |
| 2 | Interview | goals (1), skip when clear |
| 3 | Refine | to one prompt that keeps every goal as its own part and states the order between them and any decision only you can take |
| 4 | Dispatch | to a graph, loadout picked per node |
What you see: as in Ultracode Gatling, mechabedo lists the goals it found, you confirm or drop them, and it asks one sharp question per goal. Then, instead of a fleet, it writes one graph from them and starts it under your session, as in Graph True Shot.
Use it when the goals have a real order between them. When they are independent, Ultracode Gatling's fleet is simpler.
True Shot
One interview, one optimized prompt, and this session works it end to end.
| # | Stage | Settings |
|---|---|---|
| 1 | Interview | scope (2 rounds), ship (1 round) |
| 2 | Refine | to one prompt |
| 3 | Dispatch | to this session, inheriting its loadout |
What you see: two or three cards of questions, then the optimized prompt appears in your session as a marked workflow dispatch and the agent starts working on it. Nothing else is opened, nothing is waited on.
Use it when the work is one job for one agent and the only real risk is that the agent guesses wrong about scope.
Documented Shot
True Shot with
/documentarmed: the same interview and optimized prompt, and when the work lands the session updates the documentation for what it changed.
| # | Stage | Settings |
|---|---|---|
| 1 | Interview | scope (2 rounds), ship (1 round) |
| 2 | Refine | to one prompt |
| 3 | Dispatch | to this session, inheriting its loadout, /document armed |
What you see: the same cards and the same marked dispatch, then a mechabedo agent standing on your session. When the agent finishes the work, that agent asks it to bring the project's documentation up to date for exactly what changed, following the documentation profile you saved on the Enhance page's Documentation row, and to touch nothing else. A turn that changed nothing a user sees gets no documentation turn.
Use it on a project that keeps documentation, when the work is user-facing. Typing /document on the prompt line arms the same agent without the interview.
Parallelized Shot
The same interview, then a third part sizes a fleet. Each agent takes a share, mechabedo waits for all of them and concludes into this session.
| # | Stage | Settings |
|---|---|---|
| 1 | Interview | scope (2), ship (1), fleet (1) |
| 2 | Refine | to briefs |
| 3 | Dispatch | to a fleet; count asked, loadout asked |
| 4 | Observe | all, 180 minutes |
| 5 | Conclude | into this session |
What you see: the scope and ship cards as before, then mechabedo proposes a fleet and asks how many agents; then a card per group of agents asking which loadout each runs on. It writes a brief per agent, opens them beside your session, and the graph fans them out under the dispatch. Each agent reports by ending its turn. When they are all in, mechabedo writes the conclusion into your session.
Use it when one job divides into slices that do not collide.
Ultracode Gatling
The prompt is scavenged for every goal it holds, each goal gets one focused question, and one agent per goal works independently.
| # | Stage | Settings |
|---|---|---|
| 1 | Scavenge | up to 12 goals |
| 2 | Interview | goals (1), fleet (1), skip when clear |
| 3 | Refine | to briefs |
| 4 | Dispatch | to a fleet; one per goal, loadout asked, peering on, independent on |
| 5 | Observe | all, 240 minutes |
| 6 | Conclude | on the record |
What you see: mechabedo reads your prompt and lists the goals it found; you confirm or drop them; it asks one sharp question per goal; then one agent per surviving goal opens and works its own goal.
Peering is what separates this from Parallelized Shot. Each agent is told who its siblings are, with their session ids, and is pointed at peer_list_sessions, peer_inspect_session, peer_ask_session, peer_queue_message and ask_mechabedo, with the instruction not to edit what a sibling owns but to tell them instead. The conclusion stays on the record rather than landing in your session, because independent work usually has no single answer worth pasting back.
Use it to widen scope fast: many small independent improvements at once.
A fleet is capped at twelve
"Any number of agents" is bounded in practice. Scavenge finds up to 24 goals and a fleet opens at most 12 agents, so a Gatling run over 20 goals works the first 12. This is a deliberate ceiling on machine load, not a limit of the design.
Writing your own
The Enhance page's Staged row, under Graph runs in the Workflows group, is the editor. It shows your list on the left, the definition and its stages in the middle, and a live picture of what the run will do on the right. Clicking a stage in the picture scrolls to its knobs.
Three ways to start:
- Duplicate a shipped one and change it. The copy is yours; the original is untouched.
- Save over a shipped id to override it everywhere. Deleting your row is the reset.
- Start blank, which gives you interview, refine and dispatch to fill in.
Only your own rows are stored. The shipped ones live in code, and your rows are laid over them by id.
A worked example: "Second Opinion"
Here is a workflow worth having that none of the shipped ones give you. Some problems are hard enough that you want two independent attempts on different models, and then a straight comparison. That is five stages.
| # | Stage | Set it to |
|---|---|---|
| 1 | Interview | skip when clear on, two parts: scope (1 round), brief "Ask only what would make both attempts wrong. Do not ask about approach - the point is that they differ."; then fleet (1 round) |
| 2 | Refine | output briefs |
| 3 | Dispatch | target fleet, count 2, loadout ask, peering off, independent off |
| 4 | Observe | all, 90 minutes |
| 5 | Conclude | deliver to this session, brief: "Contrast the two attempts. Say where they agree, where they differ and why, and recommend one with a reason." |
Why each knob is what it is:
- Skip when clear means a well-posed prompt goes straight to work. You get asked only when something genuinely blocks both attempts.
- Count 2 rather than
askfixes the fleet size, so you are never asked "how many agents". - Loadout
askis the whole point: mechabedo proposes a model per agent and puts it to you on a card, which is where you pick two genuinely different ones. - The
fleetpart in stage 1 is there because of that.loadout: askneeds one before it, since something has to have proposed the loadouts. It is worth seeing what that part then does: because the count is already fixed at 2, it skips the "how many" question entirely and asks only which loadout each of the two agents runs on. Afleetpart asks only what the dispatch after it actually left open. - Peering off, independent off: the two agents are solving the same problem, not neighbouring ones. They should not talk, and they should not divide the work.
- Conclude into this session puts the comparison where you are reading, which is the deliverable.
Other workflows worth building from the same six kinds: a Spec First that is True Shot with confirm turned on, so you read and approve the optimized prompt before it goes; or a Sweep that scavenges a refactor into goals and runs them one agent per goal with peering off, for changes that genuinely never touch each other.
Rules the editor enforces
Save is refused, with the reason, when a definition could not run. The checks exist because each is a way a run would otherwise fail halfway through.
| Rule | Reason |
|---|---|
| A fleet dispatch needs a refine writing briefs before it | There would be nothing to hand the agents |
| A dispatch to this session needs a refine writing a prompt | One session takes one prompt, not a set of briefs |
| A dispatch to a graph needs a refine writing a prompt, if any refine comes before it | A graph is written from one prompt, not a set of briefs |
Count ask or loadout ask needs a fleet interview part before it | Nothing would have proposed them |
Count one per goal needs a scavenge before it | There would be no goals to count |
A goals interview part needs a scavenge before it | Same |
| Observe needs a fleet dispatch before it | There would be nothing to wait for |
| Conclude needs any dispatch before it | There would be nothing to conclude |
A custom interview part needs a brief | Nothing would tell it what to ask |
Ids are lowercase letters, digits and hyphens. A workflow holds at most twelve stages.
The picture
Every workflow draws itself: the prompt, each stage in order, an interview opened into its parts, a fleet fanned out under its dispatch and gathered again by the stage after it, and the end.
Positions are computed rather than force-simulated, so one definition always draws the same picture. During a run the same picture is recoloured by state, so you can see which stage is active and which fleet members have reported.
During a run
| Detail | Behaviour |
|---|---|
| The questions | Asked on the run's own mechabedo record, and embedded in the Workflows tab so you can answer without leaving your conversation. Interview questions always take typed text beside their options, so you are never boxed in by what mechabedo thought to offer. The fleet and confirm cards are plain choices, because their options are already the whole set |
| Waiting | The run reads waiting while a card is up and running otherwise |
| The record | A mechabedo session named Workflow <name>, in your session's directory. Each stage is one of its turns, with the Think calls drawn as tool calls. It is in the rail and it is archived like any other session |
| Reports | A fleet member reports by ending its turn. Every brief ends by asking for a short closing report of what changed, what was verified and what was left for others |
| Cancel | Stops the Think call in flight, skips the pending card and releases the wait. Sessions already opened keep working - cancelling the run does not kill the agents |
| A busy session | A dispatch to a session mid-turn queues behind it rather than being refused |
What is not there yet
Runs live in memory alongside orchestrator jobs and relays. A restart drops the run: a fleet already opened keeps working and the record's transcript survives in the archive, but nobody is left waiting for the reports or writing the conclusion. Persisting a run is deferred work rather than an oversight - a run holds a model call or a question open and waits on live sessions, so restoring one would have to re-arm every wait.