For months, two opposite defects in the same system looked to me like a single problem. Worse: every fix I tried on one of them aggravated the other — and I did not even have the words to say which was which.
The first defect even had a physical artifact: the context paragraph. Every new conversation began with me typing the same thing again — what I am building, why that decision exists, which risk has already shown up, what got discarded along the way. I was carrying, by hand, the memory of a system that presented itself as intelligent. And every retelling came out slightly different from the last: missing the exact criterion of the old decision, missing the risk that had seemed important the month before. The system forgot too much, and my own memory refilled it with losses.
The second defect was the exact inverse. A preference I had stated once, inside a specific context, started weighing on new decisions as if it were a rule. A momentary correction became a principle; a passing complaint became a criterion. The system had remembered wrong — in a way that never showed on the surface. It showed up later, at the moment of deciding and trusting.
My instinctive reaction was to give both defects the same name: "the AI's memory is bad". And as long as they shared that name, every fix I tried made one of them worse. Keeping more context shortened the ritual paragraph and worsened the contamination. Keeping less cleaned up the contamination and lengthened the paragraph. I was turning a single knob for two problems that lived in different layers.
That was when I understood something uncomfortably simple: I did not have a technology problem. I had a vocabulary problem.
Why "it's all AI" gets expensive
When the category is too small, so is the diagnosis.
If I call everything an assistant, I measure the system by the quality of the current answer — and never see that tomorrow's value is leaking away. If I call everything memory, I treat any record as a durable asset — and Tuesday's venting becomes a decision criterion in December. If I call everything an agent, I see autonomy where there is only a sequence of obedient steps — and I trust what I should not.
The pattern is the same in all three cases: the wrong word hides the layer where the defect lives. And a defect that cannot be located cannot be fixed, only compensated for — which was exactly my months-long cycle of turning the wrong knob.
Vocabulary, in a personal system, is not pedantry. It is a diagnostic instrument: you can only fix the layer you can name.
Atlas needs four words because it has at least four layers with different rules. Here is the map.
To follow the four layers, it helps to trace one single piece of information through the whole path. Say that, in the middle of a conversation, I decide: "in this project, we will not use that shortcut — the cost shows up later". That one sentence will reappear in all four sections below, changing nature at every passage.
Session
A session is the live slice of an interaction: the current conversation, with its immediate context, its goal and its provisional decisions.
The session is valuable because it concentrates attention — it gathers enough context to produce a useful answer now. And it has a property that took me a while to accept: sessions are built to die. The defect is not that the conversation ends; it is that everything that mattered was trapped inside it when it did. My first defect lived here: I was expecting continuity from a layer whose job is to be disposable. In the example: the decision about the shortcut is born as speech — said once, alive as long as the conversation lasts, and dead with it if nobody does anything.
Memory
Memory is what deserves to survive the end of the session. The decisive word is deserves.
It is not the full log. It is not every sentence. Memory is retention with criteria: a preference that actually repeats, a decision that needs to come back later, a risk already identified, a relationship between projects. In the example: the sentence about the shortcut gets promoted as "this project's decision, for this reason" — not as a transcript of the whole conversation. My second defect lived here — not because the system remembered, but because it remembered without criteria: it promoted a casual remark to the same status as a considered decision.
Without this layer well defined, both errors from my story show up together: either the system forgets too much and always comes back naive, or it keeps too much and turns noise into invisible influence.
The most expensive version of that lesson I paid in code, not in conversation. Over several weeks I built an entire work-orchestration subsystem. It worked — and it was wrong: it duplicated a simpler path that already existed. I deleted all of it at once, 158 thousand lines removed in a single day, with the quality gates green before and after. Code that works can still be debt. "Does it deserve to survive" is a question that applies to everything a system accumulates — and the courage to answer "no" is part of the design.
Knowledge
Knowledge is what has already been prepared for stable reuse.
The difference from memory is subtle and it matters: memory preserves a case — "I decided X in that context". Knowledge organizes understanding — "this is the principle I use for cases like this". A study synthesis, a decision principle, a map of a topic become knowledge when they stop being residue of one conversation and start guiding many future tasks. In the example: when the same decision about the shortcut repeats across three projects, it stops being a case and becomes a principle — "shortcuts of this kind cost more than they save".
Atlas is not merely trying to remember. It is trying to turn context into capability — and that transformation happens exactly at this passage: from the remembered case to the prepared understanding.
Agent
An agent is the part that acts: it takes a goal, consults memory and knowledge, uses tools, and produces work without line-by-line instruction.
An agent is not a synonym for a model — a model answers. It is not a synonym for automation — an automation repeats a fixed flow. The agent occupies the more demanding spot between the two, and it is the layer that inherits every other layer's defects: without context it executes poorly; without memory it repeats mistakes; without knowledge it acts without understanding. When an agent fails, the cause is almost never in the agent — it is in the layer below that nobody named. In the example: the agent is the one who, months later, finds the principle about shortcuts and applies it to a new project — without anyone having to repeat the original conversation.
Four words, four policies
For someone who builds systems, here is the summary I would give: session, memory, knowledge and agent are not four features — they are four different retention policies. And "policy" here has teeth: each layer answers four concrete questions in its own way.
- Admission — what gets in? In the session, everything. In memory, only what passes a criterion. In knowledge, only what has repeated enough to become a principle. In the agent, nothing — it does not store, it consumes.
- Expiration — what dies, and when? The session expires whole, by design. Memory expires item by item, when the context that supported it changes. Knowledge does not expire by time: it gets revised when a principle fails in practice.
- Writes — who may record? In the session, anything said. In memory, only a deliberate promotion. In knowledge, only a synthesis someone — or something — prepared.
- Audit — what question must the layer answer? The session: "what is happening right now?". Memory: "why is this here?". Knowledge: "in which cases does this hold?". The agent: "based on what did you act?".
These policies are not theory: I trip over them inside Atlas itself. I found entire test suites that "passed" by pinning the behavior of an era of the system that had already been replaced. Green on the dashboard, a lie in meaning: they were protecting the past against the present. In this post's vocabulary, that is an expiration failure at the knowledge layer — a principle that had already failed in practice and that nobody revised. I rewrote the suites to test properties of the current contract, not snapshots of the old one.
A system that applies the same policy to all four layers will fail in four ways that look like one. That was the lesson of my two defects: they were never the same problem. One was a session doing memory's job — an expiration failure. The other was memory with no admission criterion. With separate names, each had an obvious fix. Without names, both were "the AI's memory is bad" — and bad it stayed.
One piece of honesty: the hardest boundary in this vocabulary, for me, is still the one between memory and knowledge. Edge cases show up every week — is a decision repeated three times already a principle? — and I still do not have a promotion rule that does not depend on judgment. The four words do not eliminate judgment. They only guarantee it happens at the right layer.
The question the vocabulary opens
With the four words in place, the next problem appears on its own, and it is the hardest one in the series: if memory is retention with criteria — which criteria? What exactly must a session contain to deserve becoming memory, and who decides?
That is where the next post goes: the memory problem in AI.