🐛 Bug Report: Sub-agent recursion loop / Inefficient delegation in `sdd-apply`

[Milor123]

📋 Pre-flight Checks

• I have searched existing issues and this is not a duplicate
• I understand this issue needs status:approved before a PR can be opened

📝 Bug Description

I am experiencing an unexpected and inefficient behavior regarding the multi-agent orchestration.

The orchestrator agent delegates a task to the Implementation Sub-agent (sdd-apply). Instead of executing the task directly (which was a simple code modification), the sdd-apply sub-agent made the decision to call another implementation sub-agent to do the work.

This created a "sub-sub-agent" loop that:

1. Increased Costs: The task should have cost ~0.02 tokens but ended up consuming over 0.1 tokens according to my API activity.
2. Reduced Visibility: The OpenCode interface only allows me to see the activity of the first sub-agent level, making it impossible to debug what the "sub-sub-agent" was doing.
3. Inefficiency: The task was straightforward (adding a parameter to a tool), which the first sub-agent was perfectly capable of doing with its assigned tools.

🔄 Steps to Reproduce

1. Use the sdd-apply agent for a simple code implementation task (e.g., adding a parameter to an existing function).
2. Monitor the API token usage/activity.
3. Observe the logs to see if the sub-agent delegates the task further instead of using write or edit tools directly.

✅ Expected Behavior

The sdd-apply sub-agent should use its own tools (read, write, edit, bash) to complete the implementation task assigned by the orchestrator, especially for low-complexity changes.

❌ Actual Behavior

The sub-agent delegates the task to another instance of a sub-agent, creating an unnecessary nested call that increases costs and hides execution logs.

---

🖥️ Environment

Operating System
Windows 11 (Gentle-AI All-in-one installer v1.7.9)

Agent / Client
OpenCode / Gentle-AI

Shell
PowerShell / Bash (via OpenCode)

Model Configuration

• Model: DeepSeek v3.2 (via OpenRouter)
• Temperature: 0.2
• Config Snippet:

    "sdd-apply": {
      "mode": "subagent",
      "model": "openrouter/deepseek/deepseek-v3.2",
      "temperature": 0.2,
      "hidden": true,
      "description": "Implement code changes from task definitions",
      "prompt": "You are an SDD sub-agent for the apply phase. Read your skill file at ~/.config/opencode/skills/sdd-apply/SKILL.md and follow its instructions. It includes a Step 1 for loading the skill registry — do NOT skip it.",
      "tools": {
        "read": true,
        "write": true,
        "edit": true,
        "bash": true
      }

📋 Relevant (Subagents Logs)

<task-notification>
<task-id>compulsory-cyan-mammal</task-id>
<status>complete</status>
<summary>Agent "## Implementation Progress" complete</summary>
<result>## Implementation Progress

**Change**: youtube-transcript-filename
**Mode**: Standard

### Completed Tasks
- [x] Agregar parámetro filename a youtube-transcript_get_transcript
- [x] Cuando se pasa filename, guardar el transcript en un txt con ese nombre en la carpeta de trabajo
- [x] Mantener el comportamiento actual (devolver el transcript como string) cuando no se pasa filename

### Files Changed
| File | Action | What Was Done |
|------|--------|---------------|
| `src/index.ts` | Modified | Added optional filename parameter to tool schema and file saving logic |

### Deviations from Design
None — implementation matches requirements.

### Issues Found
None.

### Remaining Tasks
N/A

### Status
3/3 tasks complete. Ready for verify.

**Executive Summary**: Successfully implemented the filename parameter feature for the YouTube transcript MCP tool. The tool now accepts an optional `filename` parameter that, when provided, saves the transcript to a .txt file in the working directory while maintaining backward compatibility for existing users.</result>
</task-notification>

💡 Additional Context

Is this behavior related to the model's reasoning (DeepSeek v3.2) or a potential misconfiguration in the sub-agent's prompt/system instructions? It seems the agent "hallucinates" the need for further delegation even when it has the tools to perform the job. Also, the lack of visibility into nested sub-agent calls makes this very hard to audit.

---

[sebascld]

I've also experienced this problem, i disabled background-agents plugin and started to work better.