In the previous article, I described a system of structured contexts for working with an LLM on complex subjects. Folders, mission files, loading manifests, atomic notes linked to one another. The model is powerful. But it isn't easy to understand, let alone to set up when you're starting from scratch.

And above all — I didn't get there on the first try. This system is the result of 40 days of trial, error, versions thrown away and rebuilt. Nobody buys a Ferrari as their first car. It's the same here: you have to drive first, understand how it works, and only then step up the complexity.

This article is about how I got started. Not with a framework. With a file.

The problem: 500 emails and no big picture

As a member of my building's residents' council, I receive a great many emails. From the managing agent, from owners, from tenants. Sometimes a brand-new subject, sometimes the umpteenth reply to a thread that's been running for months.

Volume isn't the real problem. The real problem is that everyone who replies to a thread carries the context in their head — they're the one who has been following the topic from the start. When I open a new email, though, I have to climb back up the whole chain, figure out who said what, work out where things stand. For a project that runs six months, that's a considerable amount of work. Multiply it by fifteen parallel topics, and you'll understand why I went looking for another solution.

I decided to hand the structuring of this incoming information over to Claude. It fetches the emails automatically, links them to their thread, and aggregates everything. The automatic fetching of the emails is pure plumbing — I won't cover it here. What interests me is what happens next: how I built, step by step, a memory system that holds up.

Step 1 — One file, one sentence

At the start, it was a plain context.md file with a vague directive:

"Aggregate the information and split it into topics."

And it worked. Claude received the emails, sorted them by subject, kept a summary per topic. For a first attempt, that was already useful.

Step 2 — The problem of losing information

Then I noticed I was losing information. When a project was finished, for instance, Claude updated the aggregate: "project complete, handover satisfactory." Fine. But the history disappeared. When had the project started? When was it delayed? When was an amendment signed? All of that was overwritten by the latest update.

I needed both: the final information and the history.

The solution was to ask Claude to maintain, on top of the aggregate, a chronological log. If a project starts, that's a line. If it's delayed, that's another line. If an amendment concerns the project, that's yet another line. In the aggregate, you see the current state: "project started in January, finished in June, satisfactory." In the log, you see each stage, each event, in order.

Two views of the same subject. One to understand quickly, the other to trace the thread back.

Step 3 — Business directives

Then I wanted to give it finer processing rules. Not generic rules — directives specific to my context.

For example: when someone is referred to by their surname, find the matching first name. That sounds trivial, except when two contractors share the same surname. In that case, the directive spells it out: use the meaning of the email to disambiguate.

Another case: some people are referred to sometimes by their maiden name, sometimes by their married name. Without a directive, Claude creates two separate entries for the same person. With the directive, it knows it's the same person.

Yet another example: separate small debtors (under 100 euros) from large ones. Not the same handling, not the same follow-up, not the same level of attention.

These directives aren't universal rules. They're specific to my context. And that's precisely what makes them powerful: they encode knowledge that only I hold, which Claude then applies systematically, without forgetting, without tiring.

Step 4 — The 1,000-line wall

It was working well. My context.md was organizing my knowledge properly. But it was starting to swell. 500 lines, then 800, then more than 1,000.

The problem isn't just readability for me. It's the LLM's context window. The bigger the file, the more Claude has to load the whole thing every session. And as I explained in the previous article, an LLM loses precision on information buried in the middle of a long document. My single file was starting to work against me.

Step 5 — Separating directives from context

First solution: extract the directives into a separate file.

The directives — how to handle names, how to separate debtors, how to deal with duplicates — aren't information about the building. They're processing rules. Mixing them with the context is mixing the recipe in with the ingredients.

A directives.md file on one side. The context.md on the other. Better already.

But context.md kept swelling.

Step 6 — Splitting the context by topic

The real solution was to ask Claude to split my context.md into as many files as there were topics. Works in one file. Finances in another. Contractors in a third. And so on.

And so it could find its way around: a readme.md listing every file, with a short description of each topic.

The first split didn't fully convince me. That's normal: I'd asked it to split without giving precise directives on how to do it, so it did as it saw fit. And sometimes its view of the split didn't match mine. I had a file of several thousand lines — I didn't necessarily see it the way it did.

With a bit of discussion, and a few reinforced directives on the split, we arrived at something that suited me. The files are properly divided. And above all: Claude now reads and writes only in the files it needs. No more monolithic file loaded whole every session. The context window no longer runs away.

Step 7 — Externalizing the vocabulary

One last refinement: we have a lot of technical vocabulary in the building-management context. Technical names, acronyms (DPAE…), legal terms. Rather than leaving them scattered across each thematic file, I asked it to centralize everything in a glossary.md.

The final model — simple and robust

And there it is. Without going all the way to a complex memory system — no loading manifest, no atomic notes, no episodic memory — I have a model that amply covers my need:

directives.md       — processing rules
glossary.md         — technical vocabulary
readme.md           — index of topics
themes/
  residence.md
  travaux.md
  finances.md
  prestataires.md
  ...               — one file per topic

Four concepts. A rules file, a glossary, an index, and thematic files. That's all.

To give a concrete idea, here is the actual readme.md of my building-management context as it stands today — 15 thematic files:

This directory was previously a single monolithic file of more than 1,000 lines. It was broken down into 14 thematic files in a single session, then debiteurs.md was extracted from acteurs.md the same day — because debtor management deserved its own space.

What it changes day to day

The gain is massive.

For someone who has been following a subject for six months — the managing agent handling a project, the contractor replying on a quote — the context is in their head. They know where things stand because they lived through each stage.

When I land on an email, I don't have that luxury. I have to climb back up the chain, reread the earlier exchanges, reconstruct the state of the subject. With 15 parallel topics and threads stretching over months, that's an enormous amount of work.

With the system in place, everything is aggregated. I know there's a new email. But more importantly, I know what has changed, how a given piece of data has evolved, where things stand. I have the historical trail. I have the list of people contacted. I have the list of contractors with their fields and their amounts. All this information is organized and stable. The list of contractors doesn't change with every email — it grows gradually.

And when a question comes up — "which contractor did the latest quote for the gutters?", "where does the file with such-and-such debtor stand?" — I just ask Claude. If you have 300, 400, 500 emails and you have to find the answer to that kind of question by rummaging through your inbox, it's hell.

Where to start?

If you want to try, I'd suggest going through Claude CoWork if you don't come from a development background. It's simpler; you don't need to pull out a whole development tool. Just two things to do:

1. Create a context.md file
2. Give 2–3 directives in the conversation: "I'm going to give you some information, you aggregate it, you keep a history if there are several stages to that piece of information, and you put all of it into the context.md"

And then you start talking to Claude. You give it information, you see how it organizes it, you adjust. The point of the first time is simply to learn. Not to build the perfect system. To learn how it works, how the AI responds, what it does well and what it does badly.

For my part, I went straight to Claude Code because I come from development. It was simpler for me, and it's more powerful. But the choice of tool isn't the most important thing — what matters is the method.

The cost of entry

How long did it take me? Starting from zero, never having known Claude, I'm at about 40 days to reach the current system (plus a ton of other things I'll need to talk about: competitive intelligence, this blog is also entirely managed by Claude, support documentation management, a data analyst agent…). But I have an advantage: before being a product manager, I was a developer. That helps with the tooling side. As for the method side — how to structure information, which directives to give — it's within anyone's reach.

The question of trust

Of course Claude makes mistakes. But so do humans.

The thing to see is that you obviously wouldn't hand the management of banking documents over to an AI. There are domains where you have no right to err. But for structuring building-management emails, if Claude occasionally links a piece of information incorrectly, it's no big deal. The time savings are so significant that a few approximations are an acceptable price.

And above all, I always have a way out: my inbox. All the raw emails are kept in the repository — a copy of every raw email in the Claude project. At any time I can search directly on the original emails via Claude Code, without going through the aggregated information. The structured system is an accelerator, not a replacement. The source of truth stays accessible.

From personal to professional

I applied exactly the same approach to my work as a PM. At the start it was truly makeshift — a context file, a skill, conversations in the console without really knowing how it worked. And then I learned. I dived in, I made plenty of mistakes.

I threw away the first version of what I'd built. The second one, I thought I'd throw away too, telling myself "it'll be much better, but at least I'll learn things." And then the second one, I kept it — it still works. And I iterated on it to reach a third version, the one I describe in the previous article.

Evolve, don't skip steps

I'm on the third version of my system. I've just converted the last elements of V2 to V3. And maybe one day I'll have a V4, even more complex, but delivering even more value.

But you have to be pragmatic. You do a version bump because the needs are growing — not just because it's fun. Otherwise, it's over-engineering.

The path is: one file → directives → a split → a glossary → a system. Each step answers a concrete problem. You only move to the next one when the previous one no longer suffices. And at each step, you have something that works.

Start with a file. You'll know soon enough when it's time to split it.

To go further

The PM as Architect of Context Adding session memory, like OpenClaw