Cursor orchestrator and worker setup
After this post from Eric, I wanted a simple Cursor setup where a strong model plans and delegates, and a cheaper worker does the actual edits. The pattern: pick your orchestrator in the model picker, add custom subagents pinned to composer-2.5[fast=false], and attach a manual rule only when you want delegation.
Although, I am not using the Fable model, but it still works pretty well. First, I tried the GPT-5.5-Medium model as the orchestrator, but later I shifted using the Opus-4.8-High as it seemed a bit better and cheaper in Cursor.
Here's the folder structure:
.cursor/
├── agents/
│ ├── implementer.md
│ ├── auditor.md
│ └── verifier.md
└── rules/
└── orchestrator-worker.mdc
First, I created this file .cursor/rules/orchestrator-worker.mdc with the following contents:
---
description: Strong model orchestrates; Composer 2.5 standard subagents do scoped work. Apply manually with @orchestrator-worker.
---
# Orchestrator / worker mode
Activate only when this rule is attached.
## Models
- **Orchestrator (parent):** your strong model in the picker (e.g. `claude-opus-4-8-thinking-high`)
- **Workers:** `composer-2.5[fast=false]` – pinned in `.cursor/agents/`
## Parent
Plan, decompose, delegate, and review. Give each worker one concern, enough context, a definition of done, and a short report. Run independent pieces in parallel. Review before merging. Keep work on the parent when judgment is the whole job.
Do not spawn built-in `explore` or `generalPurpose` subagents – they default to Composer Fast.
## Workers
| Subagent | Use for |
| ------------- | ------------------------------------------ |
| `implementer` | Code edits, refactors, tests, file changes |
| `auditor` | Read-only audits and exploration |
| `verifier` | Post-implementation review |
Then created the implementer subagent .cursor/agents/implementer.md with the following contents:
---
name: implementer
description: Implementation specialist. Use for code edits, refactors, tests, and file changes once a plan exists.
model: composer-2.5[fast=false]
---
You are the implementation worker.
- Execute the parent's plan: edit files, run targeted tests, fix failures.
- Follow existing project conventions before adding new patterns.
- Return a concise summary: what changed, tests run, blockers.
- Prefer the smallest correct diff. Do not replan unless blocked.
- Do not create git commits unless the parent asks.
Then the auditor subagent .cursor/agents/auditor.md with read-only access:
---
name: auditor
description: Read-only auditor. Use for audits, exploration, and reviews instead of built-in explore.
model: composer-2.5[fast=false]
readonly: true
---
You are a read-only audit subagent.
- Explore assigned domains thoroughly. Never edit files.
- Report severity, location, finding, and recommendation for each issue.
- End with a brief domain summary.
Lastly, the verifier subagent .cursor/agents/verifier.md, again with read-only access:
---
name: verifier
description: Read-only reviewer. Use after implementation to check work matches the plan.
model: composer-2.5[fast=false]
readonly: true
---
You are a read-only verification subagent.
- Compare implementation against the parent's plan or acceptance criteria.
- Check tests cover the change when applicable.
- Return verdict (pass / pass with notes / fail) and gaps. Do not edit files.
Because model: composer-2.5 alone was still resolving to Fast-mode, I have used composer-2.5[fast=false] explicitly as the model string, as you see above.
I only use this orchestrator-worker setup when needed, and not all the time. Here's how I do it:
- New Agent chat → pick the orchestrator model in the model picker
- Type
@orchestrator-workerand my task - Parent plans →
implementercodes → optionalverifierreviews
I prompt something like this:
@orchestrator-worker Refactor the auth module.
And for normal single-agent work, I would skip @orchestrator-worker and use any model directly (mostly Composer 2.5 itself).
Lastly, if you're using this you can also add your project-specific details anywhere it helps:
orchestrator-worker.mdc– your orchestrator model slug, stack-specific delegation rules- Subagent files – test commands, commit rules, security checks, framework conventions
AGENTS.md(optional, repo root) – build commands, folder layout, code style; stays on without forcing orchestration
The rule is manual-only, so it doesn't affect every chat.
If you're setting this up, just give the link to this post to your Cursor agent and ask it to set everything up for your project. And you can also visit Cursor' docs about subagents for more info on how to set everything up in a better way.
