Work trees: making every project easy to pick up

A retail chain is rebuilding its website before the end of the year. Three weeks in, the person running the project goes on extended leave and a colleague takes over. She opens the shared folder and finds dozens of documents, a few chat threads and a half-finished to-do list. It takes her two days to work out what is done, what is waiting on design, and which task is actually due next week.

Those two days were not her fault. The project's status had simply never lived in one place. It was spread across people's heads, conversations and inboxes, and when a person left, the status left with them.

When the work involves several AI assistants as well as people, the problem gets sharper. When an AI conversation ends or its context is compressed, what was said earlier can disappear. We needed something that does not depend on anyone's memory — something that lets any person or any AI walk in at any time and know within minutes where things stand. We call it a work tree.

A work tree is a map

The root of a work tree is the project's goal, such as "launch the new website by year end". A few branches grow from it, each a fairly independent stream of work: content, design, engineering, launch. Branches split further until they reach leaves — concrete pieces of work one person or one AI can finish in a reasonable stretch of time.

How small is a leaf? Our test is simple: someone reading it should know what to do and what done looks like without asking a single question. "Handle the homepage" is not a leaf. "Rewrite the three homepage sections in the new brand voice and send them to the owner for review" is.

The map is not for show; it is for handover. It answers three questions only: where is this going, where are we now, and what happens next. Everything else — discussion, references, background — can live elsewhere and be linked.

Every leaf says who moves it

Once the tree is split, each leaf gets one more label: how this piece of work moves forward. In practice there are three kinds.

• Work that needs judgment. Each case is different and involves trade-offs — the direction of a client proposal, an architectural choice. This goes to a dedicated working session where an AI prepares options and a person decides.
• Many similar tasks. The same action repeated hundreds of times, such as adding the same fields to a hundred articles. This is split into small pieces, handed out to several AI workers in batches, and spot-checked.
• Routine work. Things that happen every day or week, like a morning summary or a backup. This runs on a schedule.

The benefit is that human attention lands where it is actually needed. Nobody reviews repetitive tasks one by one, and nobody has to remember to press the button for routine ones. What a person sees each day is the handful of leaves marked "stuck" or "waiting for you".

Each node holds four fields

Every node carries a short status. We deliberately keep it to four fields, because the more fields there are, the less anyone fills them in, and soon the whole thing is out of date.

• Where it is: what has been done, in a sentence or two.
• Next step: one concrete thing someone could start now — not a direction.
• Waiting on: who or what this is stuck on — a person, an outside party, or nothing.
• Due: when it needs to be done. If there is no deadline, write "none" rather than leaving it blank.

Together, these four fields are the node's stop point. A stop point is not "we got to page three". It is "this is where the next person should begin". If the stop point is right, a handover needs no meeting.

Back to the retail chain. If the original owner had left these four fields on every node, her colleague would have opened the tree and seen within five minutes: homepage copy done; next step, hand the new product pages to design; waiting on design's drafts; due next Wednesday. No digging through chats, no phone call to someone on leave. That is the whole reason the four fields exist.

Status lives in files, not chat

The most important rule is that a work tree must be a readable, versioned file — not a conversation.

The reason is plain. Conversations with an AI end, get compressed, or move to another tool. If "where it is" only exists in one conversation, then a different AI or a different computer will act as if it never happened. Files do not have that problem. Any AI that can read a file can continue from the same stop point without guessing and without relying on anyone's memory.

So every new piece of work begins by reading the work tree, not by trying to recall where the last chat left off. And every piece of work ends by updating the four fields. Both steps are small, yet they make the whole project something anyone can pick up at any moment.

Branches write back to one main tree

Larger projects often have several streams running at once, each with its own smaller tree. The common failure is that every stream believes its own version is the real one, and nobody can say where the whole project is.

Our approach: a project has exactly one main tree. Branches can keep their own detail, but meaningful progress — a milestone reached, a changed next step, a new blocker — is written back to the matching node on the main tree. The main tree does not copy every detail; it holds a sentence and a link.

If two streams need to change the same node, they take turns: read the latest version first, then write, never overwriting someone else's change wholesale. It is the same courtesy people use when editing a shared document, written down as a rule.

There has to be one map, or nobody trusts it enough to follow it.

In short

• A work tree runs from a goal down to leaves, each a concrete task someone can start without asking questions.
• Each leaf names how it moves: judgment work goes to a person, repetitive work is batched, routine work is scheduled.
• Each node keeps four fields — where it is, next step, waiting on, due — which together form the stop point.
• Status lives in files, not conversations, and branches write back to a single main tree.