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 :-).

[ericdallo]

I wonder if this is already enough for agents to use this and continue how your tests went?

[ericdallo]

Looks good overall, can you fix conflicts so I take a final look pls?

[zikajk]

@ericdallo @itkonen I will do it (as a new commit), I hope you don't mind.

[zikajk]

@itkonen I merged master and put all my changes in one commit on top of yours. Its message lists every change. The main ones: I dropped the config/trust check (it blocked continuing after config changes), and model/variant are now allowed on continue.

Could you test it with a real model? Mainly: a subagent returns a request for clarification, the parent asks the user, then continues the same subagent with the answer. Also test continuation after maxSteps/timeout and after a stop.

One open problem: after an ECA restart, the parent still sees the old chat_id in its history, but continuing it is rejected. Could you check how big a problem this is in practice, e.g. does it confuse the model, or does it just spawn a new subagent? I still plan to do a follow-up though. It doesn't look like a big change (although I can see us throwing away a lot of code if we start working on Agent Swarm)

@ericdallo You might want to take a look, there are some bigger changes.

[itkonen]

Thanks, @zikajk, for cleaning this up and making the implementation more robust!

I built the PR branch at 40de443 and ran the live-model tests using the resulting ECA server in Emacs. All the scenarios we tested passed, and I didn’t encounter any user-visible problems with the continuation and recovery flows. Thanks again for the improvements.

Below is an AI-assisted summary of the setup, tests, and evidence.

Test setup

• Commit: 40de4432893ba8c856a9651b394ed2bba27f390e
• Build: bb debug-cli; reported version 0.163.0
• Environment: Linux, Java 21, Emacs 31.1
• Subagent model: openai/gpt-6-astra; no explicit model or variant overrides
• Method: Real model calls through the normal spawn_agent tool. Stop was triggered manually in Emacs, and the server was manually restarted. Read-only nREPL inspection supplemented the visible results; it was not used to force state transitions or reset budgets.

No implementation changes were made during validation. Temporary test-agent configurations were removed afterward.

Live-model results

Scenario	Test and observed result
Clarification round-trip	The child requested a choice, the parent asked the user, and the same child resumed with only the answer. It retained the original instructions and evidence marker and successfully made fresh tool calls. Passed.
Continuation after maxSteps	A child with maxSteps: 2 was given two sequential source lookups. The first succeeded; the second attempt triggered Halted and a no-tools summary. Continuing the same child, without raising its budget, completed the remaining lookup. Live state confirmed that the limit/summary flags were cleared and the new run’s step count was 1. Passed.
Continuation after timeout	A child with timeoutSeconds: 45 ran foreground sleep 90, with a longer shell-tool timeout. The agent timeout interrupted the running shell command. After cancellation settled, the same child resumed, read the remaining file, and returned its original evidence marker without repeating the delay. Passed.
Continuation after Stop	The user pressed Emacs’s normal Stop control while another child was running foreground sleep 90. The shell call was interrupted after approximately five seconds, well before either timeout. On the next parent turn, the same child resumed and completed the remaining file read with its original context intact. Passed.
Recovery after server restart	A completed explorer child provided a baseline before restart. After restarting the server and restoring the same parent conversation, continuation with the old ID was rejected with instructions to omit chat_id and spawn a new child. A fresh child received an explicit handoff, successfully reread the relevant files, and confirmed the baseline. Passed.

For timeout and Stop, live inspection showed settled child workers and cleared tool resources before continuation; no matching delay process remained. The resumed runs completed without repeating the interrupted work.

The restart test confirmed a changed server PID and an unchanged parent chat ID. The old child’s saved history was still present, but its live management record was absent. The fresh child correctly attributed its prior context to the parent’s handoff rather than claiming retained memory.

Recorded message ranges were also separate for the initial and continued invocations.

Automated checks

These passed on the tested checkout:

• clojure -M:test --focus eca.features.tools.agent-test --focus eca.features.chat-test
  127 tests, 882 assertions, 0 failures
• bb integration-test --dev --ns integration.chat.subagent-test
  3 tests, 21 assertions, 0 failures or errors

Observations and scope

• The step-limit test left the blocked tool attempt marked :preparing in internal state. It did not prevent continuation, was absent from the recorded replay ranges, and no stuck tool card was visible in Emacs.
• Newly created test agents required a new parent turn before they were callable. Both interruption-test agents were configured to inherit directly from explorer, after checking that chained inheritance did not preserve all of its settings in the initial test setup.
• These were deliberately scripted smoke tests on one model. They demonstrate the exercised continuation and recovery paths, not exhaustive provider/race-condition coverage or reliable unprompted orchestration.
• Explicit model/variant overrides and broader configuration/trust changes were not live-tested.

Overall: all five planned live-model scenarios passed on this revision, with no blocking issue found in the tested flows.