--- title: Agent memory as a file format | daily.dev description: A new open file format called "memoryfield" proposes a simpler alternative to complex agent memory systems built on graph databases, vector stores, and... canonical: https://daily.dev/posts/agent-memory-as-a-file-format-v8fhkzjn3 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Agent memory as a file format | daily.dev og:description: A new open file format called "memoryfield" proposes a simpler alternative to complex agent memory systems built on graph databases, vector stores, and... og:url: https://daily.dev/posts/agent-memory-as-a-file-format-v8fhkzjn3 og:image: https://api.daily.dev/og/posts/V8FhKzJN3.png og:image:alt: Agent memory as a file format og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Agent memory as a file format **[Cal Paterson](https://daily.dev/sources/calpaterson)** · 12 min read · 0 upvotes · 0 comments ## Summary A new open file format called "memoryfield" proposes a simpler alternative to complex agent memory systems built on graph databases, vector stores, and LLM-based extraction pipelines. A memoryfield is just a zip file of Markdown pages with optional YAML frontmatter and a SQLite vector index for semantic search, letting agents write memories directly in prose rather than chunked or graph-linked facts. The design argues against knowledge-graph traversal (Karpathy wikis) as slow and unreliable, favoring one semantic search jump plus parallel reads instead. Tooling includes an RFC-style spec, a CLI tool, and an agent skill, with setup requiring ollama, uv, and npx. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the memoryfield file format for AI agent memory? A memoryfield is a zip file containing Markdown pages with optional YAML frontmatter, plus a SQLite vector index built with the nomic-embed-text-v1.5 embedding model for semantic search. Pages have a soft size limit of about 8kb (roughly 2000 tokens) so they fit into a single vector embedding. Agents write memories directly in prose rather than chunked or extracted facts. _Developers designing agent memory systems can track emerging approaches like this on daily.dev._ ### Why is graph-based agent memory like Karpathy wikis slow and unreliable compared to semantic search? Graph traversal requires the agent to make a serial tool call for every hop, so retrieving information N steps deep needs N+1 tool calls, each taking a few seconds, and it penalizes deeply nested graphs. It is also unreliable because relevance is judged only from link text or titles, causing agents to miss well-written but poorly captioned pages, and forces SEO-style metadata hacking to make pages discoverable. _Teams comparing memory architectures for AI agents can weigh trade-offs like this via daily.dev._ ### Why does the memoryfield spec use nomic-embed-text-v1.5 despite it being an older embedding model? Embedding models move much slower than frontier LLMs, and nomic-embed-text-v1.5 remains a good balance of small size and strong performance at only 270MB, making it fast enough to run on non-GPU hardware. It is a widely popular, frequently recommended default embedding model, though the spec allows substituting other embeddings. _Anyone picking an embedding model for a retrieval project can follow choices like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 187 comments across lobsters, hackernews (as of 2026-09-02). **TL;DR:** Discussion is dominated by a long, technical back-and-forth about whether 'agent memory' is a meaningful new category versus just RAG/grep with extra steps, with many developers sharing their own competing memory setups and skepticism about memory reliability in general. **Sentiment:** 20% positive · 45% mixed · 35% skeptical **The case for** - Markdown plus semantic search is seen as substantially better than plain keyword/grep search for finding related material. - The format is praised as simple, portable, and easy to understand after reading the spec. - Storing created/updated timestamps in frontmatter offers a cheap way to detect and prune stale memories. - Separating declarative facts from active skills is seen as helpful for reducing prompt drift. **The pushback** - Many argue this is functionally indistinguishable from RAG despite the author's framing. - Semantic search is criticized as overly optimistic since outdated, wrong, or superseded memories can still look highly relevant and get surfaced. - Several commenters say auto-managed memory tends to accumulate 'poisoned' or false information over time that's hard to diagnose and clean up. - Some prefer simpler alternatives like well-maintained AGENTS.md files, temp folders, or pointing agents to existing repos instead of a dedicated memory system. - Storing the SQLite vector index doesn't play well with git version control. **By community** - lobsters (mixed): A single comment speculates that manual context management is a temporary, 'barbaric' phase that LLMs will eventually outgrow themselves. - hackernews (heated): Extensive, contentious debate over whether 'agentic memory' is a distinct concept from RAG/retrieval, mixed with many personal anecdotes about memory systems people actually use (or deliberately avoid) and concerns about memory poisoning. **Hottest debate:** Whether 'agentic memory' is a genuinely distinct concept or just RAG/retrieval rebranded. **Open questions** - How should page boundaries be determined when a memory spans multiple topics, and should new info update or create a new page? - How should schema versioning work when memoryfields are shared across different agent harnesses? - Is there a better git-friendly format than SQLite for storing the vector index? - How well does the approach actually perform in practice at scale? **Highlights** > Just retrieving usually doesn't count as memory. "Memory" tends to imply writing too. And I agree: it's not a very special thing. That's why I propose: Markdown + a simple embedding. > — [calpaterson on hackernews](https://news.ycombinator.com/item?id=49509179) > Does anyone else not use memory? I find once there is one poisoned line of text it negatively affects everything else downstream. Instead, I use a temp/ folder with documents and use different files for different agents and models. Then I have to constantly prune and delete the files. Any information that can be extrapolated is just noise which negatively affects the agent. If you have a definition of a database structure and it has been implemented, that information should not be contained in any text document -- it is noise, will drift, and be impossible to debug why the agent keeps producing undesired behavior. I have a ~/Projects folder. For example, I use Playwright with Chrome DevTools Protocol in order to do performance testing and leak detection. There is a script that handles this. My prompt is "Search ~/Projects for perf testing with CDP and Playwright and implement here". Point being, if I need anything I point to a resource or ask to search a resource and it will find it quick and, most importantly, tends to improve it every iteration. If I was in an institution, I would have a repository and would rather just point the resource and say use that than have memory of it locally. > — [dataviz1000 on hackernews · 11 comments](https://news.ycombinator.com/item?id=49509345) > Agent memory is to computer memory is what Mongo DB is to relational database. Incredible to watch things come full circle. Next thing you know, someone is going to figure out a binary encoding. > — [titzer on hackernews · 1 comments](https://news.ycombinator.com/item?id=49508892) > "Irrelevant material is simply never surfaced by the semantic search." thats quite optimistic. there's lots of "memory" or past chats with agents that should be suppressed and forgotten because they were looking in the wrong place or were eventually proven wrong. yet semantically they'd look very relevant to a future search. thats why you shouldn't search both textbooks and scifi when trying to solve an examination. > — [Avijit\_Thawani on hackernews](https://news.ycombinator.com/item?id=49510885) > > Markdown "pages", with > (optional) YAML frontmatter and > (optional) SQLite vector index for semantic search This is basically exactly what I use in a MCP service I built and it works pretty well. Can be enriched further if you use a storage system like S3 and take advantage of metadata. "harness managed" memory is utter garbage, I am convinced, and I disable it immediately. The major problem being over time it degrades and sneaks in conflicting or outright false information. Then one day you'll swear it's drunk, and every time I got to this state and investigated, auto managed memory was always the problem. > — [JohnMakin on hackernews](https://news.ycombinator.com/item?id=49512238) > Instead of having to regenerate a zip file everytime you add/delete a memory... could we just use a git repo of markdown pages? This buys you incremental writes, commit hash pinning and diffs for free. In addition to having a git archive outputting a zip export as well? Main wrinkle is you would need to gitignore the sqlite database as it doesn't store very well in git (binary, changes lots per insert). But it's easy to regenerate anyway as a rebuild-able cache. > — [mofosyne on hackernews · 1 comments](https://news.ycombinator.com/item?id=49517430) **Source threads** - [lobsters](https://lobste.rs/s/nmhtnw/agent_memory_as_file_format) · 1 points · 1 comments - [hackernews](https://news.ycombinator.com/item?id=49508317) · 190 points · 186 comments ## Similar posts on daily.dev - [How we built Agent Builder’s memory system](https://daily.dev/posts/how-we-built-agent-builder-s-memory-system-9xlrrfk2b) · LangChain · 23 upvotes · 0 comments - [memweave: Zero-Infra AI Agent Memory with Markdown and SQLite — No Vector Database Required](https://daily.dev/posts/memweave-zero-infra-ai-agent-memory-with-markdown-and-sqlite-no-vector-database-required-tkigxykuq) · Towards Data Science · 1 upvotes · 0 comments - [I Replaced Vector DBs with Google’s Memory Agent Pattern for my notes in Obsidian](https://daily.dev/posts/i-replaced-vector-dbs-with-google-s-memory-agent-pattern-for-my-notes-in-obsidian-nfi4qzoyp) · Towards Data Science · 0 upvotes · 0 comments --- Tags: [#ai-agents](https://daily.dev/tags/ai-agents), [#rag](https://daily.dev/tags/rag), [#vector-search](https://daily.dev/tags/vector-search), [#sqlite](https://daily.dev/tags/sqlite) [View this post on daily.dev](https://daily.dev/posts/agent-memory-as-a-file-format-v8fhkzjn3) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Agent memory as a file format","url":"https://daily.dev/posts/agent-memory-as-a-file-format-v8fhkzjn3","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/agent-memory-as-a-file-format-v8fhkzjn3"},"datePublished":"2026-08-31T23:45:01.445Z","dateModified":"2026-09-02T00:58:28.831Z","description":"A new open file format called \"memoryfield\" proposes a simpler alternative to complex agent memory systems built on graph databases, vector stores, and...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f97b6da43022fb6b92a8ec1a52ff648a?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f97b6da43022fb6b92a8ec1a52ff648a?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Cal Paterson","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Cal Paterson","logo":"https://media.daily.dev/image/upload/s--9F10mv1a--/f_auto,q_auto/v1774960032/logos/calpaterson?_a=BAMAMiWQ0","url":"https://daily.dev/sources/calpaterson"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/agent-memory-as-a-file-format-v8fhkzjn3","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"ai-agents,rag,vector-search,sqlite","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Cal Paterson","item":"https://daily.dev/sources/calpaterson"},{"@type":"ListItem","position":3,"name":"Agent memory as a file format"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/agent-memory-as-a-file-format-v8fhkzjn3#faq","mainEntity":[{"@type":"Question","name":"What is the memoryfield file format for AI agent memory?","acceptedAnswer":{"@type":"Answer","text":"A memoryfield is a zip file containing Markdown pages with optional YAML frontmatter, plus a SQLite vector index built with the nomic-embed-text-v1.5 embedding model for semantic search. Pages have a soft size limit of about 8kb (roughly 2000 tokens) so they fit into a single vector embedding. Agents write memories directly in prose rather than chunked or extracted facts. Developers designing agent memory systems can track emerging approaches like this on daily.dev."}},{"@type":"Question","name":"Why is graph-based agent memory like Karpathy wikis slow and unreliable compared to semantic search?","acceptedAnswer":{"@type":"Answer","text":"Graph traversal requires the agent to make a serial tool call for every hop, so retrieving information N steps deep needs N+1 tool calls, each taking a few seconds, and it penalizes deeply nested graphs. It is also unreliable because relevance is judged only from link text or titles, causing agents to miss well-written but poorly captioned pages, and forces SEO-style metadata hacking to make pages discoverable. Teams comparing memory architectures for AI agents can weigh trade-offs like this via daily.dev."}},{"@type":"Question","name":"Why does the memoryfield spec use nomic-embed-text-v1.5 despite it being an older embedding model?","acceptedAnswer":{"@type":"Answer","text":"Embedding models move much slower than frontier LLMs, and nomic-embed-text-v1.5 remains a good balance of small size and strong performance at only 270MB, making it fast enough to run on non-GPU hardware. It is a widely popular, frequently recommended default embedding model, though the spec allows substituting other embeddings. Anyone picking an embedding model for a retrieval project can follow choices like this on daily.dev."}}]} ```