Why use the file system as context?
Every model has a finite context window, and stuffing it full has two costs: you eventually hit the limit, and quality degrades as relevant details get lost in a wall of text. The file system as context pattern sidesteps both by treating files as the agent's memory and loading only what's relevant into the prompt at each step.
The agent works the way a developer does: it lists files to see what exists, reads the specific ones it needs, writes intermediate results back to disk, and keeps only a compact working set in context. A large codebase, a long research corpus, or a multi-step project that would never fit in a context window becomes tractable, because the window only ever holds the slice the current step requires.
This pattern is central to coding agents and any system operating over large bodies of structured content. In Prodinit's DevOS work on codebase understanding, treating the repository itself as the context store — reading and indexing files on demand rather than cramming them into the prompt — was what let agents reason over codebases far larger than any window.
How it relates to RAG and memory
File system as context overlaps with RAG and agent memory but isn't identical.
| Approach | Where knowledge lives | Retrieval |
|---|---|---|
| File system as context | Files on disk | Agent reads files directly |
| RAG | Vector store / database | Similarity search at query time |
| In-context memory | The prompt itself | Always loaded, limited by window |
RAG retrieves by semantic similarity; file-system context lets the agent navigate and read deliberately, like a person browsing a project. They combine well — index files for similarity search, but let the agent open and edit specific files directly.