Allow main agents to resume subagent conversations

[itkonen]

This PR allows main agents to reuse subagents and their accumulated context to speed up orchestration. Similar features exist in harnesses such as OpenCode, Codex, and Claude Code. Here, this is implemented by allowing the spawn_agent tool to accept the chat_id of an earlier subagent. When a chat_id is provided, the subagent continues its conversation from where it left off.

This supports several communication patterns. For example, a subagent can request more details from the main agent and return. The main agent can then answer through the task argument, using chat_id to continue that same subagent conversation.

AI summary

Implementation

• Adds optional chat_id to spawn_agent. Calls without it continue to create fresh subagents. agent and task remain required.
• Reuses the existing chat-prompt machinery and retained child history, including tool calls and results. Existing context compaction still applies.
• Preserves the child’s original resolved model and variant. Continuation requires the same agent and does not accept model or variant overrides.
• Returns the reusable ID at the beginning of the tool result so normal output truncation preserves it.
• Resets the step budget for each invocation and extracts its result only from newly appended history, preventing an earlier answer from being returned as the new result.

Ownership and lifecycle safeguards

Continuation is limited to the same parent chat and server session. Invalid, foreign, or unauthorized IDs are rejected without silently creating a fresh child. Changes to configuration, workspace, or trust also require a fresh subagent. History replay checks child ownership before expanding referenced conversations.

Session-local bookkeeping prevents overlapping invocations and waits for prompt workers and tool cleanup to finish. Cancelled or provider-failed runs can be continued once their previous work has settled; active tools or unfinished cleanup still block continuation.

The patch also makes targeted corrections to existing cancellation handling:

• Tool completion is signalled after post-tool and status hooks finish.
• Stopping no longer bypasses the wait for dispatched tools and their cleanup.
• Tool-state callbacks read current state rather than a captured snapshot.

There is no new messaging protocol, scheduler, or dedicated parent-question tool. Fork-aware continuation and persistence across server restarts are outside scope.

Validation

Regression coverage includes retained conversation and tool history, fresh-child behavior, invalid and unauthorized IDs, parameter ordering, model preservation, step-limit continuation, truncated results, transient provider failures, cancellation races, and rejection while old work remains active.

• Full unit suite: 976 tests, 5,974 assertions, zero failures, using an explicit English/US JVM locale because existing numeric-format tests assume decimal points.
• Existing subagent integration tests: 2 tests, 13 assertions, zero failures or errors.
• Changed-file lint, editor diagnostics, and whitespace checks: clean.

🤖 Generated with ECA (openai/gpt-6-astra - xhigh)

[zikajk]

Personally, I think we need this functionality, so thank you for working on it @itkonen.

I do wonder, though, whether a more general orchestration model like the one used by Claude Code or Codex might be better in the long run. Chats and subagents could share the same underlying session model, with agents able to communicate with one another.

(when using Opus, you can sometimes see the main agent give subagents instructions that assume they have access to the main chat's context).

I don’t see any bugs, but some of the code Astra generated feels rather awkward for Clojure. Maybe it would be worth running it through an Anthropic model, but I’ll leave the decision to @ericdallo.

[itkonen]

Thank you for the comment @zikajk!

I also briefly considered more elaborate communication tools, but I came to the conclusion that this simple solution would already allow for quite many communication patterns – although it might require a bit more from the agent instructions, as agents might not figure it out by themselves.

And I must apologize for the Astra code. I've found it almost impossible to force Astra to keep it simple and focus on the main quest, and not create to a plethora of validators and tests. Yet it is quite clever in figuring out solutions to complex problems.

[zikajk]

Totally agree, Astra is smart but not the best worker :-).