DataMind Oda can hand part of a task to a helper agent, called a subagent. Where a subagent runs and what a delegation can ask for depend on the delegation backend behind it. This page compares the backends and covers what it takes to enable one. How delegation itself works is in Delegating work to subagents.
What a delegation backend decides
Two things vary between the backends:
Where the subagent runs. Some backends run subagents inside the app; others start a process of their own for each run.
What a delegation can ask for. A model of its own and the extra child options are available only where the backend supports them.
Every backend reaches the model through a delegation tool. One tool targets one backend, and each tool carries its own name.
The backends at a glance
Backend
Where the subagent runs
It starts from
A model of its own
Extra child options
Fresh in-process
Inside the app
Nothing; a new subagent
Yes
Yes
Seeded in-process
Inside the app
The chat's completed turns
Keeps the chat's model
Yes
SDK
Its own process
A fresh, separate session
Yes
No
ACP
Its own process
A fresh external agent
No
No
Claude Code
Its own process
A fresh unattended session
No
No
Codex
Its own process
A fresh unattended session
No
No
A model of its own means a delegation can choose the subagent's model and reasoning effort; Choosing the model for a subagent covers the choice.
The extra child options are a structured result, a tool filter, a persona and a depth limit. Where a backend answers No, a delegation that asks for one is refused before the subagent starts, instead of being quietly dropped.
Each backend that runs in its own process starts one fresh process for every run.
Choose a backend
Fresh in-process for a self-contained task. The subagent starts empty, sees no part of the chat's history, and runs inside the app.
Seeded in-process when the subagent must already know what the chat has done. It starts from the chat's completed turns; the turn in progress is never included, and before the chat's first completed turn it starts like a fresh subagent. The history is taken once, when the subagent starts. Its tools keep the chat's model.
SDK when the subagent should run on its own, as a separate process with its own session and the model you give it.
ACP, Claude Code or Codex when the work belongs to an outside agent or a coding-agent product. These run one task per run and return a final answer, or a safe failure diagnostic; Subagent failures and diagnostics collects their failure messages.
Several backends can be available at once, and each delegation tool targets one of them.
Enable a backend
Install the backend's bundle. The Plugins page installs plugin bundles, and extra bundles can also be added from a command line; Plugins and bundles has the steps.
Add a delegation tool for the backend, with its own tool name. The default name is subagent; backends use names such as subagent_claude_code or subagent_codex.
Installing a bundle only makes the backend available to Oda. It does not give the model access to it: the model reaches a backend only through a delegation tool added for it.
Configuration checks
Setting up a backend runs its checks before anything can start:
A working directory must resolve. A configured one wins; otherwise the subagent inherits the chat's directory. An empty value is refused with config cwd must not be empty, and a subagent left without any directory does not start: no working directory for the child.
Its timing values must be positive numbers, within the allowed maximum.
Configured files must exist, and a configured home path must be absolute.
Adding and removing backends
Backend names are unique. A second backend cannot reuse a name; the add is refused: a subagent provider named "<name>" is already registered. Delegation tools also need distinct names.
An add that fails halfway rolls back, and nothing half-added is left behind.
Removing a backend blocks new delegations to it, but it never stops a run that was already accepted. Its delegation tool goes away with it.
Permissions in delegated runs
Delegated runs are unattended: they cannot ask a person for approval.
The ACP backend takes a permission policy of allow or reject, and rejects by default. What the policy decides is recorded inside the run.
The Claude Code and Codex backends take their own permission modes; their pages describe them.
The ACP, Claude Code and Codex backends start one-shot subagents: one task per run, and no follow-up messages in that run.
A run in its own process is not stopped by a clock: it ends when it finishes, fails, or is stopped.
Stopping a run does not undo changes the subagent already made on the computer. Its report is the record of what it did.
Messaging works only between a parent and its direct children, and only while both sides are live; nothing waits for a chat that is not live. Continuable subagents covers messaging and interrupts.
Questions, answered
Which delegation backend should I choose?
Fresh in-process for a self-contained task; seeded in-process when the subagent needs the chat's completed turns; SDK when it should run as a separate process with its own model; ACP, Claude Code or Codex when an outside agent or a coding-agent product should do the work, one task per run. The table above compares them.
Where do I install a backend's bundle?
On the Plugins page, which installs and manages plugin bundles; extra bundles can also be added from a command line. See Plugins and bundles.
Why can the model not delegate to my new backend?
Installing a bundle makes the backend available to Oda, but the model reaches a backend only through a delegation tool added for it. Add the tool, with its own unique name, and the model can delegate to it.
Which backends let a delegation choose the subagent's model?
The in-process backends and the SDK backend support it; ACP, Claude Code and Codex refuse the request before the run starts. The seeded in-process tools keep the chat's model. See Choosing the model for a subagent.
What happens when a delegation asks for something the backend does not support?
It is refused before anything starts, so no partial run is left behind. A delegation tool configured for an option its backend does not offer is refused as well.
Can two backends share a name?
No. A second backend cannot reuse a name, and the add is refused: a subagent provider named "<name>" is already registered. Delegation tools also need distinct names.
What happens to a running subagent when its backend is removed?
The run keeps going: removing a backend blocks new delegations to it, but never stops a run that was already accepted. The backend's delegation tool goes away with it.
What working directory does a delegated subagent get?
The one configured for the backend; otherwise the subagent inherits the chat's directory. An empty value is refused (config cwd must not be empty), and with no directory at all the subagent does not start (no working directory for the child).
Do the backends handle permissions differently?
Yes. ACP takes a policy of allow or reject and rejects by default; Claude Code and Codex take their own permission modes. In every backend the run is unattended, so it cannot ask you for approval, and the decisions are recorded inside the run. See Subagent permissions and sandboxing.
Is a stopped run's work undone?
No. Stopping a run does not undo changes the subagent already made on your computer; check what the run reports it did.