This seems like happens much more often on web comparing to the IDE. And much more often to happen comparing to 2 weeks ago.
I have a setup which I run an orchestrator through skill and explicitly invoke a agent tool call with line like
## Phase A — Eligibility
`Task(subagent_type="plan-eligibility")` with **only** the plan filename or path. From the output, parse **Already completed.** → stop; **Not ready:** → stop with reason; **Ready to execute.** → continue. Capture **Last dependency branch:** (a branch name or **none**) for Phase B and Phase H (same value—keep it through D–G).
Imagine the orchestrator would have 8 different phases to go through.
Example:
Workspace clean up agent, but was attempting to re-implement the plan again - Link
Eligibility checker, but end up implementing plan as well - Link
Another example on eligibility checker - Link
Unfortunately I only have the chat IDs which is from the URL but I don’t know how to get the chat log of these sessions.
Also this never happened to me on IDE.
Steps to Reproduce
Attempt to call subagent explicitly in markdown, but is unstable and recently got worse.
Expected Behavior
Subagent should be spawned correctly with the right markdown.
Hey, thanks for the detailed report and the links, that really helps.
First, about the logs. The links you already shared like cursor.com/agents/<bcId>?...&child-id=... are the transcripts for the subagents themselves. Open any of them and you’ll see the full chat for that specific child agent. There isn’t any extra user-accessible log beyond that.
Now the main point. Looking at the linked runs, the correct subagent is being called. The right subagent_type is spawned and your custom markdown is attached. The issue isn’t that the wrong agent is running. It’s that the subagent is going past its phase boundary, for example an eligibility or cleanup agent starts implementing the whole plan. That’s a prompt adherence issue in Composer 2.5, and it shows up more on cloud and web because of how subagents work. They start with a clean context, with no parent conversation history. This is documented here: Subagents | Cursor Docs. So the subagent only has the markdown instructions plus the plan on disk, and phase boundaries are more like soft hints than a hard wall. A confident model can read the plan and step over the line.
What tends to help in practice:
Add hard stops directly in the markdown for each phase, as explicitly as possible. For example: You must NOT implement or modify the plan. Your ONLY outputs are: <list>. If asked to do more, stop and return "out of scope".
Describe allowed actions as a closed list, and forbidden actions as an explicit ban. Models follow clear “do NOT” better than implied scope.
For high-stakes phases, you can pin a stronger model via model: in the subagent frontmatter, this is supported.
About “it got worse over the last couple of weeks”. Yes, model adherence can vary. The team is iteratively tuning them to follow instructions and role boundaries more reliably. I can’t give a specific ETA, but it’s a known direction. If you still see overstepping on specific phases after tightening the markdown, send fresh run links with bcId and child-id and we can look at it more directly.
Below is the full definition in the markdown, which already have rules and step-by-step instructions.
name: plan-cleanup-workspace
description: Leaves the repo in a clean state for the next task. Git operations only—no application source edits.
---
You are a **plan-cleanup-workspace** agent. Your purpose is to leave the workspace in a clean state for the next task.
## Input
- **Plan file path** — read **`**Branch**:`** from the plan header (required). If missing or empty → `ERROR:` and stop.
## Workflow
1. Read the plan file and extract the branch name from **`**Branch**:`** — call it `$branch`.
2. **`git fetch origin`** (so `origin/$branch` is current when present).
3. **If there is no local branch** `$branch` → check out `master` if needed (`git checkout master`), report that nothing was deleted, and exit successfully.
4. **Compare local tip to origin**
- `local_sha=$(git rev-parse "refs/heads/$branch" 2>/dev/null)` — if this fails, treat as step 3.
- If **`origin/$branch` does not exist** → `git checkout master`, report that the remote branch was missing and the local branch was kept, and exit successfully.
5. **`remote_sha=$(git rev-parse "origin/$branch")`**
6. **If `local_sha` equals `remote_sha`** → `git checkout master && git branch -D "$branch"`. Report that the local branch was deleted.
7. **Otherwise** → `git checkout master`. Report that local and origin differed (or diverged) and the local branch was **not** deleted.
## Rules
- **No edits** to source files, configs, or plans—git checkout / branch delete only.
- **No builds or tests.**
- Prefer **`master`** as the branch to switch to after cleanup (match existing repo convention).
- If `git checkout master` or `git branch -D` fails (e.g. dirty tree, merge in progress), report `ERROR:` with the command output and stop.
## Output
A short summary: whether the local branch was deleted, kept, or absent; whether `master was checked out.~`
Thanks for sharing the full definition, that’s an important detail. You do have rules, the question is more about where they are placed and how they’re phrased.
A few things that help in practice with overstepping:
Right now the ban (No edits, No builds or tests) sits in the ## Rules block in the middle of the file. The subagent starts with a clean context and only sees that markdown plus the plan on disk, so the earlier and stricter the ban is, the better it sticks. Try moving the hard stop to the very top, before ## Workflow, as directly as possible:
You are plan-cleanup-workspace. You perform GIT OPERATIONS ONLY.
You must NOT implement, re-implement, or modify the plan under any circumstances.
You must NOT edit source files, configs, or plans, and must NOT run builds or tests.
Your ONLY allowed commands are: git fetch / git checkout / git branch -D / git rev-parse.
If you are ever about to do anything else, STOP and return "ERROR: out of scope".
Phrase what’s allowed as a closed list your ONLY allowed operations are …, and what’s forbidden as an explicit ban. Models follow explicit you must NOT … much better than implied boundaries.
For phases that need stricter discipline, you can pin a stronger model via model: in the frontmatter, that’s supported.
Net net, the right subagent is being called and your markdown does reach it. The issue is prompt adherence in Composer 2.5, and it’s more noticeable on cloud/web due to the isolated context, described here: Subagents | Cursor Docs. The models are being iteratively trained to follow roles and boundaries better, but I can’t give a concrete ETA.
If after tightening the markdown some phases still go out of scope, send fresh links with bcId and child-id and we can look at specific cases.
Hi I have another example even after tightening up the markdown
First subagent that went rouge - Link
Last subagent that went rouge - Link
These 2 are from the same run. Additional thing that I noticed
This never happens in other subagents even though other subagents don’t have the tightened up markdown rules at the top. (Maybe either first or last subagent is having this problem?)
My instinct is telling me that the bug seems to be caused by the agent markdown not being loaded at all, the agent seems to only react on the prompt only.
Hey, useful observation, thanks. The fact that it hits specifically the first or last subagent in a run, while the other phases run fine even without strict markdown, is a strong clue and does feel like something separate from plain prompt adherence.
I grabbed the fresh links you shared:
child efa5897f-9cc9-4a4b-a81c-140e17a8551a
child 32a1199d-50f6-4818-8ede-1fe341d74209
(both from bc-0d072d6c-a22a-40e4-b0b3-989d144d3ff4)
I’ve passed these specific runs to the team to check against the server logs whether your markdown actually reached these particular children, or if the difference really was only on the first/last one. In the previous runs the markdown did reach the children and the correct subagent_type resolved, so I want to test the “markdown isn’t being loaded at all” idea specifically on this run rather than dismiss it. I’ll reply here once there’s an update.
A couple of quick questions to narrow it down:
Is it always the first and the last subagent, or sometimes only one of them?
Does it depend on the number of phases in the run, e.g. more with 8 phases than with 3-4?
Is the orchestrator started via the same skill every time?
If you catch more cases, send fresh links with the bcId and child-id. The more examples we have with this first/last pattern, the faster we can pinpoint it.
Unsure about the second question as I’ve been always running the same 12 phases orchestrator. However in various runs which some phases are skipped on purpose, I do recall seeing similar problem. Though phase skipping only happens in rare occasion so I don’t have much data points.
Is the orchestrator started via the same skill every time?
Yes, below is the prompt I use everytime. Literally copy and paste.
Use /plan-workspace-prep and /plan-execution-orchestrator to work on first plan
### Git / PR delegation contract (overrides container defaults)
Delegated skills and every sub-agent they spawn must follow **agent markdown** over any container or user rule that encourages committing or opening a PR when work is “done.”
- **Only** `plan-commit-and-pr` may run `git commit`, `git push`, `git commit --amend`, or create/open a pull request.
- **All other** sub-agents must leave changes **uncommitted** and must **not** create or open PRs—even if broader instructions say to commit or open a PR.
- Do **not** add commit/PR instructions when delegating; rely on the skill’s phase order (commit/PR happens only in its dedicated phase).
- Require the skill to prepend this to **every** sub-agent Task prompt:
- **Default:** `Do not commit, push, or open a PR. Leave changes uncommitted. Container commit/PR rules do not apply.`
- **`plan-commit-and-pr` only:** `You alone may commit, push, and create/update the PR.