I've already told the story of why an LLM's memory doesn't fit in a single file, and why context is the asset the PM has to build. Those were articles about the why.

This one is about the how. I'm going to lift the hood on my context engine — the system that lives in a 02-CONTEXT/ folder of my vault — and follow a real mission from beginning to end. At each step, I'll explain the building block that comes into play: the mission, the focus, the directives, the todo, the offline queue, and the three types of memory.

The goal: that a stranger who has never seen this system understand how it's organized, and above all why it's organized the way it is. Because every folder, every file, answers a problem I ran into while working with an AI on subjects that stretch over weeks.

The founding principle: the disk is the memory

One thing to establish before everything else. In this system, the file system is the AI's primary memory. Not the conversation.

A conversation with an LLM is volatile. Close the tab, and everything is lost. The context window is finite, and the more you fill it, the more attention degrades — that's the Lost in the Middle phenomenon I've discussed elsewhere. So instead of keeping everything in the conversation, you write everything to disk, in files split by the nature of the information. And at each session, you reload only the strict minimum.

A context, then, is a folder. One folder = one mission. There is no implicit cross-cutting memory between two contexts: what the AI knows about project A doesn't leak into project B. Each mission has its own head.

Here, in simplified form, is what a context looks like:

<contexte>/
├── 00_mission/     ← the stable frame: why we're here, the rules
├── 01_active/      ← the living state: where we stand, today
├── 02_checkpoints/ ← the milestone snapshots
├── 03_sources/     ← the raw material
├── 04_notes/       ← the extracted ideas, linked together
├── 05_memory/      ← the consolidated memory
├── 06_index/       ← the machine index, so the AI can find its bearings
└── 07_outputs/     ← the deliverables

The filing logic is simple but strict: what is stable (the mission, the rules) is separated from what shifts at each session (the current state), which is itself separated from the raw material (the sources), from what we extract from it (the notes) and from what we produce (the deliverables). Nothing is mixed together. We'll see that this separation isn't cosmetic: it's what makes reasoning traceable over time.

To make all of this concrete, I'll follow a mission I actually carried out (a simple example, to make for easy reading): PM016 — writing LinkedIn posts from three articles I published in a marketing magazine. A content-production mission, short, but one that activates most of the building blocks.

Opening a context: what the AI loads, and what it leaves on disk

I start a session. The first thing the AI does is not to read everything. It's to read a configuration file: the load manifest (load_manifest.json). This file tells it what to load, and conversely what should be left on disk.

It contains three lists:

• always_load — the core, loaded every time. The mission, the scope, the directives, the risks, the current state, the plan, the focus, the todo, the decisions, the contradictions, the resumption sheet, the synthesis.
• load_on_demand — everything that stays on disk and is loaded only if the task requires it: the dozens of sources, the atomic notes, the session journals.
• Some guardrails: no more than 12 active files, roughly 1,200 lines maximum in the LLM's context window.

It's a surgeon's tray. The essential instruments are already laid out; the others are within reach, but you don't cover the whole table. A human expert doesn't reread their entire file before every meeting — they've internalized the essentials and go fetch a specific document when they need it. An LLM can't internalize: it has only what you give it. Hence the importance of giving it the right subset, not everything.

In practice, opening a context is done through a command — I type /context_use pm016 — and the AI runs the manifest: it reads the core, it reads the latest checkpoint, and it's operational. It knows where we stand without my having had to re-explain anything to it.

The mission and the focus: the goal is not the same thing as the attention

Let's zoom in on the two lead folders — the stable and the living:

00_mission/          ← the stable frame
├── mission.md       the goal (doesn't change)
├── scope.md         the perimeter
├── directives.md    how the AI should work
├── risks.md         the threats to watch
└── glossary.md      the mission's vocabulary

01_active/           ← the living state (changes at each session)
├── focus.md         the attention of the moment
├── current_state.md where we stand
├── current_plan.md  where we're going
├── todo.md          the future actions
├── decisions.md     what we've settled
├── contradictions.md what doesn't add up yet
├── resume_work.md   the resumption sheet
└── offline.md       the mailbox

Here is the first subtlety, and probably the most important one to grasp.

There are two files that look like "what we're working on," but that have nothing to do with each other.

The first is the mission (00_mission/mission.md). It's the goal. It's stable. For PM016, the mission fits in one sentence: "write LinkedIn posts based on the three articles I published in issue no. 16 of the magazine." That sentence doesn't change over the entire life of the context. It's the heading. The file lives in 00_mission/, the folder for stable things.

The second is the focus (01_active/focus.md). It's the attention of the moment. It changes at each session, sometimes several times within a session. The focus is "today, we're working on breaking article 2's ideas out into distinct posts." It's not the goal — it's the sub-problem the spotlight is trained on right now. The file lives in 01_active/, the folder for living things.

Why separate the two? Because confusing the goal with the attention is the surest way to drift. If the AI mistakes the focus of the day for the goal of the mission, it risks redefining the entire mission around a detail. Conversely, if it has only the goal in front of it, it's too vague: "write LinkedIn posts" doesn't say what we're concentrating on at this instant. The mission gives the direction, the focus gives the depth of field. You can redo the focus ten times without ever touching the mission. It's exactly like a human: your job (your mission) doesn't change because you spend the afternoon on a specific task (your focus).

Around the mission, in 00_mission/, you find three other framing files.

The scope delimits what falls within the perimeter and what does not — the barrier against subject drift.

The risks (risks.md) are the grid of threats bearing down on the mission. On PM016 it's modest; but on a real product opportunity, this file tracks Marty Cagan's four big risks — value, usability, feasibility, business viability. The idea: to keep permanently in view the questions that can make the project fail, and to tick off each risk as new evidence sheds light on it or makes it worse. An empty section = a risk still undocumented, and therefore a blind spot you've acknowledged.

The glossary (glossary.md) freezes the mission's vocabulary, so that the same words keep the same meaning from start to finish. It's the same reflex as in my co-ownership context, where I'd ended up externalizing all the technical terms and acronyms into a dedicated file: without it, everyone — human and AI alike — ends up using the same words with different meanings.

An important point about all these files, and perhaps the most counterintuitive one in the system: they don't fill up all at once at startup. They fill up progressively, over the course of exchanges. And "exchange" doesn't only mean "bringing in a document." Most of the time, it means talking. I chat with the AI, I think out loud, I give it context I have in my head — and it's the AI that files this flow in the right place: this point is a viability risk, this term deserves a glossary entry, this sentence delimits the scope. An unwritten risk becomes a line in risks.md because I mentioned it in passing, not because I opened the file to fill it in. That's where the context stops being a folder to sort and becomes a personal secretary jotting down what I'm thinking aloud.

The directives: encoding knowledge the AI doesn't have

Another file in the stable core: the directives (00_mission/directives.md).

A directive doesn't talk about the subject of the mission. It talks about the way of working. It's the difference between the ingredients and the recipe.

An example drawn from another of my contexts, where I have hundreds of co-ownership emails processed: "when two people share the same surname, use the meaning of the email to indicate their first name and their company" (two service providers had the same surname). This isn't a piece of information about the co-ownership. It's a processing rule. It encodes knowledge that only I possess, and that the AI then applies systematically — without forgetting, without tiring.

For PM016, a typical directive would be: "each post must defend a single atomic idea, never a summary of the entire article." It's a production constraint I set once, and that holds for all twenty-seven posts.

The directives are in the always_load core: they are therefore reloaded at each session. A rule established in week 1 still applies in week 6, without my having to repeat it. It's cumulative. The further a mission advances, the more its directives get refined, and the more the AI works the way I do.

A usage detail: to add a directive mid-conversation, I simply prefix my message with alpha directive : ... and the AI consolidates it into the file. There's a handful of keywords like that (decision :, contradiction :, todo :, checkpoint, fin de session) — shortcuts for filing a piece of information in the right place without having to spell it out. These are just conveniences; the heart of the system is the concepts, not the keywords.

The todo: future actions don't pollute present reasoning

The todo (01_active/todo.md) is a simple file that solves a real problem.

When you work on a subject, ideas for future actions come up constantly. "We'll need to check that figure." "We should turn this post into a carousel." "Remember to proofread the English version." If you let these actions float around in the conversation, one of two things happens: either you forget them, or they pollute the reasoning underway by pulling your attention in every direction.

The todo is where you park these actions so you no longer have to hold them in your head. It's a backlog. Each task has an identifier (T-NNN) and a status. You feed it by writing todo : .... And because it's part of the core loaded at each session, no action gets lost between two sessions.

It's the same logic as everything else: pulling a piece of information out of the conversation's volatile memory to park it in a stable, named place.

The offline queue: speaking to the context while it sleeps

Here's a building block you don't think of at first, and that quickly becomes indispensable: the offline file (01_active/offline.md).

The problem: ideas don't come only when you're sitting in front of the AI, context open. An idea about PM016 crosses my mind on a Sunday evening, when I have no desire whatsoever to open a full session. Where do I put it?

In the offline file. It's a mailbox. I drop a message in it — an idea, a correction, a reminder — without opening a session. The file sleeps along with the context.

Then, at the start of the next session, the workflow calls for a precise step: if offline.md is not empty, treat its contents as an incoming message, then empty the file. The AI reads my Sunday-evening message as if I'd just typed it, takes it into account, acts on it, and resets the mailbox. Nothing is lost, and I didn't have to open a session just to jot down an idea.

It's an asynchronous way of speaking to a context. The context becomes something I can leave a note for, even when it isn't "switched on."

Sources and notes: from raw material to reusable knowledge

So far we've talked about steering. Now, the content.

Let's zoom in on the chain that runs from the raw to the knowledge:

03_sources/          ← the raw material
├── SRC-001.md       the record (usable transcription)
└── raw/             the original as-is (the PDF, unreadable by the AI)

04_notes/            ← the extracted knowledge
├── atomic/          one idea = one note (NOTE-0001, 0002…)
└── thematic/        the syntheses that link several notes

When I bring in material — for PM016, the PDF of the three articles — it doesn't get dumped into the conversation. It goes into 03_sources/, the raw material. Each source gets a record and an identifier (SRC-001, SRC-002…). The original PDF, which the AI can't read directly, is preserved as-is in a raw/ subfolder, and a .md record provides a usable transcription of it. We always know where every piece of information comes from.

Then comes the extraction work. From the sources, the AI produces atomic notes in 04_notes/atomic/. An atomic note captures a single unit of thought: a fact, a definition, a hypothesis, a pattern, a contradiction. For PM016, analyzing the three articles produced twenty-two notes. Here's one, a real one:

NOTE-0022 — Arbitrating without going blind: the frame vs. autonomy dial Pattern: giving a role enough authority to arbitrate creates a new risk — blind centralization. […] Coherence is not homogeneity. The Nike example: very different universes (running, football, basketball…) coexist without everything being made uniform.

This note stands on its own: you understand it without reopening the article. It's sourced (it points to SRC-001, page 67). And it's linked: at the bottom, a ## Backlinks section connects it to the thematic note the-brand-man. This is Zettelkasten — units of thought linked together, where the intelligence emerges from the links, not from accumulation.

There's a rule I impose on myself here, and it's subtler than it looks: an atomic note is never material pre-formatted for the deliverable. Even if the goal of the mission is to produce LinkedIn posts, a note must not be a "hook" or a "punchline." The note captures neutral, true knowledge. The shaping in service of the objective happens only in the deliverables. The chain is strict: sources (raw) → notes (neutral knowledge) → outputs (targeted deliverable). As long as we're in the notes, the goal of the mission has no say yet. Otherwise, you poison your own raw material.

This rule looks rigid. In reality, it's what makes the notes powerful — because neutral knowledge is agnostic to the deliverable, and therefore reusable for any of them.

Take a product mission rather than PM016. From a single set of atomic notes — a customer stake, an adoption constraint, a market pattern — I can generate very different assets: a pitch for a steering committee, support documentation, a blog article, a sales narrative, an onboarding. Each deliverable draws and combines the building blocks it needs from this shared corpus. Had I formatted these notes for the pitch, they'd serve only the pitch. By keeping them neutral, they serve all five. The shaping, the angle, the tone: all of it comes at the last moment, in 07_outputs/, once we know which deliverable we're producing.

And the reusability doesn't stop at the mission. Contexts aren't watertight silos. A note produced for one context can shed light on another — because you can link related contexts together. I can even open a context in order to audit another one: comb through its notes and spot the good ideas worth reusing. A block of knowledge written once can thus feed one deliverable today, another deliverable tomorrow, and a decision in a third context six months from now. This is exactly the promise from the start: the deliverable is disposable, the note is an asset.

When several notes converge, we write a thematic note in 04_notes/thematic/ — a synthesis of an angle or a tension. For PM016, one per article.

The three memories: episodic, semantic, and the milestone snapshots

Let's zoom in on the three memory sites — three time scales:

05_memory/
├── journal/         what happened, day by day (the history)
└── synthesis.md     what we take away from it (the lesson)

02_checkpoints/      the complete state at a given moment T (the resumption snapshot)

This is where the system's second great subtlety plays out. A human brain doesn't have one memory, it has several, working at different time scales: the one that holds what's happening now, the one that stores lived events, and the one that consolidates lasting knowledge. The system reproduces this architecture with three distinct objects, which must under no circumstances be confused.

The journal (episodic memory). In 05_memory/journal/, one file per working day. It recounts what happened: what we did that day, in what order, which decisions were made, what got stuck. It's the chronological narrative. You go to it when you wonder "but what had we decided on Tuesday, and why?" It's dated, sequential, never rewritten.

The synthesis (semantic memory). In 05_memory/synthesis.md, a single file. It doesn't recount what happened — it condenses what we take away from it. The stable conclusions, the validated convictions, the patterns extracted from dozens of sessions. It's the long-term memory, stripped of chronology. A senior product manager doesn't rediscover at each project that users lie in interviews: it has become semantic knowledge. The synthesis is exactly that. It's part of the core loaded at each session, because it's the most useful condensate for picking the thread back up.

The checkpoints (the milestone snapshots). In 02_checkpoints/, one file per day maximum. A checkpoint is a complete snapshot of the state of the context at a given moment. Its writing angle is very precise, and that's what gives it its value: "if an LLM arrived right now having read nothing, what does it need to know to pick up without error and without starting over?" The checkpoint is the safety net for resumption.

The journal / synthesis distinction is the one that most often slips past people. The journal is the history; the synthesis is the lesson. You need both, for exactly the reason that had pushed me, in my very first experiments, to separate the aggregate from a chronological log: I wanted both to know where we stand (the synthesis) and to be able to trace back the thread (the journal). Overwriting one with the other means losing either the memory or the traceability.

And that's precisely what makes the system auditable. A brain forgets — that's its strength. A file system, on the other hand, forgets nothing. From the synthesis, you trace back to the checkpoint. From the checkpoint, to the journals. From the journals, to the notes. From the notes, to the raw sources. When someone asks "why this decision?", the answer is never "because the AI said so." It's a chain of evidence: source → note → decision.

The cycle of a session, end to end

Now that we have the building blocks, here's the full picture of a session on PM016.

At startup. The AI reads the manifest, loads the core, reads the latest checkpoint. It checks the offline file: if it contains a note I left between two sessions, it processes it and then empties it. In a few seconds, it knows where we stand. The resumption sheet (resume_work.md) even gives it the first action to take.

During the session. We talk — often out loud, in front of the screen. And as the conversation unfolds, the AI files continuously. A new source arrives → 03_sources/. A lasting idea emerges → an atomic note in 04_notes/. A decision is made → decisions.md. A contradiction appears → contradictions.md (we don't smooth it over artificially, we keep it visible). A future action → the todo. Each time a file is created, its folder's README.md and the machine index are updated. The context keeps itself constantly up to date, with no effort on my part.

At the end of the session. I type /context_close. The AI triggers the closing ritual: it writes the day's journal, updates the current state and the resumption sheet, promotes to the synthesis whatever deserves to become lasting, and creates a checkpoint if a threshold is reached. Then it commits it all. The next session will be able to pick up exactly where this one left off.

There's also a mid-course compaction (/context_push): when the current state swells, when the todo becomes illegible, or when we're going in circles, we condense, we deduplicate, we prioritize, we archive what's no longer useful — without ever losing traceability.

But /context_push has an even more vital role, and it's a trap you inevitably fall into when you discover the system. When a session runs long, the conversation eventually exceeds the LLM's window. At that point, the LLM does its own compaction: it silently summarizes the older exchanges to make room. And everything that hadn't yet been written to disk at that instant — a decision mentioned aloud, an idea tossed out in passing, an important nuance — is planed down, distorted, or purely and simply lost. The LLM doesn't warn you; it believes it has kept the essentials, but it's the LLM that chose what was essential.

/context_push is the countermeasure: it forces persistence to disk before the LLM compacts its working memory. By pushing regularly, you guarantee that everything that matters is already written into the files — in the right place, sourced, traced — so that the LLM's compaction no longer loses anything important. It's the article's founding principle, applied over the course of the session: whatever lives only in the conversation is living on borrowed time; only what's on disk is truly remembered.

Forgetting without loss

One last point, because it says a lot about the system's philosophy. There is no brutal deletion.

When a piece of information is no longer useful, we don't erase it. We take it out of the default load, we compact it, or we archive it. When one idea replaces another, we don't overwrite it: we mark it superseded, we keep the old identifier, and we make the old one point to the new one. We only truly delete in the case of an obvious error or an unambiguous duplicate.

Why so many precautions? Because auditability is the whole value of the system. The day a product conviction has to be defended, I need to be able to trace back to its source, even if it dates from two months ago and has been "superseded" since. A line of reasoning whose history has been erased is no longer reasoning — it's an opinion without evidence.

What the context really is

At bottom, this context engine isn't a filing system. It's a memory architecture for an intelligence that has none natively.

Each building block answers a limitation of the LLM: the manifest answers the finite window; the three memories answer forgetting between sessions; the atomic notes answer Lost in the Middle; the sources/notes/deliverables separation answers the need for traceability; the offline file answers the fact that thinking doesn't stop when the session closes.

And the result is what I described in my previous articles: the deliverable is no longer the starting point of the work, it's a by-product. What has value is the context itself — that structured, traceable, reusable memory, which you enrich session after session and which ends up producing far more than what you asked of it.

For PM016, the goal was twenty-seven LinkedIn posts. But what remains, once the posts are published, is a context: twenty-two linked atomic ideas, three thematic syntheses, traced sources. Material I'll be able to reopen in six months for an entirely different deliverable. The post was the objective. The context is the asset.

To go further

From the Single File to a System of Contexts: Why an LLM's Memory Won't Fit in One Document The PM as Architect of Context One file, a few directives, and Claude does the rest — how I structured 500 emails effortlessly What Is an Atomic Note? What Is a Thematic Note?