A Working Context System is a small, human-governed record of what is true now, why it changed, and what your AI should load next. You keep the record, so the same context can travel between tools without depending on what any one of them happens to remember.
This is a method, not an app. The complete template is free to use, adapt and share.
The efficiency AI promised quietly disappears the moment you cannot be sure what actually got remembered, or find yourself rebuilding context anyway because retrieval missed it, guessed wrong, or never reached the tool you are using. Here is what that looks like in practice.
Even with memory switched on, you cannot be sure what carried over. You end up rebuilding a partial, improvised picture of your work anyway, slightly different each time, never quite complete, because you are guessing at what the tool kept rather than checking.
What one tool knows, the other does not. Switching tools means starting again. Your context does not travel with you.
Having to re-explain is exactly what kills the efficiency the tool promised. You spend time briefing instead of working.
Native memory may well have retained the fact. The question is whether the assistant judges it relevant enough to surface for this particular task. Retention and retrieval are separate steps, and the second one is where the gap appears.
The fix is not a better prompt. It is deciding, deliberately, what the tool should know - and loading it on purpose.
This repays people juggling several clients, projects, organisations or collaborators, especially when decisions need to survive for months and the work moves between AI tools. If you use AI occasionally for one-off questions, native memory or a single context document may already be enough.
The system is built from three plain files and a short ritual at the start and end of every working session.
The current instructions that should shape behaviour now. Edited in place so it always reads as current state - this is what makes sessions feel continuous rather than improvised.
The dated history that preserves provenance and explains how the current position was reached. Append-only; history is never rewritten.
Stable facts, structures and pointers to the source material that owns the detail. Changes rarely but earns its place every session.
Keep each piece of information in the record that owns it and link to it from everywhere else. Most real work stays in documents, decks, spreadsheets and threads. Record a pointer: what it is called, where it lives, what it is for and when a future session should open it. This reduces duplication, makes correction possible and keeps the system small while connected to the detail.
The four files stay small because they point at work rather than holding it. If you will keep returning to a subject, and the useful detail would swamp the system, write a file in your ordinary folders and point at it from Durable reference. That is for a special-interest topic, not for every email or one-off draft. After you have updated that same file more than once, put a short dated Change Log at the foot of the file. Keep that history there, not in Durable reference. A later session picks the work up from the file, not from memory.
A useful draft, a sent email or an interesting conversation does not become memory merely because it happened. If a future session will not act differently and nobody needs to find it again, it stays out.
A context document solves the first-day problem by telling an assistant what matters. A Working Context System also solves the hundredth-day problem: it separates current rules from history, routes lasting facts to the right record and gives every session the same governed way to propose and approve change.
As an analogy, the AI supplies the thinking while the Working Context System supplies continuity. Active rules act like reflexes, the Log preserves learning, Durable reference supplies the body of knowledge and pointers connect the system to the work itself.
This is an analogy to aid understanding, not a technical claim.

The same three layers hold the two things a working life actually runs on: outstanding actions and live relationships.
Actions belong in a task manager, not in the context files. If your assistant can connect to the task tool you already use, it can check what is due and create approved actions at wrap-up. If it cannot, keep the task list separately or use a simple Tasks file.
For a solo practice or a small relationship pipeline, the tracker records who the relationship is with, how it began, where it stands and what happens next.
Native memory has got good, and this argument does not need it to be bad. Both of the main assistants let you see what they have stored, correct it and delete it, and one will cite the earlier conversation a claim came from. None of that is a black box.
You can see and edit a good deal of it. What you cannot see is all of it. One vendor states in its own documentation that the summary shown to you may not include everything it remembers, and that the sources it displays may not reveal every factor that shaped a response.
The distinction is narrower and it holds anyway. Native memory optimises continuity and relevance. A Working Context System governs currentness, provenance and authority. Recall asks what is likely to be useful here. Governance asks what is currently true, what replaced what, and who agreed to it.
Governance sounds like approving a proposal at the end of a session. That is the most visible part and the least important. In practice it is four things.
Most of what happens in a session is worth recording nowhere. That judgement is made dozens of times a day and leaves no trace, which is exactly why the record stays small enough to load and trustworthy enough to believe.
Editing a current rule in place is not an update, it is a declaration that the previous version no longer governs. A log can only accumulate, and stored memory has no concept of a fact being deliberately killed as opposed to merely not retrieved.
The same sentence behaves differently depending on which record it lands in: shaping what happens next, explaining how you got here, or sitting inert until something calls for it. Choosing which decides how much power it has later.
When two records disagree, someone decides which one wins. That is the act the other three are tested by, and the one that cannot be handed over.
The assistant proposes, sorts and drafts. What stays yours is refusing, retiring, filing and ruling.
The obvious objection is that bigger context windows and better retrieval will make a curated record unnecessary. They will not. A large knowledge base, retrieved intelligently, still leaves the assistant to work out which of two documents is current and which one lost the argument. Scale is a retrieval problem and it is being solved. Authority is an editorial problem, and it stays with you.
Memory inside any one tool is improving quickly, and the selection problem will keep getting better - so the case here does not rest on today's weaknesses. The gap that is not closing at the same speed is the boundary between tools. Each vendor's memory is a retention feature for its own product, not a portable record of how you work.
Native memory will continue to improve, and cross-tool portability is likely to improve with it. That does not remove the need for judgement. Moving more memory between products is not the same as deciding what deserves to become organisational context, which version is current or who approved the change.
Memory from Claude's ordinary chat does not currently carry into Cowork sessions. Cowork projects can keep their own project-scoped memory, so the boundary is not no memory, but continuity that remains separate by mode and project.
ChatGPT web uses ChatGPT memory, while local Codex clients use a separate local memory store and controls. Both can carry context forward, but they do not use one shared memory layer.
Checked against both vendors' own documentation, most recently on 4 August 2026. What is available to you also depends on your plan, settings and surface, and these particulars change quickly.
These are concrete examples of the wider portability problem: continuity can still be scoped to a product, mode or project. A Working Context System keeps the record people need to inspect, correct and carry between those boundaries.
Native memory optimises continuity and relevance. A Working Context System governs currentness, provenance and authority. Use both.
I have resumed a client thread weeks later without rebuilding the brief because the current decision, its history and the documents to open were already in the record. That is an observed use case, not a claim that every session will recover context perfectly.
For a solo practice or a small relationship pipeline, the tracker covers the continuity that matters most: every organisation, how the thread started, what stage it is at, when it was last touched and what happens next.
The same three layers carry this alongside the rest of the work. Larger teams or more complex pipelines may still need a CRM.
At wrap-up, the assistant proposes what changed and what happens next. Once approved, it updates the relationship record as part of the session rather than leaving a separate administrative chore.
The system stays current because keeping it current is not a task.
This grew out of the same discipline behind Grant Resource Studio's funding work. AI is only as good as the knowledge beneath it. There, the knowledge is a Funding Knowledge Base; here, it is your own working context.

"Start the client session." The assistant loads current rules, client context and the relationship record.
The assistant operates with full context throughout. No re-briefing, no rebuilding from memory.
"Wrap up." The assistant proposes one changed rule, one lasting client fact, one task and the items that should be recorded nowhere.
You review and correct the proposal before anything is written. The records are updated only after your approval.
Colleagues can use different assistants against the same record, provided each assistant has appropriate access to the shared workspace. What is shared is the deliberate organisational context, not anyone's private conversation history. Nobody has to standardise on a vendor, nobody pays for seats they do not want.
A shared source of truth needs ordinary access controls and an agreed editing routine. The append-only Log preserves history, while dated entries and approval make it clear what changed, who agreed it and when. The workspace itself still has to manage permissions, version history and simultaneous editing.
On your own machine, as a folder of plain files. This is the simplest option, and it already works across more than one AI tool - any tool with access to that folder reads and writes the same files, and a tool without folder access can still be given them by hand. Put the folder in a synced drive and it follows you between machines. Choose this if the system is yours alone.
In a shared workspace - a team wiki or a shared document space. This takes a little more setup, and it is the option to choose if anyone else will ever use the system with you. A common arrangement is to keep the shared workspace as the master and a local copy as a backup.
A folder on one person's machine cannot be a shared source of truth: a shared workspace is a requirement for working with other people, not a preference. This is the version that survives a team, because it belongs to the work rather than to one person's account.
Four working files, a session ritual skill, a START HERE guide and a setup note. The complete introductory Working Context System, free to use, adapt and share.
Current instructions and preferences, edited in place so they shape behaviour now.
An append-only, dated history of decisions, corrections and learnings.
Stable facts, structures and pointers to the source material that owns the detail.
Relationship history, current status and agreed next steps, one row per contact.
The session ritual. Install this. Then say "start session" and "wrap up".
The start, work, wrap-up and approval ritual at a glance.
How to give a suitable assistant read and write access to the workspace. Includes the paste for installing the working-context-skill.
Roughly and honestly. Done beats perfect. You will refine it as you go.
That is the ritual. Do not paste the ritual into Project, Gem or custom-instruction fields as well.
Say "start session" at the start and "wrap up" at the end. Notice what you reach for that is not there yet. Add it to the right layer.
You can hand the pack to your assistant and ask it to install the skill.
The free pack uses Markdown: portable plain-text files that people and AI assistants can both read. They work in an ordinary text editor, but a free Markdown application such as Obsidian will display the headings, links and emphasis as a formatted document.
Markdown uses a few simple markers, such as # for headings and ** for bold text. Because it is plain text, it is easy to search, update, compare and move between tools without locking the record to one product. Obsidian is free to use, including for work; its optional Sync and Publish services are paid.
The assistant needs both read and write access to the workspace.
Reading loads the context at the start; writing allows approved updates at wrap-up. If it can only read, the method still helps, but you will have to apply the proposed changes yourself.
You install a skill in the assistant you already use, or you ask another assistant to wrap that skill file. A hosted workspace plus a connector still avoids a desktop app. A desktop app is still only needed if the four files live in a folder on your machine. Reading without writing is still not enough. Skill without write access is not enough either.
The honest way to start is to try it on whatever you already pay for, or do not pay for, before changing anything.
The payoff is real, but it is not instant. The system earns its keep through repetition, not through a single impressive session.
If you stop appending and stop loading, the system drifts out of date. The ritual is not optional - it is the mechanism.
If your notes are chaotic, the system organises your chaos rather than fixing it. Clear thinking still has to come from you.
The version I use also includes periodic housekeeping: reviewing what has accumulated, correcting stale context, moving detail back to the record that should own it and removing duplication only after checking the authoritative source. That becomes useful once a system has been running for long enough to accumulate history. The full housekeeping method is beyond the scope of this introductory resource; the free pack gives you the structure and session ritual needed to begin.
A hands-on session for networks, membership bodies and support organisations. Participants bring one real area of work, decide what their AI should know, build the first version of their records and leave with a start-and-wrap ritual they can run in the tools they already use.

45 - 90 minutes, hands-on in the room
Networks, membership bodies, infrastructure organisations
Each participant leaves with a working system skeleton
Everything on this page is free to build yourself. If the difficult part is deciding what belongs where, connecting it safely or getting a team to maintain it, I also build the system with people around their actual work. Book a call.
The first version was inspired by MJ Jaindl's four-file Claude setup shared on LinkedIn. I adapted it through daily use to meet my own needs, separating current rules from history, durable reference from tasks, and useful material from the things that should be recorded nowhere.
Other useful open-source projects have proposed related approaches, often for a more technical audience. This resource translates the same broad concern into a method that non-technical practitioners and small organisations can inspect, adapt and maintain. The ingredients are established. The particular contribution here is the operating discipline: what belongs where, when the record changes and who approves it.
This is a practitioner method, not a research finding. These sources explore adjacent ideas about persistent instructions, external memory and durable Markdown-based context.
Official documentation for persistent project instructions and hierarchical memory files.
Research on managing limited model context through tiered external memory.
Research on building evolving project memory from long-running interactions.
An open-source, Markdown-based knowledge system designed to keep AI context portable and inspectable.
These are related precedents rather than identical systems. The Working Context System is deliberately aimed at people who want the operating discipline without adopting a developer workflow.
If the bigger version of this problem in your organisation is grant applications, the same thinking applied to funding knowledge is the core of what Grant Resource Studio does. The method here - deliberate context, curated layers, disciplined recording - scales directly into the funding world, where the knowledge beneath the application is everything.
The home of the funding knowledge approach. grantresourcestudio.com
A free starting point for organisations thinking seriously about funding. starterkit.grantresourcestudio.com
See the approach applied in practice, in a real organisation with a real funding knowledge base, and what changed as a result. casestudy.grantresourcestudio.com
Stop re-explaining yourself to AI