The first time an agent is used, it can feel like magic. Ask a question, get an answer. But the next session starts from the same place — no memory of what was discussed, no record of what was decided, no continuity. The magic was in the answer, not in any persistent capability.

That changes once memory is added. The agent that writes decisions to a file and reads them back in the next session has continuity. The agent that does not has none. The difference is entirely in what the operator sets up, not in any special capability of the model itself.

This piece is the practical first-day explanation. It covers what a session is, what memory is, how the two compose into a lifecycle, what the common mistakes are, and what the operator's session ritual should look like.

What a session is

A session is a bounded conversation. It starts when the agent wakes up and ends when the session closes. Inside the session, the agent has perfect recall of what was said in that session. Outside the session, the agent has nothing.

The session has a beginning. When the agent starts, it receives its system prompt, its context from prior turns, and whatever the user typed. Everything the agent sees in that first moment shapes what it will do for the rest of the session.

The session has a middle. The user asks, the agent responds, the agent reads files and writes outputs, the conversation accumulates useful information. The session is warm during this phase.

The session has an end. It ends when the user closes it, when the context fills and the system compacts it, or when the system reclaims the session after a period of inactivity. What is not written to durable storage before the session ends is gone.

The cold start

Every session starts without context. The agent does not remember yesterday's conversation. It does not remember what was decided last week. It does not remember the operator's preferences unless those preferences are written somewhere the agent will read at startup.

The first job of each session is to recover the relevant context. This is called the cold start — the agent is cold because it has no session-specific memory, and it must warm up by reading files, recalling memories, and restating the current task.

What the cold start looks like in practice: the agent reads a MEMORY.md file, reads recent daily notes, reads the current project's files, and orients itself to what is in progress. This takes a few seconds and a few tool calls. It is not free. A session that skips the cold start starts working on assumptions that may be wrong.

The operator controls the cold start. The operator decides what files the agent reads at startup and what the agent should know before it begins work. A well-designed cold start is fast — it reads only what is needed for the current task — and thorough — it reads everything that is needed.

The warm middle

Once the agent has context, work happens. This is the warm middle of the session: the user asks, the agent responds, the agent reads and writes, the conversation fills with useful information.

During the warm middle, the agent is drawing on three sources simultaneously. Context holds what is in front of the model right now — prior turns, tool outputs, files that were just read. Memory holds what was written in prior sessions — decisions, preferences, project state. Pattern-matching holds what the model learned in training — conventions, facts, plausible continuations.

The warm middle is where the agent is most capable. It has context, it has memory, and it has the full model. The risk during the warm middle is that context fills. As the conversation grows, older content is pushed toward the edge of the context window. Eventually, if the session is long enough, the oldest content is truncated. The piece on how does an agent understand covers the three-place model that operates during the warm middle.

The cool end

Two things can end a session, and they have very different consequences.

The first is a clean end. The user closes the session or explicitly ends it. Before closing, the agent has a chance to write what it learned to memory. A clean end is an opportunity: the agent should have written its key decisions to durable storage before the session closed.

The second is a compaction end. The context window fills, and the system compresses older turns into a summary. The summary is not the original transcript. Details are lost. The agent sees a compressed version of what was said, not what was actually said.

The compaction end is the failure mode most operators do not anticipate. If the agent has not written its work to memory before compaction, anything only in the context is gone. The fix is aggressive writing: write decisions as they happen, not only at the end of the session. A decision in a memory file survives; a decision only in context does not.

The cold start cycle

The pain point of the session model is the cold start. Every session starts without memory of what happened in the last one. The agent has to re-learn what the operator already told it. The operator has to re-explain what was already decided.

The fix is memory, but the fix has a correct implementation and an incorrect one.

The incorrect implementation is writing memory at the end of the session only. This works if the session always ends cleanly. It fails if the session compacts before the end, or if the operator closes the session without waiting for the agent to write.

The correct implementation is writing memory as work happens. When a decision is made, write it. When a preference is stated, write it. When a project changes state, write it. The agent that writes during the warm middle is not dependent on a clean end to preserve its work.

The agent that reads aggressively at session start also has a better cold start experience. The session-start read should be targeted — the agent reads what it needs for the current task, not everything in memory. But it should read what it needs before it starts acting, not after it has already made assumptions.

What to write down

Not everything belongs in memory. The discipline is to write what is durable and skip what is session-specific.

What belongs in memory: decisions (what was agreed to, what the plan is, what the constraints are), preferences (how the operator likes things formatted, what the operator's default approach is), entity details (facts about projects, clients, and work that do not change often), and standing constraints (rules the agent should follow on every task).

What does not belong in memory: small talk, debugging logs, session-specific scratchpad content, information that will be outdated within a day, and notes that are really just a transcript of what was said.

The test for what to write: if this fact changes how the agent approaches its next task, write it. If it is just a record of what happened, decide whether the record is worth keeping. A memory file that is too full to read is as bad as no memory file at all.

Three memory mistakes

The first mistake is writing too much. The agent fills its memory with trivia — every turn logged, every minor decision recorded, every随口说一句 noted. The result is a memory file that takes longer to read than it would take to re-learn the facts. The agent slows down because it is reading its own notebook instead of doing the work.

The fix is a memory hygiene standard. Review the memory file periodically. Remove what is no longer relevant. Summarize what has accumulated. A memory file that fits in a few pages is readable. A memory file that fills a dozen pages is not.

The second mistake is writing too little. The agent decides not to write something because it seems obvious, or because the session ended before the write happened, or because the operator never established the habit. The result is an agent that forgets what was decided and requires re-explanation every session.

The fix is a session ritual: before ending, write the key decisions to memory. Before starting, read the memory. Make the ritual a habit and the agent's continuity improves dramatically.

The third mistake is writing in the wrong format. The agent writes a wall of text that is technically accurate but hard to parse. Future sessions cannot find what they need because the memory file is a prose dump, not a structured record.

The fix is structure. A decision belongs in a decision log. A preference belongs in a preferences section. A project status belongs in a project file. Structured memory is findable. Unstructured memory is a pile.

The session ritual

The session ritual has two parts: the start ritual and the end ritual.

The start ritual: before doing anything else, read the MEMORY.md file, read recent daily notes, read the current project's status. Orient to where the work stands. Then begin.

The end ritual: before closing, write key decisions to the memory file, update the project status if anything changed, and note what is left for the next session. Then close.

The two rituals take less than a minute. They are the difference between an agent that has continuity and an agent that starts from zero every session.

What this is not

This piece is not a guide to the OpenClaw session system specifically. The mechanics of session files, memory paths, and context compaction are platform-specific. The concepts — cold start, warm middle, the session lifecycle — apply to any agent system.

This piece is not a guarantee that following the ritual prevents memory failures. Memory files drift. Decisions become outdated. The operator needs to review the memory files periodically, not just write to them. The piece on memory: short, long, and semantic covers the ongoing curation that keeps memory accurate.

See also