Workflows need their own runtime
A development preview of MendCode dynamic workflows: finite execution graphs, hardened loop scheduling, and graph memory that remain connected without becoming the same system.
Editorial cover
A story-specific system diagram. Product evidence, when present, appears beside the claims it supports.
Agent products keep calling every multi-step action a workflow. The label is cheap. The runtime contract is not. A real workflow needs validated phases, dependencies, artifacts, retries, budgets, and a durable answer to one question: what exactly is running right now?
MendCode is designing that runtime now. The goal is not to replace loops or rename background sessions. It is to give finite, inspectable work its own execution graph while preserving the systems that already own recurrence and knowledge.
Three graphs, not one
MendCode needs three graph-shaped systems because they answer different questions. The knowledge graph describes what the system knows. The execution graph describes what must happen and in what order. The lifecycle graph describes when durable work wakes, runs, backs off, and stops.
Keep the graph contracts separate
| Graph | Owns | Must not become |
|---|---|---|
| Knowledge | Facts, provenance, support, conflict, supersession | A task scheduler |
| Execution | Phases, tasks, dependencies, barriers, artifacts | A permanent memory store |
| Lifecycle | Wakeups, runs, signals, backoff, stop policy | The workflow itself |
Connecting these systems is useful. Collapsing them is dangerous. A memory edge should not accidentally schedule work. A loop wakeup should not become a fake dependency. A finished task should produce evidence without turning the transcript into the durable database.
A workflow is finite
A workflow starts, moves through a validated directed acyclic graph, and reaches a terminal state. It can run once without a loop. Phases can contain parallel tasks, explicit barriers, retry policy, budgets, and named artifacts. Completion is not a pleasant-looking assistant message; it is a state transition backed by outputs.
Workflow diagram
Validate phases and dependencies
Run ready tasks and collect artifacts
Resolve gates and finish with durable evidence
Each agent-backed task should execute through MendCode's existing durable BackgroundTask primitive. Generations, revisions, leases, cancellation, bounded terminal results, and child-session ownership stay there. The Workflow scheduler owns DAG readiness and barriers instead of inventing a second task supervisor. A chat session may display the run, but it should not be the only place its truth exists.
Loops own cadence
Loops already describe durable objectives that can wake again. They own triggers, run history, gates, signals, artifacts, cost pressure, leases, pause and resume, and stop policy. A loop may launch a workflow, wait for its result, and decide whether another cycle is justified.
That relationship keeps both concepts sharp. The workflow answers “how does this run complete?” The loop answers “why and when should another run exist?” Recurrence belongs to lifecycle, not to the execution DAG.
The current development branch hardens that lifecycle before Workflow execution lands. Overdue interval loops repair their wakeup once, duplicate scheduler ticks converge on the same catch-up run, completion re-arms a future cadence, and scheduler health records the project, database channel, service definition, executable identity, last wake attempt, bounded error, and drift state.
The scheduler prerequisite now proves
- Repeated overdue ticks do not create duplicate catch-up runs.
- A completed catch-up leaves a future next wakeup instead of a permanently overdue loop.
- Forty-eight half-hour boundaries survive duplicate tick pressure and one instance restart with forty-eight unique runs.
- Service status can explain missing, stale, drifted, or degraded scheduler identity instead of returning only loaded or unloaded.
Memory is knowledge
Graph memory is the third system. It can preserve facts, evidence, conflicts, and relationships that outlive one run. Workflow artifacts may propose memory. Loop history may provide provenance. Neither should be allowed to write invisible lore directly into future sessions.
The current graph can represent and visualize relationships, but retrieval still relies on flatter legacy paths. Bounded neighborhood retrieval and graph-aware planning remain future work. The honest architecture treats that as a gap, not as proof that every memory graph is already operational intelligence.
Durable source of truth
The execution record must survive navigation. Sessions are useful transcripts and entry points, but a user should be able to leave the chat, open the workflow monitor, and see the same phase, task, artifact, retry, and gate state. If the UI has to reconstruct truth from prose, the runtime contract is already lost.
A workflow record must explain
- Which definition and input started the run.
- Which tasks are blocked, ready, running, failed, or complete.
- Which artifacts and costs belong to each task.
- Which retry, gate, cancellation, or terminal decision changed the run.
Two surfaces
Chat needs a compact receipt: the workflow started, its current phase, the next gate, and a path to inspect it. The dedicated workflow monitor needs the full execution graph, task detail, artifacts, retries, and live progress. Agent View can focus on one workflow root and its children. The loop surface remains responsible for cadence and lifecycle history.
Chat starts and steers work. The workflow runtime owns execution truth. The loop owns recurrence. Memory owns knowledge.
What exists today
The current development runtime already has durable Loop workflows with daily, self-paced, and external-signal triggers; independent evaluation; gates; artifacts; loop memory; usage and cost; workspaces; leases; global paging; background sessions; and visible chat and dashboard state. The scheduler-hardening branch adds catch-up deduplication, cadence endurance, and bounded service health and drift diagnostics.
The focused loop and service suites pass, including the 48-interval restart scenario. The installed-service smoke remains intentionally pending, and the first-class Workflow store, scheduler, tool, chat receipt, and /workflows route remain future implementation. The point of publishing the contract early is not to manufacture a launch. It is to make that boundary reviewable before the UI and persistence choices harden around the wrong abstraction.