Codex rewrites three files you never mentioned and reports "Done." The problem is almost never the model — it is the assignment. Seven observable checkpoints for writing clearer task briefs, spotting drift in real time, and verifying output before you merge anything.
Every AI agent for business assumes you are holding the queue. Sixteen roles, more than thirty agent windows, and I talk to one of them. The dispatcher pattern that stops you being the bottleneck — the four things it must ask permission for, and the one thing it must refuse to do itself.
Skills, Subagents, and Hooks answer three different questions and get confused for one another constantly. Reusable procedure, parallel execution, or an enforced check? Three questions asked in order route any task correctly, with beginner pitfalls named.
Every AI agent for business assumes you are holding the queue. Sixteen roles, more than thirty agent windows, and I talk to one of them. The dispatcher pattern that stops you being the bottleneck — the four things it must ask permission for, and the one thing it must refuse to do itself.
Sixteen defined roles. More than thirty agent windows. I talk to one of them.
That is not a productivity boast. It is the only arrangement I found that survives past about six agents, because at six agents a specific problem shows up that no amount of tooling fixes: you become the scheduler. Every AI agent for business I have tried is built on the assumption that a person is standing there holding the queue. Past a handful of agents, that person is the bottleneck.
Every task means finding a window that is free, clearing its old context, writing the instructions, remembering that you sent it, coming back to check, reading the output carefully enough to judge whether it is actually good, and then closing the loop. Seven steps of overhead per task. Six tasks in a morning and you have spent the morning dispatching instead of deciding.
The General Manager pattern puts one agent in the middle. It sits in a permanent window. You tell it what you want. It does the seven steps.
Key takeaways
The obvious alternative to a coordinating agent is a program that does the dispatching. That is what I tried first, and it does not work — but the reason is specific and worth stating, because it tells you exactly where the line falls.
Some parts of running a group of agents are genuinely mechanical: keep the server alive, rebuild windows after a restart, sort tabs into order, poll for health. Those are jobs for a background service. They contain no judgment, they run on a schedule, and a program does them better than any agent because a program does not get tired or creative.
Other parts are not mechanical at all:
Every one of those requires reading something and forming a judgment. My automation could dispatch and it could poll. It could not judge whether output was good, could not decide that a broken tool needed fixing before continuing, and could not notice that two tasks were about to collide.
Those turn out to be exactly the parts that determine whether a day of agent work produces anything usable.
The line is clean enough to draw as a table, and drawing it saved me from building three more scripts that were going to fail:
| Job | Who does it | Why |
|---|---|---|
| Restart windows that died | Background service | Same action every time, no reading required |
| Sort tabs into the declared order | Background service | The order is written down; a program can compare |
| Poll for health, rebuild what is missing | Background service | Runs on a timer, needs no opinion |
| Decide where a large task splits | Coordinating agent | Depends on what the task means |
| Judge whether output is good or just shaped like output | Coordinating agent | Requires reading the content |
| Notice two tasks will collide in the same folder | Coordinating agent | Requires holding both tasks in mind at once |
| Decide a broken tool must be fixed before continuing | Coordinating agent | Requires weighing the cost of stopping |
Everything in the top half runs without me. Everything in the bottom half needs something that can read. Trying to move a bottom-half job upward is how you get a scheduler that dispatches beautifully and accepts garbage.
💡 "General Manager" is a job title, not a product. There is no software called this. It is a window running an ordinary agent, pointed at a folder that contains its job description — the same mechanism as every other role in the seats-and-pools split. What makes it a dispatcher is what the job description says, and specifically what it says the agent must not do.
The loop is seven steps and it repeats for every task.
Receive. A task arrives — from me directly, or from the scheduled agent that wakes up on a timer.
Predict risk. Thirty seconds of thinking about what could go wrong before starting. Batch jobs invite corner-cutting. Two windows editing the same repository will conflict. If the risk is real, flag it upward before the work starts rather than reporting the wreck afterwards.
Break down. One request becomes a set of dispatchable tasks, each small enough for one window to finish inside one context.
Dispatch. Pick a window by capability, clear it, write the task card, send it.
Monitor. Watch state. Handle exceptions without escalating them. If a tool breaks mid-task, fix the tool.
Accept. Read the output. Judge it. Reject what does not pass.
Report, then release. Tell me what happened. Clear the window.
Running several of these at once is the normal state, not a special case. A dispatcher that can only track one thing is a slower version of me.
Every one of my AI agent roles carries a trust level, and there are only two. Two is enough, and I have never wanted a third.
L1 is the level that cannot reach outside. An L1 role can read anything and write into my own files, and that is where its reach ends — it publishes nothing, ships nothing, and touches nothing anyone else can see. My content role is L1: it writes into the knowledge base all day and cannot send a single thing outward.
L2 roles act. They change things directly, within their scope. The General Manager is L2 across the whole fleet — it can dispatch to anyone — with one carve-out: it does not write code itself. It assigns code to windows that write code.
That carve-out is deliberate and it is the single most important line in the role card. A dispatcher that starts writing code stops dispatching. Its context fills with implementation detail and every other task stalls while it debugs something. The role is defined by what it refuses to do as much as by what it does.
Cutting across both levels is a smaller distinction: some roles produce only analysis. Quality review, customer analysis, investment research and the supervisor hand back a document and nothing else. That has consequences for routing, which is a section of its own below.
Here is the arithmetic when you are the coordinator.
Say a dozen tasks in flight. Each needs a window chosen, cleared, briefed, watched and accepted. Say ten minutes of your actual attention per task per day — not the task's runtime, just the human overhead of getting it started and judging the result. That is two hours a day of pure coordination, spent entirely on getting work started rather than deciding what work should exist.
The time is not the real cost. Three other things are worse.
Acceptance quality collapses. When you are the bottleneck, "did the file get created?" becomes your acceptance test, because reading the actual output takes ten times as long. Template-shaped filler passes. Code that does not build passes. You find out three days later.
Windows leak. A window occupied by a finished task is a window you cannot use. Without someone whose job is to release them, they accumulate, and eventually you have thirty windows and four available ones.
Nothing runs while you are asleep. Every task waits for your next attention cycle. A task that finishes at 2am sits until morning, and the four tasks that depended on it sit too.
The dispatcher lives in a fixed window. On startup the agent reads its instructions from the folder it launched in — the folder is the role. There is no prompt saying "you are the general manager." Point the window at the right folder and it wakes up in character.
The card is short. Here is what is in it and why each part earns its space.
Task dispatcher for the fleet. Trust level L2 — manages the whole fleet, does not write code personally. Reports to me.
Mission: track several tasks at once, each one all the way to a passing acceptance.
Two sentences. The trust level and the "does not write code" clause carry the weight.
The "does" list is the seven-step loop above. The "must ask first" list is four items, and these are the only things that stop and wait for me:
Everything else, it decides. This list is short on purpose. A long escalation list produces an assistant that asks permission constantly, which is worse than no assistant, because now you are doing the same work and answering questions about it.
The rule that makes the short list work is the one people leave out: no reply from me means approval. If the dispatcher reports something and I do not respond, it proceeds. It does not wait, does not follow up, does not pause. The four red lines are the only exceptions. Without this, every report becomes a blocking checkpoint and the whole thing runs at the speed of my inbox.
⚠️ Do not adopt "no reply means approval" without the red lines. The two are one mechanism. The red lines are what make silence safe: everything irreversible is already carved out, so the worst case of a missed message is work you would have approved anyway. Copy the permission rule without the carve-outs and you have built something that will eventually publish or delete on its own.
Five rules, each of which came from a specific failure.
Fix tools before continuing. When a task hits a rate limit, a payment error or a crashed command-line tool, the correct response is: diagnose the root cause, fix the tool, verify the fix, then resume. Not skip. Not work around. Not report "blocked" and move on. A broken tool that gets routed around stays broken and breaks the next five tasks too.
Check the history before continuing prior work. When I mention something already in progress, the first move is finding out how it was done last time and reusing the same template, configuration and thresholds. Half the "the AI did it differently this time" complaints are actually "nobody looked at what was done last time."
Predict risk for thirty seconds before accepting a task. Where is this likely to go wrong? If the answer is substantial, say so before starting.
Default to the cheapest capable model. If a task can be done by a lower-cost agent, it goes to the lower-cost agent. Only when a task genuinely needs sustained context across many turns does it escalate to a more expensive one — and that escalation gets flagged to me rather than taken quietly.
Never hardcode a window name. Resolve it by capability and project at dispatch time. The same short name means different things on different machines, which is what the roster file is for.
Window operations only through the wrapper. Never the underlying multiplexer commands directly. The wrapper knows about the roster; the raw commands do not, and raw commands create tabs in the wrong place, lose track of agents and scramble the layout.
Always clear before dispatching. Stop, clear, send. Old context contaminates new tasks in a way that produces plausible-looking wrong output — which is worse than an obvious failure, because it passes inspection.
Acceptance means reading the content. Not checking that a file exists. For code, run the build and the tests. For writing, read a section and check whether it is actually specific or just shaped like an answer. This single rule is what separates a setup that produces work from one that produces files.
Release when finished. Clear the window the moment the task closes. Windows are a finite resource and a finished task holding one is pure waste.
Delegate through a defined workflow, chosen by the shape of the job:
| Situation | Approach |
|---|---|
| Ten tasks or fewer | Watch-and-accept dispatch |
| More than ten similar tasks against a shared dataset, with written pass criteria | Batch pipeline |
| Work on another machine | Cross-machine delegation |
| Running out of context mid-job | Handoff to a fresh session |
The card states three levels, not two. Passing and failing are the obvious ones; the third exists because "not failing" is a low bar for something you leave running.
A pass is: the task got done the way I intended, the output landed somewhere with a recorded path, acceptance involved actually reading the output, and the board matches the task files.
Excellent is the one people leave out, and it is what turns a dispatcher from a relay into something worth having:
A failure is the useful list, because it is specific:
Every item on that last list is something that actually happened. An evaluation standard made of abstractions — "maintain high quality" — does nothing at all. One made of the four ways you have already failed is a checklist an agent can run against its own work.
With sixteen defined roles, the dispatcher has to know who does what. Two boundaries cause most of the misrouting, and both look obvious written down.
Broken tools go to infrastructure. Product features go to development. The dividing line is which part of the system the change lands in — internal tooling and plumbing versus shipped product code. It gets confused constantly, because "the thing is broken" feels like one category.
Report-only roles do not fix anything. Quality, customer, investment and supervisor produce analysis. Dispatch a fix to any of them and you get a document explaining the fix. Landing it takes a second dispatch to a builder. Forgetting this is the single most common wasted round trip in my setup.
The command chain has three fixed rules:
That last rule exists because a dispatcher that can edit its own audit is not being audited. It is the one piece of deliberate inefficiency in the whole design and I would not remove it.
Two more boundaries about which windows to touch at all. Some pools are mine, reserved for interactive work — the resolver excludes them automatically, which is most of the reason to use a resolver rather than a remembered name. And a busy window bouncing a message is the system working correctly, not an error to retry around.
This distinction took me a while to get right, and getting it wrong is the fastest way to build something you cannot trust.
Every role has a written list of the work it normally handles. The content role knows it owns the publishing calendar. The infrastructure role knows it owns the tooling. Reading that list is how a role gets its bearings when it loads.
That list is a reference, not a schedule. Out of sixteen roles, exactly two start anything on their own — both on timers, both doing narrow routine work. The other fourteen know precisely what they are responsible for and still do nothing until they are handed a task.
That sounds like a limitation. It is the safety property that makes the rest of it work:
| Knows its job | Starts on its own | |
|---|---|---|
| What it gives you | The dispatcher can hand it work with no briefing | Work happens while you sleep |
| What it costs | Nothing — it is a file the role reads | Every wrong decision compounds unattended |
| How many of mine do this | 16 | 2 |
Most writing about autonomous AI operations treats "runs by itself" as the goal and "waits to be asked" as an unfinished version of it. In practice they are two separate switches, and you want the first one on for everything and the second one on for almost nothing. A role that knows its job is useful the instant you dispatch to it. A role that starts on its own needs to be right without supervision, which is a much higher bar and worth paying for only where the work is genuinely routine.
If you build one thing from this article, build the first switch. Write down what each agent is responsible for. Leave the trigger in your own hands until a specific job proves it does not need you.
Context runs out. Sessions get compacted. Machines reboot. So the role card's first instruction after loading is: read the active board.
The board is one file listing every in-flight task with a pointer to its full task file. It is the entire AI task management system — no database, no app, no ticket tool. One line per task, and a rule that it gets read first. It is the recovery point, and reading it takes seconds.
Without it, a restarted dispatcher is a very capable agent with no idea what is happening — which is worse than no agent, because it will confidently start something that is already half done. This is the failure mode that makes people distrust autonomous AI operations in general, and it is entirely preventable with one text file that gets read first, every time.
🔍 Why a file and not the conversation. A conversation is the thing that disappears. Anything the dispatcher must survive losing has to live outside the conversation, in a place it is instructed to read before anything else. That is true of the board, the role card and the roster alike — three files, all read at startup, all cheap to maintain, all the reason a restart costs seconds instead of an afternoon.
You do not need sixteen roles. You need one dispatcher and a board.
Copy everything below into any AI agent session you want acting as your dispatcher. Fill in the bracketed parts. This is a complete role definition, not a description of one.
You are my General Manager. Your job is to take work I hand you, break it down, dispatch it, monitor it, accept the results and report back. You manage several tasks at once — that is the normal state, not an exception.
Identity. You are a task dispatcher, not a producer. You coordinate the whole operation but you do not personally do [WRITING CODE / DESIGN WORK / WHATEVER YOUR MAIN PRODUCTION ACTIVITY IS]. If you start doing that work yourself, your attention fills up and every other task stalls. Hand it to someone else and stay free.
Your loop, for every task: receive → predict risk for 30 seconds → break down → dispatch → monitor → accept → report → release.
What you must ask me before doing. Exactly four things:
Everything else, decide yourself and proceed. If you report something and I don't reply, that means approval — continue, don't wait, don't follow up, don't pause. The four items above are the only exceptions.
Decision rules.
Execution rules.
Routing. [FILL IN: the kinds of work you delegate and who or what handles each.] Mark which of those only produce analysis and recommendations — those cannot land a change, so anything they find needs a second dispatch to someone who builds.
Dispatch format. Every task you hand off starts with this header block, at the top, before any instructions:
From: [your identifier]
To: [recipient identifier]
Task: [one sentence]
Report when done: [exactly what you want back, mirroring what you asked for]
Then the body. Then a closing line telling them to execute rather than waiting for approval. The report instruction goes at the top because anything after the task body gets skipped. Always include a failure branch — "or tell me which step you got stuck at" — so that silence means something died rather than something failed quietly.
When you start or restart. Your first action in any session is to read [PATH TO YOUR ACTIVE TASK BOARD] and tell me what is in flight. Do this before anything else, every time, including after your context has been compacted.
How I'll judge you. You pass if tasks get done as I intended, output lands somewhere I can find, you actually read what you accepted, and the board matches reality. You fail if you accept output without reading it, let template-shaped filler through, hold capacity after a task closes, or let the board drift out of sync with what is really happening.
Acknowledge this role, then read the board and tell me what is currently in flight.
Is this an agent framework I need to install?
No. Every product sold as an AI agent for business ships its own console; this is the opposite — a role description pasted into an ordinary agent session, plus one text file it reads at startup. You can run it in a browser tab today.
Does the dispatcher need to be the most capable model I have?
It needs to be good at judgment and cheap enough to leave running, which usually means yes for the dispatcher and no for the workers. The dispatcher's job is deciding and accepting; the workers do the volume. Sending the volume to a cheaper model is one of its own decision rules.
What if I only have two or three agents?
Then you are the dispatcher and that is fine. The pattern earns its keep somewhere around five or six, when the overhead of coordinating stops being noise. Write the board anyway — it costs nothing and it is what you will hand the dispatcher when you get one.
Won't it just approve everything and cause chaos?
That is what the four red lines are for. Everything irreversible needs explicit permission; everything else is recoverable, and recovering from a wrong-but-reversible decision costs less than the coordination it replaces. If you find yourself wanting a fifth red line, look closely — it is usually a symptom of an acceptance rule that is too weak rather than a permission rule that is too loose.
How is this different from an agent orchestration pattern in a framework?
Frameworks orchestrate steps inside a program you wrote. This orchestrates work across sessions, tools and machines that were never designed to know about each other. They are complementary. The dispatcher will happily hand a task to something built in a framework.
What is the one part I shouldn't skip?
The acceptance rule. Everything else improves throughput; that one determines whether the throughput is worth anything. A dispatcher that accepts without reading is a very efficient producer of files.
Related tutorials
This is part of the Knowledge Base and Fleet tutorial series. Previous: Workflow Automation Tools — Send a Task, Get a Result. Next: AI Productivity Tools — Put a File Viewer and a Real Browser in Your Terminal.
— hh
Most people find out where the boundary sits by hitting it mid-task. The two layers are simple enough to understand in advance — and understanding them in advance is the whole difference.
Workflow automation tools run the task. None of them can tell you where the answer is supposed to go. Twelve tasks took 381 seconds on a timer and 40 seconds on events — here is what changed, the two rules that stopped the loop spinning, and the four-line header that makes results come back.
Every AI workflow automation guide covers the flow and skips the question you actually hit: which agent runs where. More than thirty windows across three computers, and not one of their names appears anywhere in the code. Here is the one file that answers it, and the two bugs it caused.
Grok Bot has no official API. But its cloud VM runs an internal HTTP gateway on port 1340. Here is how to reach it from your terminal using Tailscale, send commands to your bots, and wrap the whole thing in shell functions.
When I rebuild one with AI agents, you get the write-up — including the parts that didn't work. No weekly roundup, no "5 tools you need."