Agent ignores explicit /subagent invocation and fulfills request directly instead of using Task tool

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When explicitly invoking a custom subagent using the /name syntax in the chat prompt, the main agent frequently ignores the instruction to delegate the work. Instead of using the Task tool to launch the requested subagent in an isolated context, the main agent completes the work itself in the main conversation window.

Because the work is done by the main agent rather than the subagent, the specialized system prompt and rules defined in the custom subagent’s .md file are completely bypassed.

P.S. I asked the agent to explain its behavior and got this response:

Here is exactly what happened under the hood:

  1. When you typed /dev-backend let’s add code coverage…, Cursor correctly intercepted that and attached a hidden system instruction to your message telling me: “The user has indicated they want you to delegate work to the following subagent(s): dev-backend. To delegate, call the Task tool with the subagent_type parameter.”
  2. I ignored that instruction. Instead of launching the Task tool to spin up the actual dev-backend subagent in its own isolated context, I just started searching the codebase and wrote the test class myself in the main conversation.
  3. Because I did the work directly, the dev-backend subagent was never actually launched. Since it was never launched, its specialized system prompt (containing the domain-apex-architecture rules about Assert.*, API version 66.0, etc.) was never loaded into the context window.

So the system worked perfectly on your end. The failure was entirely mine—I was too eager to just write the code directly instead of passing the baton to the subagent you explicitly requested.

In the future, if you see me start using Grep/Read/Write tools immediately after you invoke a subagent with /, you can stop me and say “delegate this to the subagent” to force me to use the Task tool.

Steps to Reproduce

Create a custom subagent at ~/.cursor/agents/dev-backend.md (or .cursor/agents/) with specific rules (e.g., “Always use Assert.areEqual() instead of System.assertEquals()”).
In a chat prompt, explicitly invoke the subagent: /dev-backend let’s add code coverage for MyClass.cls

Expected Behavior

The main agent should immediately call the Task tool with subagent_type=“dev-backend” to spin up the requested subagent, ensuring the subagent’s specific system prompt and rules are applied.

Actual Behavior
The system correctly intercepts the / command and injects the <subagent_delegation_context> instruction into the prompt (e.g., “The user has indicated they want you to delegate work… To delegate, call the Task tool”). However, the main agent ignores this instruction, directly uses tools like Read/Grep/Write to do the work itself, and consequently violates the rules that would have been enforced by the subagent’s context.

Operating System

MacOS

Version Information

Version: 3.2.21
VSCode Version: 1.105.1

For AI issues: which model did you use?

Composer-2-fast

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Your debugging is spot on. When you type /dev-backend, the system does inject a delegation instruction, but it’s a prompt-level hint rather than a hard enforcement.

A few things to try:

  1. Use a different model for tasks where delegation matters

  2. Reinforce in your prompt text. Instead of just /dev-backend add code coverage..., try: /dev-backend delegate this to the dev-backend subagent: add code coverage for MyClass.cls.

  3. Interrupt early. If you see the agent start using Read/Write/Grep tools directly after your / invocation instead of the Task tool, stop it and say “use the Task tool to delegate this to dev-backend.”

We’ve filed this with our engineering team. The system already has patterns for structurally enforcing tool usage in other features, so applying the same approach to /subagent invocations is a natural next step.