Instructions are advice; permissions are control — and the difference decides how far an agent gets
Claude Code beyond the basics: project memory, skills, sub-agents, hooks, MCP and plan mode
The question: What separates an hour of fighting a coding agent from an hour of shipping with one — and how much of it is decided before the first prompt?
Lesson 26 taught you to review an agent's work. This one is about arranging things so there is less to review. Nearly everything that decides whether a session goes well is set up beforehand: what the agent can read without asking, which procedures are written down rather than re-explained, what happens automatically, and what it is simply not allowed to do. None of it requires you to write code.
What the lesson covers
Start with the distinction that organises everything else. **Project memory** — a CLAUDE.md file loaded at the start of every session — and the notes an agent accumulates about your corrections are both treated as *context*: material the model reads and usually follows. The documentation is unusually direct about this, and the sentence is worth memorising: they are context, not enforced configuration. **Permissions and hooks** are the other kind. They run regardless of what the model decides. So every feature in this lesson sorts into advice or control, and the sorting tells you which ones still hold when the model is confused — which is precisely the moment you need them to.
**Project memory** is the highest-return five minutes available. Write down what an agent would otherwise ask about or, worse, guess: how to run the thing, how to test it, which conventions are deliberate, what must never be edited by hand, and the one-line reason behind each. Two failure modes to avoid. A file that has grown into a manual gets skimmed — keep facts here and move procedures out. And rules scoped to particular file types belong in `.claude/rules/` rather than as paragraphs everybody's session pays for. The test of a good memory file is simple: a new colleague should be able to run the project from it.
When a section of that file has turned into a procedure — "how we release", "how we review a migration", "how we write a lesson" — it has become a **skill**. Write it once as a SKILL.md and it is invoked when relevant or called directly by name. The mechanical advantage is real: a skill's body loads only when it is used, so a long checklist costs nothing on the sessions that do not need it, whereas the same text in project memory is paid for on every session forever. The habit to build is noticing the third time you paste the same instructions, and writing them down instead.
Two features exist to protect the thing this course keeps calling the scarce resource: the context window. A **sub-agent** is a specialised worker with its own window, its own system prompt, and its own tool access and permissions — used when a side task would otherwise flood your main conversation with search results and logs nobody will re-read. It does the work elsewhere and returns the summary. And when a session does fill up, compaction is lossy, so the constraint you set an hour ago may quietly vanish: anything that must survive belongs in the memory file rather than in the conversation. That is the same argument as Lesson 10 in this module, arriving from a different direction.
Finally, the controls, in rising order of firmness. **Plan mode** makes the agent agree a plan before it may change anything — the cheapest place in the entire process to catch a misunderstanding, because nothing has been touched yet. **Permissions** decide which actions need asking; the useful setting is not the most restrictive but the one that keeps the interruption meaningful, so that gating force-push and deploy still means something. **Hooks** fire automatically at lifecycle points — run the formatter, run the tests, refuse a commit that touches production config — and because they execute whatever the model concluded, they are the only genuine enforcement in the list. And **MCP servers** decide what exists to be reached at all, which is where the primer's permission table earns its keep.
Key points
- Sort every feature into **advice** or **control**. Memory files and skills are context the model usually follows; permissions and hooks run whatever it decides. Only the second kind holds when the model is confused.
- **Project memory** is the highest-return setup step: how to run it, how to test it, what is deliberate, what must never be hand-edited — and a reason for each. Keep facts here; move procedures to skills.
- A **skill** is a procedure written once. Its body loads only when used, so a long checklist costs nothing on the sessions that do not need it — unlike the same text in project memory.
- **Sub-agents** protect the context window: a side task that would flood the conversation with logs runs in its own window and returns only the summary.
- **Plan mode** is the cheapest catch in the process — a misunderstanding found before any file is touched — and **hooks** are the only feature on this list that genuinely enforces anything.
Framework — Read · Remember · Delegate · Gate
Four questions to answer before the first prompt of any serious session. READ: what can the agent see without asking — the memory file, the rules, the connected servers? REMEMBER: which procedures are written down as skills rather than re-explained? DELEGATE: what goes to a sub-agent so it never enters the main context? GATE: what is genuinely blocked — plan mode, permissions, hooks — regardless of what the model decides? The first two make it faster. The last two make it safe. Confusing them is why people write increasingly emphatic instructions and wonder why they stop working.
The lab
Set one project up properly, then prove which of your instructions are advice and which are control.
Open this lesson, its lab and its quiz
Sources and further reading
- Claude Code best practices — Anthropic Engineering
- Memory: CLAUDE.md and auto memory — Anthropic
- Skills — writing a procedure once — Anthropic
- Sub-agents — specialised workers with their own context — Anthropic
- Hooks — the part that is enforcement rather than advice — Anthropic
- Connecting MCP servers to Claude Code — Anthropic