Multi-agent workflows
Mission control: the router, the shared brain and the runbook behind dozens of AI jobs
Every morning dozens of scheduled AI jobs wake up across the cloud and a Mac mini: ad monitors, content runs, research desks, store upkeep. Before any of them does real work it asks a router which model to use, reads the same brain as everyone else, and follows one runbook. That is the bit nobody posts about, and it is the bit that makes the rest work.
Once you have more than a handful of AI jobs running on a schedule, the problem stops being “can the AI do this” and becomes “which of my jobs is doing what, on which model, using which rules, and does it know what the others decided yesterday”. This is the layer that answers that.
Step zero: the router
Every job starts the same way. Before touching anything, it sends a short description of today’s task to a router. The router runs on Clef, a small and very fast decision model, and answers in under a couple of seconds: which tier of model the job deserves, how hard it should think, whether it needs images or video, and which skills and connectors to load.
A job that formats a spreadsheet gets the cheap tier. A job that writes an article or reviews a portfolio gets the expensive one. Every call is logged, so I can see where the effort goes and which jobs are overpaying. I wrote about why this matters before I had built it. Now it is the first line of every job.
One brain
Every session, whether it is a cloud job, an OpenClaw agent or me in a chat on my phone, reads the same Postgres database before non-trivial work and writes back any decision it changes. One key per topic, overwritten on update, old versions kept. The store’s rules, the investment mandate, my working preferences, which machine does what.
Before this, the same rules lived in memory files, shared docs and the instructions of each job, and they drifted apart. Now there is one copy, and everything else points at it.
A second database holds the noisy stuff: run logs, every comment and DM an engagement job has sent, metrics, lessons. It searches by meaning as well as keywords, so a job can ask “have we said something like this to this person before” and get a straight answer.
One runbook
A single document sets the rules every job follows. Quiet hours from 11pm to 7am. Spend caps per run. Nothing posts, publishes or spends without my approval. Which machine runs browser work. How to fall back when a connector fails, and the order to try the alternatives in. When a rule changes, it changes once, and every job picks it up on its next run.
The audit that runs itself
Once a week a job reads every other job’s instructions, checks them against the brain and the runbook, and fixes stale lines: an old device ID, a retired tool, a rule that changed. It is the most boring job on the system and it has saved more runs than any other.
What broke
- Jobs pinned to things that moved. A browser ID changed and four jobs quietly stopped working because each had the old one hard-coded. They now read it from the brain.
- Memory files that filled up. One store log hit its size limit and every job that appended to it failed. Logs moved to the database, and memory now holds rules, not diaries.
- A router that was too cheap. The fastest model misrouted anything involving video. The default is now the slightly bigger one, and the cheap one is opt-in.
What I would tell you
The first ten AI jobs are about prompts. Everything after that is about plumbing: one place for the truth, one set of rules, and a log you can actually read.