What is SMFS (Supermemory Filesystem)?

SMFS is an agentic filesystem powered by FUSE that loads instantly. It features a /profile.md auto-generated and updated based on content in the filesystem, supports multi-modal data (images, etc.) that can be grepped through as SMFS runs OCR and stores them as text files, and replaces Grep and some other commands to give the agent an option to do semantic search as well.

What is xAFS and why was it created?

xAFS is a benchmark created by Supermemory to measure and test the quality of SMFS. There was no benchmark for agentic search specifically on the internet, so they created one. It includes both conversational and document data, gradually increasing number of files, non-needle-in-haystack questions that test for multi-hop, temporal and other types of queries, each file being more than 10k tokens, and testing up to 10k files.

How does SMFS use grep for semantic search instead of exact-match retrieval?

In SMFS, grep is replaced with a semantic-aware version that lets an agent query by meaning rather than by literal string match. This means an agent running a standard grep command gets back semantically relevant results — not just files containing the exact characters — without changing the command it already knows how to issue.

What is a FUSE-based agentic filesystem and why does it matter for agent memory?

FUSE (Filesystem in Userspace) lets SMFS mount as a real filesystem that any process — including a coding agent — can interact with using native OS commands like ls, cat, and grep. Agents access memory the same way they access any other file, so no new tooling or special API calls are required; the filesystem itself becomes the memory interface.

Agentic search vs. RAG for agent memory — which one should I use?

Neither alone is the right answer. Agentic search gives structural control but can't locate content by meaning at scale; RAG retrieves by meaning but severs chunks from the surrounding context an agent needs for multi-hop reasoning. SMFS combines both — semantic search surfaces a trusted starting path, and the agent then navigates the surrounding file structure agentically from there.

How does SMFS handle multi-modal files like images inside the filesystem?

SMFS runs OCR on image files and stores the extracted text alongside the original, so an agent can grep through visual content the same way it would a plain text file. This means images, scanned documents, and other non-text assets become part of the searchable, navigable memory without requiring the agent to call a separate extraction service.

Why does token cost per question grow so much faster with a standard filesystem agent as corpus size increases?

A standard filesystem agent explores blindly — it lists directories, reads partial files, and re-searches for context that earlier reads discarded, inflating the context window with each traversal step. The xAFS benchmark shows this produces roughly 7× token growth over the tested corpus range; SMFS holds to roughly 4× by anchoring the agent to a semantically trusted starting point, which cuts redundant reads.

What does the auto-generated profile.md file in SMFS actually contain?

profile.md is a live synthesis of the user or project context that SMFS generates and updates automatically from the content in the filesystem. An agent can cat profile.md to get a coherent, current summary of preferences, facts, and context without traversing dozens of individual files — it acts as a pre-built working brief that reduces cold-start exploration on every new session.

Can I reproduce the SMFS benchmark results myself, or are they only verifiable internally?

All evaluation runs are publicly available at smfs.ai/research/runs, where each individual run can be inspected. The xAFS dataset is also published on Hugging Face at huggingface.co/datasets/supermemory/xAFS, so any team can re-run the benchmark against their own agent harness and compare results directly.

How does SMFS perform at very large corpus sizes — does accuracy hold above 1,000 files?

At 9,988 files, SMFS holds an 81% pass rate while the standard filesystem agent drops to 69% — a 12-percentage-point gap that widens as corpus size grows. The standard agent's accuracy collapses at scale because blind traversal degrades reasoning; SMFS preserves accuracy by anchoring retrieval to semantically relevant starting points before the agent explores.

What makes xAFS different from existing RAG or memory benchmarks?

xAFS was built specifically for agentic retrieval — there was no existing benchmark for this task. It tests with gradually increasing file counts up to 10,000 files, uses multi-hop, temporal, and non-needle-in-haystack question types, requires each file to exceed 10K tokens, and constructs a single coherent story across all files so facts are genuinely interconnected rather than isolated. Standard RAG and memory benchmarks don't model this kind of agent traversal workload.

How does SMFS fit into Supermemory's broader set of context-infrastructure primitives?

SMFS is the Filesystems primitive in Supermemory's seven-building-block stack — a POSIX-compatible filesystem mount that gives an agent a persistent, searchable memory layer it operates through native commands. It composes with the other primitives: Connectors keep external sources in sync, Extractors index multi-modal content into the filesystem, and Profiles surface synthesized context via profile.md, so the full stack works together without requiring a separate orchestration layer.

SMFS: 55% Cheaper, More Accurate Agent Retrieval

We launched SMFS.ai (Supermemory Filesystem) a few weeks ago, with a simple bet: We can redesign the filesystem specifically for agents, with special files, structures, and commands that it can use for it's tasks. Today, SMFS is used by hundreds of companies to power their agents.

TL;DR
You can read the report here - smfs.ai/research/memory-as-a-filesystem

If you missed that launch, here's a quick summary of SMFS:

Agentic Filesystem powered by FUSE that loads instantly.
/profile.md auto-generated and updated based on content in the filesystem.
Multi-modal data (images, etc) can be grepped through, as SMFS runs OCR stores them as text files
Grep and some other commands are replaced to give the agent an option to do semantic search as well.

All of that, built into a true filesystem - that the agent can use and navigate.

It was time for us to run some benchmarks!

In this blog, I'll go over some of the intuition and introduce the things we did to fix them.

The problems

Two halves, each broken on its own.

Agentic search is what every coding agent already does: list a directory, cat a few files, grep for a string, reason, repeat. It's powerful because the agent stays in control. It's kinda like having a stack of books in front of you - without a title. In order to find a specific thing, you'll have to open the books, remember which had what, and then skim through each page to get something, holding all that traversal in your "context window"

Semantic retrieval, RAG-style, SHOULD fix exactly that. One query pulls content by meaning, surfacing passages no grep could locate. But it hands back a top-K list of chunks ripped out of context: excerpts with no neighbors, no surrounding file, no thread to pull. The agent gets an answer fragment and nowhere to stand. Multi-hop reasoning suffers worst, because the next question depends on context the chunk threw away.

Our users were always stuck choosing. Agentic search gives structure and control but can't find things at scale. File search finds things but severs them from the structure the agent needs to reason. Pick one and you've picked your failure mode.

The whole point is: you shouldn't have to pick.

Per-question token cost across 5 to 9,988 files (log scale). fs-only grows ~7× over the range; SMFS grows ~4×. The 299-file corpus is a notable outlier where fs-only thrashes. n = 220 (fs) + 220 (smfs) trials · smfs.ai/research/runs

The bottleneck of agent memory was never the speed of a single retrieval. It's the number of retrievals an agent issues before it has enough context to answer - every one of them inflating the context window with paths, partial reads, and overlapping chunks until reasoning degrades.

Agentic search inflates that count by exploring blindly. File search inflates it by making the agent re-search for the context each chunk is missing.

Combine them and the count collapses. Semantic search lands on a path. The agent reads the surrounding file, follows the thread, greps the subtree, agentically, from a starting point it actually trusts. You get the reach of file search and the control of agentic search in the same motion. That's the bet. That's the north star.

Introducing xAFS

To measure and test the quality of SMFS, we needed a realistic benchmark with:

Both conversational and document data (Memory + Filesystem)
Gradually increasing number of files (So we can determine the curve of change)
Non-Needle-in-haystack questions that test for multi-hop, temporal and other types of queries
Each file being more than 10k tokens
Testing upto 10k Files, all of them being one coherent "Story" with coherent facts

There was no benchmark for agentic search specifically on the internet - so, we created one.

This benchmark is specifically made for agentic retrieval, and extendable for any use cases! We invite people to come and try it out huggingface.co/datasets/supermemory/xAFS

How SMFS performed

SMFS results were truly staggering. At 10,000 files, the standard filesystem agent's accuracy collapses to 69%. Ours holds at 81%.

Total bill across the whole eval: $2,103 vs $946. 55% cheaper.

On one corpus the baseline thrashed to $20.95 per question. Ours answered the same question for $4.71.

53.8% fewer tokens. 53.1% fewer tokens per _correct_ answer.

Claude's harness used −66% tokens, and −60% tool calls — and it got more accurate.All the evaluation runs are publicly available at smfs.ai/research/runs, where each run can be inspected. Here's a run where smfs used 50% less tokens, latency and cost:

Side-by-side eval comparing Filesystem (218k tokens, $2.67) versus SMFS (182k tokens, $1.28) on the same agent task

Work doesn't end here

We have published a detailed report about SMFS - How it has a sync engine, Profiles, using Grep as retrieval, and all the other thought we put in, in a technical report here - smfs.ai/research/memory-as-a-filesystem

Title page of the "SMFS: Memory as a Filesystem" technical report by Supermemory Research

SMFS: making agentic retrieval 55% cheaper AND more accurate

The problems

Per-question token cost vs. corpus size

Introducing xAFS

How SMFS performed

Work doesn't end here

Other posts.