# Custom instructions > The same correction gets retyped at the start of every conversation. - Canonical: https://patterns.konigi.com/ai-assistants/custom-instructions - Group: Memory and context - Level: implementation - Status: published - Updated: September 12, 2026 - Also called: system prompt, preferences, style guide --- ## Problem Every conversation opens with the same three sentences. Write in British English. Do not use bullet points. I am a designer, not an engineer. Typing them again is a tax on every single session, and forgetting to type them produces an answer that has to be thrown away. ## Solution A persistent block of text the viewer writes, prepended to every conversation. The distinction from memory is worth holding firmly: these are declared rather than inferred. The viewer wrote them, knows they exist, and can change them. Memory is the system's guess about them, and confusing the two in one interface makes both harder to reason about. The real design problem isn't the text field. It's that instructions written once become invisible and keep working. Six months later an answer is strangely formal, or keeps producing tables, and the cause is a sentence written in February that the viewer has forgotten writing. HAX guideline 17 asks for global controls over what the system does, and the control is only real if the viewer can find the thing that's currently in force. Two cheap mechanisms fix most of that. The first is a visible indicator on the conversation showing that custom instructions are active, with a click to see them. The second is a date: showing when each instruction was written turns an invisible standing order into something a person can audit. Scope is the second decision. One global block is simple and wrong for anyone who uses the product in more than one role, because instructions for writing code are actively harmful when drafting an email. Per-project or per-workspace instructions, layered over a small global set, matches how people actually work. Layering has to resolve predictably, and the resolution order should be stated rather than discovered. The field also needs honesty about its limits. Instructions are advisory, not binding. A model will drift from them over a long conversation, weight them against the immediate request, and occasionally ignore them outright. An interface that presents the box as a settings panel implies a determinism the mechanism doesn't have, and the resulting complaint is that the product ignores its own settings. Framing them as standing guidance is more accurate and sets a recoverable expectation. Length works against the viewer in a way nobody warns them about. A long instruction block consumes context on every turn and dilutes itself, so the twentieth rule weakens the first nineteen. A visible character budget does more good here than most affordances in this pattern. ## Use when Someone uses the assistant repeatedly with stable preferences that are cheap to state and expensive to repeat. ## Don't use when Use is occasional or the account is shared. Instructions written by one person on a shared login silently reshape everyone else's answers, and the people affected have no idea the block exists. ## Trade-offs Standing instructions remove repetition and make behaviour harder to debug, since the prompt on screen is no longer the whole input. They also compound with memory: an inferred preference and a declared one can contradict, and few products say which wins. Per-project scoping is more useful and adds a resolution order people have to learn. Every instruction spends context on every turn forever. Against a long conversation that's a real cost, and a silent one. ## Checklist - Can the viewer tell from a conversation that instructions are active? - Is the text reachable in one click from where it takes effect? - Is the date each instruction was written visible? - Do global and project instructions layer in a stated order? - Is there a budget or a warning as the block grows? - Does the interface promise determinism it cannot deliver? - What happens when an instruction conflicts with a stored memory? - Can instructions be turned off for one conversation without deleting them? - On a shared account, is it clear whose instructions are in force? - Are the instructions included when a conversation is shared or exported? ## Compare **ChatGPT** keeps a global instruction block and adds per-project instructions above it, so the layering is explicit in the interface rather than implied. **Claude** attaches the equivalent to projects, so the natural unit is a body of work rather than the account. That fits anyone who switches between roles. **Gemini** leans toward inferring preferences from past chats instead of asking for them, trading the audit trail for less setup. **Notion** puts the equivalent in the workspace as written documentation the assistant reads, so the standing instructions are also a thing colleagues can see and edit. ## Related Memory chip is the inferred counterpart and the one this gets confused with. Scoped context determines which layer of instructions applies. Conversation history is where instructions quietly shaped every past answer. First-run state is where the existence of this feature should be introduced. Refusal is what an over-restrictive instruction block starts producing. ## Related patterns - [Memory chip](https://patterns.konigi.com/ai-assistants/memory-chip) — The assistant knows something about the viewer that the viewer never agreed to in this conversation. - [Scoped context](https://patterns.konigi.com/ai-assistants/scoped-context) — The assistant sits inside a product full of data and the viewer cannot tell how much of it is in scope. - [Conversation history](https://patterns.konigi.com/ai-assistants/conversation-history) — The useful exchange was three days ago and the viewer remembers one word from it. - [First-run state](https://patterns.konigi.com/ai-assistants/first-run-state) — The most common screen in the product is an empty box, and it has to teach without running a tour. - [Refusal](https://patterns.konigi.com/ai-assistants/refusal) — The assistant will not do the thing, and the viewer needs to know whether to rephrase or give up. ## Sources - [Microsoft HAX Toolkit, Guideline 17, Provide global controls](https://www.microsoft.com/en-us/haxtoolkit/guideline/provide-global-controls/) - [Microsoft HAX Toolkit, Guideline 13, Learn from user behavior](https://www.microsoft.com/en-us/haxtoolkit/guideline/learn-from-user-behavior/) - [Google PAIR, Feedback and Control](https://pair.withgoogle.com/chapter/feedback-controls/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.