Sub-agent Plugin
The bundled subagent plugin lets Elowen delegate work to child conversations, or run several child tasks as a workflow. For how to use delegation and follow results, see Sub-agents & Workflows.
Agents page
Open Agents in the web interface to browse built-in and custom agent types. Administrators can add, edit and delete custom types. Each type has a name in lowercase kebab-case, a one-line description that helps Elowen decide when to use it, instructions and a tool-access mode: read-only, full tools, inherited tools or a custom comma-separated list. Built-in types cannot be edited. The catalog is readable by every authenticated account, but only administrators can change it.
The page also lets you choose a model for each built-in type for your own delegations. Automatic leaves model selection to Elowen. These model choices are per-account. Editing an agent type requests a daemon restart before new conversations use the updated catalog. For example, an administrator might add a code-reviewer type with a one-line description, review instructions and the Read, Search, Bash tool list.
The plugin adds no slash command. The /workflow prompt command is core behavior, described on Sub-agents & Workflows.
Delegation and workflow tools
| Tool | Purpose |
|---|---|
Delegate | Starts one child task. By default, the result arrives in a later turn. |
DelegateStatus | Takes a one-time snapshot of a running child's state, tool count, token use and current activity. It does not wait. |
DelegateResult | Reads the final text or error of a finished child. |
DelegateModels | Lists available model and reasoning-level choices. |
DelegateList / DelegateRead | Lists this conversation's children or reads a result in pages. The list shows 20 by default. |
DelegateContinue / DelegateStop | Continues a child with its existing context, or stops it and its descendants. |
WorkflowStart | Starts a workflow from a JSON file. |
WorkflowStatus / WorkflowResume / WorkflowStop | Checks a workflow, resumes unfinished work, or stops it. |
WorkflowAddNodes | Adds tasks to a running workflow. |
Pass background: false to Delegate or WorkflowStart to wait for results. Otherwise, work is asynchronous and the result is delivered later. A follow-up to a running child steers its current work; it does not start a separate reply. Don't poll for work that will deliver its result on its own; use DelegateStatus for a one-time progress check or DelegateResult if a delivery was missed. A child continues in its existing context when resumed.
Limit a child’s access
A child cannot receive more access than the caller. You can narrow its tools with read_only, tools or subagent_type, and choose a configured model or thinkingLevel. read_only removes write and edit tools and restricts shell commands, but shell redirection can still write files, so it is not a security sandbox.
The built-in explore type is read-only. plan and review inherit the caller's tools but do not change a repository: plan writes only the plan file the caller names, and review reports findings without editing anything. The read-only shell is a guardrail, not a security sandbox: redirection can still write files. A caller can resume its own read-only child with broader access through DelegateContinue, subject to the caller's current permissions. The child also inherits the caller's model, reasoning level and working directory unless the delegation selects otherwise.
With fork: true, a child inherits the current conversation's prompt, tools and history. The task becomes a directive, not a separate briefing. A fork cannot be combined with tools, read_only, subagent_type, or a different working directory (cwd); it keeps the caller's exact toolset. A different model or thinkingLevel is allowed but gives up the shared prompt cache that makes a fork cheap, so prefer the caller's own model. Forks are available only from an owner conversation.
A typed role such as explore or a custom type chooses a saved prompt and tool mode. You can also pass an exact tools list from the caller's tools. An empty list is rejected. DelegateModels shows valid provider/model choices and supported reasoning levels. To wait instead of receiving a later result, use background: false; a child that has no conversation to deliver into waits by default.
Run a workflow
Write a JSON file before calling WorkflowStart, then pass its path. A workflow is either an array of nodes or an object with a nodes array and optional title, fork and background. Each node needs a unique id and a self-contained task; optional dependencies determine which results it receives. Independent nodes can run in parallel.
A node receives a short handover from each direct dependency, not the full context of every earlier node. The node should end with a ## Handover section; without one, the workflow passes the end of its result. Each handover is limited to 4,000 characters. Put any information a later task needs in the dependency chain. Nodes whose dependencies fail are skipped. A workflow can have up to 64 nodes; each task is limited to 4,000 characters and each id to 64 characters. Up to 16 workflows can run at once. A node may also 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.
For example, a workflow can ask one node to inspect a bug and make a second node wait for its findings before writing a test. Give the second node the first one's id in deps; it receives that node's handover, not the full conversation.
Settings and limits
In Settings → Plugins, open the bundled subagent plugin to set:
| Setting | Default | Range |
|---|---|---|
| Result retention | 1 hour | 10 minutes–24 hours, in 10-minute steps |
| Stall timeout | 60 minutes | 5 minutes–4 hours |
Retention controls how long finished background results remain available; the default one hour applies to workflows as well as background delegations. The stall timeout interrupts a child with no tool or step activity; continue it with DelegateContinue. It is a safety limit for stuck work, so increase it for a long analysis that pauses without using tools. Saving these settings or enabling or disabling the plugin requests an Elowen restart, announced as Restart. The new values apply after the restart.
The plugin can have up to 64 foreground or background delegations in progress; when full, a new child is refused until one finishes. A finished child can be continued after a daemon restart, but live progress is no longer available. A workflow can add nodes only while it is running; resume retries only unfinished nodes and keeps completed nodes. A workflow can have up to 16 running workflows per instance. If a daemon restart interrupts a workflow, Elowen recovers it from its saved journal: completed nodes stay complete and unfinished nodes are retried, subject to current access checks. If recovery cannot verify access or the journal is unavailable, it cannot resume the workflow. A workflow result remains available while retained. A stored child error is clipped to 100,000 characters from the start; a long successful result stays recoverable through DelegateRead, which returns at most 50,000 characters per call, 8,000 by default.
Permissions
Enabling the plugin requests consent for its workflow-dag capability. If consent is declined, the plugin stays installed but disabled. Administrators can set per-account model choices for built-in agents and manage the custom agent catalog; all accounts can view the Agents page. Normal account tool permissions and model restrictions still apply. Workflow nodes inherit the adding caller's access and cannot widen it.