Skip to content
Install

Engineering · · Updated · 6 min read

Workflows need their own runtime

A MendCode workflow is a plan of agent and check tasks with a completion contract that decides when the work is done. Script workflows decide at run time which agents to start, inside the same limits and approvals.

Generated editorial cover. Product screenshots inside the post are unedited.

One long chat that tries to do a migration, check it and report on it at once loses track of what is finished. A workflow splits the work into tasks with their own child sessions, runs them in dependency order and only calls the work done when a contract says so.

Plans

a plan
{
  "name": "api-rewrite",
  "objective": "Rewrite the API layer to the new client.",
  "tasks": [
    { "kind": "agent", "id": "survey", "prompt": "List every endpoint and caller.", "mode": "read" },
    { "kind": "agent", "id": "impl", "prompt": "Port every endpoint.", "needs": ["survey"] },
    { "kind": "check", "id": "unit", "command": "bun test", "needs": ["impl"] }
  ],
  "contract": "release-gate",
  "permission": "edits"
}

How it runs

  • A read task runs in plan mode and cannot change anything; a work task gets the workflow’s permission, and only one runs per directory at a time.
  • A task starts when everything it needs is done. A failed task skips what depends on it.
  • An interrupted task, after a daemon restart for example, goes back to pending, up to three starts.
  • The permission in the plan is a request: the applied one is the lower of it and what you granted.

Done means the contract passed

The completion contract, inline or from contracts/<name>.json, lists criteria, the checks that cover them and the tasks that own them. A read-only auditor judges the criteria no check covers. A rejection sends the owners back with the failure as feedback; when repairs run out, the run is blocked until you verify again or accept it with a reason.

Script workflows

Some work is shaped by its own results: review every finding, migrate every directory, research from several angles and merge. A script workflow is a short JavaScript program that decides at run time which agents to start. Every agent() call is an ordinary workflow task with its own child session, so limits, permissions, cost and cancel all apply.

review-and-verify.js (shortened)
export const meta = {
  description: "Review a change on several dimensions, then verify each finding",
  phases: [{ title: "Find" }, { title: "Verify" }],
  budget: { agents: 60, tokens: 3000000, usd: 10, minutes: 45 },
}
phase("Find")
return await pipeline(plan.dimensions, (d) => agent("Review for " + d, { label: "Review: " + d }))

Starting one

From chat

/workflows run, or /workflows new <name> for a commented starter.

From the CLI

mendcode workflow run <file.js|name> [--wait].

From the model

The workflow_script tool asks in every permission mode and shows the meta, caps and source.

Examples

examples/workflows/ has review-and-verify.js, migrate-many-files.js and research.js.

Controls and evidence

A run can be paused, resumed, stopped, retried, verified again, accepted with a reason or deleted. In /workflows, b opens the run’s evidence ledger: events, artifacts and completion receipts. Each run is one stored row of at most 160 KB, and at most 50 finished runs are kept.

Loops

A loop is recurring agent work: an objective, a trigger and a budget. Triggers are manual, interval, daily at a time in a time zone, adaptive (the interval doubles when a run found nothing and halves when it acted) and external, fired with mendcode loop fire from cron or CI.

The /loops page, drawn from MendCode’s own render code.