Most agent memory systems are overbuilt before they are useful. You get a database, a separate extraction model, a graph layer, a ranking service, and a collection of APIs that your agent has to learn before it can remember one useful fact.

There is a simpler idea: store memories as Markdown pages, then add search as a replaceable index. Cal Paterson calls this a memoryfield. The format is fresh, the implementation is small, and the interesting part is not the branding. It is the decision to treat memory as data that an agent can read and edit, rather than as a background pipeline that owns the agent's history.

Obsidian graph view that shows why visual links are not the same as useful retrieval

That distinction matters if you run agents across different models or harnesses. A folder of Markdown files can move with you. A proprietary memory service usually cannot.

Build a memoryfield in ten minutes

The smallest useful memoryfield is a directory of Markdown files. Each page can contain YAML frontmatter, a short summary, and ordinary prose. A page about a production incident should explain what happened, what fixed it, and where the evidence came from. Do not reduce it to a bag of detached facts. Future retrieval needs the surrounding explanation.

The format's suggested soft ceiling is about 8 KB per page, roughly 2,000 tokens. That is a limit worth keeping. A memory page should describe one subject clearly. If it needs a 40-page essay, split it into several pages with useful titles rather than letting one giant document become a retrieval black hole.

The author's current starter recipe uses three commands:

# Pull the local embedding model
ollama pull nomic-embed-text

# Install the command-line tool
uv tool install memoryfield-tool

# Install the agent skill
npx skills add calpaterson/memoryfield-skill -g -y

The tool can create a field, write pages, list them, validate the format, build an index, search, and export the whole collection as a .memoryfield.zip file. Its README says the tool needs Python 3.12 or newer. That detail is easy to miss if your machine still ships Python 3.11, so check python -V before you blame the memory format for an install failure.

Start with a local field and one page:

memoryfield-tool create work-notes
memoryfield-tool new "Deploying the staging worker" --field work-notes
printf '%s
' 'The staging worker needs the queue service running first. Check the deploy log at https://example.com/run/123.' | memoryfield-tool write --field work-notes deploying-the-staging-worker
memoryfield-tool validate --field work-notes
memoryfield-tool index --field work-notes
memoryfield-tool search --field work-notes "why did the staging worker fail?"

The command names above come from the tool's documented CLI. The practical sequence is the important bit: create a field, write a readable page, validate it, then build the optional search index. You can still read and edit the files when Ollama is off. Without the embedding model, the tool falls back to substring search, according to its README.

That fallback changes the shape of the risk. The vector index is a cache. The Markdown files are the actual memory. If the index becomes stale or you replace the embedding model, rebuild it. Your stored knowledge does not disappear.

This is also where the existing case for starting RAG projects with SQLite instead of vectors is useful context. A memoryfield goes one step further in the data-first direction. SQLite can hold the index, but it does not become the product's source of truth.

A good first field needs fewer pages than you expect. Add the agent's recurring constraints, the decisions it must not repeat, and links to primary evidence. A page titled client-api-timeouts.md is more useful than five isolated lines saying "timeout," "retry," and "backoff." The agent can search the prose and read the whole page once it finds it.

What breaks in practice

The first failure is memory pollution. If every conversational detail becomes a page, the collection turns into a junk drawer. The format makes this less damaging because irrelevant pages should not appear in semantic search, but storage is still finite and stale advice can still be retrieved. Put dates and source URLs in frontmatter or the body. Review old pages. Delete memories that describe a system you no longer run.

The second failure is security. A memory file is part of the agent's context, so a poisoned memory is effectively a persistent prompt injection. The original proposal is blunt about this: do not share a context window, including memories, with people or services you do not trust. If someone sends you a memoryfield archive, inspect it before connecting it to an agent. For a static archive, pinning the files with sha256sum gives you a cheap way to detect changes later. It does not tell you whether the content is safe, but it tells you whether the content changed.

The third failure is transport. Local files are easy, but people eventually want to sync them or serve them. The format is designed to work from a local directory, a zip archive, an S3-compatible store, GitHub, or HTTP. That portability is useful, but a remote writable field deserves the same access controls as any other data store. The tool's own HTTP server refuses writable non-loopback hosts, which is a sensible default. Do not remove that guard just to make a demo reachable from the internet.

The fourth failure is operational rather than technical. The current setup pulls in Ollama, uv, npx, and the skill installer. That is four package managers or runtimes in one recipe. It works, but it is not elegant. If you are building a team product, freeze the environment in a container or package the setup as one reproducible command. If you are giving one agent a durable notebook, the documented commands are probably enough.

There is a real tradeoff against graph-based memory. A graph is attractive because relationships are visible. In an agent, walking those relationships can require serial reads and can drag irrelevant pages into the context. The memoryfield approach searches the page content and reads matching pages in parallel. The proposal describes a best case of 2 tool calls, one search and one parallel read, rather than one call for every hop through a graph. That is a claim about the design, not a universal latency benchmark, but it points at the right cost: every extra retrieval decision is another chance for the model to get lost.

The embedding model is not the exciting part. The Ollama listing describes nomic-embed-text-v1.5 as a 270 MB model, small enough for ordinary non-GPU hardware. That makes it a practical default, not a permanent dependency. The spec leaves room to swap the embedding function later. Keep that freedom. A memory format that cannot survive an embedding-model change is quietly another vendor lock-in mechanism.

So should you use this instead of a full memory platform? Use it when you want files you can inspect, copy, back up, and hand to another harness. Do not use it as an excuse to skip access control, freshness checks, or review. The mechanism is smaller. The responsibility is still yours.

The useful experiment is cheap: create one field, write five pages from real recurring tasks, and ask your agent to search them for a week. If the pages help, keep growing the collection. If they do not, you can delete the directory without migrating a graph database or untangling a hosted memory API.

Sources