Two similar words name two different things. The prompt is a text: the one the model receives, with your instructions, the context, examples and the request itself. Prompting is a practice: writing that text and, more broadly, choosing everything the model reads before it answers. A disappointing result rarely comes from a missing magic formula. It almost always comes from information a colleague would have had and the model did not.
From the prompt to context engineering
An LLM (large language model) knows about your task only what sits in its context window at the time of the request. That text does not come from you alone. The tool's vendor puts its own instructions there. Your organization may add its own. Then come a document or a search result, then your message. Writing a good request still matters. But the job has grown: deciding what goes into the window, what gets fetched when it is needed, and what comes out. Technical teams call this work context engineering. In September 2025, an Anthropic engineering post summed it up as finding the smallest set of useful information that makes the right result most likely.
Key concept
The prompt is the text the model receives. Prompting is the practice of building it: clear instructions, the reason behind them, examples, what counts as done, each instruction at the right level (permanent, conversation, message), and only what the task needs in the window. A good prompt is checked against real cases; it is not guessed.
Principles that last
New models arrive every few months, and each vendor publishes advice for its own models. The principles below, however, appear as of October 2026 in the official guides of several vendors.
Be clear and direct
Anthropic suggests thinking of the model as a brilliant new employee who lacks context on how you work. Its test: show your prompt to a colleague who doesn't know the task. If they are lost, the model will be too. Mistral advises writing for someone with no prior context. OpenAI compares the model to a junior coworker who does best with explicit instructions. Google asks for "clear and specific" instructions. Say what you want, for whom, in what form and under which constraints.
Say why
An instruction that comes with its reason is applied better, and the model can extend it to cases you did not foresee. Anthropic gives this example: "never use ellipses" works less well than "your response will be read aloud by a text-to-speech engine, which cannot pronounce ellipses." Google writes that context helps the model understand the constraints of the request. Microsoft makes context one of the four parts of a request to Copilot: why you need it, and who is involved.
Show examples
A few examples (few-shot) set a tone or a format better than a long description. Anthropic recommends three to five, close to your real cases, varied, and kept apart from the instructions. But the model also copies what you did not mean to show. Google warns that with too many examples, the model sticks too closely to their form. OpenAI advises trying without examples first for its reasoning models.
Structure the text
When a prompt mixes instructions, documents, examples and a request, separate each part: headings, or tags such as <context> and <request>. Anthropic, OpenAI, Google and Mistral all recommend this separation. Google adds that you should pick one format and stick to it. For a long document, Anthropic and Google advise putting the document first and the question at the end.
Describe the result, not how to think
A good brief fits in seven lines: the goal, the context, the constraints, the tools, what counts as done, the check and when to stop. What recent models lack is your definition of the result.
Recent models can plan their own work. What they lack is your definition of the result. According to OpenAI's guide for its latest models, you often no longer need to prescribe every step. The guide asks instead for the goal, the context, the constraints, the evidence required, the success criteria and the format. Google considers it generally unnecessary to have the model spell out its reasoning steps in the response. Microsoft sums up a good request to Copilot in four parts: goal, context, sources, expectations. How much the model thinks is set separately: that is reasoning effort.
A good brief fits in seven lines:
- The goal. What you want, and for whom.
- The context. What a colleague would need to know: the situation, what has been tried, the documents to read.
- The constraints. Tone, length, allowed sources, what must not be changed.
- The tools. What the model may read or do, and what needs your approval.
- What counts as done. The expected deliverable, in which format.
- The check. How the result will be verified: figures cross-checked, a source cited, a test that passes.
- When to stop. What should bring the model back to you rather than carry on.
Be specific instead of vaguely forbidding
"Avoid jargon" or "be more professional" leave the model guessing. Anthropic recommends saying what to do rather than what to avoid, and notes that a vague instruction such as "avoid a generic style" often swaps one default for another. Name what you want gone instead. Mistral asks you to avoid blurry phrases such as "make it better" and to say exactly what you want. Microsoft advises writing down what the assistant should do when it lacks information or when a request falls outside its role.
Test and iterate
A prompt is judged on real cases, not on an impression. OpenAI recommends rerunning the tests every time a prompt is published, and lists "it seems like it's working" among the mistakes to avoid. Microsoft advises testing with realistic requests and adversarial ones. Google and Mistral point out that writing a prompt takes several rounds. The page Evaluations (evals) explains how to build those test cases.
Three levels of instructions
Not all instructions live in the same place. On every request, an AI assistant reads instructions set at three levels.
The permanent level. These instructions apply to every conversation, without being repeated. They are the instructions of your account or organization, those of a project, a product's system prompt, an instruction file an agent reads, and skills, which load only when a task calls for them. This is where what doesn't change goes: who you are, the brand's tone, company rules, a project's conventions.
The conversation. At the start of an exchange, the brief sets the task at hand: the case, the client, the deadline, the documents to read. It holds for that conversation, and that conversation only.
The message. Each request specifies the next step: "draft section 3," "shorten this paragraph."
Take a sales team that uses an AI assistant. At the organization level: the company's tone, the commitments never to make in writing. In an "RFPs" project: the response template and three winning responses. In a conversation: this week's RFP, its client and its deadline. In a message: "redo the pricing section with the agreed discount." A development team does the same with an instruction file in its code repository: the test commands, the conventions, the folders not to touch.
What does not belong at the permanent level
Anything that changes often: today's client, a price, a date, the current project. Outdated information in permanent instructions keeps shaping every answer, unseen. A rule that allows no exception does not belong there either: the model reads these instructions as context, not as an enforced rule. The harness: everything around the model explains where such rules go.
How the levels combine
At the organization level: the company's tone and the commitments never to make in writing. These instructions apply to every conversation.
Levels do not replace each other: they add up. The tool assembles them and sends them to the model together. When they conflict, the product decides which one wins. As of October 2026, at Anthropic, organization instructions take precedence over each person's own. In ChatGPT, a project's instructions override custom instructions inside that project. On GitHub.com, Copilot's personal instructions come before the repository's, which come before the organization's. And Claude Code's documentation warns that if two files conflict, the model may follow either one. The safest course is not to let two levels contradict each other.
Why the permanent level should stay short
Permanent instructions are read again on every request. They take up room in the context window and are paid for in tokens (fragments of text, often pieces of words) each time. GitHub asks for short, self-contained instructions, precisely because they go with every message. As of October 2026, Anthropic advises keeping each CLAUDE.md file under 200 lines: beyond that, it uses up context and is followed less well. Microsoft notes that an overly long system prompt leaves less room for users' requests. Keep at the permanent level what is needed almost every time, and put the rest in a skill or a document the tool fetches when needed.
Who offers what, as of October 2026
- Anthropic. In Claude: profile instructions for all your conversations, project instructions on paid plans, and, on Team and Enterprise plans, organization instructions of up to 3,000 characters, added to every message from every member. Claude Code reads
CLAUDE.mdfiles at several levels: organization, user, project. - OpenAI. In ChatGPT: custom instructions for all conversations, project instructions and, on the Enterprise plan, workspace-wide instructions. Codex reads
AGENTS.mdfiles, a global one and those in the repository; the one closest to the working folder wins. - Google. In the Gemini app: your instructions for Gemini (personal accounts), Gems and notebooks. Gemini in Google Workspace has its own, separate instructions. Gemini CLI reads
GEMINI.mdfiles and sends them with every request. - Microsoft. Microsoft Copilot offers custom instructions, in preview, which administrators can turn off. Copilot notebooks have their own instructions, and Copilot Studio gives each agent instructions. GitHub Copilot accepts personal, repository and organization instructions.
What goes into the window, what comes out
Pixel François shows what goes into the context window: the brief, the rules and the documents the task needs, not the whole document base. An agent can keep a file path and open the content only when needed. Then old tool results and abandoned leads come out, and the history is summarized: compaction frees up room.
Context engineering asks three questions on every request.
What should go in? The brief, the rules that apply, the documents the task needs. Not the whole document base: Google advises against sending the model tokens it doesn't need.
What should be fetched? What is too large or changes too often to be placed in advance gets looked up at question time. That is the idea behind RAG. An agent can also keep plain references (a file path, a link) and open the content only when needed, an approach Anthropic describes for its agents.
What should come out? Old tool results, abandoned leads, outdated details. OpenAI advises keeping the agent anchored to the user's latest goal without dragging stale details along. When the window fills up, summarizing the history (compaction) frees up room. A conversation that runs too long degrades: it is often better to start a fresh one with an up-to-date brief.
What it means for you
For founders
Write down once, at the permanent level, what you repeat in every conversation: your offering, your typical clients, your tone, what you never promise. Keep it short and reread it whenever your offering changes. For a one-off task, a seven-line brief will save you more time than ten follow-ups.
For product managers
In an AI feature, the prompt is part of the spec. Write into it the goal, the constraints, what counts as done and what the assistant does when it lacks information. Decide what comes from the product, what users can set and what is fetched at question time. Measure every change on test cases before you ship it.
For tech leads
Version the system prompt and instruction files like code, with review. Separate instructions, documents and user input with tags, and treat that input as data, not as commands. Keep instruction files short, and move rare procedures into skills. Rerun your evals when you change models: an instruction that helped the old one can hurt the new one.
For business leaders
Organization instructions reach every conversation of every employee. Name who writes them, who reviews them and who updates them, as you would for an internal policy. Keep stable rules there and let teams add their own projects. Before writing a mandatory rule, ask whether it should become a setting or a check in the tool instead.
The classic mistake
fAIling RULE X
The trap: One mega-prompt to rule them all
A single, endless prompt, written once and for all, looks complete. Yet it mixes permanent rules with today's case, it is read and billed on every request, and its instructions contradict each other without anyone noticing. Put each instruction at its own level, keep the permanent part short, and improve the whole through small, tested changes.
Read rule X in the manifestoTry it
Now. Open the permanent instructions of the assistant you use most: account, project or organization. Sort each line: it is needed almost every time, it is needed for one project only, or it is out of date. Move the second kind into a project and delete the third.
This week. For a real task, write a seven-line brief: goal, context, constraints, tools, what counts as done, check, when to stop. Give it to the assistant, then compare the result with what your usual request produces. Note what changed.
Around this topic
Go deeperModel-specific tips, as of October 2026
Each vendor also publishes advice for a specific model, and that advice ages with it. As of October 2026, Anthropic's guide for Claude Opus 5.5 gives four examples. Reasoning effort, rather than a line such as "think carefully," sets how much the model thinks. On a loosely specified task that spans several apps, asking the model to look through the sources before acting improves its results. In an agent loop, a message without a tool call is a report, not proof that the task is done. And text the user pasted in is best wrapped in tags, so that the model does not follow the instructions it contains. Reread such tips whenever you change models: what helped yesterday may be useless tomorrow.
Go deeperShould you still write “you are an expert”?
Giving the model a role still helps set a tone and a point of view: Anthropic notes that a single role sentence in the system prompt already changes its behavior. But a role replaces neither the context nor the definition of the result. "You are a seasoned lawyer" does not tell the model which contract to review, for whom, or what to flag.
What to do with it
Write down once, at the permanent level, what you repeat in every conversation, and keep it short.
Version the system prompt and instruction files like code, with review, and name who writes and updates the organization's instructions.
Rerun your test cases whenever you change the prompt or the model: an instruction that helped the old model can hurt the new one.