The need

Working with an LLM on a complex subject — a product opportunity, strategic intelligence gathering, a discovery — quickly outgrows the simple conversation. You accumulate sources, decisions, hypotheses, contradictions. You come back the next day and the LLM has forgotten everything. You copy-paste an ever-growing context.md file, and at some point it just stops holding together.

The problem isn't that the LLM lacks intelligence. It's that it lacks structured memory.

How I got here

I started out like everyone else. On ChatGPT, chatting away. The problem showed up fast: with every exchange, the AI would regenerate the entire document. Or only part of it, but without access to what came before. I'd say "show me what we did earlier," it would regenerate everything, we'd waste an enormous amount of time, and the content would end up drifting apart.

The next step was to move to Claude Code — a tool that lets you talk with an LLM while letting it write directly into a Markdown file. Every so often I'd ask it to restructure things, I could reread easily, and even edit the text myself. It was better. But a single long file still wasn't enough.

And above all, a deeper problem surfaced: the file is either organized for the human or for the AI — never for both. The AI needs landmarks to pick a session back up where it left off, to remember decisions, to find sources again. The human needs to aggregate the information, validate it, break it down by theme or by risk. Not the same structure, not the same needs.

So I ended up with two files. One for the AI, one for the human. That held for a while. But both eventually ballooned, and there was a bit of everything in each — sources, decisions, hypotheses, directives, all mixed into the same stream.

I started splitting things up. A separate directives file, which isn't about a feature but about how the AI should work. Then a definitions file. Then others. And at some point it clicked: I shouldn't be thinking in files anymore, but in a system of organization. And since LLMs are inspired by the human brain, perhaps their memory should be too.

Here, in a simplified version, is what a structured context looks like:

<context>/
├── 00_mission/
│   ├── mission.md            ← why we're here
│   ├── directives.md         ← how the AI should work
│   └── load_manifest.json    ← what to load, in what order
├── 01_active/
│   ├── active.md             ← current state + plan
│   └── decisions.md          ← decisions made and why
├── 02_checkpoints/           ← stage snapshots of the context
├── 03_sources/
│   └── source_catalog.md     ← index of raw sources
├── 04_notes/                 ← atomic notes, linked to one another
├── 05_memory/
│   ├── journal/              ← what happened (episodic)
│   └── synthesis.md          ← what we take away from it (long term)
└── 07_outputs/               ← deliverables produced

Each folder has a precise role. Nothing is mixed together. And above all, you don't load everything each session — you load the core (00_mission + 01_active), and the rest on demand.

What really matters is context

But before spelling out why this structure works, we have to lay down a broader truth.

What makes us excel in a field is rarely technique. It's the depth of the context we've internalized.

A good salesperson doesn't sell better because they've mastered a script. They sell better because they understand what's at stake for their client — their constraints, their fears, their vocabulary, what they leave unsaid. A good product manager doesn't build a better product because they know the frameworks. They do it because they've understood the user's context — their habits, their friction points, the workarounds they resort to for lack of anything better. A sociologist doesn't understand a social movement by reading statistics. They understand it by grasping the lived context of a group — its codes, its internal tensions, its relationship to the world.

Context is what turns information into understanding. The rest — the decision, the action, the production — follows almost mechanically.

And that's exactly what's missing when you work with an LLM on a subject that stretches over time.

You can't put everything in a single file

A human brain doesn't function by loading everything it knows at every instant. It breaks things down. It files them away. It separates what's stable from what's in progress. It distinguishes a raw source from a personal conviction. It forgets the details to keep the patterns.

An LLM is the same — but worse. Its context window is finite. And the more you fill it, the more its attention degrades on whatever is buried in the middle. This isn't a hunch: Stanford researchers demonstrated it in Lost in the Middle (Liu et al., 2024). Their conclusion: an LLM retrieves information placed at the beginning or the end of its context far better than information buried in the middle. Loading a 3,000-line file and hoping it will "understand everything" is like reading an entire book aloud to someone and asking them to retain every sentence.

What you need is to load only what matters for the task at hand. And for that, you have to have broken the knowledge into navigable pieces.

Load the minimum, with the maximum impact

If the problem is clear — you can't load everything — the question becomes: what to load, and how?

The solution is to have a compact core that you load systematically: the mission (why we're here), the current state (where we are), the plan (where we're going), the decisions made, the open contradictions, and a resumption sheet. This core fits in a few short files. It gives the LLM everything it needs to be operational immediately, with no noise.

Then, depending on what the session requires, you load on demand: a specific source you want to analyze, a note you want to enrich, an old checkpoint you want to compare against. The rest — the dozens of sources, the atomic notes, the session journals — stays on disk, accessible but not in the context window.

For this to work, you need a mechanism that tells the AI what to load, in what order, and with what priority. That's the role of a load manifest — a kind of context playlist. First: the mission and the current state (the core, always). Then: the recommended files for the current phase. Finally: the files that are available but loaded only if the session calls for them. It's a surgeon's tray: the essential instruments are already there, the others are within reach, but you don't put everything on the table.

That's exactly what a human expert does. They don't reread their whole file before every meeting. They've internalized the essentials, and they go find a specific document when they need it. The difference is that an LLM can't internalize — it only has what you give it. Hence the importance of giving it the right subset, not everything.

Separating sources from what you produce

A common mistake: mixing everything together. The transcript of an interview, the hypothesis you draw from it, the decision you make, the deliverable you generate — all in the same file, in the same stream.

The problem is traceability. When everything is mixed together, you no longer know what came from where. You no longer know whether a statement is a sourced fact or an interpretation. You no longer know whether a decision is still valid or whether it has been superseded.

Separating the sources (the raw material) from the memory (what you retain from it) and from the outputs (what you deliver) isn't bureaucracy. It's what lets you keep your reasoning reliable over time.

A well-structured context produces more than what you ask of it

A classic problem in product management: you write plenty of documents, but you can never find what you're looking for. The discovery notes are asleep in a Google Doc. The product brief is in a Notion. The write-up of the strategy meeting is somewhere in Slack. The information exists, but it's scattered, unlinked, unusable.

When you structure a context around a subject — separating the sources, the notes, the decisions, the memory — something powerful happens. That context becomes a reusable foundation. From the same core of knowledge, you can generate very different deliverables: a release brief, user stories, a communication pack (summary, newsletter, LinkedIn post), a presentation for the leadership committee.

You don't rewrite everything each time. You combine the right building blocks of the context to answer a specific need. The LLM invents nothing — it assembles what's already there, at the right granularity and from the right angle. It's the difference between dictating a document from scratch and asking an assistant who already knows the whole file to reframe it in a new format.

That's where structuring goes from "good practice" to a real advantage: a well-organized context isn't just readable, it's productive.

The end of the sequential

Classic product management works in phases: you do the discovery, then you write the specs, then you deliver, then you communicate. Each step waits on the previous one. It's clean on a diagram, but it's slow — and it doesn't reflect the reality on the ground.

With a system of contexts and an LLM, this sequencing breaks down. Discovery never really stops. You're in continuous dialogue with the AI to refine, challenge, reformulate. The context matures constantly, and the deliverables improve as it matures — not at the end of a phase, but during it. You can put out a first brief as early as the second session, have it evolve as the context grows richer, and the final deliverable is nothing but the latest iteration of a document that grew alongside the thinking.

But the most interesting effect is elsewhere. When you work this way, you open a lot of contexts. Product opportunities, explorations, intelligence gathering. Some will never become a feature. They're "useless" in the classic sense of the word. Except that these contexts aren't isolated. They're connected. An exploration of industrial maintenance habits feeds into a reflection on asset management. A survey of SaaS pricing models sheds light on an opportunity to monetize a module. Three contexts that seemed independent converge one day on a fourth, which would never have been as rich without them.

It's a shift in posture. You no longer work in "one idea → one deliverable" mode. You cultivate a network of contexts that fertilize one another. And the day a product decision has to be made, the soil is already there.

Precise ideas, linked to one another

This network of contexts operates at large scale. But within each context, the same principle applies at the scale of ideas.

What makes intelligence — human or artificial — isn't accumulating knowledge. It's linking precise ideas to one another. And especially distant ideas.

An example. In the field of timetable optimization — assigning rooms, resources, and slots under multiple constraints — one of the most effective approaches is called simulated annealing. In 1983, Kirkpatrick, Gelatt, and Vecchi published a foundational paper in Science: they showed that a metallurgical process — heating a metal and then cooling it slowly so its atoms find a stable configuration — could be transposed into a combinatorial optimization algorithm. No obvious connection between a foundry and a room schedule — and yet this transfer changed an entire field of research. The link exists, provided you've caught it.

That's exactly the promise of the Zettelkasten — the system of atomic notes invented by the German sociologist Niklas Luhmann, who described his slip box as a “communication partner” (Luhmann, 1981). Each idea is isolated, precise, and explicitly linked to others. You don't store blocks of text. You store units of thought, each with its links. And it's in those links that intelligence emerges: when a note on a physical phenomenon meets a note on a scheduling problem, when a field observation joins up with a theoretical hypothesis read six months earlier.

Applied to a system of contexts for an LLM, this means: don't write long monolithic syntheses, but short notes, well titled, well linked. Each note is a point. The network of links between those points is the map. And it's this map that lets you — human and LLM alike — make connections that a flat file would never allow.

This is, incidentally, the intuition behind A-MEM (Xu et al., 2025) — a memory system for LLM agents directly inspired by the Zettelkasten. Structured notes, dynamically indexed, linked to one another. An architecture that gives the AI the means to navigate its own memory rather than loading everything in one block.

Short memory, long memory, and the right to trace the thread back

A human brain doesn't have a single memory. It has several, operating on different timescales. That's what Atkinson and Shiffrin formalized as early as 1968 with their multi-store model: a sensory register, a short-term memory, a long-term memory. Endel Tulving then refined the distinction in 1972 by separating episodic memory from semantic memory. Concretely: working memory holds what's happening right now — a conversation, a calculation in progress. Episodic memory stores lived events — what you did on Tuesday, what the client said in the meeting. And long-term memory consolidates lasting truths — the reflexes, the convictions, the patterns you've internalized through experience. An experienced driver no longer thinks about how to shift gears. A senior product manager doesn't rediscover on every project that users lie in interviews. That knowledge has become automatic.

A system of contexts for an LLM reproduces this architecture. The session journal is the episodic memory: what happened, when, in what order. The consolidated synthesis is the long-term memory: the stable conclusions, the validated decisions, the patterns extracted from dozens of sessions. And the checkpoints are the stage snapshots — the complete state of the context at a given moment.

But there's a fundamental difference from the human brain. A brain forgets — and that's even its strength, it keeps it from saturating. A file system, on the other hand, forgets nothing. And that's where auditability comes into play. In a well-structured system, every refined piece of information — a product conviction, a strategic decision, a validated hypothesis — can be traced. From the synthesis, you go back up to the checkpoint that produced it. From the checkpoint, you go back up to the sessions. From the sessions, you go back up to the raw sources — the interview, the article, the data.

It's the same principle as in science: a conclusion is only worth something if you can trace it back to the method and the data that produced it. When a stakeholder asks "why this decision?", the answer isn't "because the AI said so." It's "here's the path: source → analysis → synthesis → decision." Everything is traceable, everything is verifiable. Memory isn't a black box — it's a chain of evidence.

What this changes in practice

Before, my job as a product manager consisted, for a good part, of producing documents. Lots of documentation. Some pieces called on expertise — strategic framing, architecture trade-offs, prioritization. But many others were content production from already-existing information: support documentation, blog articles, newsletters, release notes, internal communication. Necessary work, but largely automatable once you have a solid context.

Today, that's in the process of being automated. Not because AI is "magic," but because a strong, coherent, complete context makes it possible to generate these deliverables almost autonomously. Support documentation is deduced from the decisions and the specs. The newsletter is built from the release notes and the product context. Some deliverables are automated at nearly 100%. Others — user stories, for instance — still require a human review, but the first draft is already solid.

The most profound change isn't in the production. It's in the raw material. Before, we wrote documents in order to build products. We drafted deliverables so we could ship software. It was the deliverable that mattered — the final document, fixed, validated.

Today, we write contexts. We talk with the AI — often out loud, in front of the screen — to create, enrich, and refine context. The deliverable is no longer the starting point of the work, it's a by-product. What has value is the context itself — and, as we've seen, the network of connected contexts that fertilize one another.

Where this leads

What's taking shape is a shift in the product manager's posture. You go from someone who does a lot of things alone — discovery, specs, communication, coordination — to someone who manages a team of AIs. You discuss, you explain context, you challenge the results, you arbitrate. The day-to-day looks less like writing and more like management.

And it's a demanding exercise. Explaining a context to an AI that knows nothing about it forces you to check that you understand it yourself. Re-explaining, reformulating, clarifying — it's a merciless mirror. If the context is fuzzy in your head, the result will be fuzzy. AI doesn't compensate for vagueness, it amplifies it.

Naval Ravikant talks about specific knowledge — that knowledge which can't be taught, which can't be reduced to a process. You can teach accounting. You can even automate it, hand it off to an AI. But there are skills we don't know how to formalize. Why is a given person excellent in a field we can't manage to reproduce? That's specific knowledge — built through experience, intuition, lived context.

I believe that's where the human refocuses. The AI takes charge of what's formalizable: content production, aggregation, formatting. The human keeps what isn't: the opinion. Because building product means cross-referencing quantitative and qualitative data, it means piecing together weak signals — but in the end, it means having a conviction. And a conviction can't be delegated.

Having an opinion sometimes even means taking outsized risks. In a startup, some people choose a 1 or 2% chance of becoming a unicorn — and a 99% chance of dying. What AI would make that decision? Taking risks, holding clear-cut positions, betting on a vision the data doesn't yet validate — an AI doesn't know how to do that. Not today, at any rate. And that's precisely what gives a software company its culture, its color, its DNA. What makes one product not interchangeable with another, even when the features look alike. It isn't the AI that creates this difference — it's the human behind it.

This system of contexts isn't an end in itself. It's a tool so the human can focus on what they do best — thinking, deciding, having a point of view — while delegating the rest to an AI that finally has the means to remember.

This system handles the upstream — the reflection, the structuring, the decision. But downstream, another transformation is underway.

We've all lived it: documentation is produced at the specification stage, then development moves forward, trade-offs are made, adjustments happen along the way — and nobody has the time to go back and update every spec, every changelog, every support document. The result is always the same: the documentation and the code end up drifting apart. The older the product gets, the wider the gap grows.

Today, AI makes it possible to reverse this flow. When the code is clean and documented enough, you can make it the source from which everything else is rebuilt: updating support documentation after a release, generating a more reliable changelog, or reconstructing a functional specification from the actual state of the product rather than from an old document.

This is what you might call a code centric approach. The code is no longer just the final deliverable — it becomes the central element, the source of truth around which the product's other artifacts orbit and regenerate. The same logic holds for design: if you're able to reconstruct a design system from the actual code and keep it up to date, the mockup changes status — it's no longer a fixed representation, it becomes a workable base.

I explore this idea in more detail in this article.

To learn more

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