Organize ChatGPT with Playbooks and Memory

When I work with an AI on a recurring task, I want the next conversation to build on that work. What decisions did we make? How should the task be handled? Where is the current version?

I use a playbook system for this. Brief instructions describe how we collaborate. An index shows which files a task needs. A shared working method sets out how to research, check results and improve our procedures. Task playbooks describe the specific workflows. Memory adds earlier decisions and experiences.

You can build this with an accessible file store. In my current setup, the complete documents live on GitHub, alongside a separate external memory system. What matters is that the AI can actually read the relevant foundations and save results where we can continue working later.

Each part has a different job#

These functions do not each need a separate file. A small project can work with just a few documents. Every piece of information needs a clear place where it is maintained.

Brief instructions lead to the right starting point#

My custom instructions tell the AI to complete tasks thoroughly, check uncertainties and ask questions only when important information is missing. They also tell it to identify the relevant project and read the current foundations.

A simplified example of this starting instruction:

Work proactively, critically and thoroughly. Identify the right context for specialized or recurring tasks. Read the index and shared working method, then only the task files you need. Use available memory selectively and compare it with current files. Save lasting insights within the authorized scope and verify that they were saved. Answer simple general questions directly.

The actual location matters too. “Read my index” is of little use if the AI cannot tell which index you mean or how to access it. The instruction therefore names the entry point or explains how to find it. It does not itself establish a connection to GitHub or a memory service.

The index is a map of the system#

My index gives a short explanation for each relevant file: what it covers, when it is needed, and whether it is current or archived. Larger areas can also include file length and the person or AI responsible.

Suppose I want to rewrite a blog article. The index leads to the writing method, the relevant requirements and the existing version. For research, it leads to the research procedure and existing knowledge. The AI does not need to read every other project along the way.

The task determines the selection. Personal work, businesses and clients remain separate contexts. An available business profile is no reason to use it for a general question.

The shared working method keeps procedures together#

Some rules apply to almost every substantial task: understand the desired result first, check current sources, consider necessary parts of the work and review the outcome. Those rules live once in the shared working method.

It also describes how we handle conflicts. An old memory can be outdated. A new answer from another agent can be wrong. A user preference answers a different question from a factual source. The AI needs to check origin, date and scope when a conflict affects the task.

The method distinguishes discussion, planning and execution. I can share a thought without asking for something to be built. Conversely, the AI should complete a clear task and carry out steps that have already been authorized.

A playbook makes a task repeatable#

A task playbook describes how to handle a particular job. A research playbook might cover the question, appropriate sources, counterevidence and the required report. A blog playbook might cover audience, structure, tone, fact checks and the final review.

A useful playbook contains:

• its purpose and the situations in which it applies;
• required inputs and how to handle missing information;
• the workflow and important decisions;
• checks for completeness and common mistakes;
• factual foundations with sources and review dates;
• confirmed adaptations and its actual state of testing.

The practical instructions come first. Detailed evidence and examples can follow later or live in linked files. An untested working draft remains clearly marked as such.

My playbooks grow out of real work. When a task recurs or a mistake happens repeatedly, we first check whether an existing procedure can be improved. Creating a file for every new keyword would quickly make the system hard to navigate.

What happens during a concrete task#

Take the rewrite of this article. The task is to explain the actual playbook system and change the corresponding blog files.

1. Identify the task: This concerns an existing website article. The requested result includes the text and a change in the repository.
2. Retrieve earlier decisions: Memory provides relevant information about the working architecture and references to its foundations.
3. Read current files: The agent reads the index, working method, relevant repository rules and existing article. It checks whether the memory references still hold.
4. Edit the content: It rewrites the article on that basis and checks specific product claims against current sources.
5. Review the result: Text, translations and metadata must agree. A GitHub change and a live deployment are separate steps.
6. Verify the saved version: The agent reads the changed files again. A lasting decision can be recorded as a short memory entry with a reference.

This is how the parts fit together. The index finds the documents, the playbook supplies the procedure and memory adds relevant history.

Memory connects earlier work to current files#

In my setup, memory means an external StudioMeyer memory service accessed through a separate connection. ChatGPT's built-in memory is a separate system. Depending on the account and settings, it can contribute context from earlier conversations and other available sources; it does not remember every detail. The available controls are described in OpenAI's memory documentation.

My external memory keeps confirmed decisions, lasting preferences, supported experiences and project references short and searchable. A small initial idea can be stored with an idea status. Once it becomes a developed concept, the complete text belongs in the appropriate GitHub area and memory points to it.

For example, a memory entry briefly records the confirmed audience for a project and where its current strategy lives. The repository contains the full strategy, its reasoning and progress. The agent can then find and read the right file.

At the start of a working session, I use a short briefing from the available memory, then search specifically for the context of the task. Briefing suggestions are not new assignments. Even an entry marked as verified needs comparison with current files and information when appropriate.

The rule in this system is that GitHub holds the complete working version, while memory holds short context and references. Documents are not automatically mirrored. Project filters help select information; access permissions and separate storage scopes need their own configuration.

The system improves through checked experience#

When a result misses the mark, we first investigate the cause. Was the wrong context loaded? Was the task unclear? Was a source outdated? Was a step missing from the playbook?

A confirmed improvement goes where it belongs. A changed procedure goes in the playbook. A lasting preference or supported experience can also be summarized in memory. A one-off request initially stays with that task.

New files are read again after saving. Only then is their reference activated in the index. After an interruption, the actual saved state is what counts, so the next session can continue from the unfinished step.

This is what I mean by learning here: traceable changes to the foundations of our work. Whether a change produces better results must be tested in practice.

Optional: bring several AI systems together through GitHub#

Several AI systems can collaborate on these foundations. I also use a private GitHub exchange for that purpose. It holds contributions, handovers and decisions with their origin and status. Each system can read the authorized documents and work with its own tools.

GitHub makes it possible to trace who proposed what and which version was adopted. Another agent's contribution remains material that needs checking. File access alone does not set up automatic runs or synchronize memories.

This collaboration is an extension. To start, one AI, a readable index, a shared working method and a playbook for a real recurring task are enough.

Start with one task and check the workflow#

Choose a task for which you keep explaining the same foundations. Record its workflow and necessary facts. Add the files to a small index and give the AI a clear starting point. You can add memory when access is available and its scope has been established.

Then test in a new conversation: Does the AI find the index? Does it read the relevant files? Does it use earlier decisions in the right context? Does it deliver the complete result and verify an authorized save?

That is how to assess the setup. It should let you build on maintained work using normally worded requests. Actual use shows how well it succeeds.

Sources and scope#

The setup described here is our working method. The roles of the index, playbooks, GitHub and external memory are deliberate procedural choices, not an OpenAI product guarantee. The private working files are explained here as a general workflow.

Product foundations checked on October 1, 2026: ChatGPT Custom Instructions and Memory in ChatGPT. Connections and reading or writing capabilities depend on the actual environment and its permissions.