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

This one is about the how. I am going to lift the lid on my context engine — the system that lives in a 02-CONTEXT/ folder in my vault — and follow one real mission from start to finish. At each step I will explain the building block that comes into play: the mission, the focus, the directives, the todo, the offline queue, and the three kinds of memory.

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

The starting principle: the disk is the memory

One thing to settle before anything 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 gone. The context window is finite, and the more you fill it, the more attention degrades — the Lost in the Middle phenomenon I have 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 bare minimum.

A Context, then, is a folder. One folder = one mission. There is no implicit memory running across two Contexts: what the AI knows about project A does not leak into project B. Each mission has its own head.

Here is what a Context looks like, simplified:

<context>/
├── 00_mission/     ← the stable frame: why we are here, the rules
├── 01_active/      ← the living state: where we stand, today
├── 02_checkpoints/ ← the stage-by-stage snapshots
├── 03_sources/     ← the raw input
├── 04_notes/       ← the extracted ideas, linked to one another
├── 05_memory/      ← consolidated memory
├── 06_index/       ← the machine index, so the AI can find its way
└── 07_outputs/     ← the deliverables

The filing logic is simple but strict: what is stable (the mission, the rules) is kept apart from what shifts at every session (the current state), which is itself kept apart from the raw input (the sources), from what you extract from it (the notes) and from what you produce (the deliverables). Nothing is mixed. As you will see, this separation is not cosmetic: it is what makes the reasoning traceable over time.

To make all this concrete, I will follow a mission I actually ran (a simple example, to keep it easy to read): PM016 — write LinkedIn posts from three articles I published in a marketing magazine. A short content production mission, 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 is to read one configuration file: the load manifest (load_manifest.json). That file tells it what to load, and what to leave on disk instead.

It holds 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 handover note, the synthesis.
• load_on_demand — everything that stays on disk and is loaded only if the task calls for it: the dozens of sources, the atomic notes, the session logs.
• A set of guardrails: no more than 12 active files, around 1,200 lines maximum in the LLM's context window.

It is a surgeon's tray. The essential instruments are already laid out; the others are within reach, but you do not cover the table with them. A human expert does not reread the whole case before every meeting — they have internalised what matters and go and fetch one precise document when they need it. An LLM cannot internalise anything: it only has what you give it. Hence the importance of giving it the right subset, not all of it.

In practice, opening a Context is a command — I type /context_use pm016 — and the AI runs the manifest: it reads the core, it reads the last checkpoint, and it is ready to work. It knows where we stand without my having to re-explain anything.

Mission and focus: the goal is not the same thing as the attention

Zoom in on the two head folders — the stable one and the living one:

00_mission/          ← the stable frame
├── mission.md       the goal (does not change)
├── scope.md         the scope
├── directives.md    how the AI should work
├── risks.md         the threats to watch
└── glossary.md      the vocabulary of the mission

01_active/           ← the living state (changes at every session)
├── focus.md         the attention of the moment
├── current_state.md where we stand
├── current_plan.md  where we are going
├── todo.md          the future actions
├── decisions.md     what we have settled
├── contradictions.md what does not add up yet
├── resume_work.md   the handover note
└── offline.md       the letterbox

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

Two files look like "what we are working on", and yet they have nothing to do with each other.

The first is the mission (00_mission/mission.md). It is the goal. It is stable. For PM016, the mission fits in a sentence: "write LinkedIn posts based on the three articles I published in issue 16 of the magazine". That sentence does not change for the whole life of the Context. It is the heading. The file lives in 00_mission/, the folder for stable things.

The second is the focus (01_active/focus.md). It is the attention of the moment. It changes at every session, sometimes several times within one. The focus is "today we are working on splitting the ideas in article 2 into separate posts". That is not the goal — it is the sub-problem we are shining the light on right now. The file lives in 01_active/, the folder for living things.

Why keep them apart? Because confusing the goal with the attention is the surest way to drift. If the AI mistakes today's focus for the goal of the mission, it may redefine the whole mission around one detail. Conversely, if all it has in front of it is the goal, it stays too vague: "write LinkedIn posts" says nothing about what we are concentrating on at this instant. The mission gives the heading, the focus gives the depth of field. You can redo the focus ten times without ever touching the mission. It works exactly as it does for a person: your job (your mission) does not change because you spend the afternoon on one specific task (your focus).

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

The scope marks out what is in and what is out — the fence against subject drift.

The risks (risks.md) are the register of threats hanging over the mission. On PM016 it is a modest file; but on a real product opportunity it tracks Marty Cagan's four big risks — value, usability, feasibility, business viability. The idea: keep permanently in view the questions that could sink the project, and tick off each risk as something comes along that sheds light on it or makes it worse. An empty section means a risk still undocumented, so a blind spot you are knowingly accepting.

The glossary (glossary.md) pins down the vocabulary of the mission, so that the same words keep the same meaning from beginning to end. It is the same reflex I had in my residents' association Context, where I ended up moving all the technical terms and acronyms out into a dedicated file: without that, everyone — human and AI alike — ends up using the same words with different meanings.

One important point about all these files, and perhaps the most counter-intuitive thing in the system: they do not get filled in one go at the start. They fill up gradually, as the exchanges go on. And "exchange" does not only mean "bringing in a document". Most of the time it means talking. I talk with the AI, I think out loud, I give it context I have in my head — and it is the AI that files that flow in the right place: this point is a viability risk, that term deserves a glossary entry, this sentence marks out the scope. An unwritten risk becomes a line in risks.md because I mentioned it while talking, not because I opened the file to fill it in. That is the moment the Context stops being a folder to be filed and becomes a personal secretary taking down what I think out loud.

The directives: encoding knowledge the AI does not have

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

A directive says nothing about the subject of the mission. It is about the way of working. It is the difference between the ingredients and the recipe.

An example from another of my Contexts, where I have the AI process hundreds of residents' association emails: "when two people share a surname, use the sense of the email to give their first name and their company" (two contractors had the same surname). That is not information about the residents' association. It is a processing rule. It encodes knowledge only I hold, and that the AI then applies systematically — never forgetting, never tiring.

For PM016, a typical directive would be: "each post must defend a single atomic idea, never summarise the whole article". It is a production constraint I set once, and it holds for all twenty-seven posts.

The directives are in the always_load core, so they are reloaded at every session. A rule established in week 1 still applies in week 6, without my having to repeat it. It is cumulative. The further a mission goes, the more its directives sharpen, and the more the AI works the way I do.

A practical detail: to add a directive mid-conversation, I simply prefix my message with alpha directive : ... and the AI consolidates it into the file. There are a handful of keywords like that one (decision :, contradiction :, todo :, checkpoint, and fin de session, French for "end of session") — shortcuts for filing a piece of information in the right place without having to say so explicitly. They are only conveniences; the heart of the system is the concepts, not the keywords.

The todo: future actions do not 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 keep surfacing. "We will need to check that figure." "We should turn this post into a carousel." "Remember to reread the English version." If you let those actions float in the conversation, two things happen: either you forget them, or they pollute the reasoning under way by pulling attention in every direction.

The todo is where you put those actions down so you no longer have to hold them in your head. It is a backlog. Each task has an identifier (T-NNN) and a status. You feed it by writing todo : .... And because it is part of the core loaded at every session, no action is lost between one session and the next.

It is the same logic as everywhere else: take a piece of information out of the volatile memory of the conversation and put it somewhere stable and named.

The offline queue: talking to the Context while it sleeps

Here is a building block you do not think of at first, and that quickly becomes indispensable: the offline file (01_active/offline.md).

The problem: ideas do not only come when you are sitting in front of the AI with the Context open. An idea about PM016 crosses my mind on a Sunday evening, when I have no wish at all to open a full session. Where do I put it?

In the offline file. It is a letterbox. 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 one 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 had just typed it, takes it on board, acts on it, and resets the letterbox. Nothing is lost, and I did not have to open a session just to jot down an idea.

It is an asynchronous way of talking to a Context. The Context becomes something I can leave a note for, even when it is not "switched on".

Sources and notes: from raw input to reusable knowledge

So far we have talked about steering. Now the content.

Zoom in on the chain that runs from raw input to knowledge:

03_sources/          ← the raw input
├── SRC-001.md       the record (a usable transcription)
└── raw/             the original as it came (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 together

When I bring in something to work with — for PM016, the PDF of the three articles — it does not get poured into the conversation. It goes into 03_sources/, the raw input. Each source gets a record and an identifier (SRC-001, SRC-002…). The original PDF, which the AI cannot read directly, is kept as it came in a raw/ subfolder, and an .md record gives a usable transcription of it. You always know where each 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, analysing the three articles produced twenty-two notes. Here is one, a real one:

NOTE-0022 — Making the call without going blind: the frame versus autonomy dial Pattern: giving one role enough authority to make the call creates a new risk — blind centralisation. […] Coherence is not uniformity. The Nike example: very different worlds (running, football, basketball…) coexist without everything being made the same.

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

There is a rule I hold myself to here, and it is subtler than it looks: an atomic note is never material pre-shaped for the deliverable. Even though 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. Shaping it to serve the objective happens only in the deliverables. The chain is strict: sources (raw) → notes (neutral knowledge) → outputs (deliverable, with an angle). As long as you are in the notes, the goal of the mission has no say yet. Otherwise you poison your own raw input.

The rule looks rigid. In fact it is what makes the notes powerful — because neutral knowledge is agnostic about the deliverable, and so reusable for any of them.

Take a product mission rather than PM016. From one and the same set of atomic notes — a customer stake, an adoption constraint, a market pattern — I can generate very different material: a pitch for an executive committee, support documentation, a blog article, a sales narrative, an onboarding. Each deliverable picks and combines the building blocks it needs from that shared body of knowledge. Had I shaped those notes for the pitch, they would serve the pitch and nothing else. Kept neutral, they serve all five. The shaping, the angle, the tone: all of that comes at the last moment, in 07_outputs/, once you know which deliverable you are producing.

And the reusability does not stop at the mission. Contexts are not sealed 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: go through its notes and pick out the good ideas worth taking. A building block of knowledge written once can feed a deliverable today, another deliverable tomorrow, and a decision in a third Context six months from now. That is exactly the promise we started from: the deliverable is disposable, the note is an asset.

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

The three memories: episodic, semantic, and the stage-by-stage snapshots

Zoom in on the three places where memory lives — three timescales:

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

02_checkpoints/      the complete state at a given moment (the snapshot you come back to)

This is where the second big subtlety of the system plays out. A human brain does not have one memory, it has several, working on different timescales: the one that holds what is happening now, the one that stores lived events, and the one that consolidates lasting knowledge. The system reproduces that architecture with three distinct objects, which must never be confused.

The log (episodic memory). In 05_memory/journal/, one file per working day. It tells what happened: what we did that day, in what order, which decisions were taken, what got stuck. It is the chronological account. You go there when you wonder "hang on, what did we decide on Tuesday, and why?". It is dated, sequential, never rewritten.

The synthesis (semantic memory). In 05_memory/synthesis.md, a single file. It does not tell what happened — it condenses what we take from it. The stable conclusions, the validated convictions, the patterns drawn from dozens of sessions. It is the long-term memory, stripped of chronology. A senior product manager does not rediscover on every project that users lie in interviews: it has become semantic knowledge. That is what the synthesis is. It is part of the core loaded at every session, because it is the most useful condensed form for getting back into the thread.

The checkpoints (the stage-by-stage snapshots). In 02_checkpoints/, at most one file per day. A checkpoint is a complete snapshot of the state of the Context at a given moment. It is written from one very precise question, and that is what makes it valuable: "if an LLM arrived right now having read nothing, what does it need to know to carry on without mistakes and without starting over?" The checkpoint is the safety net for picking work back up.

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

And that is precisely what makes the system auditable. A brain forgets — that is its strength. A file system forgets nothing. From the synthesis you go back to the checkpoint. From the checkpoint, to the logs. From the logs, 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 is a chain of evidence: source → note → decision.

The cycle of a session, end to end

Now that we have the building blocks, here is the whole film of a session on PM016.

At the start. The AI reads the manifest, loads the core, reads the last checkpoint. It checks the offline file: if it holds a note I left between two sessions, it processes it and then empties it. Within seconds, it knows where we stand. The handover note (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 goes on, the AI files things continuously. A new source arrives → 03_sources/. A lasting idea emerges → an atomic note in 04_notes/. A decision is taken → decisions.md. A contradiction appears → contradictions.md (we do not smooth it over artificially, we keep it visible). A future action → the todo. Every time a file is created, the README.md of its folder and the machine index are updated. The Context keeps itself up to date constantly, with no effort from me.

At the end of the session. I type /context_close. The AI runs the closing ritual: it writes the day's log, updates the current state and the handover note, promotes into the synthesis whatever deserves to become lasting, and creates a checkpoint if a threshold has been reached. Then it commits the lot. The next session can pick up exactly where this one stopped.

There is also a mid-course compaction (/context_push): when the current state swells, when the todo becomes unreadable, or when we are going round in circles, we condense, deduplicate, prioritise, and archive what no longer serves — without ever losing the traceability.

But /context_push has an even more vital role, and it is a trap you are bound to fall into when you first meet the system. When a session runs long, the conversation eventually outgrows the LLM's window. At that point, the LLM does its own compaction: it silently summarises the older exchanges to make room. And everything that had not yet been written to disk at that instant — a decision mentioned out loud, an idea thrown out in passing, an important nuance — is shaved down, distorted, or simply lost. The LLM does not warn you; it believes it has kept what matters, but it is the LLM that decided what mattered.

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

Forgetting without losing

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

When a piece of information is no longer useful, you do not erase it. You take it out of the default loading, you compact it, or you archive it. When one idea replaces another, you do not overwrite it: you mark it superseded, you keep the old identifier, and you make the old one point to the new one. The only real deletions are for an obvious mistake or an unambiguous duplicate.

Why so much care? Because auditability is the whole value of the system. The day a product conviction has to be defended, I have to be able to trace it back to its source, even if it dates from two months ago and has been "superseded" since. Reasoning whose history has been erased is no longer reasoning — it is an opinion with no evidence behind it.

What a Context really is

At bottom, this context engine is not a filing system. It is a memory architecture for an intelligence that does not natively have one.

Every building block answers a limit of the LLM: the manifest answers the finite window; the three memories answer the forgetting between sessions; the atomic notes answer Lost in the Middle; the separation of sources, notes and deliverables answers the need for traceability; the offline file answers the fact that thinking does not stop when the session closes.

And the result is what I described in my earlier articles: the deliverable is no longer the starting point of the work, it is a by-product. What has value is the Context itself — that structured, traceable, reusable memory that you enrich session after session and that 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. Something I will be able to reopen in six months for an entirely different deliverable. The post was the objective. The Context is the asset.