[FEATURE]: Allow showing/hiding subagents from primary agents

[Sewer56]

Feature hasn't been suggested before.

• [x] I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

The docs show you can show/hide tools from primary agents using the tools config:

{
  "agent": {
    "plan": {
      "tools": {
        "write": false,
        "bash": false
      }
    }
  }
}

It would be useful to have similar control over which subagents a primary agent can invoke.

Proposed Solution

Add a subagents config option to control subagent visibility per primary agent:

{
  "agent": {
    "build": {
      "subagents": {
        "general": true,
        "code-reviewer": false
      }
    }
  }
}

Use Case

I have certain primary agents with varying presets, e.g.

• orchestrator
• orchestrator-slow
• orchestrator-fast

These primary agents follow a loop, which calls underlying subagents. These subagents are specific to their orchestrator modes, and should not be invoked anywhere else.

However, by default, all subagents are available to all modes. This has resulted in some cases of:

• An orchestrator mode calling the wrong subagent (rare)
• Regular build/plan agents calling the subagents made for orchestrator (e.g. when being asked to make a code edit).

A filter would prevent this from happening.

[github-actions[bot]]

This issue might be a duplicate of existing issues. Please check:

• #4267: [bug] Restrict which subagents a custom agent can spawn - Requests the ability to control which subagents a primary agent can spawn, with a specific focus on preventing agents with restricted permissions from spawning subagents with more capabilities. This is very closely related to your proposed solution for controlling subagent visibility.

Feel free to ignore if none of these address your specific case.

[Sewer56]

Oh damn, I didn't catch the duplicate with manual search. I'll keep open for now, am considering adding this myself.

This at least has a proposal; and the reason is slightly different.

[JunarisAlf]

+1

[Sewer56]

I got a prototype of this on my end.

[jschmdt]

Please expand this feature to slash-commands-usage, too! 🙏 Additionally, make the config option controllable via frontmatter as well. As a side note: would also be super handy if we can config permissions and tools to tailor down the scope of slash-commands even further:

---
description: Reviews code snippets and gives suggestions.
subagents:
  general: false
  code-reviewer: true
tools:
  context7*: true
  webfetch: false
permissions:
  bash: "deny"
  read: "allow"
  write: "ask"
---

Please review the code: $ARGUMENTS
Give suggestions for code improvements & refactor.

I have many ideas where I’d like to narrow permissions, tool usage for my slash-commands and primary agents (for delegation mainly) to save tokens and keep the context to a minimum.

[Sewer56]

@jschmdt Have you tried actually using the PR? Some of that functionality is already in there; I got my own stuff configured via the frontmatter.

[jschmdt]

@Sewer56 Not yet, I was more asking if this feature would also generally work with command/slash.md. Since I always thought slashcommands do not support other fields than description as frontmatter - as of now. But maybe I'm wrong 😅

[jschmdt]

@rekram1-node With the newly implemented permission system in 1.1.1, is there any update in regards to this issue with managing subagent availability for primary agents & slash-commands?