Give Your Bots a Manager: The Ops-Bot Pattern
Once you have several Muse routines and specialists running, you become their manager. Hand the job to an ops-bot: a daily standup, a shared playbook, and postmortems for bot mistakes.
By Professor Muse10 min read
I now have five routines running. A nightly downloads audit, an expense sweep, an inbox sifter, a Friday receipts review, and a Sunday bookmark check. Each one reports to me every morning, which was the plan. Then one Tuesday I caught myself doing something strange: I was reading the audit’s report, comparing it against the expense sweep’s report, making notes about which routine needed a nudge, and writing down a fix one of them needed. I had not hired an assistant. I had become a middle manager with five direct reports, none of them human.
The specialist team solved the one-Muse-doing-everything problem. The routines lesson solved the do-it-by-hand problem. Neither solved the last problem: once the team is running, somebody has to manage it, and by default that somebody is you. The ops-bot is the pattern that fixes that. One setup whose only job is managing the others.
The short version
- An ops-bot is a setup whose whole job is managing your other setups: it runs the standup, keeps the playbook, and writes postmortems.
- The ops-bot reads reports. It never re-runs a worker’s job and never does the underlying work itself.
- Three prompts get you there: the morning standup, the postmortem, and the playbook builder.
- The quiet failure mode is the telephone game: an ops-bot summarizing summaries. Keep reports short and always let yourself read the raw one.
Why the manager can’t be you
Three pains show up once a roster of routines and specialists is actually running.
First, the morning queue. Each routine sends you its report, which is fine for one. At five, you are the bottleneck doing what machines do badly: reading five threads to decide whether anything needs attention. The work each routine saves you gets spent on managing the routines.
Second, nobody remembers the org chart. Six weeks in, you forget which specialist owns what, what each one’s approval line is, and why the expense sweep ignores parking charges. That knowledge lived in your head at setup time and decays from there. When a bot does something odd, you cannot diagnose it because the configuration is scattered across threads.
Third, mistakes repeat. One routine flags the wrong emails, you correct it in its thread, and the correction stays in that thread. A month later a different routine makes the same class of mistake, because nobody carried the lesson across. Our failure modes lesson lists the ways individual bots break; the ops-bot is where the lessons from those breaks get written down so they stop recurring.
Multi-agent systems have run this shape for years: one coordinator owns the plan, workers own the jobs, and the coordinator’s context holds the running summary rather than everyone’s full output. The industry version runs in code. Ours runs in a scheduled routine and a document.
What the ops-bot owns, and what it never touches
The line between the ops-bot and the worker is the whole pattern. Get it wrong and you have six generalists instead of five specialists.
| The ops-bot owns | The ops-bot never touches |
|---|---|
| The daily standup: collect each routine’s last report, summarize status | The underlying jobs: it does not re-run audits or sifters |
| The shared playbook: what each bot does, its approval line, its quirks | Any approval-gated action: it cannot approve on your behalf |
| Postmortems: when a bot makes a mistake, write it up and update the playbook | External sends: no messages, no purchases, no posts |
| The change log: when a routine gets a new rule, record it | Workers’ memory: each specialist keeps its own notes |
The ops-bot reads reports; it never re-runs a worker’s job or does the underlying work itself, because re-running is how two routines end up owning one task, the exact failure our specialist team lesson warns about. If the report looks wrong, the ops-bot flags it for you. You are the only debugger.
Prompt 1: the morning standup
This is the one routine that pays for the whole pattern. It runs after your morning reports land, reads each one, and gives you a single thread: everything fine, or the one thing that needs you.
Every weekday at 7:30am, run my morning standup. Read the latest report from each of my routines: [name each routine and where its report lands]. For each one, give me one line: running normally, or what needs attention. If two routines disagree with each other, say so plainly. Keep the whole standup under 10 lines. If every routine is fine, say “all clear” and stop. Read reports only: never re-run a routine’s job, never change any routine, never send anything.
Name each routine explicitly. The standup works because it reads from named sources, not because it goes looking. If you add a sixth routine, you update the prompt. That is the change log habit starting.
Prompt 2: the postmortem
When a bot makes a mistake worth learning from, do not just correct it in its thread. Run a postmortem. This is the prompt that turns an incident into a playbook entry.
One of my bots made a mistake. Here is what happened: [describe what it did, what it should have done, and what the correction was]. Write a postmortem: what went wrong, the warning sign I should watch for, and the fix. Then update my shared playbook: add the failure mode to that bot’s entry so the lesson survives this thread. Keep the postmortem under 150 words.
The postmortem habit is the difference between a team that improves and a team that repeats. A correction given in a worker’s thread fixes one instance. A postmortem written into the playbook fixes the category. Our nightly audit lesson showed the same principle at small scale: the audit that caps its list at 15 items only stays capped because the rule is written down where it will be read.
Prompt 3: the playbook builder
The playbook is one document, one page per bot: its name, its one job, its schedule, its approval line, its connectors, and its known quirks. Build it once from what already exists.
I have several Muse routines and specialist setups running. Interview me about each one: its name, what it does, when it runs, what it is never allowed to do unsupervised, and one quirk I have learned about it. Then write my shared ops playbook as one document: one short section per bot, plus a change log at the bottom with today’s date. Save it where I can find it again.
Do not write the playbook from memory of your setup instructions. Interview yourself through the prompt. The quirks are the valuable part: “the expense sweep flags parking garages as duplicates,” “the sifter is too aggressive on Tuesday newsletters.” That is operational knowledge that currently lives only in your head, and the playbook is where it moves out of your head.
A named setup: The Duty Officer
Here is the complete named setup, the one I actually run. The Duty Officer is the ops-bot; the name is the point, because you will say it out loud when something looks off.
The Duty Officer
- Cadence: Weekdays at 7:30am, America/Chicago, after the morning reports land.
- Reports to it: the Downloads Audit and Expense Sweep (nightly, 2:00am), the Inbox Sifter (three times daily), the Friday receipts review, the Sunday bookmark check.
- Inputs: the latest report from each routine, read only. The Duty Officer has no access to your Gmail or your folders; it reads what the workers wrote.
- Report contract: one standup thread per morning, 10 lines max, “all clear” on quiet days.
- Playbook: one document with five entries plus a change log; the Duty Officer updates it after every postmortem and every routine change.
- Approval line: The Duty Officer reads and summarizes. It never re-runs a routine, never edits a routine’s instructions, never sends anything, and never approves a worker’s draft on your behalf. Anything needing action goes to you in the standup.
Two details from running it. First, the standup goes at 7:30am, not 6:00am, because the 2:00am audits sometimes finish closer to 6:00 than 2:00 when the queue is long, and a standup that reads a half-finished report invents the ending. Give the workers time to finish. Second, I keep a second copy of the playbook rule in the Duty Officer’s own prompt: “when in doubt, ask me.” An ops-bot that guesses is worse than one that asks; the escalation costs one message.
The ops-bot is the next step after the specialist team. If you have not split your work into named specialists yet, start there: an ops-bot with nobody to manage is overhead, and the roster lesson shows how to build the team the Duty Officer will run.
What can go wrong
Here is the honest failure note, and it is a real one. My first Duty Officer worked well for a week. Then one morning the standup reported that the expense sweep had found three duplicate charges. It had not. The sweep’s actual report said “no duplicates found,” and the ops-bot, reading quickly, hallucinated a problem from the phrase “duplicate check: clean.” I spent twenty minutes chasing charges that did not exist. An ops-bot summarizing summaries is a telephone game, and every hop between a fact and your eyes is a chance to garble it.
The fix has two parts. First, the standup’s contract now includes the raw-report rule: any item that needs my attention must quote the worker’s report verbatim, not paraphrase it. Paraphrase is where the garbling happens. Second, the standup links back to each routine’s thread. When the report says something surprising, I read the source before I act. The ops-bot exists to tell you where to look, not to replace looking.
A second, slower failure mode: an ops-bot with broad instructions drifts toward doing the workers’ jobs. Mine once tried to “help” by re-running the bookmark check it thought had failed, because the Sunday report was late. Two routines then owned one task, and their reports disagreed. The guardrail is the same as the specialist team’s: the work order pattern. The ops-bot may write a note for a worker (“bookmark check is late; re-run when ready”). It may not do the work. Our routines lesson covers what belongs in a routine’s own instructions; the ops-bot’s instructions should reference the workers, never duplicate them.
Start with the standup
Do not build the whole pattern today. Pick the morning standup prompt, name your routines in it, and run it once tomorrow at 7:30am. Read the standup, then read one of the raw reports, and check that they agree. That single verification is the habit the whole pattern rests on: trust the ops-bot, verify at the source.
The playbook comes second, and the postmortem habit comes when the first mistake happens. Six weeks from now you will have a team that reports, an ops-bot that summarizes, and a playbook that remembers, and the bottleneck in the middle of it all will be gone. You will not have gotten better at managing bots. You will have stopped.
