Typically the child will just run, and the parent needs to check back in on the child when it’s done. Potentially we might want to fix this though, so that the parent automatically gets a message when the child completes.

✅ Done! Here's what the two repos actually say. 1. TaskTool (software-agent-sdk) — returned automatically, because it's blocking The Task tool is synchronous, so there's no "push" involved: the parent's tool call is the wait.

TaskExecutor.__call__

calls

TaskManager.start_task(...)

, which runs the child

LocalConversation

to completion (

_run_task

→

send_message

→

run()

→

_run_until_finished

) and blocks until it reaches

FINISHED

. The child's final response is then extracted with

get_agent_final_response(events)

— the last

FinishAction.message

or the last agent

MessageEvent

— and handed straight back to the parent inside the

TaskObservation

(or as an error/partial result if it stopped for a run limit, stuck, etc.). The parent doesn't query anything; it receives the result as the return value of its own tool call in the same turn. The child conversation itself is persisted (under the parent's

subagents/

dir, or a temp dir), and

resume=task_id

re-runs it blocking again. So for TaskTool (and the sibling Delegate tool `spawn`/`delegate`, same blocking pattern) the answer is: always, by construction. 2. Canvas child conversations (

launch_child_conversation

) — only a launch receipt comes back, not the result This path is deliberately fire-and-forget. The tool description in the Canvas repo is explicit: "The child runs on its own. It does not block you, you do not see its output, and it cannot see this conversation's history." What is posted back to the parent automatically is a launch acknowledgement, and it happens at launch time — not completion.

launch_child_conversation

is a client-side tool, so the agent-server acks the call immediately; the frontend then does the real work and posts a machine message

[child-conversation] {"status":"launched","conversation_id":…,"url":…,"initial_status":…}

into the parent (

reportLaunchResult

→

sendMessage

). That's the child's id/URL/initial status, not its final answer. When the child later finishes, nothing forwards its result into the parent. The parent/child relationship is persisted server-side (

parent_conversation_id

→ the parent's

sub_conversation_ids

, added in software-agent-sdk #4188 / agent-server ≥ 1.37.1), but that link is used for discovery, recovery and deletion bookkeeping — not message delivery. There's no completion hook that injects the child's final message into the parent. To get the child's output the parent has to explicitly check back in on that conversation id (or a human relays it). So Graham is right, and the docs' "its result is returned to the parent conversation" is misleading — it's really just the link/record that's returned. The one time it appeared to work was almost certainly the model (or you) going back and reading the child's conversation after the receipt, not a deterministic handoff. The tool-parser config can affect whether the model chooses to poll the child, but it can't create a delivery that the code never performs. Practical takeaway: if you need a child's result delivered to the parent, use the SDK Task tool (blocking, result in the observation). If you're using Canvas child conversations, treat them as independent and have the parent explicitly read the child's conversation when you need its output. This reply was drafted by an AI agent (OpenHands) on behalf of the user.