From a conversation thread to a structured project

The method, written as eight steps.

This walkthrough takes one open conversation thread about a project and grows it into a structured, multi-session system: work lanes, system surfaces, task home folders and schemas. The operating layer is Cursor, and the files in example/ are a sanitized demo that carries no private project content.

The problem

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 and re-derives its decisions before it does any work. The gap is measurable, the context a run carries and re-bills. This method closes it by giving the work a structure on disk that holds its own memory, so a session resumes from recorded state.

The eight steps

Start from the open thread

A project begins as one long conversation thread that holds intent, decisions and dead ends. Name the project and its scope in a single sentence, so everything after has a fixed center.

Name the work lanes

List the distinct kinds of work the thread contains. Each kind becomes a lane, a team with a lead actor that spawns supporting actors as the work compounds. A zero element called 00 sits above the lanes as the central orchestrator.

See example/actor_catalogue.yaml and 00, the orchestrator.

Set up system surfaces

Give every file a surface class with one job: authoritative memos, derived reports, narrative logs or current state. The path alone then tells a reader what to trust.

See system surfaces.

Create task home folders

Each piece of work gets a task home: one folder inside its 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.

See example/work_home_schema.yaml.

Add the schemas

Two schemas hold the system together. The catalogue schema defines the lanes and the folder rules. The work-home schema defines what every task folder must contain. Both are plain files a person and an agent can read.

Record checkpoints as memory

The unit of memory is a checkpoint: 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.

See example/checkpoint_policy.yaml and a step log.

Keep a 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, so long-running work stays coherent while the heavy steps run elsewhere.

Hand off in writing

When work moves between lanes or sessions, the handoff is written down in the task home. Because the contract is explicit, one agent takes over from another with the context intact.

What this buys you

A session that starts weeks later opens the relevant task home, reads the recent checkpoints and continues with the thread intact. The conversation thread becomes a system that holds its own memory.

Glossary

00: The zero element and central orchestrator. It routes work and reconciles state, and leaves execution to the lanes.
Local orchestrator: A per-lane orchestrator, numbered 01 through 016, that records step state for its lane and its actors and relays verified summaries up to 00.
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.
System surface: A file class with one job, namely authoritative memos, derived reports, narrative logs or current state.
Work home: One task folder inside a lane, named yyyymmdd_slug, with a manifest, a readme, a step log and handoff notes.
Checkpoint: The unit of memory, a recorded state change in what a lane knows, can do, is blocked by or is allowed to write.
Handoff: A written transfer of ownership or next-action authority between lanes or sessions.

Honest scope

This method is recent and still maturing. The checkpoint discipline reduces context loss, it depends on care, and a change in one lane reaches another only when it is carried there on purpose. Naming the limit is part of the practice.

Slide deck: the walkthrough deck · Demo page: the eight steps in cards · In practice: the aimez.ai program · Source: GitHub