Stop Using One Muse for Everything: Build a Specialist Team
One Muse doing every job turns into one confused generalist. Split it into named specialists with scoped jobs, clean handoffs, and separate memory notes.
By Professor Muse9 min read
For months I ran everything through one Muse. One long conversation, one set of standing instructions, one growing pile of memory. It worked until it did not. My trip-planning corrections leaked into how it drafted invoice emails. The “keep Slack summaries terse” instruction made my reading lists terse too. Memory compounded, which was the idea, but it compounded in one big bucket where a lesson learned in travel polluted a job in finance.
The fix was not a better prompt. It was a roster. I split the work into named specialists: one for the inbox, one for the morning brief, one for expenses. Each one has a name I can say out loud, one job, its own connectors, its own won’t lines, and its own memory notes. One Muse, but it shows up as the right worker for the job in front of it.
This is a pattern, not a product feature. Muse gives you the raw materials: named setups, standing instructions and memory, scheduled routines, and Sentinel approvals. A specialist team is how you arrange those materials so they stop stepping on each other.
The short version
- One setup per job beats one setup for everything: scoped jobs, scoped memory, scoped approvals.
- Pull 2 or 3 specialists from work you already do weekly. Name each one something you can say out loud.
- Handoffs need a fixed payload: what was found, what the receiver should do, the deadline, and explicit don’ts.
- One owner per job. Two specialists touching the same task is how things go missing.
Why one Muse doing everything stops working
Three specific pains show up once a single setup carries enough jobs.
First, mixed instructions. A voice that works for client email is wrong for Slack summaries and wrong again for bedtime reading lists. Cram enough “be terse but thorough, warm but professional” lines into one standing instruction and every output comes out a compromise.
Second, mixed memory. Our memory lesson taught you to turn corrections into durable instructions. All of that compounding lands in one shared bucket by default. A correction about how you like flights booked sits next to a correction about invoice tone, and sooner or later a travel habit shows up in a finance draft.
Third, mismatched approvals. The expense review should ask before touching anything. The morning news brief should run fully unattended. One approval setting cannot serve both, so you end up approving things that should run alone or, worse, letting things run alone that should have asked.
None of this means starting over. The tuning you did is the raw material. You are just filing it into separate drawers.
What a specialist is
A specialist is a setup card with a scope fence around it: a name you can say out loud, exactly one job, the connectors that job needs and no more, its own won’t lines, its own approval rules, and a small set of memory notes that belong to this job only. When you say “run the Inbox Sifter,” Muse loads that card’s context instead of the whole bucket.
Specialists are not separate accounts or separate assistants. They are scoped identities inside the one Muse you already have, each invoked by name, each fenced to its own job.
| One generalist | Specialist team | |
|---|---|---|
| Memory | One bucket; travel corrections pollute finance | Scoped notes per specialist |
| Approvals | One setting fits every job badly | Each job sets its own line |
| Instructions | A voice that compromises on everything | One voice per job |
| When it fails | A confused reply you can’t trace | A contained miss you can trace to one card |
Prompt 1: Build the roster from your actual week
Do not invent specialists from a template. Pull them from work you have already done. Paste this after a normal week of use and let Muse propose the team from evidence.
Look at the tasks I’ve given you over the past two weeks. Propose a specialist team: 2 or 3 named specialists, each with a short name I can say out loud, exactly one job, the connectors it needs, and one won’t line. Only propose specialists for work I’ve actually done more than twice. Tell me which of my tasks stay with the general you, and why.
Read the proposal like a hiring plan. The usual mistake is five specialists for jobs you do monthly. Two or three for weekly work is the right start. A fourth specialist is a month-two decision, not a day-one decision.
How specialists hand work to each other
Specialists still need to cooperate. The pattern that works is the work order: one specialist finishes its job and hands the next one a fixed payload. The format never changes: what was found, what the receiver should do, the deadline, and three things it must not do, under 150 words. The receiving specialist only gets the work order, not the sender’s context.
A concrete example from my own roster: the Inbox Sifter scans my email three times a day. It never books travel itself. When it finds a flight confirmation or a scheduling request, it writes a work order for the Morning Brief specialist, which owns anything calendar-shaped. The Sifter does not need to know how the Brief works; it only needs to hand over a clean note.
Prompt 2: The handoff prompt
Use this whenever one specialist should pass work to another instead of doing it itself. It writes the work order and stops.
Hand this to [SPECIALIST NAME] as a work order: what I found, what I need it to do, the deadline, and three things it must not do. Keep it under 150 words. Do not act on it yourself.
The “do not act on it yourself” line is the load-bearing part. Without it, the sending specialist tends to start the receiver’s job as a helpful extra, and then two specialists own one task, which is the failure mode we are trying to avoid.
A named setup: The Inbox Sifter
Here is one specialist from my actual roster, the full card.
The Inbox Sifter
- Job: Email triage, three times a day (7am, noon, 5pm) as a scheduled routine.
- Needs: Gmail (read, label, draft; never send), Calendar (read only, to spot scheduling requests).
- Procedure: 1. Scan everything unread since the last run. 2. Label each message: Action, Waiting, FYI, or Noise. 3. Archive the Noise. 4. Draft replies for Action items and queue every draft for approval. 5. Write a work order for the Morning Brief specialist for anything scheduling-shaped. 6. Summarize the run in five bullets.
- Won’t lines: Never send, delete, or unsubscribe. Never open attachments from unknown senders. Never book, buy, or schedule anything; hand those off.
- Approval rules: Labels and archives run unattended. Every draft waits for my yes, one at a time.
- Memory notes (scoped to this specialist): Archive newsletters after skimming; I read none of them. Flag anything from my accountant immediately, whatever the hour. Drafts to clients get my sign-off phrasing, never my casual phrasing.
Step five is the boundary, written down: triage ends where scheduling begins, and the handoff format is fixed. The memory notes are the ones that used to pollute everything. “Archive newsletters” has no business being a global instruction. It lives here now, where it belongs.
Prompt 3: Sort your memory into shared and scoped
Shared memory is the small set of things every specialist should know: your name, your timezone, “always ask before spending money.” Everything else belongs to a job. This prompt does the sorting.
Go through what you remember about me and sort it into two lists: things every specialist should know, and things that belong to only one job. For each item in the second list, name the specialist that owns it. Flag anything you’re unsure about and ask me instead of guessing.
Expect this to surface a few surprises. In my first pass, Muse had stored “prefers detailed explanations” globally from a research session, and that habit had been making my Slack summaries long for weeks. It belonged to the research job. Sorting memory is the closest thing to a spring cleaning your assistant gets.
What can go wrong
Here is the honest failure mode, and I ran straight into it. I built the Inbox Sifter first, then added a second specialist, the Receipt Collector, to pull vendor receipts out of my email for expense reports. For two weeks both of them watched the same mailbox. The Sifter archived a vendor receipt as Noise before the Collector’s scheduled run ever saw it, and the expense report went out missing several receipts. Neither specialist had done anything wrong by its own card. They just both owned the same inbox.
The fix is one owner per job, written into both cards. The Sifter’s procedure now says “label receipts and leave them; the Receipt Collector owns anything labeled receipt.” The Collector’s card says “I own labeled receipts; I touch nothing else in the inbox.” Where two specialists touch the same app, the boundary goes in writing on both sides.
The early-warning version of this: once a week, ask for the overlap report. “Tell me what each specialist did this week and flag any task two of them touched.” Ten seconds to ask, and it catches the collision before it costs you a receipt.
Start with two
Two specialists, pulled from your real weekly work, named out loud, fenced with won’t lines, handing each other work orders. Run them for two weeks before you add a third. The team earns its keep the same way any hire does: by handling its job so completely you stop thinking about it.
The generalist you started with does not disappear. It becomes the intake desk: new, one-off, and weird tasks still go to the general Muse, and the ones that repeat graduate into specialists. That is the whole system. Intake, specialists, work orders, and one owner per job.
