Zed AI Memory: Keep Coding Context Between Sessions

Zed AI memory starts with identifying the agent in your thread, the instructions it loads, and the context supplied for the task. To keep coding knowledge between sessions, use maintained project guidance and a verified handoff, then test a fresh thread. An old conversation or a long summary does not establish what every future agent will receive.

fenbs can keep the project’s decisions, lessons, and stopping point outside the editor. Use its web app or a supported connected assistant for that record, then bring the relevant facts into your Zed workflow. The aim is to preserve useful work without assuming every agent shares the same local state.

How do you check what a new thread will know?

1. Identify whether this is the Zed Agent, an External Agent, or a terminal-based assistant. Record which project and worktree you opened.
2. Inspect the instructions intended for that agent. Check which file is selected and whether it contains the current project guidance.
3. Choose a harmless test instruction that is absent from the chat. Start a fresh thread and ask the agent to identify the relevant guidance and its source.
4. Provide the current task and a short handoff. Ask the agent to separate completed checks from remaining work before it edits anything.
5. Correct any mistaken context, start again, and confirm the change took effect. Repeat the test when you switch agent types.

Zed’s Agent Panel documentation↗ (opens in a new tab) distinguishes its own agent from External Agents and Terminal Threads. It also describes independent threads and a New From Summary option for the Zed Agent. Choose a genuinely fresh thread when testing persistent instructions; a summary carries earlier conversation content into the test.

Which instructions does the Zed Agent read?

The current Instructions documentation↗ (opens in a new tab) describes personal and project instructions, with AGENTS.md as the primary format. Compatible project files have a documented selection order, so a leftover file such as .rules can be selected ahead of AGENTS.md. Project instructions take precedence over conflicting personal guidance.

Inspect the selected file before adding another one. If an older instruction says to use a retired test command, fix the source that is actually loaded. Several files with slightly different instructions make it harder to understand why an assistant chose a particular approach.

Keep permanent guidance short and actionable. Name the relevant test command, the architectural boundary a change must preserve, and any action requiring human approval. Leave current bug symptoms and unfinished experiments with the task. Instructions should tell the next session how to work; the handoff should tell it where to begin.

What changes when you choose an External Agent?

Zed’s instruction loader does not govern every assistant running inside the editor. Its documentation says External Agents and Terminal Threads may read their own native instruction files. Check the chosen agent’s behavior and documentation instead of assuming a personal Zed instruction applies to it.

Use the same small test across the agents you actually run. Give each the same task and ask it to name the project constraints before changing a file. Compare whether it read the intended source, respected scope, and preserved open questions. If two agents disagree, resolve the underlying instructions before trusting either one’s proposed edit.

A shared handoff should make sense without editor-specific commands. “The empty export case fails; reproduce it with the named fixture before changing the serializer” is portable. “Continue what we were doing” depends on context the new agent might never receive. See portable AI memory for carrying work between tools.

Does compaction preserve everything important?

Zed’s Agent Settings documentation↗ (opens in a new tab) explains automatic compaction and the manual /compact command. Compaction summarizes earlier messages to keep a long thread usable within the model’s context window, meaning the amount it can consider in a request. It is a conversation-management feature, not proof that every detail will be available in a separate thread.

Before a long investigation becomes hard to follow, write a checkpoint in plain language. Include the actual symptom, the useful attempts, the evidence for the leading explanation, and the next test that would distinguish it from alternatives. Explicitly mark anything that remains a hypothesis.

For a hypothetical import bug, “the parser is broken” is too broad. “The quoted-comma fixture fails before validation; simple rows pass; inspect delimiter handling next” gives the next session an actionable starting point. Read that checkpoint after compaction and correct any summary that changed its meaning.

Which coding discoveries are worth keeping?

Keep discoveries that would cost time to establish again and would change the next action. Good candidates include a nonobvious service boundary, a verified cause of a recurring failure, or an agreed reason for leaving an apparently redundant check in place. Include source locations and the conditions under which the finding holds.

Save lessons as what happened, what you learned, and what to do differently. “Regenerating before updating the schema produced an incomplete client; update the schema first and inspect the generated diff” is useful. “Be more careful” gives the next assistant nothing concrete to recognize or do.

Review those notes when the code changes. The current repository remains the source for implementation details; old findings should guide inspection rather than overrule it. The team AI memory guide explains how shared ownership helps keep this record dependable, while fenbs’s workflow overview shows how lessons sit beside active work.

How to do this with fenbs

1. Create a free account, add the coding project, and create a task for the investigation or change.
2. Write verified findings as AI context notes. Record a person’s decisions and lasting instructions in Decisions and rules, and reusable mistakes in Lessons learned.
3. After working in Zed, update task progress and Where we left off through the web app. Include the exact stopping point and checks that remain.
4. To use the record from another coding app, choose a supported assistant from Integrations, follow its connection guide, and ask it to read project context before starting.

fenbs is free for one person, no credit card. It does not import Zed threads, and it does not replace repository instruction files. If you only need a short, stable set of coding conventions inside one agent, local project instructions may be enough.

What should you verify before handing off?

Ask the receiving assistant for the project goal, the decision it must respect, the checks already completed, and its first next action. Compare its answer with the record. Fix missing evidence or ambiguous wording before allowing a mistaken summary to shape the next change.

For adjacent questions, AI memory explained covers the general concept and AI memory management covers upkeep; the AI memory hub collects more ways to preserve context.