When Your AI Assistant Becomes a Project Manager
I have been building AI systems for a while now, and the same problem keeps appearing at every level.
The AI can do the work. It just cannot manage the work.
That distinction sounds subtle until you experience it. An AI that can write beautiful code, draft documents, and run complex analysis is still useless if it cannot decide what to do next without you spelling it out every single time.
So I built something to fix that.
The Problem
My AI assistant Karl runs on a system called OpenClaw. He has access to my files, my code, my tools. He can read, write, search, and execute. He is genuinely useful at the individual task level.
But every session worked the same way.
I would describe a task. Karl would execute it. Then he would wait for the next instruction.
That works fine for a single task. It falls apart when you have eight things that need doing. I do not want to sit there and hand out assignments one at a time like a micromanager. I want to have a conversation about what matters, agree on the scope, and then go live my life while the work gets done.
The Dispatcher
The solution was embarrassingly simple in retrospect.
I created a JSON file called TASK_QUEUE.json in Karl's workspace. Each task has an ID, a title, a priority, a status, a description, scope, and acceptance criteria. Then I set up a cron job that runs every hour.
The dispatcher reads the queue, finds the highest-priority pending task, spawns an isolated worker session to handle it, and updates the status when done. Max two concurrent workers. If a worker goes stale, it gets re-dispatched on the next cycle.
That is it. That is the whole system.
I considered using a message broker like Redis or RabbitMQ, but for a single-machine setup with one consumer, a JSON file is the right level of abstraction. The overhead of running a broker would exceed the complexity of the work it manages.
But the impact was immediate.
The Shift
The first time I queued eight tasks and went to bed, I woke up to find five of them completed. Workers had spawned, run tests, reported results, and cleaned up after themselves. The dispatcher had monitored for stale sessions and re-dispatched the ones that failed.
No prompting. No hand-holding. No "are you still working on that?"
The interesting part was not the automation. The interesting part was the shift in how I interacted with Karl.
Instead of assigning tasks one by one, I started having planning conversations. I would describe the work in Discord DMs. Karl would ask clarifying questions. We would nail down the scope together. Then he would queue it and say something like "Cool, got that queued up."
The DM conversation stays snappy because it is not doing the work. It is planning the work. The dispatcher handles execution.
Why This Matters
Most AI assistant conversations look like this:
- Human asks for something
- AI does it
- Human asks for the next thing
- AI does that too
- Repeat until someone gets tired
That is a fancy calculator with extra steps.
The pattern that actually feels useful looks more like this:
- Human and AI discuss priorities
- AI helps refine scope and catch misunderstandings
- Tasks get queued
- Workers handle execution independently
- AI reports back when done
The difference between those two patterns is the difference between a tool and a coworker.
A tool waits for instructions. A coworker understands the work, manages their own time, and comes back with results.
The Architecture
The implementation has three layers:
Conversation layer. Discord DMs or webchat. This is where planning happens. Scope gets discussed, clarified, and agreed upon. No heavy work happens here. If something takes more than 30 seconds, it gets queued.
Dispatch layer. A cron job that runs every hour. It reads the task queue, picks the highest priority pending task, spawns an isolated worker, and monitors completion. If a worker goes stale or crashes, the next cycle re-dispatches it.
Execution layer. Isolated worker sessions with their own context. Each worker gets a clear objective, scope constraints, and acceptance criteria. They do the work, run tests, and report back.
The separation matters because each layer has different requirements. Conversation needs to be fast and responsive. Dispatch needs to be reliable and patient. Execution needs to be thorough and isolated.
Trying to do all three in one session is why most AI assistant workflows feel broken.
What I Learned
The biggest surprise was how little infrastructure was needed — the dispatch pattern that enterprises typically solve with a message broker and worker pool collapsed to a file and a timer at this scale. A JSON file. A cron job. Some behavioral rules in a system prompt. That is genuinely all it takes to turn a single-task AI into a multi-task coordinator.
The harder part was getting the behavioral rules right. The dispatcher needs to know when to re-dispatch a stale task versus when to mark it blocked. The conversation layer needs to know when to ask questions versus when to just queue something. The execution layer needs to know how long to persist before giving up.
Those are not technical problems. They are judgment problems. And they are the kind of problems that benefit from iteration rather than theory.
If you are building AI workflows, the single most useful thing you can do is separate planning from execution. Even a rough version of this pattern will change how you work.
Not because the AI gets smarter. Because you stop being the bottleneck.
