Everything I have written about context management started with code. The five .md files, the handover discipline, and the agent-team split all came out of watching Claude Code drift on long software projects and building scaffolding to stop it.

But most of my actual work is not code. It is the consulting kind: an RfP response, a discovery, a research report, a stakeholder analysis that runs for weeks and lands in a deck or a document rather than a repository. These projects have the same problem, context rot, drift, silent loss of the thread, but none of the things that make code manageable. There is no test suite to catch a regression and no compiler to reject an inconsistency. The "bug" is a proposal that contradicts something the client said in a call three weeks ago, and nobody notices until it has already been sent.

So I built the knowledge-work version. It runs in Claude Cowork, out of one shared folder that syncs to the team via OneDrive, and after using it across several real projects I am confident enough in it to publish. It is the same core idea as the coding system, with the memory living in files rather than in the conversation, adapted for work where the inputs are messier, the truth is contested, and half of what you write cannot be shown to the client. You can grab the full starting prompt and adapt it; the rest of this post is why it is shaped the way it is.

Folder as memory

The premise is one line: the shared folder is the single source of truth, and it should always be ahead of the conversation. Findings, decisions, and drafts get written into the folder as we go, rather than summarized in chat and lost when the session ends.

The structure is a hierarchy, and the hierarchy is what does the work:

[Project]/
├── README.md            - what this is + how we work in it
├── BACKLOG.md           - open items, questions, things to chase
├── context/             - our synthesised understanding ("what it means")
│   ├── overview.md      - goal, scope, constraints
│   ├── current-state.md - what we know so far, source-linked
│   ├── stakeholders.md  - people, roles, positions
│   └── <topic>.md       - per-theme synthesis
├── inputs/              - everything received, logged; INDEX.md registers each
├── working/             - the work in phases (analysis → drafts → review → final)
└── source-documents/    - untouched originals (read-only reference)

If you have read my post on .md files as a memory architecture, this maps onto the same hierarchy I described there, just with different labels. source-documents/ and inputs/ are the raw episodic record, what actually landed on the desk. context/ is the synthesized long-term layer, what it all means, which is the thing you actually reason from. working/ is the active surface where the current task lives. The context/ files are the equivalent of DECISIONS.md and CLAUDE.md: the distilled, durable understanding that a fresh session reads first so it does not start from zero.

The failure I am designing against is the one from my very first context post: five months into a project, the AI produces something "technically competent but strategically wrong" because the foundation has drifted into the fading middle of a giant context window. The fix is identical to the coding fix: keep the active working set small and well-organized, put everything else in files you pull in when needed, and treat context like a workbench with limited surface area rather than a bucket you fill. The folder is that workbench.

Additional constraints for knowledge work

Three things about consulting work broke assumptions my coding system quietly relied on.

Capture discipline. In code, an un-integrated decision eventually announces itself when the build breaks or a test goes red. In knowledge work, a debrief that nobody folds back into the synthesis silently evaporates, and you find out months later when the proposal misses a requirement everyone "knew." So the core rule of this model is mechanical: every input (email, transcript, doc, link) gets logged in inputs/, registered in an INDEX.md with an ID, date, source and one-line summary, and its findings propagated into every relevant context/ file, each fact tagged with where it came from. A debrief nobody folds back is wasted work. The context files hold the memory, not the chat. This discipline has the highest payoff and is the easiest to skip, which is why it is written as a non-negotiable step rather than a suggestion.

Facts versus interpretation. Code does not have this problem: a function does what it does. But in a discovery, two stakeholders will tell you two contradictory things about the same process, and both are "true" until you triangulate. My coding DECISIONS.md assumes a single authoritative reality. The knowledge-work version cannot. So the model insists on separating what a source actually said, attributed to that source, from our interpretation of it, and when two sources conflict, you keep both and mark it "to triangulate" rather than silently overwriting one with the other. Correcting facts is part of the job, not something to editorialize about. This sounds like bookkeeping pedantry until the first time a client asks "where did that number come from?" and you can answer in ten seconds.

Client-safe versus candid. A codebase has no audience problem. A consulting folder does: the same project contains minutes you would happily send the client and strategic reads you absolutely would not. So the model bakes in an audience rule. Anything client-facing gets written neutral and safe to send; candid assessments and strategy live in clearly-marked internal notes. And because the folder syncs to a team, the model treats files other people co-edit as theirs: generate a v1, then propose changes, rather than overwriting what a colleague is working in. That is a governance concern I raised at the organizational level, who can see what context and how candid it is safe to be, showing up at the project level and enforced by folder convention rather than hope.

Subagents

One move in here ties directly back to the agent-teams work: large inputs get digested by a subagent that reads the whole thing and returns a structured debrief, so the main thread never has to take in a 40-page transcript raw. The main session then writes the analysis and propagates it into context/.

This is context-rot avoidance as a work method. A discovery call transcript is the kind of bulk, low-density input that dilutes attention across a long session, the accumulation problem I decomposed in the context-rot post. Reading it in a scoped subagent means its 15,000 tokens never land in the main context at all; only the distilled debrief does. It is the same reason I argued agent teams work in the first place: a bounded agent that only reads and summarizes never accumulates the constraint load that degrades coherence. Here I am using that principle to get through a week of inputs without the main thread degrading, rather than to build a product.

Adversarial posture

The last piece is not structural, but it changes the day-to-day most: the prompt tells Claude to be a thinking partner rather than an executor, to stress-test my ideas before agreeing, lead with what is weak or missing, and flag the decisions that are genuinely mine to make. Left to default, these tools are agreeable in a way that is unhelpful on strategy work; you do not want a research partner that validates a weak win theme because you sounded confident about it. Writing the adversarial posture into the operating model is what turns it from an organized note-taker into something that improves the thinking.

Conclusion

I keep ending these posts on the same line, and it applies here too: context is a resource that needs to be managed, not a bucket that needs to be bigger. What is new here is only the domain. The discipline that made my code projects feel continuous rather than episodic works just as well on an RfP, a discovery, or a research report. It just needs three additions that code never demanded: rigorous capture with provenance, a hard line between source facts and our interpretation, and a client-safe/internal split. The folder holds the memory, the subagents keep the thread clean, and the model reads its own context files first so a fresh session picks up where the last one stopped.

The starting prompt is here. Fill in the two brackets, tell it who else can see the folder, and it scaffolds the rest. Adapt the file names to whatever you are actually doing; the structure is not fixed, but the principle underneath it holds.