By now you've directed an agent and watched it build something real. Here's the question that decides whether you ever feel in control of that work: where does the plan live? Because if the plan lives in one place and the work lives in another, you become the unpaid courier between them. This lesson is about closing that gap for good — so the plan you read is the same plan the agent runs.
Think about your own week. The to-do list is in one app. The calendar is in another. The project board — the columns, the cards, the colored labels — lives in a third. And the work itself is somewhere else entirely: in files, in documents, in the thing that's slowly taking shape. Four places, four pictures of the same project, and none of them agrees with the others for more than an afternoon. So someone's job quietly becomes updating the board. Dragging cards. Checking boxes. Copying what's true into a tool that only ever drifts away from the truth again.
That isn't laziness, and you can't fix it by buying a better tracker. It's deeper. The plan and the work are two separate things in two separate places, and nothing connects them. Every status meeting where someone reads the board aloud and someone else corrects it from memory is the price of that gap.
A workbook closes the gap with one stubborn idea: the plan isn't a note about the work. The plan is the work.
one file yOu read aNd the agEnt runs
Here's the move. Instead of keeping the plan in a database somewhere and the real work somewhere else, the plan is written as plain text — readable sentences, in the same file as everything else — and that text is the only copy there is.
It looks like an ordinary outline. A heading for each task. A small word in front of each one that says where it stands: TODO for not-yet, DONE for finished. Underneath a task you can write why, in full sentences, right where the decision lives instead of buried in a comment thread three tools away. "Waiting on the brand pass — see the thread with Maria." That note isn't a sticky on top of the plan. It's in the plan, traveling with it forever.
The reason this matters to you: the file is written to be read by two readers at once. You read it and see a to-do list. The agent reads the exact same lines and sees instructions it can carry out. Nobody translates between the two. So this is also how you tell the agent did its job right — you don't take its word from a chat bubble, you open the one file and read what it says is done.
the only rUle that rUns the whOle thing
You might expect that turning a plan into something a machine can run takes a thicket of settings — priorities, schedulers, assignment rules. It takes almost nothing. The whole engine rests on one small word: ready.
A task is ready when two things are true: it's still unfinished, and everything it depends on is already done. That's the entire definition. No scheduling configuration, no clever algorithm deciding who does what. Readiness is just a fact you can work out by reading the file.
So you tell the plan which tasks depend on which — "you can't build the page until the artwork is rendered" — and from those few hints the order of work falls out on its own. You never draw the sequence yourself. You never maintain it. The plan works it out every time, from the current state of the file: this is done, so that one is now ready; that's still waiting, so the thing after it waits too.
Then the work is a loop so simple it barely earns the name. Find the tasks that are ready. Do them. Write DONE back into the file. Look again. Anything that was waiting on those tasks is now ready, so do those next. Repeat until nothing's left. The plan clears itself one wave at a time, and nobody ever wrote down the order — the order was hiding in the dependencies all along.
Two quiet payoffs come with this. First, when the work stalls, the reason is never a mystery. If nothing is ready but tasks remain, something is stuck — and stuck always has a name, because the only thing that can hold a task back is a dependency you can point to. "Why isn't this moving?" has an answer you can read, not a meeting you have to schedule. Second, you can tell at a glance whether the agent followed your direction or wandered: a finished task resting on an unfinished one is a contradiction the plan exposes, not a thing you have to catch by intuition.
the boarD talks Back — boTh ways
Now the part that makes the four-tools problem dissolve.
A kanban board with its columns. A timeline. A calendar of deadlines. In a workbook, none of those is a separate thing with its own database. Each is a rendering of the plan file — drawn from it the way a web page is drawn from its underlying text. If you go looking for a table of cards or a column schema, the search comes up empty. There's no board stored anywhere. That absence is the design, not a missing feature.
But a rendering you can only look at would be half a tool, so the board is honestly two-way. There's a read half that draws the columns from the file, and there's a write half that takes your action and writes it straight back into the same file. Drag a card from "doing" to "done" and the word in the file flips to DONE. Edit the file by hand and the board redraws to match. The two can never disagree, because there aren't two of them — there's one file wearing different clothes, and editing the clothes edits the file.
That two-way path is the whole reason the board is real and not a screenshot. You're not maintaining a tracker that mirrors the work. You're touching the work directly, through whichever view is in front of you — the outline, the board, the calendar. They're all editing the same lines.
time thE enginE has tO honor
Here's where it would be easy to over-promise, so let's be exact. "Every Friday at nine" is written right on the task — a timestamp in the same readable file as everything else. A deadline that's passed isn't a notification you missed; it's a fact anyone can read off the plan. That part is lovely and true.
But a file can't fire itself. A few kilobytes of text sitting on a disk at nine a.m. does what text always does: nothing. So the schedule has two halves, and it's worth knowing both. The declared half is the timestamp you write into the plan — that's for you and the agent to read. The cadence half is an engine-side heartbeat — a small steady tick that wakes the agent up, has it read the plan, and notice what's now due. The line in the file declares the intent; the heartbeat is what actually shows up at nine.
So "self-running schedule" is fair as long as you hold the honest version of it: the plan says when, and the running engine keeps a metronome going so that when gets honored. It isn't the text magically animating itself. It's a declared time and a worker that wakes to meet it — and because both are in the open, you can always check whether the thing that was supposed to run actually did.
the workErs are iNterchaNgeable
The loop genuinely does not care who clears it. A person working down the ready list and an agent waking on the heartbeat are interchangeable. The agent might clear the first round overnight; you pick up the next round with your coffee; neither of you has to brief the other, because the file is the meeting. That's what makes handoffs between people and machines boring, in the best possible way.
And before a task gets to call itself done, the plan can demand proof — a small check that has to pass, instead of taking the writer's word. That's a separate idea worth its own lesson, but it's the reason the ready loop doesn't quietly rot: DONE can be made to mean actually finished and verified, not an agent typed five letters.
what iT does Not prOmise
Two honest edges, because this is powerful enough to be worth being straight about.
A plan made of free text can still drift. An agent writing into it can duplicate a task or mark something done that isn't. What a workbook changes isn't that drift becomes impossible — it's that drift becomes catchable. Because the plan is structured, the contradictions are checkable facts: a task that depends on something that doesn't exist, a finished task resting on an unfinished one. These get caught and named, with a line number, instead of passing as a shrug at the next standup.
And running a plan is not the plan running itself. This was never about software that works without you. Direction stays human. The workers stop at the edges you set. What changes is that following through gets cheap — the tedious part, the keeping-it-all-in-sync part, the dragging-cards part, simply goes away. The judgment doesn't. That's still yours, and it always will be.
What's left is the thing you wanted all along: one plan, in one file, that you can read and the agent can run — a board that talks back both ways, a schedule a steady heartbeat keeps honest, and no second copy to keep in sync, because there was only ever one.