Continuable subagents: follow-ups and control

DataMind Oda can hand part of a task to a helper agent, called a subagent, that keeps working in the background and stays reachable after it starts: a continuable subagent. Oda can send it follow-ups, interrupt its current turn, and list the subagents of a chat with their status. This page covers everything after the start; how delegation itself begins is in Delegating work to subagents, and one-shot background runs are in Background subagents and job collection.

How a continuable subagent starts

The delegation call returns the line started subagent <childId>, and the subagent keeps that id: follow-ups, interrupts and list entries are all addressed to it.
A continuable subagent stays tied to the chat that started it. Follow-ups need that chat to be live: when it is not, a follow-up is not delivered.
When its run ends, the chat receives one settlement notice; see Subagent settlement and results.
When the chat is archived, the subagents it started that are still running are stopped; subagents that are not running are left as they are.

Send a follow-up

Oda sends a follow-up with send_message, addressing a direct continuable subagent by its id; a resident subagent may also send a message to its direct parent. Messages travel between neighbours in the tree: down from a parent, or up to a direct parent. A deeper subagent is a candidate for an interrupt, not for a message.

Note

message delivered to agent <agent_id> confirms that the message reached the subagent, nothing more. The call returns no answer from the subagent, only that receipt, and a failure means the message was NOT delivered.

A message to a subagent that is still working reaches it at its nearest step; a message to an inactive subagent starts or resumes a turn.
How a prompt is delivered can be chosen per prompt: queued (it waits, and the subagent takes it up later) or steering (it reaches the subagent at its nearest step). Prompts can also be sent from the app, with the same rules.
A prompt can carry images, but only to a subagent whose model accepts them; otherwise the prompt is refused before anything is delivered.

Interrupt a turn

Oda asks a subagent to stop its current turn with interrupt_agent. The line interrupt requested for agent <agent_id> means the request was accepted; the stop is cooperative, so the subagent may keep running briefly, and the call returns as soon as the request is accepted.
Only a live ancestor can interrupt: the chat that started the subagent, or an ancestor above it in the tree. A caller that is not a live ancestor is refused, for example interrupting "<id>" requires the exact live ancestor agent; a subagent cannot interrupt itself (agent "<id>" cannot interrupt itself), and an unrelated caller is refused too (subagent "<id>" belongs to another parent session, or subagent "<id>" is not a live descendant of agent "<id>").
What survives an interrupt: messages already waiting stay parked until a later message, subagents it started keep running, and the subagent itself stays available for follow-ups.
Interrupting a subagent that already finished is an accepted no-op.
An interrupt can also be requested from the app, and it reaches a live subagent even while the chat that started it is not live.

See a chat's subagents

Oda lists the continuable subagents of a chat with list_agents. Scope children (the default) lists the chat's direct subagents; scope descendants lists the complete tree below in order, adding each entry's place as parent=<id> depth=<n>.
Each entry carries the subagent's id, its status in square brackets, and its label.
running means the subagent is working right now. inactive means no turn is executing, whether it is loaded or must be resumed; it is not a verdict on the work, so it does not say that the subagent finished, succeeded or failed, or that it waits for other subagents.
A direct subagent stays a candidate for a follow-up in every status: a message steers it while it runs, or starts or resumes a turn when it is inactive.
A one-shot background run never appears in the list: it cannot take follow-ups. See Background subagents and job collection.
An entry that cannot be read takes a diagnostic line instead, [diagnostic: <reason>], in the descendants scope only: corrupt means its record cannot be read, and unavailable means it was temporarily unreadable, so a later listing can show it again.
An empty list reads (no subagents).
Reading the list never starts, resumes or changes a subagent: it is a snapshot, not a promise, and a listed subagent can still refuse a follow-up. Use it to recall what was started, not to poll for completion; the chat is told when a subagent settles.
In the app, the subagents of a chat can be browsed: the direct subagents, and the complete tree below them, each with its status.

When a request is refused

When	What appears
A message comes from outside the direct relationship	`message delivery requires the exact live sender agent`
The chat that started the subagent is not live	`direct parent is not live; the message was not delivered`
The subagent is being wound down	`subagent "<id>" activation is being disposed; the message was not delivered`
A message targets a subagent that cannot be resumed	`subagent "<id>" has no supported continuation state and cannot be resumed; choose a different target`
The active-subagent limit is reached	`subagent limit reached (active child limit: <n>); wait for an existing child to finish or complete this work with the current agents`
A start repeats an existing subagent id	`subagent "<id>" already exists`
An image prompt meets a model without image input	`Model "<model>" does not support image input.`
A prompt carries too many images	`Image batch exceeds the configured image-count limit.`

The active-subagent limit is shared across the chat's tree of subagents and defaults to eight; Subagent settings holds it. More failure messages are collected in Subagent failures and diagnostics.

Questions, answered

What can Oda do with a subagent's id?

Everything that happens after the start is addressed to that id: follow-ups, interrupts and the entries in the subagent list. A one-shot background run works differently; see Background subagents and job collection.

Does `message delivered` mean the subagent answered?

No. It confirms that the message reached the subagent, nothing more. The call returns no answer from the subagent, only that receipt, and a failure means the message was NOT delivered. A reply from the subagent, when it sends one, is a separate message.

Why was a follow-up not delivered?

A message goes through only between neighbours in the tree, and only while the chat that started the subagent is live: a caller that is not the exact live sender is refused, a message sent while that chat is not live is not delivered, and a subagent that is being wound down or cannot be resumed refuses the message as well. The exact lines are in the table above.

Can Oda stop a subagent that is still working?

Yes. Oda requests an interrupt for the subagent's current turn, and the line interrupt requested for agent <agent_id> means the request was accepted. The stop is cooperative, so the subagent may keep running briefly. Interrupting a subagent that already finished is an accepted no-op.

Does interrupting a subagent stop the subagents it started?

No. An interrupt stops only the target's current turn. Messages already waiting stay parked for a later message, and subagents it started keep running. The subagent itself stays available for follow-ups.

What happens to messages that were waiting when a subagent is interrupted?

They stay parked: an interrupt does not deliver or discard them. A later message wakes the subagent, and the parked messages are taken up then.

What does `inactive` mean in the subagent list?

No turn is executing for that subagent right now, whether it is loaded or must be resumed. It is not a verdict on the work: it does not say that the subagent finished, succeeded or failed, or that it waits for other subagents. A direct subagent stays a candidate for a follow-up in every status: a message steers it while it runs, or starts or resumes a turn when it is inactive.

Why is a background subagent missing from the list?

The list shows continuable subagents only. A one-shot background run cannot take follow-ups, so it never appears; its result is collected as a job instead, as described in Background subagents and job collection. An entry that cannot be read appears as a diagnostic, not as a subagent.

What is the diagnostic in the list?

In the descendants list, an entry that cannot be read takes a [diagnostic: <reason>] line instead. corrupt means its record cannot be read; unavailable means it was temporarily unreadable, and a later listing can show it again.

Why was an image follow-up refused?

Prompts can carry images only when the subagent's model accepts them; an image prompt to a subagent whose model takes text only is refused before anything is delivered (Model "<model>" does not support image input.), and a prompt that carries too many images is refused as a batch (Image batch exceeds the configured image-count limit.).

What happens to subagents when I archive the chat?

The subagents it started that are still running are stopped; subagents that are not running are left as they are. If one stop fails, the others still stop. Archiving a chat is described in Chat with Oda.

How many subagents can be active at once?

A chat allows a set number of active continuable subagents, shared across its whole tree of subagents and eight by default; Subagent settings holds the limit. At the limit, starting or resuming one is refused with subagent limit reached (active child limit: <n>); wait for an existing child to finish or complete this work with the current agents, and waiting for a subagent to finish frees a place.