Subagent backends
When Oda hands part of a task to a helper agent, called a subagent, a backend runs that helper. Backends differ in where the helper runs, what a delegation can ask for, and how the run reports back. How delegation itself works is in Subagents.
What a backend is
- A backend is what runs a helper: a delegation target set up for your DataMind installation. Choosing and enabling a delegation backend covers how one is enabled and turned into a tool a chat can use.
- Each backend is reached through its own delegation tool, and each tool carries its own name. A chat can hold several tools at once, so several backends can be in play in the same chat.
- Backends come in two kinds: helpers that run inside Oda itself, and helpers that run as separate agent programs in their own process.
Where a helper runs
- In the app. A fresh in-process helper starts from nothing and runs inside Oda itself. A seeded in-process helper starts from the chat's completed turns instead: it begins knowing what the chat has done. The turn in progress is never included, and the history is taken once, at the moment the helper starts.
- In its own process. A helper on one of these backends runs as a separate agent program, and every run starts one fresh process of its own.
Whichever kind the chat uses, the chat stays the owner of the task: it reads the helper's result and decides how to carry on.
What each backend can be asked for
| Backend | Where the helper runs | It starts from | A model of its own | Extra child options |
|---|
| Fresh in-process | Inside Oda | Nothing; a new helper | Yes | Yes |
| Seeded in-process | Inside Oda | The chat's completed turns | Keeps the chat's model | Yes |
| SDK | Its own process | A fresh, separate session | Yes | No |
| ACP, Claude Code, Codex | Its own process | A fresh agent of their own | No | No |
- A model of its own means a delegation can choose the helper'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 does not offer something, a delegation that asks for it is refused before the helper starts, instead of starting and quietly dropping the option.
Runs that cannot ask you anything
- A delegated run never brings a question to you. It runs while you may be away, so anything that would need a person is answered mechanically or refused, never queued for you.
- An in-app helper runs with approval pinned off: a step that would need your answer is rejected automatically.
- A backend that runs an agent program of its own answers such requests inside that program, from its own permission settings. Those settings range from denying everything and accepting edits to planning only and bypassing checks; the ACP, Claude Code and Codex pages list their values.
- Every helper is told at its start that its permission scope
was fixed when you were started and cannot be widened from inside this session, and that when access is missing it should report the limit in its reply instead of retrying. The limit then comes back to your chat, which can handle the step.
- What a helper may reach is settled when it starts. Subagent permissions and sandboxing covers how it is taken from the chat, and Workspaces, files and permissions covers the access modes.
When a run ends early
- A run that does not complete brings back a headline, a
Diagnostic: line, and the text the helper produced before it ended.
- The diagnostic names where the run stopped and what kind of problem it was. The shape is the same on every backend; the values differ, and Subagent failures and diagnostics lists them.
- Behind every ending sits a stop reason: the run completed, it was stopped, it hit its token limit, it declined the task, or it failed.
- A run stopped while its helper 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 helper's input first and gives it a short grace to finish writing; only then does it terminate the helper.
Structured results
- A backend that supports it can be asked for a structured result: the helper closes its run by recording one result that matches the requested schema.
- The helper 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: structured output already recorded: the run is complete.
- A schema outside the supported set is refused before a helper starts, with
unsupported JSON schema.
- Structured subagent output covers the tool, the schema's limits and the runs that end without a result.
Limits of the separate-process backends
- One fresh process per run: nothing is pooled or reused between runs.
- The ACP, Claude Code and Codex backends take one task per run, with no follow-up messages in that run. Messaging for helpers that accept follow-ups is in Continuable subagents.
- No clock: a run is not stopped by a time limit. It ends when it finishes, when it is stopped, or when it fails; reaching its token limit also ends it.
- No rollback: stopping a run does not undo changes the helper already made on your computer.
- The settings fixed for your installation bound delegation, such as how deep helpers may nest and how many may run at once; see Subagent limits.
Questions, answered
Why do two subagents behave differently in the same chat?
Each runs on a different backend. Backends differ in where the helper runs, what a delegation can ask for, and how the run reports back: one backend starts a helper 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.
Where does a subagent actually run?
It depends on the backend. In-app helpers run inside Oda and share what Oda has running; a separate-process backend runs the helper as its own program, one fresh process per run.
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 helper, and which tools a chat can use comes from how it is set up, not from that step. Choosing and enabling a delegation backend covers the setup.
Can more than one backend be available at once?
Yes. Several backends can be set up together, each with its own delegation tool, and a chat can hold several of those tools at once. One tool targets one backend.
Does a delegated run stop on its own after a while?
Not by a clock. It ends when it finishes, when it is stopped, or when it fails, and reaching its token limit also ends it.
Can a backend ask me something while it runs?
No. Delegated runs are unattended: an in-app helper has approval pinned off, and a backend that runs an agent program of its own answers such requests from its own permission settings. Nothing reaches you; a step that would need your answer is refused instead of waiting for one.
Do all backends report failures the same way?
The shape is the same: a headline, a Diagnostic: line, and any partial text the helper produced. The detail differs per backend; Subagent failures and diagnostics lists each backend's stages and categories.