I Got Tired of Pasting Context Into Agents, So I Built MFS

Most of my failed agent runs do not fail because the model cannot reason. They
fail because I pasted the wrong context, missed the important thread, or forgot
which repo/doc/ticket had the real answer.

That is the part that started to bother me. Modern agents are getting very good
at reasoning, coding, and using tools, but in my day-to-day work the annoying
part is often much more basic: the agent still cannot reach the context it
needs.

A bug report might start in Slack or Feishu. The decision might be buried in a
Jira ticket. The reproduction data might live in Postgres. The fix is somewhere
in a repo. A useful note might sit in an old memory file or a skill I tuned a
month ago.

The agent is right there, ready to help. But I still end up doing the awkward
middle work: open five systems, search manually, copy snippets, paste them into
the chat window, and hope I included the right pieces.

That is the problem I wanted MFS to attack.

MFS stands for Multi-source File-like Search. It is an open-source context
harness for agents: a single searchable and browsable workspace over code,
memory, skills, docs, chat, tickets, databases, object stores, and other working
context.

Project: github.com/zilliztech/mfs

Make Every Source Look Like a Tree

Agents already know how to use shell-like tools. They can list files, inspect
paths, grep for strings, and read specific ranges. So instead of inventing a new
interface for every source, MFS turns each source into a file-like tree under a
stable URI.

A Postgres database can be browsed like a tree. A table exposes rows that can be
searched and reopened. A Slack channel becomes a tree of channels and threads.
A GitHub repo, an issue tracker, a PDF folder, an S3 bucket, or a Notion space
all become objects under paths the agent can inspect.

The same small command set works everywhere:

mfs tree github://acme/backend -L 1
# src/
# tests/
# README.md

mfs ls postgres://prod/public
# tickets/
# users/

mfs cat jira://acme/PLAT/issues.jsonl --locator '{"id":"PLAT-491"}'
# reopen the exact issue record

The point is not to replace the shell. If I know the exact file and exact string,
rg, grep, and cat are still the fastest tools in the room.

MFS earns its keep when the hard part is finding: the wording in my head does
not match the wording in the source, the answer could be in several systems, and
I need the agent to locate evidence instead of asking me to paste it in.

Search Gives Candidates. Browse Gives Evidence.

The most important design choice in MFS is pairing two moves that often get
treated separately:

1. Search to quickly find candidates across a large indexed corpus.
2. Browse to reopen the exact source and verify the evidence.

That sounds simple, but it matters a lot for agent reliability.

A search result is a hint. It is not yet proof. A ranked snippet can point the
agent to the right file, row, thread, or document, but the agent should reopen
the source before it quotes, edits, summarizes, or makes a decision.

This is how humans search too. Google narrows the world down to candidates. Then
you click a result and read the actual page. A library catalog gets you to the
right shelf. Then you open the book and check the page.

MFS gives agents the same loop:

mfs search "where do we retry failed webhook deliveries?" ./repo --json
mfs cat file://local/repos/payments/webhooks/deliver.go --range 80:110

Search narrows the field. Browse verifies the evidence.

Two Skills: One for Ingest, One for Find

MFS ships with two agent-facing skills:

Skill	What it handles
mfs-ingest	Register a source, configure connectors, sync, index, and troubleshoot ingestion.
mfs-find	Search, grep, list, browse, and reopen exact evidence from sources already in MFS.

The split is deliberate. Ingest can change state and trigger indexing work.
Find is read-only retrieval and browsing. Agents behave better when those
boundaries are explicit.

Installation is one command:

npx skills add zilliztech/mfs --all -g

After that, I can ask the agent in plain language:

Use mfs-ingest to index this repo, then use mfs-find to find where webhook
retry logic is implemented.

The agent does not need me to remember every command. It follows the skill,
runs the right mfs commands, and reopens the evidence before answering.

What Can It Connect To?

The current connector set covers the sources that tend to make up real working
context:

• Local files: code, Markdown, PDFs, docs, screenshots
• Object stores: S3, R2, GCS, MinIO
• Cloud drives and docs: Google Drive, Notion, web pages
• Databases and warehouses: Postgres, MySQL, MongoDB, BigQuery, Snowflake
• Code and work tracking: GitHub, Jira, Linear
• Support and CRM: Zendesk, HubSpot
• Chat and mail: Slack, Discord, Gmail, Feishu/Lark

These sources do not look alike at all. A PDF, a database row, a Slack thread,
and a GitHub file have different shapes, sync rules, credentials, and failure
modes. MFS hides as much of that repetitive work as possible behind one model:
objects, paths, metadata, chunks, search hits, and locators.

That means a search across all registered sources can return results in the same
format:

mfs search "what do we already have about hybrid retrieval?" --all

Example shape:

postgres://prod/public/engineering_tickets/rows.jsonl   score=0.88
  #482 hybrid retrieval flaky on long queries ...

notion://workspace/design/retrieval-rfc.md              score=0.85
  Hybrid search: combine dense + sparse ...

web://milvus-tutorials/hybrid-search                    score=0.81
  Hybrid search runs an ANN search and a BM25 search ...

file://local/repo/src/milvus.py                         score=0.76
  def hybrid_search(self, query: str, top_k: int = 10):

The agent can then reopen each hit through cat, line ranges, or structured
locators instead of relying on snippets.

A Small Evaluation Signal

I do not want to oversell the numbers. They are not a universal guarantee. They
come from specific agents, corpora, prompts, and timeouts.

But they are still useful evidence for the search-plus-browse loop.

In one code-search run over 2,000 Python files from CodeSearchNet, the agent had
to identify target source files from natural-language tasks. The shell-only
baseline found 22 of 24 targets, using 962 average tokens. With MFS search plus
browse, it found 23 of 24 and used 460 average tokens.

The hard subset was clearer. For paraphrased queries with weak literal anchors,
shell tools found 7 of 8 targets with 1,734 average tokens. MFS search plus
browse found 8 of 8 with 692 average tokens.

The interesting part is not just better retrieval. It is that the agent can
spend fewer tokens wandering around because search gives it a good candidate set
and browse lets it verify narrowly.

Local First, But Not Local Only

MFS is a client/server system.

For a local demo, it can run with Milvus Lite for vectors, SQLite for metadata,
local cache, and an ONNX embedding model. That path does not require an API key,
a GPU, or a cloud account after setup.

For production, the same architecture can move to a server deployment: Zilliz
Cloud or Milvus for vector search, Postgres for metadata, object storage for
artifacts, and Docker Compose or Kubernetes for deployment.

The important boundary is where state and credentials live. The CLI and skills
are clients. The server owns connector config, credentials, indexing jobs,
metadata, cache, and search backends. Connector TOML files reference secrets
like env:SLACK_BOT_TOKEN or file:/path/to/key; they do not store raw secret
values.

That matters if you want agents to use real company context without handing
every secret to the client process.

Building on Top of It

MFS can be used directly as a daily search tool, but the larger goal is to make
it a foundation for agent applications.

If you are building an agent, plugin, MCP server, or skill system, you should not
have to rebuild connector sync, document conversion, chunking, embeddings,
vector indexing, metadata bookkeeping, caching, and evidence reopening every
time.

MFS tries to make that lower layer reusable.

The upper layer can focus on the product experience: what the agent should do
with the context once it has found it.

Final Thought

The next jump in agents will not come only from bigger models or longer context
windows. It will also come from better contact with the working environment:
repos, docs, chat, tickets, databases, memory, skills, and all the messy history
that surrounds real work.

MFS is my attempt at that context layer: search broadly, browse precisely, and
let the agent reopen the original evidence before it acts.

Links:

• GitHub: github.com/zilliztech/mfs
• Docs: zilliztech.github.io/mfs
• Discord: discord.com/invite/FG6hMJStWu