From a conversation thread to a structured project

The problem

A measurable, avoidable cost

A long-lived agent re-sends its whole growing context on every turn, so input tokens climb worse than linearly, and a cold session re-reads the thread before it does any work.

This method closes the gap by giving the work a structure on disk that holds its own memory, so a run resumes from recorded state.

The shape

Eight steps

1. Start from the open thread. Name the project and its scope in one sentence.
2. Name the work lanes. Each kind of work becomes a lane, with 00 above them.
3. Set up system surfaces. Give every file a class so the path says what to trust.
4. Create task home folders. One dated folder per task, with a fixed file set.
5. Add the schemas. The catalogue and the work-home schema hold it together.
6. Record checkpoints as memory. A recorded state change is the unit of memory.
7. Keep a local and cloud boundary. Memory stays local, heavy work goes to cloud agents.
8. Hand off in writing. Work moves between lanes with a written contract.

Concept · lanes and actors

A lane is a team, not a single worker

Lane. A team that owns one kind of work such as research, data pipelines, modeling, writing or packaging. It runs a lead actor and spawns supporting actors as the work compounds.

Actor. A worker inside a lane, named by the lane letter and an instance number, so lane one runs A1 and A2 and lane two runs B1 and B2.

Concept · orchestration

00 is central, the lanes orchestrate locally

00 is the central orchestrator. It routes work and reconciles state, and leaves execution to the lanes. Each lane has a local orchestrator, 01 through 016, that records step state for its actors and relays verified summaries up to 00.

Step 3

System surfaces

Give every file a surface class with one job, so a reader knows from the path alone what to trust.

Steps 4 and 5

Task homes and schemas

Task home. One folder inside a lane named yyyymmdd_slug, carrying a manifest, a readme, a step log and handoff notes. A session opens the task home and hydrates from it.

Two schemas. The catalogue schema defines the lanes and the folder rules. The work-home schema defines what every task folder must contain.

Step 6

Checkpoints are the unit of memory

A checkpoint is a recorded state change in what a lane knows, can do, is blocked by or is allowed to write.

The types cover hydration, pre-write inventory, worker reports, gate transitions, blockers, handoffs, commits and authority changes.

Steps 7 and 8

Local memory, written handoffs

Local and cloud boundary. The memory and audit layer stays local. Production work such as formatting, packaging and cross-repository assembly can be delegated to cloud agents.

Handoff. When work moves between lanes or sessions, the contract is written in the task home, so the next agent takes over with the context intact.

What this buys you

The thread becomes a system that remembers

A session that starts weeks later opens the relevant task home, reads the recent checkpoints and continues with the thread intact.

In practice · the catalogue

Sixteen lanes, A through P

The ID is the lane's local orchestrator, 01 through 016, under the central 00. Actors take the lane letter plus an instance number.

In practice · aimez.ai

The cast deployed on a real program

Some lanes are live and some are cast and held.

Honest scope

Recent and still maturing

The checkpoint discipline reduces context loss, and it depends on care. A change in one lane reaches another when it is carried there on purpose.

Naming the limit is part of the practice.

Read more

Go deeper

The full method in prose, plus the worked program and the cost story.