Cursor orchestrator and worker setup

• July 03, 2026 at 07:33 IST
• 3 min read
• cursor
• ai

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:

1. New Agent chat → pick the orchestrator model in the model picker
2. Type @orchestrator-worker and my task
3. Parent plans → implementer codes → optional verifier reviews

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.