[v2] Workflow Agent: DAG scheduling with dependencies + retries

[devzeebo]

Part of the Orchestrator v2 rebuild — a tear-down/rebuild in a new self-contained orchestrator-v2/ folder (Vite+ / vp, vp test + vitest-gwt, no hooks, single RPC/WebSocket runner interface, engine adapters copied wholesale). Fulfills #31 (Workflow Agent). See also #29, #30.

Problem

There is no interface for defining a workflow; today every agent is implicitly "Do start, Do LLM, Do stop", which is inflexible and prevents dynamic scheduling of Task Agents (#31). Workflows need to be explicit, named sequences of tasks scheduled with dependencies, tracking their own state and retrying via a script task. This must stay separated from Bifrost — Bifrost is one of many task sources.

Proposed solution

New agent-4-workflow package (a Workflow Agent, built atop the task interface like agent-3-task):

• A workflow is itself a script task. On run it: computes the ready set, creates draft child tasks, sets dependency edges, promotes ready children to live, persists its own WorkflowState, and returns paused so it is re-yielded as children complete (re-entrancy).
• The scheduler is an orchestrator-side RPC service (tracks workflow state + ready-set); the Workflow Agent drives it via RPC.
• Per-step retry via a script-task wrapper ([feat] Implement Workflow Agent and Interfaces #31 "retries via a script task").
• The orchestrator stays uninvolved in dependency resolution (the task source owns that).

Alternatives considered

• Implicit workflow skeleton (Do start / Do LLM / Do stop) — rejected; explicit named DAG.
• Orchestrator resolves dependencies — rejected; the source owns resolution.
• Couple workflows to Bifrost — rejected; Bifrost is one of many task sources implementing the interface.

Area

Orchestrator v2 / agent-4-workflow (fulfills #31)

Acceptance criteria

• Linear A→B→C: children promoted in order; C runs only after B.
• Diamond A→{B,C}→D: B and C run concurrently where runners allow; D after both.
• A step failing twice then succeeding with maxAttempts: 3 ultimately completes.
• Re-entrancy: after a child completes the workflow is re-yielded and skips already-completed steps.

Dependencies

• [v2] Task source with dependencies + draft/live
• [v2] Thin orchestrator (scheduler RPC)
• [v2] Script task execution primitive
• [v2] Structured output package ([v2] Structured output package: schemas, sentinel files, JSON/YAML validation #41) — validate child Task Agent outputs on the verify dispatch.

Verification

vp test + vitest-gwt: linear ordering, diamond DAG concurrency, retry policy, re-entrancy.

[devzeebo]

We should include a workflow builder pattern. Something like:

const myWorkflow = new Workflow({ name: 'my-workflow' });
runner.registerWorkflowAgent(myWorkflow
  .step(task('some-task'))
  .step(
    task('another'),
    new Workflow({ name: 'inner-workflow' }
      .step(someFn)
      .step(task('next'))
  )
  .step(lastOneFn)
);

task('some-task') represents a step to a level 3 agent
someFn represents a raw script work item

the registerWorkflowAgent function needs to ensure that the tasks are registered (throw if a referenced task is not in the data set), handle registering the script work items automatically (probably as my-workflow:step3[someFn] if possible. reading the name from the function name)

the builder isn't the actual workflow, it's the definition of the workflow. the register will validate it, and then construct an actual agent internally.

we should probably also allow the workflow to hard reference the Task agent's "new Agent" instance in place of task('some-task')

additionally, we should be able to nest workflows. The above example would execute:

some-task => { another, someFn => next } => lastOneFn

The sub-workflow needs to be modified such that it isn't registered as a standalone workflow at all; it is embedded and the handler for those nodes would respond to my-workflow:inner-workflow:step1[someFn] for instance

[devzeebo]

The response from a workflow step should allow only 3 transitions:

Success (go to next step)
Fail (eject, fail the workflow)
Rewind (go to a previous step)

These should be hidden behind the workflow step wrapper. The user doesn't see the scripts that handle this, but need to wrap every task execution