[coordination][deferred] Retire the workflow closed enum → declarative behavior

[serge-ivo]

DEFERRED (the larger 'open the vocabulary' frontier). Today capabilities.workflow is a closed enum (JOB_APPLY/CODING_SESSION/INSURANCE_QUOTES) — a creator can only pick one, not define a new autonomous loop. Make durable behavior a declared composition (steps/triggers + a decide-loop) so a new agent type needs no monorepo PR. Pairs with the connector-manifest work (#143) as the second half of making agents fully data. Part of #154; see agent-platform-strategy.md + third-party-agents-plan.md.

[serge-ivo]

Plan refinement (2026-08) — the substrate is emerging. Two durable runners now exist — PipelineRunWorkflow (#97, declarative data pipelines) and CodingSessionWorkflow/Pilot (durable coding objective-runner) — plus the pipeline attach write path (2eb08cd) and the trigger form to start pipelines on cron/webhook (2f55433, #134). These are the same shape: a durable, observable, objective/goal runner.

So retiring the workflow closed enum isn't a from-scratch build — it's converging those two workflows into one declared durable-behavior capability (steps + triggers + a decide-loop), with the pipeline attach/trigger UI as the authoring surface. Pairs with the connector-manifest work (#143) as the second half of "agents as data": tools ✅, connectors ✅, behavior = this. Sequence after coordination #155 proves the delegate→durable-runner path.

[serge-ivo]

Cross-reference: this is the actual blocker on "configure a Coder agent", and it is independent of the supervision work.

Status of the authoring path:

• Wire declarative capabilities (surfaces/runtime/workflow/tools) through create + update — the missing authoring path (#51) #141 (closed) — capabilities (surfaces/runtime/workflow/tools) are validated on create + update, so a Coder-equivalent can be stamped out from config.
• Trust gating before third-party creators may declare runtime/workflow capabilities (gates #141) #142 (open) — trust gating before a creator may declare runtime/workflow.
• This ticket — capabilities.workflow remains a closed enum (JOB_APPLY/CODING_SESSION/INSURANCE_QUOTES) backed by code. You can select Coder's brain; you cannot define one.

So "configurable Coder" decomposes into two independent tracks that can run in parallel:

1. Its behaviour — this ticket (declarative durable loop instead of the enum).
2. Its hierarchy — [coordination] Supervision graph as configured platform data — hierarchy belongs to the platform, not inside an agent #183 supervision as platform data, per docs/supervision.md.

Neither subsumes the other: retiring the enum without supervision gives you a configurable brain with a hardcoded org chart; supervision without the enum gives you a configurable org chart of un-configurable brains.

[serge-ivo]

Reassessment at HEAD (9007758) — the premise has expired; the residual is real but is not "an enum"

Measured, not assumed. Three findings, two of which cut against doing this ticket as written.

1. The ticket's premise is no longer true: a creator CAN define a new autonomous loop today

"a creator can only pick one, not define a new autonomous loop"

workers/api/wrangler.toml has five [[workflows]] bindings. Two of them are not in the enum at all — PIPELINE_RUN and AGENT_LOOP — and both are selected by data:

• AGENT_LOOP is the fallthrough. loop-drivers.ts:246 const DRIVERS = { CODING_SESSION: codingDriver } — one entry. JOB_APPLY, BROWSER_TASK, INSURANCE_QUOTES and null all resolve to chatDriver → env.AGENT_LOOP.create(...). So an agent declaring workflow: null already gets a durable, budgeted, cancellable, escalating loop over its own declared tools[], with a run row a supervisor can read. The enum can only route away from that, to exactly one alternative.
• PIPELINE_RUN is selected by pipeline name from instance config. triggers.ts:306-309 already states this ticket's thesis as shipped fact: "the pipeline is DATA — loaded by name from instance config via startPipelineRun — so adding a new pipeline type never touches the closed workflow capability union."

And there are two existence proofs in the catalog:

• site-builder (migration 0057) — runtime: null, workflow: null, entire behaviour in lib/pipelines/site-builder.json + site-deploy.json, with seed-drift.test.ts pinning both to null.
• portal-watch (migration 0087) — its own seed says it best: "There is no portal-watch code anywhere in the monorepo — no Worker, no pipeline, no slug in a conditional. The agent is this row." Objective, start URL, read-only flag and settings are all data; only the engine is the enum value.

Six of the ten seeded agents declare workflow: null. Non-null is four slugs across three values.

2. The enum's actual decision surface is two tables and a lint — much smaller than when this was written

Complete map of what reading capabilities.workflow decides at HEAD:

site	decides
loop-drivers.ts:254 loopDriverFor	which durable loop the Loop button / start_work / delegate_goal starts. One entry: CODING_SESSION
trigger-capability.ts:56 REQUIREMENTS	whether a run_browse trigger may be wired and a browse run may start. One entry: BROWSER_TASK (#358)
agent-claims-lint.ts:31	whether catalog copy claiming runtime capability is an integrity violation
BoardTab.tsx:104	whether the "Run browser task" control renders
admin.ts, routes/agents.ts, two AgentDetail.tsx	read-back and display

Two negatives worth stating plainly:

• JOB_APPLY gates nothing. startJobApply (instances-apply.ts:189) does requireLiveRuntime + requirePro and creates the workflow; it never resolves capabilities. The declaration is decorative.
• INSURANCE_QUOTES is bound to nothing — no [[workflows]] entry, no Env field, no .create(), no migration seeds it. 1 of 4 members is inert, and the console offers it while omitting BROWSER_TASK, the only value that enforces anything. Filed separately as [bug] The creator's Workflow picker offers a value that is bound to nothing, and omits the only one the platform enforces #375; worth doing whichever way this ticket goes.

So the mechanical answer to "is retiring the enum smaller now?" is yes, much — it is two one-line tables, and loop-drivers.ts:17-19 already nominates itself as the single place that has to learn a new form.

3. And that is exactly why it should not be done — the residual is load-bearing in the #352 way

Being small is not the same as being available. Per #352's finding that sanitizeConnectorManifest rejects the very connector it was meant to absorb, I checked whether the declarative layer can express what the two remaining enum values name. It cannot, and the gap is not a missing step type.

workflows/pipeline-run.ts:90 is for (let i = 0; i < pipeline.steps.length; i++) — a linear walk over a fixed array. There is no back-edge, no conditional jump, and no step.sleep anywhere in the file. ai_generate is the only model-calling step and it writes a field; nothing reads a model verdict to decide whether to run another round. The one human gate that exists — create_ticket → approve → executeTriggerAction → run_pipeline — starts a fresh run; loop-carried state does not survive.

The three brains the enum still names (CodingSessionWorkflow, JobApplyWorkflow, BrowserTaskWorkflow) share three properties, and all three are outside that vocabulary:

1. A model decides each step over a live relay session — decideCodingAction / decideAction / decideBrowserTask inside a bounded round loop, each step reading a snapshot the previous act changed.
2. A mid-run pause that resumes the SAME run. HANDOFF_WAIT_POLLS = 180 × step.sleep(…, "5 seconds") in all three, resuming at the same step with the same in-memory job / transcript / solvedChallengeUrl. coding-session.ts:322 puts the point exactly: the runner probe sleeps through step.sleep "so a ten-minute pause survives the workflow being evicted."
3. Exclusive ownership of a physical resource — a claimed coding_sessions lease with sessionOpenedByRun semantics and mid-run machine-switch reclaim; a single browser page held across the whole run.

The declarative layer can reach the local machine — repo_*, terminal_*, browser_* are ordinary registry tools calling callRunner, and validatePipeline gates on nothing but tool existence. What it cannot do is the loop around them, with a resumable pause. That is the field a manifest has no key for, the same shape as grantModel: "instance-resource" in #352.

So workflow is not really naming a behaviour. It is naming which physical executor the platform must reach, and that the run may park itself mid-flight and come back. Replacing that string with a JSON document does not make either fact declarative; it relocates it.

Recommendation

Reframe, don't retire. The honest remaining frontier is not "kill the enum" — it is "give AGENT_LOOP a declared front", which is a different and much better-shaped ticket: let a creator declare the loop's objective source, its tool set and its decide-prompt, so a new cloud autonomous loop is config. That is genuinely reachable, because AGENT_LOOP already has the loop, the budget, the cancel, the escalation ladder and the run row; it is missing only a declaration surface. portal-watch shows how close this is — it is one pipelineRef-shaped field away from needing no enum value at all.

The two runtime brains would stay a closed set, and that is the correct answer, not a compromise: they are Tier 0 in agent-platform-strategy.md, they hold an exclusive lease on the owner's machine, and #142 (still open) says a creator should not be able to declare runtime/workflow without trust gating anyway. Retiring the enum before #142 lands would widen the very field #142 exists to narrow.

Concretely, I'd suggest:

1. Do now, cheaply: [bug] The creator's Workflow picker offers a value that is bound to nothing, and omits the only one the platform enforces #375 — drop the dead member, add the live one. Two-line tables are only reasonable-sized if their contents are true.
2. Retitle this ticket to "declarative front for AGENT_LOOP", or close it and open that, keeping this one's analysis as the reason.
3. Do not convert CODING_SESSION / BROWSER_TASK / JOB_APPLY to a manifest. create_ticket → approve → run_pipeline is the platform's human gate and it is a re-entry, not a pause; until the declarative layer has a resumable wait, a manifest for these three would either lie or be unusable — the same two outcomes [design] Stage 2: register the generic connector OAuth redirect for Drive/WorkDrive/Gmail and retire the dedicated flows (Stage 1 — the registry declaration — has shipped) #352 found.

Happy to be argued out of (3) if someone wants to add a wait/resume primitive to the pipeline runner first — that is the change that would actually make the enum retirable, and it is worth its own ticket rather than being smuggled in under this one.