The Agent OS Checklist

Seven moves that turn Claude Code from something you poke at into something that runs.

None of this is about better prompts. Prompting is the part everyone already works on, and it is not what breaks. What breaks is that nothing persists: your agent starts every session knowing nothing, so you become the memory, and by week two you are pasting the same context into a blank window every morning.

Below is the structure that fixes it. Each item has a smallest version you can do today.

1.Context it reads every session

Your agent should know what you are trying to achieve before you ask it anything. Not the task, the goal behind the task. An agent that knows you are trying to ship by Friday makes different choices than one that thinks you are exploring.

• Create a CLAUDE.md at the root of your project
• Write what the project actually is, in two lines
• Write what you are trying to achieve right now, with a real deadline if there is one
• Write how you like things done: what to always do, what to never do without asking
• Keep it short enough that reading it every session is not a cost
• Update it when the structure changes, in the same session it changes

Smallest version: ten lines saying what this project is, what done looks like, and one thing the agent should never do without asking you first.

2.Memory that survives the session

CLAUDE.md is stable instructions. Memory is the opposite: accumulating knowledge that changes as you work. You need both, and they should not be the same file.

The test for whether something belongs in memory: will this still be true in a month, and is it not already obvious from the code? Decisions, preferences, corrections, and constraints qualify. A log of what happened does not.

• Make a memory/ folder with an index file
• One fact per file, with a one-line description so the index is scannable
• Read the index at the start of every session, before doing anything
• Write to it at the end, when you know what was worth keeping
• Delete memory that turns out to be wrong. Stale memory is worse than none, because the agent trusts it

Smallest version: one MEMORY.md you append a line to whenever you make a decision you do not want to explain twice.

3.Somewhere for work to land

Output that lives in a chat window is lost output. If the only record of what your agent did is scrollback, you will redo that work in three weeks.

• Make a projects/ folder, one folder per real project
• Give each project a file saying what it is, where it stands, and what is blocked
• Give each project a place for tasks, one file per task
• Each task file: the goal, the plan, and a running log
• Nothing at the root. If it does not belong to a project, it does not belong

Smallest version: one folder per active project, one markdown file per thing you are currently working on.

4.A loop that closes out

This is the one everybody skips, and it is the one that makes the difference between a system that compounds and a system that resets.

Most people have the first half of the loop: they start work. Almost nobody has the second half, where the work gets written down in a way the next session can use.

• Before work: read your memory index and the relevant project file
• During work: checkpoint at milestones, before anything risky, and when the session might end. Three lines is enough
• After work: update the task status, and write down what is worth keeping
• Treat the close-out as part of the task, not as optional admin. A task is not done until it has one

Smallest version: before you stop working, write three lines somewhere permanent: what happened, what is next, and one thing you learned. That is a handoff to yourself, and it is why tomorrow does not start from zero.

5.Skills instead of retyping

If you have explained the same workflow three times, that is not a prompting habit, that is a missing file.

The thing that determines whether a skill ever gets used again is the description. Write it as when to use it, in the words you would actually say, not as a description of what it does. "Use when checking overnight client email" gets found. "Email processing capability" does not.

• Notice when you have done something manually two or three times
• Write it down as a skill: when to use it, the steps, and what done looks like
• Make the steps executable by someone with zero context, because that is what a fresh session is
• Say explicitly what it must never do. Anything that sends, posts, spends, or deletes defaults to drafting and asking
• Keep a list of your skills somewhere the agent checks before working

Smallest version: next time you catch yourself explaining a workflow again, stop and put it in a file instead.

6.Subagents for work that is wide

Some problems are deep and some are wide. Reading twelve files to answer one question is wide, and doing it in your main session fills your context with twelve files you do not need.

Delegate the wide part. You keep the conclusion, not the raw material.

• Use a subagent when the work is search, survey, or review across many files
• Give it a self-contained prompt. It does not have your context and cannot ask you
• Ask for the conclusion, not the transcript
• Run independent work in parallel rather than in sequence

Smallest version: the next time you need to read a lot to answer a little, delegate it and ask for just the answer.

7.A verification step that is not the same agent

The highest-leverage item on this list and the least used.

An agent checking its own work is not verification. It already believes its own reasoning, so it will confirm it. Real verification needs separation: a different pass, ideally with fresh context, and framed adversarially.

The framing matters more than people expect. "Review this" produces praise. "Try to prove this is wrong, and default to it being wrong if you are unsure" produces findings.

• After anything substantial, run a separate verification pass
• Give it fresh context so it cannot inherit the assumptions that produced the work
• Frame it to refute, not to review
• For anything important, use more than one verifier and look at where they disagree
• Verify against reality where you can: run it, check the output, read the actual file

Smallest version: after your next significant change, open a new session and ask it to find what is wrong with the work. Do not tell it you wrote it.

The order to do these in

If you do them in this order, each one makes the next easier:

1. CLAUDE.md (item 1), because everything else is easier when the agent knows the goal
2. The close-out habit (item 4), because it is free and it starts compounding immediately
3. Memory (item 2), which the close-out will start filling on its own
4. Projects and tasks (item 3), once you have enough written down to need structure
5. Skills (item 5), once you notice the repetition
6. Subagents and verification (items 6 and 7), once the system is doing enough to be worth checking

Most people try to build all of it at once, get a folder structure they never use, and go back to the blank window. Do one. Let it prove itself.