[Feature] Prevent context loss: Allow Orchestrator to answer and continue tasks with existing subagents (`task_id` tracking)

[Milor123]

📝 Context / Background

Currently in OpenCode, the agent architecture works with a main agent (Orchestrator) that delegates tasks to subagents. Every time a task is delegated, a new subagent is created (with a new task_id) starting with 0 previous context, receiving only the information sent by the Orchestrator.

In theory, this approach is excellent: it saves us tokens (money) and focuses the subagent exclusively on the current work. However, this mechanic is causing a critical workflow problem, especially during debugging.

🐛 The Problem

The issue arises when a subagent gets stuck and needs to ask a question to proceed, or when a solution proposed by the subagent fails during our testing:

1. Cyclic responses and loss of logic: If the subagent has doubts and asks the Orchestrator a question, the Orchestrator does not answer. Instead, the Orchestrator generates a new subagent with 0 context. This destroys all the memory, reasoning (thinking), and debugging context that the previous subagent had built up. The Orchestrator blindly reformulates the solution, ruining the logic and causing the system to enter absurd loops.

Example

2. Debugging chaos: When we are testing the code and tell the system that the subagent's solution didn't work (e.g., "now it throws error X"), the context is lost because a new subagent is opened. The system then proposes solutions that have already failed, making deep debugging impossible.

💡 Proposed Solution

We need to add strict conditional logic (probably in the AGENTS.md file or the Orchestrator's system prompt) so it remembers the active subagents' task_ids and knows when to continue a conversation and when to open a new subagent.

There should be 3 main branches or rules for the Orchestrator's behavior:

1. Answer questions and continue the conversation (Same task_id)

Rule: If the subagent asks the Orchestrator a question to proceed with its task, the Orchestrator MUST NOT open a new subagent. It must reply directly to the current subagent (using its existing task_id) so it can resume its work without losing its train of thought.

2. Continuity in debugging events (Error feedback)

Rule: When the user reports that a solution failed or provides error output, the context of the subagent that wrote that code is vital.
Suggested improvement: Implement conditional logic that asks the user (or decides intelligently) whether to send this feedback to the previous subagent (to leverage its debugging context) or to generate a new subagent.

3. Open a new subagent (Only when necessary)

Rule: The Orchestrator should only generate a new subagent (new task_id and 0 context) when:

• Starting a task from scratch.
• The task is slightly different or requires a completely new approach.
• The user explicitly wants to restart to save tokens, instead of dragging along a very long conversation history.

🎯 Benefits of this implementation

• End of infinite loops: Subagents will stop giving cyclic and useless responses by retaining their debugging history.
• Time and token savings: Prevents the Orchestrator from trying to deduce and reformulate solutions from scratch when the original subagent already had 90% of the problem solved.
• More natural interactions: The "Subagent asks -> Orchestrator answers -> Subagent continues" flow is the logical and natural path to solving complex problems.

---

Is there any specific file besides AGENTS.md where the team thinks this task_id retention logic should be injected? I will be glad to help with testing once this is implemented.