Build agent memory from a folder of docs in minutes

There is a moment on every new agent project where you want to try better retrieval on real data before you ask anyone for budget or commit to a pipeline. The blocker is usually cost and time. Embedding everything is cheap but flat, so multi-step questions suffer. Building a knowledge graph is better for those questions but the indexing pass runs your whole corpus through an LLM, which means an overnight job and a bill before you have learned anything.

That trade-off is why a lot of good ideas never get tested on the actual documents. FastMemory is built to remove it: point it at a file or a folder, get a usable memory in minutes, and pay no per-document model tax to build it.

The cost comes from indexing, not querying

It is easy to blame retrieval quality on the model or the chunk size. But the expensive, slow part of the graph approaches is the build: extracting entities and relationships with an LLM, one pass over every document, every time the documents change. On a mid-size corpus that is real money per rebuild and a wait every time content shifts. For a team still deciding whether the approach is worth it, that is exactly the wrong place to spend money.

FastMemory builds its map by reading structure you provide, not by inferring it with a model. There is no LLM call at ingest. The build is deterministic and it runs on a laptop. That is what makes "try it on real data this afternoon" possible.

What you give it: ATF Markdown

The input is a plain format called ATF Markdown. Each thing in your domain is a section with the same handful of headers, which become the six layers of the map — what it's made of, how it's organized, what it does, what data it uses, who is allowed, and what happens when:

## [ID: auth_module]
**Action:** Authenticate a user and issue a session
**Data_Connections:** users_table, sessions_table
**Access:** public, service_account
**Events:** login_succeeded, login_failed

Writing that first file is the real work, and it is the honest risk in the workflow: the tool is fast, but describing a slice of your domain well takes a little thought. Start small. One file for one corner you know cold is enough to judge the result.

Folder to answer, start to finish

cargo install fastmemory
fastmemory build data/input.md
fastmemory query data/input.md "<a question you already know the answer to>"

Building from a whole folder instead of one file:

fastmemory build --data ./docs

Want to see what got indexed before you trust it? Serve it and browse:

fastmemory serve data/input.md --port 16743

And to hand the map to an IDE agent over MCP:

fastmemory mcp data/input.md

One thing that trips people up: pip install fastmemory installs the Python module, which exposes fastmemory.process_markdown(markdown_text) for use inside your own code. It does not install the command-line binary. For the fastmemory build/query/serve/mcp commands above, install with cargo install fastmemory.

The one number worth quoting

Most performance figures you should test yourself. One published, reproducible result is worth stating because it speaks directly to whether this fits on your machine: FastMemory stored 445,289 records in about 129 MiB, roughly a 35x compression versus the multi-gigabyte footprint the same data takes elsewhere. A compact map is part of why the build and the queries stay cheap. Everything else — retrieval quality, fit to your domain — you should confirm on your own data, which is the entire point of a build that costs nothing to run.

Where to start

• Copy the worked example from GitHub and run it unchanged first.
• Read how the map is structured on the FastMemory architecture page.
• Then write one ATF Markdown file for your own data and run build and query.

If the only reason you have not tried structured agent memory is the cost of building it, that reason is gone. It is open source, MIT licensed, and the build runs on your laptop with no model bill.