Manage The Context Yourself

Two Kinds Of Remembering

Most assistants offer memory as a convenience, and for most people it is one. It accumulates quietly across conversations so that the tool feels like it knows you.

For this system it is the wrong mechanism, and the reason is not privacy. It is inspectability.

There are two ways a session can know something. It can know it because the platform carried it forward from a previous conversation through a process you did not see and cannot read. Or it can know it because it read a file — one that sits in your vault, that you can open, that git has a history of, and that you can correct with an edit.

Both feel identical from inside the conversation. Only one of them can be audited, and only one of them can be wrong in a way you are able to find.

What Goes Wrong With The Invisible Kind

The failure is not dramatic. It is that you slowly lose the ability to answer a simple question: why did it think that?

An assistant that carries context invisibly will one day make an inference that surprises you, and the honest answer to where it came from will be unavailable to both of you. You cannot diff it. You cannot quote the line that caused it. You can only try to talk it out of a belief whose origin neither of you can locate — which is a bad position, and one that gets worse as the system accumulates more of your life.

It also silently couples things you deliberately kept apart. Working on one venture in the morning and another in the afternoon, you want the second session to know the operating rules and not the first venture’s specifics. Automatic memory decides that for you, using a policy you did not write.

Context As An Artefact

The alternative is to make every piece of carried-forward knowledge a thing on disk. This is what files are memory argues structurally; the practice side of it is a habit.

• Turn the automatic kind off, deliberately. Not because remembering is bad, but because you want to be the one who decides what is remembered.
• Ask for the write-up before you need it. At the end of a working session that produced something durable — a decision, a rule, a shape you settled on — have it written to a file. The moment it is a file, it is reviewable, and it survives the session ending.
• Know which folder you are standing in. A session run inside the vault knows your ventures and the people in them because the vault is there to be read. A session run in a project folder knows that project. That is not a limitation to work around; it is the boundary doing its job.
• Let the gap be visible. If a session does not know something it should, the fix is a file it should have read — which is a fix you can make once and which then holds for every session afterwards. An invisible memory that failed to carry something forward gives you nothing to repair.

The Trade You Are Actually Making

You will do slightly more work at the end of a session and considerably less work six weeks later, when something is wrong and you need to find out why. That is the entire trade.

It also produces a system that another person — or another model, or the same model a year from now — can pick up and run, because everything it knows is written down rather than held in a vendor’s store you do not control. Portability is not the reason to do it. It is what falls out of doing it.

#context · #memory · #sessions · #files