[Feature] Utilize session resumption (task_id) to preserve subagent context across multiple delegations

[alvinreal]

Summary

OpenCode's task tool supports session resumption via task_id, allowing the orchestrator to call the same subagent session again with full context preservation. Currently, oh-my-opencode-slim spawns fresh subagent sessions for each delegation, losing valuable context and conversation history.

The Opportunity

When a subagent finishes and reports back, the orchestrator currently treats subsequent related work as a brand-new task. Instead, we should leverage task_id to resume the same session when:

• The follow-up work is directly related to the previous task
• Context from the previous session would improve quality/speed
• The same specialist agent is being called again

How It Works in OpenCode

From the task tool implementation:

const taskID = params.task_id
const session = taskID
  ? yield* sessions.get(SessionID.make(taskID)).pipe(Effect.catchCause(() => Effect.succeed(undefined)))
  : undefined
const nextSession = session ?? (yield* sessions.create({...}))

When task_id is provided, the tool looks up the existing session. If found, it continues that session with all prior context (files read, conversation history, todos) intact.

Benefits

1. Token efficiency - Avoid re-sending full context summaries
2. Better continuity - Subagent remembers what it already explored/did
3. Faster iterations - No warm-up period for the agent
4. Deeper work - Enables multi-step collaboration with the same specialist

Implementation Considerations

Where to Store task_id

The orchestrator needs to track active subagent sessions. Options:

• Memory/state: Track in orchestrator's working memory (simplest)
• Structured output: Have subagents return task_id in a structured format
• Session registry: Maintain a lightweight map of agent_type → active_session_id

Decision Logic

When should the orchestrator resume vs. spawn fresh?

Scenario	Action
Follow-up to same task	Resume with task_id
New unrelated task	Fresh session
Same agent, different task	Fresh session (or user-configurable)
Explicit user request to continue	Resume

Prompt Updates Needed

1. Orchestrator prompt: Add guidance on when/how to use task_id for resumption
2. Agent prompts: Ensure agents return task_id clearly when they expect follow-up
3. Documentation: Explain the feature to users

Proposed Design

// In orchestrator delegation logic
const delegate = async (task, context) => {
  const existingSession = findRecentSessionForAgent(task.agentType, context)
  
  if (existingSession && shouldResume(task, existingSession)) {
    return await taskTool({
      ...task,
      task_id: existingSession.task_id  // Resume!
    })
  }
  
  // Fresh session
  const result = await taskTool(task)
  storeSessionForAgent(task.agentType, result.task_id, context)
  return result
}

Open Questions

1. Session expiry: How long should we consider a session "resumable"? (Last 5 min? Same user turn?)
2. Context window: Very long sessions might hit token limits - should we summarize before resuming?
3. Multi-agent: If user manually @mentions an agent, should that connect to orchestrator-tracked sessions?
4. Visibility: Should users see session resumption in the UI, or is it transparent?

Related

• OpenCode PR #7756: "Add subagent-to-subagent delegation with budgets, persistent sessions"
• Current behavior: Each task call creates sessions.create({parentID: ctx.sessionID, ...})

Acceptance Criteria

• Orchestrator can resume a subagent session using task_id
• Decision logic for when to resume vs. fresh session
• Context preservation verified across multiple resumes
• Documentation updated
• Tests for session lifecycle management

---

Priority: Medium-High - This is a significant efficiency win for multi-step agent workflows.

Effort: Medium - Requires orchestrator prompt changes + state tracking logic.

[dhaern]

I can confirm a related recovery case that makes this more important than just token efficiency.

I tested an interrupted @fixer task where the subagent hit a server/provider error mid-run. In this case, the task did not complete cleanly: the subagent had already performed useful actions (reads/patches/tool calls), but the final response was cut before a normal summary/result could be returned to the orchestrator.

From the orchestrator side, the task tool returned only an empty result:

task_id: ses_...
<task_result>
</task_result>

From the orchestrator side, the task looked empty/useless. However, when I explicitly resumed the same task_id, the fixer session continued correctly and the UI appended the new output to the previous interrupted subagent session. So the subagent session itself was not lost — only the returned task_result was insufficient.

This means there are two related problems:

1. Fresh task vs resumed task
   • If the orchestrator launches a new task without task_id, the subagent starts fresh and loses the useful prior context.
   • If the orchestrator reuses the same task_id, the subagent can see prior messages, tool calls, reads, patches, and interrupted/error state.
2. Interrupted/empty task_result visibility
   • A failed/interrupted task may return an empty <task_result> to the orchestrator even though the underlying subagent session contains useful partial state.
   • This can mislead the orchestrator into thinking there is nothing to recover, causing it to spawn a fresh subagent unnecessarily.

So I think the feature should also cover failure recovery, not only follow-up work after successful delegations.

Suggested behavior:

• When task returns a task_id, Slim should make the orchestrator aware that this session can be resumed.
• If task_result is empty or the task appears interrupted/errored, Slim could inspect the subagent session via session.messages({ id: task_id }) and add a short recovery note to the task output.
• The note should be informational, not an automatic instruction to resume. The recovery note could be something like:

[task partial state available]
This task returned no final result, but its subagent session may contain partial state.

If the user asks to continue/recover this work, reuse this task_id to reconnect to the same subagent session:
task_id: ses_...

The subagent can then see its prior messages, tool calls, reads, patches, and interrupted/error state. This is recovery context, not an instruction to resume automatically.

This would prevent the orchestrator from treating interrupted subagent sessions as empty/dead, while still keeping resume vs fresh-session as a deliberate decision.

Could you please make sure the implementation also covers this edge case: interrupted/errored subagent sessions whose task_result is empty, but whose underlying session still contains useful partial state? I think preserving and exposing that recovery path is important so the orchestrator does not accidentally discard recoverable work.