Agent Memory in VS Code: Files, Tools, and Shared Context

To set up agent memory in VS Code, separate project instructions from the notes an assistant saves and the shared progress other sessions need. Choose the assistant you are using, confirm which files and tools it reads, and test the result in a fresh conversation rather than relying on the current chat.

The editor is the meeting place, but it does not make every assistant share one memory. Tools such as fenbs keep the project’s work record outside an individual assistant, so a switch can preserve decisions and next steps. Begin with one project and information you can verify.

How do you set up a useful starting point?

1. Identify the selected assistant and read its instruction-file rules. Check the active workspace before creating anything.
2. Write a short reviewed instruction file containing the project goal, commands, and conventions that future sessions should follow.
3. Ask the assistant to retain one harmless working fact using its supported memory feature, then inspect where it saved the note.
4. Save the current task status and next step in the shared project record. Open a fresh conversation and check all three kinds of information.

Use a fictional fact for the first test, such as “The sample export is called Birch.” Ask where the assistant stored it and whether it applies to this project or every project. If it cannot explain the scope, do not start by storing client details or important operational rules.

An assistant can answer correctly because the detail remains in the current conversation. That does not establish persistence. The guide to agent memory versus context explains why a fresh session is part of the setup, rather than an optional final check.

Which information belongs in files, memory, or shared work?

Use reviewed project instructions for guidance contributors depend on. Use local memory for emerging observations and personal preferences you are still checking. Use a shared work record for the agreements, current tasks, and handoffs that should remain available when a colleague or another assistant takes over.

Avoid keeping several supposedly current copies of the same decision. For example, put the reviewed rule about preserving an API response format in its agreed home, then reference it from the task. A local note can remind you where that rule lives without becoming another version of the rule.

How do you choose and verify an instruction file?

VS Code’s custom instructions documentation↗ (opens in a new tab) says support depends on the assistant selected for the session. Its formats include project instructions such as AGENTS.md and .github/copilot-instructions.md, with support varying by assistant. Do not assume a familiar filename works everywhere just because it is visible in the editor.

Start with guidance someone cannot safely infer from the code: the command that runs the relevant checks, a reason for preserving unusual behavior, and where the authoritative decision lives. Keep it concise. A long account of old tasks makes the current instructions harder to review and easier to contradict.

Then ask the assistant to summarize the applicable instructions before making a small change. Confirm both the file it names and the behavior it proposes. If a frontend rule applies only to frontend files, test a backend task too. You are checking the boundary as well as the happy path.

VS Code also supports prompt files↗ (opens in a new tab) for reusable requests, including references to files. Use one for a repeatable review request rather than treating it as automatically loaded project memory. Keep the request stable and supply the current task details when you run it.

What should you check in assistant-specific memory?

VS Code’s memory documentation↗ (opens in a new tab) distinguishes user, repository, and session memory in its memory tool. User and repository notes persist across conversations; session notes last for the current conversation. These scopes are stored locally, and repository memory is not a shared project file. Inspect notes with the documented Chat: Show Memory Files command.

Treat those details as the behavior of the documented feature, not a promise covering every extension installed in VS Code. An extension may use another storage location or its own service. Check its vendor documentation before assuming that changing the model, profile, computer, or workspace leaves the record available.

• Test a new conversation in the same workspace, then a different workspace to check scope.
• Correct the fictional Birch fact and confirm that the old version stops influencing answers.
• Inspect and remove the test note, then check that the assistant can explain what is unknown.
• Ask about a fact you never supplied. A clear unknown is more useful than a confident guess.

For the product-specific workflow, use Copilot memory in VS Code. For the wider concept, read what agent memory is. Keep this initial setup focused on where each kind of information belongs.

How do you preserve context when you change assistants?

Before switching, save what changed, the checks that ran, the checks still missing, and the next action. Include the project and task references. “The export change is ready for review; the empty-file case is untested” gives the next assistant something concrete to continue without turning uncertainty into completion.

Ask the next assistant to read that record and explain its starting point. Then compare its answer with the saved state. A successful handoff preserves the approved direction and the remaining work; it does not require copying the full conversation or reproducing every private note.

Use how fenbs works to establish that read, work, and save routine. Review connection access alongside your agent memory security checks, especially when a workspace contains material for several clients.

How to do this with fenbs

1. Create a free account, then add the project and its current tasks on your kanban board.
2. Record decisions people have approved in Decisions and rules. Add a short progress record that distinguishes finished work from remaining checks.
3. Connect the supported AI app you use through Integrations, following its browser sign-in guide.
4. Ask it to read the project context before working and save progress before stopping. Repeat with the next connected assistant and verify its proposed next step.

fenbs does not synchronize VS Code memory files or make an unsupported extension read your project automatically. If one local assistant and reviewed repository files already meet your needs, keep that setup. Add a shared record when the recurring problem is work crossing sessions, people, or AI apps.

The memory tools hub covers other approaches. For this setup, success is simple: you can point to the guidance, inspect the saved note, and give the next session an accurate place to start.