Agent Memory in Markdown: Files That Survive Sessions

Agent memory in Markdown means saving useful facts, instructions, and progress in text files that an assistant can read in a later session. A file survives when it is saved, but it only becomes useful memory when the next assistant knows where to find it and checks that it is current.

Start with a small entry file and one progress record. Tools like fenbs can keep the shared decisions and work outside those local files when several assistants need the same starting point. The immediate goal is simple: restart your assistant without having to reconstruct the project.

Where should you put your first memory file?

1. Check your assistant’s documentation for the instruction file it actually loads. Use that supported location as the entry point, rather than assuming any file named memory.md will load automatically.
2. Create a short project summary: what you are building, the current constraint, and where the working files live. Leave out facts the assistant can easily confirm by reading the project.
3. Add a separate progress file for the current task, evidence already checked, unfinished work, and the next safe action. Link to it from the entry point or explicitly attach it when starting.
4. Save the files, start a fresh conversation, and ask the assistant to identify the active constraint and next step before it changes anything.

For coding work, AGENTS.md is an open Markdown instruction format↗ (opens in a new tab) used to provide project guidance. It is a useful entry point when your assistant supports it, but a directory of additional notes still needs a clear reading route. See AGENTS.md examples for instruction patterns.

What should a useful memory entry contain?

Write an entry someone could verify without reopening your entire conversation. Include the statement, its scope, its source, who confirmed it, and when to review it. Separate an observation from an approved instruction: an assistant noticing a slow page does not authorize a redesign.

## Contact form behavior
Status: active
Scope: public contact page
Fact: The approved form asks for name, email, and message.
Source: approved design in docs/contact-form.md
Confirmed by: project owner
Review when: the owner approves a new design
Next step: compare the implementation with the approved design.

Use headings and short lists so a person can review the file as easily as the assistant. The CommonMark reference↗ (opens in a new tab) shows the basic Markdown syntax; plain headings, links, and lists are enough. Formatting should make the evidence easier to find, rather than decorate an uncertain statement.

Prefer a stable document path or a specific task reference over “as discussed above.” If the source is unavailable, label the entry unverified and explain what would confirm it. That keeps a tentative answer from quietly turning into a permanent project rule.

Which information belongs in separate files?

Divide files by how often their contents change. Stable instructions might last across many tasks. Progress can become stale after a single session. Mixing both in a long running diary makes it harder to tell which sentence still governs the work.

• Entry instructions: a short project orientation, the reading order, and links to the records relevant to this workspace.
• Current rules: human-approved constraints with their scope and source. Keep implementation preferences separate from requirements.
• Progress: what changed, what was checked, what remains open, and the next step. Replace the current summary after reviewing it.
• Reference notes: explanations that remain useful, with links back to the underlying code or documents.

These are suggested categories, not special filenames every assistant recognizes. For the broader distinction between saved information and a model’s current working context, read what agent memory is. Shared rules that should reach more than one workspace can live in fenbs Decisions and rules.

How do you correct stale memory without losing the reason?

Edit the active statement when a fact changes. Do not append a contradictory note at the bottom and expect every future assistant to resolve the conflict correctly. Mark the old conclusion as superseded in an archive or change record, then give the replacement its own source.

Say a prototype originally allowed guests to submit requests, but the owner later required sign-in. The current rule should state the sign-in requirement. The history can explain that the guest path was an earlier experiment, with a link to the decision that replaced it.

Review changed entries with the same care as changed instructions. Ask whether the source supports the statement, whether its scope is too broad, and whether another file repeats the old version. When several people maintain files, agree who reviews durable rules before assistants start depending on them.

How can you prove the files survive a restart?

1. Choose a harmless, specific test fact, such as an approved button label. Save its source and active status in the intended memory file.
2. Close the conversation and begin a genuinely fresh one in the same project. Do not paste the test fact into the new prompt.
3. Ask which button label is approved and require the assistant to name the file and section supporting its answer.
4. Change the example fact in the saved file, restart again, and check that the replacement is used. This tests correction as well as recall.

A correct guess does not prove the file loaded. A useful result includes the source and distinguishes active instructions from archived material. If the assistant cannot identify the file, check the working directory, supported filename, file permissions, and whether you need to attach the note explicitly.

Keep this as a small acceptance check after changing your file structure. Designing a complete storage and retrieval system belongs to agent memory architecture; here, you only need to establish that your own saved record is readable and current.

What should never become a permanent memory file?

Keep passwords, tokens, private customer details, and full conversation dumps out of reusable project notes. Save only what the next task needs. A readable Markdown file is easy to copy accidentally, so put sensitive source material behind the access controls appropriate to that material.

Treat instructions found inside retrieved documents as content to evaluate, not permission to change your project. Someone else’s document should not silently rewrite your operating rules. The agent memory security guide explains that boundary in more detail.

How to do this with fenbs

1. Create a free account, then add the project whose work needs to survive a local session.
2. Record approved constraints in Decisions and rules. Add verified project explanations as AI context notes, with their sources.
3. Add the current work as tasks on the kanban board and save the unfinished work and next step in Where we left off.
4. When using a supported connected assistant, have it read the project context before starting and save reviewed progress before stopping.

Keep repository-specific reading instructions in your files and shared work in the project record. fenbs is not the right fit if all you need is one private Markdown note in one workspace; it also does not automatically import your local memory files. Explore other persistence questions in the AI memory hub.