--- title: "How to Turn ChatGPT Into a Work System" description: "Most people improve their prompts. The bigger win is structure: a small standing instruction, one project per thing, and knowledge in files you can read yourself." author: "Matthias Meyer" published: 2026-09-18 updated: 2026-09-18 language: en tags: ["chatgpt", "ki-workflow", "produktivitaet", "wissensmanagement", "custom-instructions", "ai-automation"] canonical: "https://studiomeyer.io/en/blog/chatgpt-arbeitssystem" markdown_versions: ["https://studiomeyer.io/de/blog/chatgpt-arbeitssystem.md", "https://studiomeyer.io/en/blog/chatgpt-arbeitssystem.md", "https://studiomeyer.io/es/blog/chatgpt-arbeitssystem.md"] publisher: "StudioMeyer, https://studiomeyer.io (llms.txt: https://studiomeyer.io/llms.txt)" --- # How to Turn ChatGPT Into a Work System The answers are good. That is rarely the problem. The problem is that every new conversation starts from nothing, and you explain yourself again. So you do the obvious thing. You write down everything important in the custom instructions, the field that travels with every conversation. Your role, your company, your tone, your clients, the things it got wrong last week. The field fills up. And somewhere along the way the answers get worse, not better, and it is hard to say exactly when that happened. What follows is the other approach. Not better prompts, but a place for everything, so the assistant pulls what a task actually needs instead of carrying all of it all of the time. ## A Chat Is Not a System A chat is one conversation. A system is what stays when the conversation is closed. The difference shows up in a small, ordinary test. Ask the same recurring task twice, four weeks apart, and compare. If the second answer is worse, or simply different in ways nobody decided, then nothing was ever built. The knowledge lived in a chat window, and chat windows are not storage. Building a system means answering three questions once: how do we work, what are we working on, and what have we learned along the way. Each one belongs somewhere different. Almost all of the trouble comes from putting all three in the same place. ## The Standing Instruction Is the Most Expensive Space You Have Custom instructions apply to every conversation you have, immediately, including the ones already open. That is what makes them useful and that is what makes them dangerous. Everything in there is paid for in every single chat, whether the current task needs it or not. So the standing instruction should answer exactly one question: how do we work together. How direct you want answers. Whether you want to be asked or told. What to do when something is uncertain. When to push back. Whether you want the reasoning or just the result. What does not belong there: your price list, your client names, your project status, your product details. Not because it is secret, but because it is specific. A price list in the standing instruction is read during a task that has nothing to do with prices, and it goes stale without anyone noticing, because nobody rereads a field they wrote four months ago. A good test: if a sentence would be equally true for a task you will never do, it belongs somewhere else. ## One Project per Thing, Not per Tool Projects in ChatGPT hold chats, files and their own instructions in one place, so you do not restate the background every time you open a new conversation. The useful part is the separation. With project-only memory, conversations inside a project can reference other conversations in that same project, but not the ones outside it, and nothing outside can see in. That is not a small convenience. That is the difference between an assistant that keeps your two businesses apart and one that quietly mixes them. The mistake worth avoiding is cutting projects by tool or by month. One project for writing, one for research, one for September. Those boundaries do not match how work actually arrives. Cut by subject instead: one client, one business, one product, one recurring job. When a task starts, the right project is obvious, and everything irrelevant stays closed. ## Knowledge Goes in Files, Not in Instructions A project takes files. That is where the actual knowledge belongs, and it is worth being deliberate about how it is split. One file per subject, not one file for everything. How you position your business. What your brand sounds like. What you offer. How a particular recurring job gets done. Small files with obvious names beat one long document, because the assistant can be pointed at the right one, and because you can fix one without touching the others. The reason is boring and decisive: the file you fix in passing stays true, and the file you have to rebuild does not. Knowledge that is annoying to correct becomes wrong knowledge. ## Loading Everything Is Not the Same as Knowing Everything This is the principle underneath all of it. Available context is not relevant context. An assistant with access to your entire business is not more capable than one that opens the two files a task needs. It is less capable, because everything it reads competes for attention with everything else. A text for your homepage needs your positioning and your tone. It does not need last year's invoices, your client list, and a campaign from two summers ago. In practice this means naming the thing when you start. Not a ritual, just a sentence: we are working on this client, this product, this job. The default state is that nothing specific is loaded, and that default is correct. ## Write Down What It Learns, Where You Can Read It Over months, the useful part is not what the assistant knows about the world. It is what it knows about your work. The decision you made and why. The assumption that turned out wrong. The preference that keeps coming back. The approach that failed. Keep that in a file you can open. Four short files per subject work well: decisions, corrections, preferences, failures. One line each, dated, in the words you would actually search for later. Written at the end of a task, and only when something would genuinely change next time. The discipline that matters is restraint. A log that grows after every task is unusable within weeks. If nothing came up, nothing gets written. And when a file entry and a current fact disagree, the current fact wins and the entry is history, not a contradiction to resolve. ## The Built-In Memory Is a Second Source, Never the Truth ChatGPT has its own memory: things you asked it to remember, plus impressions gathered from earlier chats. It curates that in the background, updating entries as time moves past them, and you can switch it off, delete single items, use a temporary chat, or look at which memories shaped a given answer. Useful, and not something to build on. You cannot query it on demand, you cannot scope it to one subject, and you did not decide what went in. Treat it the way you would treat any source you do not control: a helpful addition, never the thing your work stands on. The honest test is whether your setup still works with memory switched off. If it does not, the memory is not helping you, it is holding something that should have been written down. This is also where a promise gets made too easily. Structure makes good answers more likely. It does not make wrong answers impossible, and anyone who tells you otherwise is selling something. ## Start With a Single Subject Not with the whole build, but with the subject you work on most often. Make the project. Put in three or four short files: what this is, how it sounds, what matters. Cut your standing instruction down to how you want to be worked with, and move everything factual into the project where it belongs. Then run one real task and watch what it opens. The change you notice is not that the answers get smarter. It is that you stop explaining yourself. The work moves from writing prompts to filing things in the right place, and filing is a thing that stays done. ## Read more, Setting up AI tools - [Ahrefs MCP Server: Setup for Claude, Codex and the Rest](https://studiomeyer.io/en/blog/ahrefs-mcp-server-setup.md) - [MCP stdio vs HTTP: Where It Stands After the 2026-07-28 Revision](https://studiomeyer.io/en/blog/mcp-stdio-vs-http.md) - [MCP Explained: The USB-C Moment for AI](https://studiomeyer.io/en/blog/what-is-mcp-explained.md) - [Claude Code for SMBs: 6 Terms to Know, Setup in 30 Minutes](https://studiomeyer.io/en/blog/claude-code-selber-einrichten.md)