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

But most of my actual work isn't code. It's 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, not a repository. These projects have exactly the same disease — context rot, drift, silent loss of the thread — but none of the things that make code manageable. There's no test suite to catch a regression. There's 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's 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'm confident enough in it to publish. It's the same core idea as the coding system — the memory lives in files, not in the conversation — adapted for work where the inputs are messier, the truth is contested, and half of what you write can't be shown to the client. You can grab the full starting prompt and adapt it; the rest of this post is why it's shaped the way it is.

The folder is the memory, not the chat

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 — not summarized in chat and lost when the session ends.

The structure is a hierarchy, and the hierarchy is the whole point:

[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've 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 doesn't start from zero.

The failure I'm 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, treat context like a workbench with limited surface area rather than a bucket you fill. The folder is that workbench.

What knowledge work forced that code never did

Here's where it stops being a straight port. Three things about consulting work broke assumptions my coding system quietly relied on.

Capture discipline, because there's no compiler. In code, an un-integrated decision eventually announces itself — the build breaks, a test goes red. In knowledge work, a debrief that nobody folds back into the synthesis just 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 no one folds back is wasted. The context files, not the chat, are the memory. This is the discipline that has the highest payoff and is the easiest to skip, which is exactly why it's written as a non-negotiable step rather than a suggestion.

Facts versus interpretation, because sources disagree. Code doesn't 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 can't. 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. Corrected facts are the job, not a problem to editorialize about. This sounds like bookkeeping pedantry until the first time a client says "where did that number come from?" and you can answer in ten seconds.

Client-safe versus candid, because half of it can't be shown. A codebase has no audience problem. A consulting folder does: the same project contains minutes you'd 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's a governance concern I raised at the organizational level — who can see what context, and how candid it's safe to be — showing up at the project level, enforced by folder convention instead of hope.

Subagents keep the main thread clean

There's one move in here that 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 swallow 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 precisely the kind of bulk, low-density input that dilutes attention across a long session — exactly 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's 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'm using that principle not to build a product but just to get through a week of inputs without the main thread going soft.

Posture, not just plumbing

The last piece isn't structural, but it's the one that changes the day-to-day most: the prompt tells Claude to be a thinking partner, not an executor — stress-test my ideas before agreeing, lead with what's weak or missing, flag the decisions that are genuinely mine to make. Left to default, these tools are agreeable in a way that's actively unhelpful on strategy work; you don't 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 a very organized note-taker into something that actually improves the thinking.

The same conclusion, one more domain

I keep ending these posts on the same line and this one earns it again: context is a resource that needs to be managed, not a bucket that needs to be bigger. What's new here is only the domain. The discipline that made my code projects feel continuous instead of 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 exactly 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're actually doing — the structure isn't sacred; the principle underneath it is.