Delegation and workflow parameters

This page is the argument reference for the bundled Sub-agent plugin's Delegate, DelegateContinue and workflow node fields. Runtime behaviour, delivery authority and recovery live in the subagent runtime module page; the user-facing guide is Sub-agent Plugin.

Access arguments

• read_only removes the write and edit tools and restricts shell commands. Shell redirection can still write files, so it is a guardrail, not a security sandbox.
• tools takes an exact list from the caller's tools; an empty list is rejected.
• subagent_type selects a saved prompt and tool mode from the catalog: explore and plan are read-only, review inherits the caller's tools and changes nothing.
• write_access: true on DelegateContinue lifts a read-only child the caller started into full write mode with the caller's current access. It is refused while the child is mid-turn, and when the child was read-only by its type or by a plan-mode caller.

No argument can widen the caller's own permissions, grants or scope.

Model and reasoning resolution

DelegateModels lists valid provider/model choices and supported reasoning levels. A model matches a full provider/model first, so a relay model whose own id looks like meta/<model> never shadows the meta provider. A bare model id resolves only when exactly one provider offers it; several providers are refused with the qualified choices.

A child inherits the caller's model and reasoning level unless the delegation selects otherwise. DelegateContinue also accepts a model for the follow-up.

Working directory

An absolute cwd runs a child or a workflow node in a chosen directory. A host-capable administrator may choose any existing readable host directory, including another registered project or a linked Git worktree; scoped callers stay inside their selected project, and managed children stay inside their own container.

The chosen directory survives continuation and restart, an unavailable directory is refused, a linked worktree uses its own project instructions, and the caller's permission ceiling still applies.

Fork arguments

With fork: true, a child inherits the current conversation's prompt, tools and history, and the task becomes a directive rather than a separate briefing. A fork cannot be combined with tools, read_only, subagent_type or any cwd, because it keeps the caller's exact toolset.

A different model or thinkingLevel is allowed, but it gives up the shared prompt cache that makes a fork cheap, so the caller's own model is usually the better choice. Forks are available only from an owner conversation.

Share conversation context, under the assistant's Limits and connection retries, makes forking the default for any delegation that leaves fork out; an explicit fork on a call still decides.

Workflow node fields and caps

A node may set its own model, thinkingLevel, tools, read_only, subagent_type, fork and absolute cwd. An explicit empty tools list is rejected, and a fork cannot be combined with a narrower tool mode or a different working directory.

A workflow accepts up to 128 nodes, each task up to 16,000 characters (a longer task is rejected rather than cut) and each id up to 64 characters. Missing dependencies, cycles and duplicate ids are refused. Up to 16 workflows run at once, and a workflow can add nodes only while it is running.

Retention and result sizes

The pure root apiContract.mjs declares all nine authenticated root API routes. Registrations spread those descriptors, and request handlers use their exact Zod body/query/path schema instances lazily. The owner model/detach parsers run after linked-account/provider admission; unknown JSON-object fields, incomplete client bindings and model normalization keep their existing behavior. Definitions remain administrator-owned files with built-in immutability and save-then-restart semantics. The definition-save wire body stays arbitrary JSON because name, directory and built-in checks precede domain content validation.

The child-view send route remains refusal-only, even for malformed JSON, before any body parsing. Workflow stop retains its JSON-before-owner boundary; result reads still prove workflow and parent ownership before reading durable text. Their wire/query schemas do not invent a parent-turn identity or replace DelegateContinue. JSON responses and existing 400/403/404/409/500/503 envelopes remain intact; no new credential approval is introduced. Importing declarations performs no I/O. The child model picker, agent settings and workflow rail are actual consumers; absent runtime state remains unavailable/not found, never a fabricated successful result.

A call's result includes every settled final reply in that call, in order, with blank lines between non-empty replies. Job and helper wake addenda do not replace the original report. The same journal reader serves live completion, DelegateRead, workflow outputs and restart recovery. A new idle continuation starts a separate call; a steer accepted while the call remains open stays inside it.

Result retention defaults to one hour and applies to workflows as well as to background delegations; the stall watchdog, stallMinutes, defaults to 60 minutes and interrupts a child with no tool or step activity. Both are plugin settings in elowen-plugin.json and the sole owners of those bounds.

The plugin runs up to 64 delegations in progress. A stored child error is clipped to 100,000 characters from the start.

A long successful result stays readable through DelegateRead, which returns at most 50,000 characters per call, 8,000 by default; DelegateList shows 20 children unless told otherwise.

Large child results and workflow summaries share the general tool-output inline limit. Above it the child gets a preview with the original byte count and a file path, and a failed save reports an explicit error with a DelegateRead recovery hint instead of cutting the answer.