The plan document is the unit of work

The cheapest place to catch a mistake is the diff the plan.

That sentence is on the front page of this site, and it is the smaller half of the argument. The cost claim is easy to nod at and easy to file away: of course a paragraph is cheaper to fix than a pull request. The claim underneath it is the one worth arguing about.

In agent-driven work, the plan document is the unit of work.

Not a message. Not a prompt. Not a stage you pass through on the way to the real artifact. A document — something with an identity, a state, and a history; something you version, mark up, argue with, put down, pick back up days later, and approve. Builds, reviews, diagrams, and the memory of what you decided are all downstream of it.

Get the document right and most of what follows is bookkeeping. Get it wrong and no amount of diff review will save you, because by the time there is a diff, the decision you should have argued with is already load-bearing.

For thirty years the unit of work in software was the line, and the IDE is built around that assumption from top to bottom. The file tree indexes lines. The editor edits them. The diff reviews them, blame explains them, the merge resolves them, and the review tool threads a conversation onto them. It is an excellent stack, refined by an enormous amount of good engineering, and it is aimed at a target that agent-driven work has quietly moved.

When an agent writes the code, you stop editing lines and start editing intent. That is not a claim that the code stops mattering. It is a claim about where a minute of your judgment is worth the most. By the time the agent has produced four hundred lines, every decision that determined whether those are the right four hundred lines has already been made: which approach, what to leave out, which constraint is real, what the failure mode is, what happens to the thing it replaces.

Those decisions were all made in one place — a plan you skimmed and answered with a sentence. The leverage moved upstream. The tooling stayed where it was. The plan is still a chat message.

Document is doing real work in that sentence; it is not a synonym for long text. A message and a document can hold the identical words and still be different objects, because a document has three properties a message does not.

identity — Every block in a Redline plan carries a stable id (rl:blk-…), written into the markdown as a comment sidecar and preserved through every transformation: parse, edit, revision, restore, export. That is what makes a comment stick to a paragraph rather than to a position in a buffer. When the agent rewrites the section around it in v7, your objection from v3 is still attached to the thing it was about.

state — A comment is not a remark; it is an item with a lifecycle: draft → submitted → resolved → accepted, with reopened for the ones that came back wrong and withdrawn for the ones you dropped. The agent has to return a resolution for every comment you submit, and nothing is auto-accepted. “Addressed” becomes a state you assign rather than an impression you form.

history — Revisions are numbered and kept: v1 through vN, each one restorable and exportable. The document is not the latest message about the plan. It is the plan, carrying the record of how it got that way.

Add an approval event at the end and you have a unit of work: identity, state, history, and a definition of done. Everything else Redline does — discussion forks off a single comment, agent-authored edits staged as tracked suggestions, exports, the memory built over past decisions — is available only because the thing at the center is addressable.

The fastest objection is that Redline is a worse version of the agentic code editor you already use — a plan reviewer that had to grow an IDE around itself and did a thinner job of it.

It is worth answering precisely, because the honest answer is not “it does something else entirely.” Redline has a file tree, and a real editor behind it: open a file from the sidebar, press Edit, and you get CodeMirror with grammars, undo, search and ⌘S — watching the file on disk so an agent editing underneath you is reconciled rather than clobbered. There are terminals. You can absolutely change a line.

What Redline does not do is arrange the workspace around any of that. A code IDE puts your source files at the center and builds the room around the code; Redline puts the document at the center and treats the code as something you reach for while you are still arguing about what to build. The difference is the center of gravity, not the feature list — and it is why the two compose instead of competing. Redline operates one level up from the buffer.

In a code IDE with a good agent, the plan is a chat message. It is real, it is often excellent, and the tool treats it exactly the way it treats everything else in the transcript — which means you cannot point at its third paragraph, because the message is the only addressable unit. There is nothing to resolve, because nothing carries a state. Round four has no structured memory of what you objected to in round two beyond whatever survived in the context window. Scroll far enough and it is gone.

The two tools answer different questions. A code IDE answers is this line right? Redline answers is this the right change to be making? A serious workflow wants both, and they compose cleanly: research it, draft it, argue the plan until it is the plan you actually want, approve it — and then let the agent, and your code IDE, take it from there.

Redline is also not a plan viewer. Reading a plan more comfortably is not the point; the point is that your reply stops being one prose message and becomes structured, anchored, resolvable markup that the agent has to answer item by item.

None of this is worth much as assertion, so here is one document out of the record. Session 8388e9f8 is a plan for Redline itself, reviewed inside Redline. It ran ten revisions and grew from 19,120 characters to 55,738 — the plan nearly tripled under review, which is the shape of a plan that was argued with rather than approved.

Twenty-three comments landed on twelve distinct blocks: nineteen pieces of feedback, three questions, one tracked edit. Every one of them came back with a resolution. Seven opened a discussion fork — a read-only side conversation with a forked agent, twenty-five messages in all — so a question could be chased down without disturbing the held session.

Then the part that matters. After v6, the reviewer put it down. The Claude Code session that had been holding the plan did not survive the gap. The better part of four days later they came back — and the document was still there, so they restored it, three times across v7, v8 and v9, each restore re-presenting the same 46,590‑character body to a fresh agent. Two new comments were written against v9, a revision that exists only because the document outlived the process that produced it. v10 came back 55,738 characters long.

That is the whole thesis in one session. Chat scrollback cannot do it — not because the transcript was lost, but because there was never a unit of work to pick back up. Only a conversation that ended.

A page making a categorical claim should say what holds it up. The argument above rests on the loop with real mileage behind it: plan sessions and the review round-trip, discussion forks, the drafter, the terminals, the browser, and the memory built over past decisions. That is where the record is thick, and it is the part of Redline used every day.

Redline has surfaces beyond it — line-by-line code review, research missions, orchestrated execution. They are younger, and the record behind them is thinner than the record behind the plan loop. The thesis does not lean on them. It needs one thing to be true: that the plan is a real object rather than a message. It is, and the rest of the product follows from that.

What stands between this argument and general agreement is not a missing surface. It is roughness — and roughness is a fixable, ordinary kind of problem.