DataMind Oda can hand part of a task to a subagent that runs in the background. The subagent keeps working while the chat carries on, and its result is collected later as a job. This page covers how such a run starts, how its output is collected, and how it is stopped.
When Oda delegates work to a background subagent, the delegation call returns at once with the line started background subagent job <id>, and the run keeps going while the chat carries on.
started subagent <childId>, and reports back on its own; see Continuable subagents.run_in_background is disabled for this tool instance (enableRunInBackground: false).The delegation call itself, its description and prompt fields, and how a run that waits returns its result are in Delegating work to subagents.
Oda reads a background run with its job tools: job_output returns a job's output, and job_list shows the jobs of the chat. A background job belongs to the chat that started it, and it is read from there.
A finished run reads as the subagent's final text followed by one status line:
[status: completed]: the run finished; the text above the line is the subagent's final answer.[status: failed, <stop reason>; diagnostic: <text>]: the run ended with a problem; the line carries the run's stop reason and a diagnostic.[status: killed, <reason>]: the run was stopped from the chat; the text after the comma is the reason given when it was stopped.Around those lines:
(no new output) with the final status.; dispose failed: <error>.Until the job is read, its output lives only in the job's record; nothing about it reaches the chat on its own. For the job list and the activity monitor in the app, see Background runs and jobs.
To stop a run before it finishes, Oda stops its job with job_kill. The stop takes a short reason; when none is given, the reason is background subagent task killed. A stopped job then reads as killed with that reason, for example [status: killed, no longer needed].
When a run instead ends with a problem of its own, it reads as failed. Subagent failures and diagnostics collects the messages a run can produce and what they mean.
A delegation tool starts one of two shapes, and each brings its result back a different way:
started background subagent job <id>, and its result is collected from a job with the job tools. It takes no follow-up messages.started subagent <childId>, accepts follow-up messages and interrupts, and reports back with a single settlement notice when its run ends. See Continuable subagents.The default shape is one-shot, and the background mode is set per delegation tool; Subagent settings covers the limits around it. How a continuable subagent reports its outcome is in Subagent settlement and results.
As a job. Oda reads the job with job_output, and a finished run returns the subagent's final text with [status: completed]. The result does not come back through the delegation call that started the run.
It stays in the job's record in the chat that started it, and nothing about it reaches the chat on its own. When the job is read, the output is delivered once; a later read reports (no new output) with the final status.
When the run ends with a problem instead of finishing. The line carries the run's stop reason and a diagnostic, in the form [status: failed, <stop reason>; diagnostic: <text>]. If cleaning up after the failure also fails, the line adds ; dispose failed: <error>.
Because it was cancelled from the chat, not ended by a problem inside the run. A killed line carries the reason given when it was stopped, like [status: killed, no longer needed], and no diagnostic. A run that ends with a problem of its own reads as failed.
Yes. Oda stops its job with job_kill, which takes a short reason; when none is given, the reason is background subagent task killed. The job then reads as killed with that reason.
No. A one-shot background run returns a job that Oda collects with the job tools; a continuable subagent returns only its id and reports back with a single settlement notice. See Continuable subagents.
Background runs are switched off for the delegation tool. The option is not offered on the call, and a call that still asks for one is refused with run_in_background is disabled for this tool instance (enableRunInBackground: false).
(no new output) mean?The job's output was already delivered. A later read repeats the final status line and adds nothing, so the output is never delivered twice.