Workflow

Workflow

Not implemented — depends on Subagent and Background Jobs capabilities.

Upstream reference: Workflow

What Upstream Provides

The workflow subsystem enables models to write and execute orchestration scripts that spawn sub-agents in parallel. It has three components:

• WorkflowEngine (ctx.workflowEngine) — executes scripts in a Node.js worker thread, one worker per run. Provides agent(), parallel(), pipeline(), and phase() primitives.
• WorkflowWorkerThread (dsh-workflow-worker-thread) — the Node.js worker_threads execution backend.
• ToolWorkflow (dsh-tool-workflow) — the model-facing tool that accepts a script body and manages run lifecycle.

Scripts return structured results. Fatal errors (schema violations, limit breaches) throw immediately; non-fatal failures (child agent errors) map to null in combinators. Persistent tool-workflow/run-start and tool-workflow/run-end events are written to the parent session log.

Current Edge Status

Not Implemented None of the three workflow packages are in Edge's dependencies. No workflow engine, tool, or execution backend is installed.

Dependencies not yet satisfied

Dependency	Edge Status	Impact
SubagentRuntime	Not implemented	Workflow scripts spawn child agents via agent()
JobRegistry	Not implemented	Workflow runs are tracked as background jobs
worker_threads	Not available	Upstream execution backend uses Node.js workers

What Edge already has

Edge has a precedent for multi-turn agent coordination: GoalRoundDriver already orchestrates autonomous continuation across turns within a single agent. This is a simpler form of the same pattern — sequential steps without parallel fan-out. Workflow adds parallel sub-agent spawning, which requires the full SubagentRuntime.

Cloudflare Enablers

Cloudflare Product	Could Enable	Plan
DO in-process execution	Single-threaded script execution within the DO isolate (no worker_threads)	Free
Cloudflare Containers	Full Node.js worker thread environment for heavy orchestration	Paid / Enterprise
Dynamic Worker dispatch	Spawn child agents as separate Worker invocations coordinated by the DO	Paid

The most viable path for free-tier users is a single-threaded in-DO execution engine that runs workflow scripts synchronously (no real parallelism, but sequential agent() calls work). True parallel fan-out would require either Containers or Dynamic Worker dispatch on paid plans.

Architecture Summary

Component	Category	Status
WorkflowEngine	Missing	Not installed — needs execution backend
ToolWorkflow	Missing	Not installed — needs engine
Execution backend	Missing	worker_threads unavailable; needs DO or Container alternative

Key observation: Workflow is blocked by two missing capabilities (Subagent, Jobs) and one platform gap (worker_threads). It's a compound dependency — implementing it requires solving the underlying pieces first. However, a simplified single-agent sequential workflow could work within Edge's existing GoalRoundDriver pattern without any of these dependencies.

TODO

Evaluate simplified in-DO workflow engine. A single-threaded execution backend that runs inside the DO isolate (without worker_threads) could support sequential workflow scripts. The upstream WorkflowEngine service interface may accept alternative backends. Evaluate whether a DO-internal backend can satisfy the interface without parallel sub-agent support.

Resolve upstream dependencies first. Full workflow support requires Subagent (#subagent) and Background Jobs (#jobs). These should be evaluated independently before attempting workflow integration.