ZCoP: The Plan That Rewrites Itself

Most attempts to make a language model do real work fail in the planning, not the execution. You hand the model a fat goal, it produces a confident wall of steps, and then it marches down that wall even as the first step teaches it the third step was wrong. The plan was written when the system knew the least, and it never gets revised. By the time the work is done the plan describes a project nobody is doing anymore.

ZCoP, Zero Chain of Prompt, is the doctrine I wrote to fix that. I wrote it in October 2024, before the agent frameworks made this fashionable, and the surprising thing on rereading it is how little has aged. It is not a prompt. It is a way of structuring a whole body of work so the plan stays alive: decompose the goal into a typed hierarchy, attach a definition of done to every node, and expand the tree lazily, one step at a time, rewriting the roadmap after each step with what you just learned.

This is the Architecture series, so I will give you the blueprint, not the war story. Here is how the thing is built and why each part is shaped the way it is.

The core bet: the plan is a living object, not a document

The dominant mental model treats a plan as something you write once and then obey. ZCoP treats the plan as state. It is the single artifact the system carries through the whole job, and it is rewritten after every executed step. The roadmap you finish a task with is never the roadmap you started it with, because the act of finishing taught you something the start did not know.

That inversion drives every rule below. If the plan is state, then it has to carry enough structure to be machine-updatable: typed nodes, explicit success conditions, and a status field that means something. And it has to be cheap to revise, which means you only ever flesh out the part you are about to touch.

Initiation: refuse to start until the goal is written down

Garbage goal, confident garbage plan. The most underrated work happens before a single task is broken out.

The first move is to pin the end goal in plain words: target outcomes, key deliverables, desired impacts. If the person asking does not yet have a clear vision, the system does not paper over the gap. It asks three specific questions: who is the beneficiary, what deliverables should the work produce, and what impact counts as success. Then it writes the goal back in one sentence and stops, waiting for confirmation before it builds anything.

This sounds like a courtesy. It is actually a load-bearing gate. A goal you cannot state in one confirmable sentence is a goal you cannot define done against, and a plan with no definition of done is a plan that will run forever.

The decomposition: a typed tree with done at every node

ZCoP breaks the goal into a three-level hierarchy, and each level carries the same skeleton.

The Goal sits at the top with its own description, reasoning, definition of done, acceptance criteria, and a progress bar measured as tasks done over tasks planned.
Tasks, the epics, each carry a definition of success, a subtask plan, and a prompt that drives them.
Subtasks, the features, each carry their own definition of done, the observations or facts that need to be surfaced or asked from the user, and the specific prompt that achieves them.

The status field is where the design earns its keep. A node in flight records its next actions and a reflection on what is missing, blocked, or still needed. A node that is finished collapses to something much smaller: its key elements, its atomic facts, and a one-line summary. Once a subtask is done, the system no longer carries its full working context. It carries the distilled residue, the few facts the rest of the plan actually needs. The tree stays light because completed work compresses itself.

That compression is not cosmetic. It is what lets a long job stay inside a finite working memory. The plan grows downward as you expand new steps and shrinks upward as old ones resolve into facts.

Lazy flow: expand the next step, not the whole tree

Here is the mechanic that makes ZCoP more than a template, and the one I have come to call lazy flow.

A naive planner expands the entire tree up front, every task and subtask detailed to the leaf, and then executes the frozen structure. ZCoP refuses to do that. It details only as far ahead as it can justify with the context it actually has. It plans the immediate step in full, gestures at the steps beyond it, and defers their real expansion until it arrives, carrying the facts the earlier steps produced. The instruction in the original is blunt: the table is regenerated after the execution of the current step, before proceeding to the next one, and it must be updated with what has been achieved.

This is lazy evaluation borrowed from programming and pointed at planning. You do not compute a value until something demands it, because computing it early means computing it on stale inputs. A plan written for step seven before step three runs is a guess dressed as a decision. Lazy flow keeps every decision as late as it can afford to be, so each one is made with the most context and the fewest assumptions. The plan flows toward the goal at the pace that information arrives, not faster.

The cost is that you cannot see the whole route at the start. That is the point. The route does not exist yet. It is being built out of what each step reveals, and a planner that pretends otherwise is just front-loading its mistakes.

The reflexes: vocalize, check externally, confirm

Three reflexes run at every node and keep the lazy flow honest.

Vocalization. Before a step, the system states briefly what it is about to do. After a step, it updates the roadmap and states what comes next. The plan is never a black box; its reasoning is always on the surface where a human can catch a wrong turn early.

The external check. At every node the system asks one question: do I have everything I need, or should I do some research first. This is the seam where the plan admits its own ignorance. A step that needs outside information is not allowed to hallucinate its way past the gap. It is required to go get the information or flag that it cannot.

The confirmation gate. After each task the system stops and asks the human to confirm before proceeding, and it pairs that request with a preview of the next step and a prompt for any input the human could usefully supply in advance. The work moves in confirmed increments. Nobody wakes up to discover the agent took twelve steps in the wrong direction overnight.

Why this still holds up

Read in 2026, ZCoP describes things the agent frameworks reinvented later under heavier names. The definition of done at every node is a goal contract. The status field that collapses to atomic facts is structured memory with compression. The external check is tool-use gating. The confirmation gate is human in the loop. The roadmap rewritten after each step is reflection. None of these was exotic when I wrote it; they were just not yet assembled into one doctrine and pointed at a single goal.

What the original does not have, by 2026 standards, is the runtime: the tasks are linear rather than a real dependency graph, the roles are not split across specialized agents, and the gatekeeping is a human pause rather than a policy an autonomous system could enforce on itself. Those are upgrades to the engine, not corrections to the design. The doctrine underneath is intact.

The blueprint in one breath

Strip away the detail and ZCoP is four commitments stacked in order.

Write the goal down before you plan. One confirmable sentence, or you have nothing to define done against.
Decompose into a typed tree where every node carries its own definition of done. Finished nodes compress to atomic facts so the plan stays light.
Expand lazily. Detail the next step in full, defer the rest, and rewrite the roadmap after every step with what you just learned.
Keep the reflexes at every node. Vocalize the move, check whether you actually have what you need, and confirm before you proceed.

None of the four is hard on its own. The architecture is in the ordering and the insistence: the plan is a living object, and the next step is the only one you are allowed to fully believe in yet. Build it that way and you get something most LLM workflows never manage. A plan that is still true at the end of the work, because it rewrote itself the whole way there.

Related reading: Orchestration Is the System makes the companion argument from the floor: the model is one component, and the layer that routes the work, gates it, and decides when the model is wrong is the real product.