Manual `/subagent` invocation incorrectly injects `subagent_delegation_context`, causing unnecessary self-delegation

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have a custom agent located at .cursor/agents/a11y-agent.md, which is designed to execute accessibility-related tasks directly.

When I manually invoke the agent using:

/a11y-agent fix JIRA-1111

I expect Cursor to execute the request directly within the already active a11y-agent.

However, after inspecting the chat transcript, I found that Cursor automatically injects the following block into the user prompt before sending it to the model:

<subagent_delegation_context>
The user has indicated they want you to delegate work to the following subagent(s): a11y-agent

To delegate, call the Task tool with the subagent_type parameter. Example:
Task(subagent_type="a11y-agent", prompt="your detailed task description")
</subagent_delegation_context>

<timestamp>Tuesday, Jul 21, 2026, 11:27 PM (UTC+5:30)</timestamp>

<user_query>
/a11y-agent fix JIRA-13652
</user_query>

Because of this injected context, the active a11y-agent ends up invoking the Task tool to delegate the work to another instance of a11y-agent, even though the user has already explicitly selected that agent via the /a11y-agent command.

This results in an unnecessary self-delegation/context switch. The agent first gathers information, then packages that information into another Task invocation, causing duplicated context, additional token usage, increased latency, and behavior that is different from what is defined in the agent prompt. My agent definition does not instruct it to delegate to itself—the behavior is entirely caused by the automatically injected subagent_delegation_context.

Steps to Reproduce

  1. Create a custom agent:
    .cursor/agents/a11y-agent.md
  2. Ensure the agent performs work directly (without instructing it to delegate).
  3. Open Cursor Chat.
  4. Invoke the agent manually:
    /a11y-agent fix JIRA-1111
  5. Inspect the chat transcript.
  6. Observe that Cursor automatically injects subagent_delegation_context.
  7. The model then delegates the work using the Task tool instead of executing it directly.

Expected Behavior

When a user explicitly invokes an agent using:

/a11y-agent ...

Cursor should treat that agent as the active execution context.

It should not inject:

<subagent_delegation_context>
...
</subagent_delegation_context>

unless the user explicitly asks for delegation or another agent decides delegation is necessary.

The manually invoked agent should simply execute the request.

Operating System

MacOS

Version Information

Cursor IDE: 3.12.17

For AI issues: which model did you use?

Model: composer-2.5

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. But this isn’t actually a bug, it’s working as intended.

Custom agents from .cursor/agents/*.md are subagents. By design, they always run inside a Task tool call in their own isolated context window and then return the result to the parent agent, see Subagents | Cursor Docs. There’s no mode where a11y-agent becomes the active context for the main chat. The main conversation is always run by the main agent, and /a11y-agent means delegate this task to the a11y-agent subagent. That’s why injecting <subagent_delegation_context> and calling Task is the only way your a11y-agent prompt gets applied at all. If the request ran directly in the main chat, the agent prompt wouldn’t be loaded.

So this isn’t self-delegation. The parent is the normal main agent, not a second instance of a11y-agent.

If you need inline execution without context isolation and without a separate Task, use a slash command or a skill instead of a subagent. They inject instructions directly into the current conversation, with no delegation and no separate context window, which matches what you described as the desired behavior.

On the extra context gathering before delegation and the token spend, that’s a valid point. It happens because the model sometimes explores before calling Task. Let me know if you still have questions after switching to a command or skill.

7

Thanks for the clarification, that makes sense.

The reason I explored subagents wasn’t because I expected them to replace the main execution context. My goal was to solve a slightly different use case.

I want to provide developers with a single entry point for all accessibility-related tasks:

  • /a11y-agent ...

From there, the agent should internally decide which internal workflow, skill, command, or prompt to use (e.g. fix a Jira ticket, explain a WCAG criterion, generate a11y tests, etc.). The developer shouldn’t need to know about the underlying implementation, they should only have to remember one executable entry point.

An important requirement for us is that these internal workflows should not be directly executable by users. They are implementation details and should only be invoked by a11y-agent. Otherwise, developers need to learn and choose from many commands/skills, which defeats the purpose of having a single domain-specific entry point.

That’s actually one of the motivations behind the other issue I raised about nested Markdown files being detected as subagents. My intention was to keep these internal workflows and reference material alongside the agent, but not expose them as user-facing subagents. (For reference: the nested Markdown files issue.)

So my question is: what is the recommended Cursor architecture for this pattern?

The pattern I’m trying to build is a domain-specific AI assistant with:

  • One user-facing entry point (/a11y-agent)

  • Multiple internal workflows/skills/prompts that are private implementation details

  • Internal routing performed by the orchestrator

  • No direct user access to those internal building blocks

This is a bit different from an orchestrator.md inside .cursor/agents that routes across unrelated subagents. In our case, the orchestration is entirely within a single domain (Accessibility).

Is there an idiomatic way to implement this today using Skills, Commands, MCP, or another mechanism? Or is this a capability that Cursor doesn’t currently support? It feels like a fairly common pattern for teams building domain-specific assistants, so I’d love to understand the recommended approach.

8

There isn’t a fully reliable built-in way in Cursor IDE today to make a workflow available to the model but hidden from the / menu. About the flags so it’s not confusing:

  • disable-model-invocation: true (a documented Cursor flag) does the opposite of what you want. For a repo-level skill it hides it from the model’s auto-invocation, but it still shows up in the / menu for manual use. It doesn’t hide it from the developer.
  • user-invocable: false has the semantics you want, and it’s documented in VS Code 1.109 and Claude Code. In Cursor it’s only partially supported. The CLI hides that skill from the / menu, but the IDE still shows it in the menu like a normal skill. Cursor docs don’t list this field. One important detail is that even when the skill is hidden from the menu in the CLI, calling it by its full name /skill-name still works. This flag only controls menu visibility, not access to the skill. So if your requirement is internal workflows must not be directly invocable by the developer, you can’t rely on it.

The reliable approach for your case:

  1. Use a single entry point, a11y-agent as a subagent at .cursor/agents/a11y-agent.md, with routing logic in its system prompt.
  2. Put internal workflows as plain markdown files outside .cursor/agents|skills|commands, for example .cursor/a11y/workflows/. The orchestrator reads them on demand via file read or @file from the prompt. These files won’t appear in the / menu and won’t be discovered as skills at all. That gives you privacy and doesn’t depend on any flags. It also avoids the bug where nested markdown gets falsely detected as subagents.

Net result: an agent-only workflow that’s invisible to the developer is built today via an orchestrator prompt plus plain files. I also logged the IDE vs CLI inconsistency for user-invocable: false for the team.

Send me the list of workflows you want and I’ll help you lay out the files and write the routing in the a11y-agent prompt.