The vault gets more useful when I ask it to carry less at the front door.
My first instinct was to keep every important rule visible all the time. That helped build the system, but it also gave every agent another wall of context to sort through before reaching the work.
This month is about turning the vault from a well-organized repository into a tighter operating loop—small instructions up front, deeper detail on demand, and a stronger expectation that useful work comes back to the project before the session ends.
Keeping the front door small
The always-on instruction layer has been cut down to connection points. It now tells an agent what is authoritative, how to classify a request, where the main boundaries live, and which deeper procedure to load. The full explanation sits behind that pointer.
That lazy-loading pattern matters for more than speed. It forces each rule to have a clear trigger. Linking guidance loads when links are being created. Project procedures load when project work begins. A routine brings its own operating details. The common layer stays stable while specialized context appears only when the work calls for it.
The design test is simple: if a rule must shape every task, keep a compact trigger in front. If it matters only to one kind of work, give it a durable address and load it on demand.
Making write-back part of done
The most valuable output of a session is often not the answer in the chat. It's the project state the answer changes: a decision recorded, a task closed, a status clarified, a procedure corrected, or a reusable artifact placed where the next session can find it.
I'm making project synchronization part of done. If the work changes the project, the brief, task list, decisions, or status log has to change with it. A polished answer without that durable update isn't finished.
This closes a subtle failure mode. Sessions can be individually successful while the shared system slowly becomes stale. Write-back keeps the source of truth moving at the same speed as the work.
Teaching the system to improve
Another piece on the desk is a more deliberate improvement reflex. When a session discovers a better procedure, a useful fact, a repeated judgment, or a deliverable that is starting to recur, the result should move into the right durable layer instead of disappearing into a status note.
That doesn't mean turning every observation into a permanent rule. The system needs different homes for different kinds of learning: a procedure can become a skill, a stable fact can join reference material, a judgment can remain a lesson with conditions, and repeated work can earn promotion into a routine.
The goal is compounding usefulness. The second time a problem appears, the vault should offer more than memory. It should offer a better way to do the work.
Routing before guessing
A growing knowledge base creates a discovery problem. An agent can still answer from general knowledge even when the vault contains a more current, local, or carefully earned answer.
The emerging fix is to route the request before reaching for an answer. First identify the kind of work. Then load the relevant domain facts and procedures. Only after that should the system ask for clarification, make an assumption, or look outside the vault.
This reduces repeated explanation for me and reduces confident guessing for the agent. It also makes missing structure visible: if a recurring request has no route, that's a signal to create one rather than keep relying on memory.
What is still loose
The vault can describe an operating discipline, but some of that discipline still depends on the session remembering to follow it. The next step is to make the important transitions structural: orientation that always happens, project changes that can't silently bypass write-back, and clearer handoffs between pieces of work.
That's where this is heading. The vault remains the durable brain, but the operating layer has to make the right behavior easier than the wrong behavior. For now the work is intentionally plain: shorten the front door, improve the routes, close the write-back loop, and keep finding the rules that still exist only on paper.