Every time we build a new AI agent, we seem to follow the same playbook.
Set up a vector database. Build a document ingestion pipeline. Chunk the documents. Generate embeddings. Configure retrieval. Add reranking. Figure out how to keep everything synchronized.
Then build another agent.
And suddenly, we’re solving the same knowledge problem again.
But here’s something I’ve been thinking about:
Why are we building complicated retrieval infrastructure when AI agents can already read, search, and navigate files?
An agent that can execute code can explore a filesystem. It can run grep, use ripgrep, read Markdown, follow references, inspect directories, and traverse structured indexes.
We don’t necessarily need to convert every piece of knowledge into vectors before an agent can use it.
What we need is a reliable way to give hundreds or thousands of independent agents access to the same authoritative knowledge, without allowing those agents to corrupt it.
I believe the answer is surprisingly simple:
Git-driven knowledge repositories, distributed as shared read-only filesystem volumes, and mounted directly inside isolated AI agent runtimes.
- Not a separate knowledge database for every agent.
- Not an API call for every knowledge lookup.
- One version-controlled knowledge source, exposed as a filesystem to as many independent agents as necessary.
1. Git Should Be the Control Plane for AI Knowledge
Let’s start with Git.
We’ve spent decades building reliable software development workflows around it.
Git already gives us versioning, branching, collaboration, history, rollback, reviews, and a clear source of truth.
Why shouldn’t organizational knowledge follow the same model?
The LLM Wiki repository
Imagine a repository called LLM Wiki.
Instead of application code, it contains the information that agents need to operate:
- Architecture documents
- Engineering standards
- API contracts
- Runbooks
- Operational procedures
- Policies
- Agent instructions
- Examples
- Indexed relationships between systems
Everything is human-readable. Everything is version-controlled.
Every meaningful change has a history.
And every approved improvement can eventually become available to the entire agent fleet.
Control plane vs. runtime knowledge layer
But Git is only one part of the architecture.
Git manages how knowledge evolves. The filesystem mount determines how agents consume it.
That’s the distinction that makes this design interesting.
Agents shouldn’t need Git credentials or permission to modify the knowledge repository just to read its contents.
They should receive a published, immutable knowledge snapshot generated from an approved Git revision.
The repository is the control plane. The published filesystem is the runtime knowledge layer.
2. The Shared Volume Mount Changes Everything
Now imagine five independent AI agents running inside lightweight isolated execution environments.
Each agent has its own session, temporary workspace, runtime, and resource limits.
For example, a lightweight agent might operate within a resource budget of approximately 512 MB RAM and half a CPU core’s worth of scheduled compute, with model inference performed externally.
Instead of embedding a knowledge database inside each agent, we mount the same logical knowledge volume into every runtime.
The interface is simply:
/wiki — shared, read-only, Git-driven knowledge
- Agent 1 can inspect /wiki/architecture.
- Agent 2 can search /wiki/runbooks.
- Agent 3 can follow references in /wiki/services.
- Agent 4 can read /wiki/policies.
- Agent 5 can navigate /wiki/indexes.
They are all operating against the same approved knowledge revision.
There is no need for each agent to independently ingest those documents.
No need for the runtime to own a separate persistent knowledge store.
The agent sees knowledge as ordinary files.
And this is particularly powerful because it uses a tool interface that coding agents already understand exceptionally well: the filesystem.
What “shared mount” really means
A shared mount is not necessarily one physical disk attached to every agent. It is one logical, authoritative knowledge filesystem, published through the storage mechanisms supported by the execution environment.
- For Linux process sandboxes, that can mean multiple read-only bind mounts of the same host directory.
- For microVMs, it can mean identical immutable filesystem images exposed as read-only virtual disks.
The critical property is consistency of knowledge and isolation of execution.
3. Bubblewrap, seccomp, and Landlock Make This Lightweight
For agents that don’t require hardware virtualization, Linux sandboxing provides an attractive execution model.
Bubblewrap: Define the agent’s filesystem view
Consider Bubblewrap.
Bubblewrap can construct an isolated filesystem environment using Linux namespaces.
We can create a sandbox with a writable temporary workspace while exposing the approved LLM Wiki snapshot through a read-only bind mount.
Conceptually, the mount operation looks like:
--ro-bind /srv/llm-wiki/releases/<commit> /wiki
Every agent receives access to the same published snapshot, but cannot write through its /wiki mount.
The sandbox might have its own writable /work directory for generated files, temporary notes, scripts, and proposed knowledge updates.
The separation is straightforward:
/wiki is shared knowledge. /work is private execution state.
Bubblewrap provides the isolated mount namespace, letting us control which host directories are visible inside the sandbox.
But mounting read-only files isn’t the entire security model.
We can strengthen it using additional Linux security primitives.
seccomp: Restrict what the agent can execute
seccomp-BPF allows the runtime to restrict system calls available to an agent process.
Depending on the workload, a policy can prevent unnecessary privileged operations and reduce the kernel attack surface.
Bubblewrap supports loading seccomp policies.
However, seccomp is primarily a syscall-filtering mechanism, not a filesystem path-permission system.
Landlock: Restrict what the agent can access
Landlock is a Linux security module that can apply additional filesystem access restrictions to a process and its descendants.
A sandbox launcher can combine Landlock policies with Bubblewrap’s namespace and mount configuration.
This makes it possible to enforce a tighter filesystem access policy: permit reading approved knowledge, permit writing only to designated workspace locations, and deny access to other protected paths.
Landlock is an additional layer; it should not be confused with a built-in Bubblewrap mount mechanism.
Putting the layers together
Combined appropriately, these mechanisms create a powerful execution environment:
Bubblewrap defines the filesystem view. Landlock restricts filesystem access. seccomp reduces syscall capabilities.
This is a compelling model for large numbers of short-lived agents because it avoids the overhead of running a separate guest operating system for every process.
And importantly, a restarted agent doesn’t lose organizational knowledge.
Its local execution state can disappear. The mounted knowledge source remains available.
4. Firecracker: The Same Architecture With a Stronger Isolation Boundary
For workloads requiring stronger isolation, we can use Firecracker microVMs.
The concept stays the same.
Each agent runs inside an independent microVM with its own guest kernel and isolated execution environment.
The knowledge source remains Git-driven.
The difference is how the filesystem reaches the agent.
How the knowledge reaches the microVM
Unlike a Linux process sandbox, Firecracker doesn’t directly use Bubblewrap-style host bind mounts inside the guest.
Instead, a Git revision can be packaged into an immutable filesystem image, then attached to microVMs through read-only virtual block devices.
Firecracker supports read-only virtio-block drives. The guest can mount the filesystem at /wiki.
This means multiple microVMs can consume logically identical knowledge without receiving write access to the underlying published data.
For deployments across multiple hosts, the immutable knowledge images can be distributed or cached where the microVMs run.
A Firecracker VM configured with one guest vCPU can also be constrained to an effective 0.5 CPU allocation using host cgroup CPU quotas; fractional vCPU counts are not directly configured in Firecracker.
The resulting architecture
The resulting architecture is simple to reason about.
- Every agent gets an isolated execution environment.
- Every agent gets an immutable view of the knowledge it is authorized to access.
- The knowledge source exists independently of the agents.
- And the control plane decides which knowledge revision each agent should consume.
Agents are disposable. Knowledge is persistent.
5. A Git Push Can Update Knowledge for the Entire Agent Fleet
This is one of the most exciting parts of the design.
Suppose a new security policy has been approved.
In a conventional architecture, updating agent knowledge might mean reprocessing documents, refreshing embeddings, rebuilding indexes, and coordinating multiple retrieval services.
In a Git-driven architecture, knowledge publication can become a standard CI/CD workflow.
The publishing workflow
- A contributor changes a Markdown file.
- A pull request is reviewed and merged.
- A GitHub Actions or equivalent pipeline validates the repository.
- The pipeline generates any required filesystem indexes and publishes an immutable knowledge snapshot.
- The new snapshot is identified by the exact Git commit from which it was created.
The control plane can then make that revision available to new agent sessions and roll existing agents forward when appropriate.
Version-pinned snapshots
Running agents can remain pinned to their current knowledge revision until they safely transition.
This is important.
We don’t want a long-running agent to read half its knowledge from one release and half from another because files changed during execution.
Immutable, version-pinned snapshots give us consistent behavior and better debugging.
If an agent produces a problematic decision, we can inspect not only its model and prompt, but also the precise revision of knowledge available during the session.
Git becomes much more than version control.
Git becomes the release mechanism for organizational intelligence.
6. Agents Should Raise Pull Requests When They Learn Something
Now consider what happens when an agent discovers something new.
A scenario
Imagine an infrastructure agent investigating a failed deployment.
It finds that a particular service requires a configuration setting missing from the organization’s existing runbook.
The agent fixes the problem.
Should that discovery disappear when its session ends?
Absolutely not.
But should the agent modify the shared knowledge volume directly?
Also no.
The governed path
The shared volume is deliberately read-only.
Instead, the agent prepares a proposed update inside its own writable workspace.
It submits that change through a controlled Git workflow, producing a pull request against the LLM Wiki repository.
The PR includes the new learning, relevant supporting evidence, and the specific knowledge files to update.
A human reviewer validates the proposed information.
Automated checks can verify schema consistency, links, documentation structure, and policy requirements.
When the PR is approved and merged, the release pipeline publishes a new knowledge snapshot.
The new information becomes available to the wider agent fleet.
The implications
Think about the implications.
One agent encounters a problem. One agent discovers a solution. A human validates it. Every authorized agent can benefit from that learning.
The agents never need direct write access to the production knowledge mount.
The repository remains governed.
The evolution of knowledge is auditable.
And individual sessions can contribute to an increasingly useful organizational knowledge base.
This is collective agent learning through software engineering workflows, rather than uncontrolled persistent agent memory.
7. The Filesystem Can Become a Knowledge Graph
A Git-driven wiki doesn’t have to be a flat collection of Markdown files.
We can organize knowledge around architecture, services, dependencies, procedures, and relationships.
A service document can link to its API contracts, deployment guides, owners, dependent services, incident history, and security requirements.
Those relationships can be represented using Markdown links, structured metadata, manifests, and generated indexes.
A build process can produce a filesystem knowledge graph from those relationships.
The agent can then navigate across related information rather than searching every document independently.
For example:
Service → API Contract → Dependency → Runbook → Incident → Resolution
All of these relationships can be discovered through the filesystem’s indexes and linked documents.
Indexes are accelerators
We can maintain exact-search indexes for symbols and identifiers, graph indexes for relationships, and semantic indexes when fuzzy discovery is necessary.
The important architectural decision is that those indexes remain derived artifacts.
The Git repository is the authoritative knowledge. The indexes are accelerators.
A graph database is useful when the relationship model becomes sufficiently complex. A vector database is useful when semantic discovery across large collections becomes necessary.
But neither needs to be the default ownership layer for the knowledge itself.
The architecture can start with files and grow only when additional retrieval capabilities are justified.
8. Why I Prefer This to Making RAG the Default Architecture
RAG is not a bad technology.
For massive unstructured collections, semantic retrieval and reranking are extremely useful.
But consider what an agent actually needs when working with engineering documentation.
It needs access to authoritative files, exact configuration values, complete procedures, linked dependencies, and the latest approved operational knowledge.
A well-structured filesystem can provide those things without a network retrieval call for every lookup.
The agent can navigate directly.
Its knowledge access can be controlled through sandbox permissions.
The organization can manage knowledge evolution through Git.
And the runtime can be entirely independent of the knowledge publication process.
That changes the system’s complexity profile.
Instead of making embedding generation and vector retrieval mandatory parts of the knowledge architecture, we treat them as optional search capabilities layered on top of a durable source of truth.
The trade-offs
There are trade-offs.
- Filesystem navigation can be inefficient for poorly organized or extremely large corpora.
- Agents can waste tokens reading irrelevant files.
- Semantic search may find information that exact search misses.
- Distributed snapshot publication requires storage, caching, and synchronization mechanisms.
Shared knowledge also requires authorization boundaries. Not every agent should necessarily see every document, even if all agents share the same underlying architecture.
These are real engineering concerns.
But they are easier to reason about when the foundational design is explicit:
- Git owns knowledge revisions.
- The publishing pipeline owns distribution.
- The filesystem mount provides runtime access.
- The sandbox enforces isolation.
- The agent consumes only the knowledge it has permission to read.
9. A More Scalable Mental Model for Multi-Agent Systems
We’re moving toward a world where organizations won’t run five agents.
They’ll run hundreds, thousands, and potentially far more.
- Some will be long-running.
- Others will exist for only a few seconds.
- Some will execute inside Linux sandboxes.
- Others will require independent microVMs.
Maintaining a separate knowledge system for every agent is the wrong abstraction.
What we want is a fleet of independent execution environments connected to a governed and reusable knowledge foundation.
An agent can start, access its approved knowledge snapshot, complete a task, and disappear.
Another agent can start on a different host, using a different model or framework, and consume that same knowledge revision.
Meanwhile, Git continues managing how organizational knowledge improves.
The execution layer can scale horizontally without requiring knowledge ownership to scale with every runtime.
And the knowledge base can evolve without tying its lifecycle to any particular agent.
This separation between knowledge ownership, knowledge distribution, and agent execution is what makes the architecture powerful.
10. The Architecture Is Surprisingly Simple
If I were building the foundational knowledge layer for an enterprise AI agent platform today, I would strongly consider the following design:
Git Repository → Review and Merge → Immutable Knowledge Snapshot → Read-Only Shared Mount → Isolated AI Agents
- For lightweight Linux workloads, I’d use Bubblewrap with read-only mounts and appropriate seccomp and Landlock restrictions.
- For stronger runtime isolation, I’d use Firecracker with immutable read-only filesystem images.
Each agent would get a private writable workspace and a shared, versioned knowledge interface at /wiki.
When an agent discovers a useful new piece of information, it can propose a PR.
A human reviews the change.
The publishing pipeline releases the updated knowledge.
And future agents gain access to that learning without modifying the knowledge volume directly.
The result is not just a different way to retrieve documents.
It’s an architecture for making knowledge persistent, reproducible, reviewable, distributable, and accessible across isolated execution environments.
Final Thought: Stop Making Every Agent Rediscover What the Organization Already Knows
The most interesting part of agentic AI isn’t that we can launch thousands of independent agents.
It’s that those agents can operate on a shared body of knowledge and contribute to improving it.
- Git gives us a proven model for evolving that knowledge.
- Read-only filesystem mounts give agents a direct, familiar interface for consuming it.
- Bubblewrap, seccomp, Landlock, and Firecracker give us different isolation mechanisms for running those agents safely.
- And pull requests give us a governed path from individual discoveries to collective organizational learning.
We don’t need to replace every RAG system or every knowledge graph.
But we should question whether those systems need to be the foundation of agent knowledge in the first place.
For many coding, infrastructure, operations, and enterprise automation agents, the better architecture may be much closer to the tools we’ve already been using for decades.
Git for knowledge. Shared mounts for access. Sandboxes for isolation. Pull requests for learning.
That’s the architecture I’d bet on.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here
