The Context Filesystem
Your agent answers a question about the deploy procedure and gets it wrong. Not wildly wrong — wrong in the way that costs you an afternoon. You want to know where it read that. You open the trace and find a similarity score of 0.83 and a paragraph with no filename, no heading and no date, sitting next to four others that scored slightly lower. It came from somewhere. The store cannot tell you where, because it never kept that. So you are not debugging a mistake. You are staring at a number and guessing.
A find with no square is scrap
Start with the shape. Context is everything the model can read during a single call — instructions, the session so far, documents pulled in, notes, the output of tools. The usual way to hold the retrievable part is a heap of chunks in a vector store: a flat index, every piece a point in space, retrieval a question of which points sit nearest to yours. It works. When it fails, it fails mutely.
Now picture a dig. There are two ways to empty a field. You can scoop it and wash everything into one crate, and end up with a beautiful pot and no idea which layer it came out of. Or you lay a grid, work square by square, and tag every find with the square and the depth that produced it. The pot is identical either way. The second one is knowledge. The first is decoration.
A context filesystem is the grid. Every piece — a memory, a document, a skill — gets a path instead of a coordinate in embedding space: resources, then the project, then docs, then the API, then the file about authentication. The agent works it the way you work a directory. It lists what is there, walks the tree, searches by name. Nothing comes back without an address attached.
Nobody excavates a whole field at full depth
Digging is expensive and it destroys what it touches, so you never do all of it at once. You survey the field, open a trench where the survey earns you one, and go down finely only in the square that turns out to matter. Layered loading applies that same discipline to a document. Each entry is prepared at three depths when it is written: an abstract of about a hundred tokens, one sentence long; an overview of around two thousand, enough to see how the thing is built; and the full original text, which costs exactly what the document costs. Relevance gets judged on the abstract. Planning happens on the overview. The full text is read only when the precise wording has to be right, and every directory carries an abstract of its own, so you can tell whether to go in before going in.
The saving is not marginal. On the LoCoMo benchmark this tiering cuts input tokens by 34 to 91 percent while landing at 80 to 83 percent accuracy, against 24 to 57 percent for the same agents running on their native memory. The same reflex handles a tool that returns forty thousand lines of log: keep the first errors, the last ones and the path, leave the bulk in the workspace, and search it later if the question ever gets that specific.
A wrong answer should leave a trail
None of this throws out semantic search. A query still opens with it, but it goes looking for the most relevant directory rather than the single best-scoring fragment, and then descends level by level, so what comes back arrives with its surroundings intact. And the descent is recorded. Each query keeps the sequence of paths it walked, which means a bad result stops being a mystery: you can see whether the error was in choosing where to start or in losing the thread on the way down. Debugging what the agent read becomes as ordinary as debugging what it did.
It also changes what you are willing to leave alone. Context is a runtime you design, and a runtime you cannot look inside is one you supervise by watching its output, forever. When every piece has an address and every lookup leaves a route behind it, you can check what the model was handed without rerunning anything.
An opaque context can only be wrong. One with paths can be wrong somewhere in particular, and that is the only kind of wrong you can fix.