Main idea

A workspace hosting several projects — technical documentation on one side, competitive intelligence on the other — produces, within the same day, exchanges that have nothing to do with each other. A global memory stacks them in the same file, in the order they arrived.

What is lost then isn't the content, it's the ability to reload it. Picking competitive intelligence back up the next morning means ingesting everything said about the technical documentation too: half of what you put back into the session is noise for the work at hand, and noise takes the place of what matters.

Partitioning is therefore settled where the memory is written, not where it is read. Each sub-project gets its own memory_sessions/ directory, and the sorting happens at the moment of recording: the exchange is attached to the project it concerns, and it will never show up in the others' memory. A filter applied at read time would arrive too late — you would have had to reread everything to know what to discard.

Layer added by "Information systems aren't going away. Their shape is changing." (2026-07-08). The same partitioning holds at company scale, where the perimeters carry the names of business functions: support doesn't need product's memory, marketing doesn't split the way engineering does, leadership doesn't work at the level of detail of the team executing. What that scale adds is a requirement the workstation case didn't surface — those perimeters have to be able to talk to each other. Partitioning remains the condition of reloading; it is not the condition of isolation.

Why it matters

This makes the partitioning of memory an architecture decision, to be taken before the first line is written, and not a tidying job for later. A mixed memory can't be untangled: nothing in the text says which project each line belonged to.

It also gives a simple criterion for sizing a context: the right memory perimeter is the one you will want to reload as a block.

Nuances and limits

Partitioning cuts through what crosses over. A tooling decision taken while working on one project often holds for all of them, and gets locked inside the one where it was taken.

And the attachment is itself a judgment: an exchange touching two projects has to be classified, and that classification can be wrong.

Open questions

• Where do you record what holds for all projects without copying it into each one?