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. Whichever backend runs a subagent, the chat stays the owner of the task: it reads the subagent's result and decides how to carry on.
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; Choose models for Subagents 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. Anything that would need a person is answered mechanically or refused, never queued for you.
An in-app subagent runs with approval pinned off: a step that would need your answer is rejected automatically.
Every subagent is told at its start that its permission scope was fixed when it started and cannot be widened from inside its session, and that when access is missing it should state the limit in its reply instead of retrying. The limit then comes back to your chat, which can handle the step.
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.
A run that does not complete brings back a headline, a Diagnostic: line, and the text the subagent produced before it ended. The shape is the same on every backend; the values differ, and Subagent failures and diagnostics lists them.
A run stopped while its subagent is still starting leaves nothing behind: nothing half-started keeps running, and one line names where it was stopped.
Ending a run is orderly. Oda closes the subagent's input first and gives it a short grace to finish writing; only then does it terminate the subagent.
Structured results
A backend that supports it can be asked for a structured result: the subagent closes its run by recording one result that matches the requested schema.
The subagent is told to call the tool exactly once and to finish with it, because only the tool call counts as your result; a plain closing message is not accepted as the answer. A second call is refused with structured output already recorded: the run is complete.
A schema outside the supported set is refused before a subagent starts, with unsupported JSON schema.
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, and reaching its token limit also ends it. Nothing is pooled or reused between runs.
The settings fixed for your installation bound delegation, such as how deep subagents may nest and how many may run at once; see Subagent settings.
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.
Why do two subagents behave differently in the same chat?
Each runs on a different backend. One backend starts a subagent from nothing, another from the chat's completed turns, and a separate-process backend starts a fresh process for every run. The table above compares them.
Can I choose the backend for a piece of work?
Not directly for a single step. Oda picks the delegation tool when it hands work to a subagent, and which tools a chat can use comes from how it is set up, not from that step.
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 Choose models for Subagents.
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.