File organization: a three-folder test for AI work

Why it matters

Before adding another AI agent, try answering a smaller question: which document contains the current decision for your project? If finding it requires opening five nearly identical files, every delegation starts with extra explanation. The resulting output also needs checking for references to outdated material.

Dan Harrison’s proposal separates work into Atlas, Projects, and End Products: material for thinking, work in progress, and finished deliverables. What interests me is the distinction between those states. A folder becomes useful when it tells the next person what they can rely on and what still needs a decision.

Harrison reports better AI output and lower token spending after reorganizing his work. The video does not provide a controlled comparison, so I would treat those outcomes as claims to investigate. The practical opportunity is to build a small, reviewable workflow and measure whether it helps you retrieve information, produce useful work, and finish with fewer corrections.

Key points

• 00:00 Duplicate documents and ambiguous filenames expose unresolved choices. A useful cleanup should establish which decisions remain current, rather than simply produce a tidier directory.
• 02:45 Harrison introduces a skill for recurring organization. Its usefulness depends on having classification rules that a person can inspect and correct before allowing automated changes.
• 04:26 Pausing agent development creates room to examine the underlying process. For a technical worker, that means identifying the inputs, decisions, and expected outputs before adding more execution machinery.
• 05:34 Harrison introduces his three-layer adaptation, starting with Atlas. Keeping exploratory material identifiable can prevent an untested idea from becoming an instruction by accident.
• 06:41 Projects and End Products distinguish active production from completed work. The missing operational detail is an acceptance rule: creating a document does not establish that someone has approved it.
• 07:16 Harrison maps Chat, Cowork, and Claude Code to different working modes. This is his personal analogy, rather than a required workflow or an official restriction on those products.
• 08:56 His communities follow a similar progression. That example explains his commercial setup; adopting the file structure does not require copying the business model.
• 12:15 Harrison connects clearer organization with lower AI effort. Any savings depend on what information actually reaches the model, so a new directory layout alone cannot establish a reduction in token usage.
• 13:21 The discussion of excessive sophistication suggests a practical filter: keep an organizational rule when it resolves a problem you can observe during real work.
• 14:59 Harrison recommends asking AI to help organize existing files. An inventory and proposed classification provide a useful first checkpoint before anything moves.

How to apply

File organization needs transition rules

Choose one active project, such as a software implementation proposal. Set aside 30 minutes and start with copies of its documents. A limited pilot makes it easier to discover unclear rules before they spread across your entire workspace.

Use the video’s three folders to describe the state of the material:

| Layer | Contents | Requirement for moving forward | | --- | --- | --- | | Atlas | Research, questions, ideas, and alternatives | A defined task needs the material | | Projects | Briefs, decisions, and working versions | The deliverable meets its acceptance criteria and receives approval | | End Products | Approved versions ready for use | Further changes start a new revision |

A proposal can be a completed deliverable while the sales opportunity remains open. Classify the artifact according to its own lifecycle. Trying to make one folder describe every aspect of the business creates avoidable ambiguity.

Give each project an entry point

Create a short README.md containing the objective, owner, next decision, authoritative references, and completion requirements. For the proposal, that might mean using the current commercial terms, confirming technical scope, and obtaining approval before sending it.

Link to the relevant source files. A reference shared by several projects can remain in Atlas, with each project pointing to it. This reduces the chance of maintaining several copies that gradually disagree. Add a review date where information changes frequently.

Anthropic recommends curating the information that enters the model’s context. My application here is to provide a small index and retrieve the files needed for a particular task, rather than attach an entire collection by default. Read Anthropic’s technical guidance.

Define approval and inactive work

The three-folder scheme leaves some practical questions unanswered. What happens to a canceled project? Who decides that a deliverable is complete? Which version did the client receive?

Record inactive or canceled status inside the project and remove it from your active-work index. Filing canceled work under End Products without an explanation would blur the distinction between stopping and delivering.

For completed work, record the approver and approved version. A technical guide might require an example that someone has successfully reproduced. A proposal might require a scope check and a review of its figures. Write those conditions down before generating the document.

An approved file could be named implementation-proposal-v1.pdf, with its approval record retained in the project. A later change starts a new revision while preserving the identity of the version already delivered.

Start with a reviewable sorting request

Examine only the files provided for this project. Propose a classification into Atlas, Projects, or End Products. For each file, report its current path, suggested destination, reasoning, and unresolved questions. Identify possible duplicates without deciding which one to delete. Do not move, rename, or delete anything. Do not classify a deliverable as approved without evidence of approval. Finish by listing the decisions that require my input.

Review the proposal and look for recurring uncertainty. If the model repeatedly confuses references with approved instructions, improve the rules and the project index. A scheduled cleanup becomes more useful once those distinctions are reasonably stable.

Run a one-week evaluation

Pick three representative tasks: retrieve a decision, update a proposal, and prepare a deliverable using existing references. Before reorganizing, record completion time, files consulted, and the corrections needed to make the AI output usable.

Repeat the tasks in fresh sessions with the same model, request, and evaluation criteria. If your service provides usage billing, record input, output, and cached tokens separately alongside reported cost. If your subscription does not expose that information, compare elapsed time and revision effort without claiming token savings.

Score each output on three conditions: it used the current source, fulfilled the request, and followed the required format. Give one point for each condition and require all three for acceptance. Compare the score and review time alongside any consumption data.

This small comparison supports a local decision; it does not establish a universal performance gain. Expand to a second project if the structure helps. If every classification still needs a lengthy explanation, revise the rules before turning the cleanup into another agent.