Memory is not the transcript

People treat the conversation as the memory. They scroll up, they paste "remember this" into a late turn, and they are surprised twice: once when the next session has forgotten the standing fact, and once when it has remembered an aside that was never meant to last. Both failures come from using one object for two jobs.

The transcript is the work in progress. It is how this particular thread got to this particular sentence. Memory is what should still be true when that thread is over. T-FORCE keeps those apart. Each agent has its own memory. The project has a shared one. The chat is neither of those stores. It is the place the work is happening.

Why one context loses the standing fact

A model attends to what is recent and what is loud. A tool result, a long quote, a stack trace, a generated image's caption: any of these can outweigh a sentence you typed forty turns ago. The sentence might have been the actual constraint. "The client is a hospital group. Do not propose a consumer brand." It loses to the last page the researcher fetched, because the last page is longer.

Stuffing more of the transcript into the next call does not fix the shape of the problem. It raises the odds that the loud thing and the standing thing are both present, and then asks the model to notice which is which. Sometimes it does. The times it does not are exactly the times you needed the constraint.

A separate memory is a bet that standing facts should not have to compete, turn by turn, with the debris of the current task. The chat can be messy. The memory should be the part you would still want if you started a fresh conversation on the same project tomorrow.

Two memories, because the team is not one person

If every specialist read and wrote the same memory, you would have rebuilt the single transcript under another name. The researcher's sources, the writer's tone notes, the developer's map of a repository, and the operator's sense of which Slack channel is the loud one are not the same knowledge. Pooled, they become a junk drawer. The next agent pulls the wrong object because it was nearby.

So each agent keeps its own. That stays true even when two agents come from the same template. Hiring a second researcher does not hand the new one the first one's notes. They share a method, in the sense that the template is the same role. They do not share a biography. This is the difference between "we have a research function" and "we have one researcher who has seen everything."

The project memory is the other half, and it exists because some facts are not anyone's specialty. The name of the effort, the repository, the deadline, the decision you already made and do not want relitigated in every hire. If that lived only in the Manager's chat, a specialist hired on Thursday would be working from a rumor. If it lived in every agent's private memory, you would have to hope they were updated together. A shared project memory is the small set of facts the whole job depends on, kept once.

The split will feel inconvenient the first time you want a specialist to "just know" something that was said in passing to someone else. That inconvenience is the feature. Passing knowledge should be a decision about where it belongs, not a side effect of having been in the room.

What not to store, even though you can

A memory that records everything is a transcript with a different label. The useful test is whether the fact changes the next piece of work, or only explains the last one. Explanations belong in the chat. They are how you audit a decision. They are rarely how you brief the next one.

A few kinds of fact earn a place:

• A constraint that would be expensive to rediscover, such as a name, a system, a file that must not be touched.
• A preference stable enough that restating it every session is the waste, such as the shape of a weekly note.
• A correction. If the team did the wrong thing and you said why, the why is more important than the attempt.

A joke, a rejected tangent, a half-formed alternative you talked yourself out of: those are how the chat got somewhere. Promoting them into memory is how next week's work inherits last week's discarded idea and treats it as policy.

T-FORCE does not pretend to know that distinction for you. The product separates the stores so the distinction is possible. It does not read your mind about which sentence was the policy. If everything you say is treated as durable, you are back to the transcript, only now it is harder to see, because it is no longer in the scrollback where you can watch it happen.

Local memory is still not a private thought

The memories live on the PC, in the same local database as the project. That is a claim about storage. It is not a claim that a model provider never sees them.

When an agent calls a model, the request goes to the provider you chose: OpenAI, Anthropic, DeepSeek, Moonshot, Ollama on the machine, or the built-in T-FORCE provider. Whatever the agent includes in that request leaves with it. A fact kept in local memory can still be inside the prompt that crosses the network, if you are not on a local model. Keeping the record at home and keeping the inference at home are different designs. This one does the first by default, and the second only when you pick a local model.

That is worth saying in an essay about memory, because "it remembers on your computer" is the sentence people hear as "it remembers in private." The file is on your computer. The recollection, at the moment it is used, goes where the model call goes. If that difference matters to the work, it should change which provider you pick, not which metaphor you use for the database.