You typed two percent of the prompt

Yesterday one of our members asked the group a simple question: did I have any good prompting guides parked, or X accounts I trust on prompting, because he's always trying to get better at it.

I started typing an answer and realized it was going to be an article. Here's what I actually wrote in the chat, typos and all:

prompting has changed SIGNIFICANTLY in the last year... What hes referring to (I believe) is the ability to provide the correct context at the correct time to the model

prompting from the chat interface has become a bit less important in my mind... still important, but less so than the other pieces that get assembled along with your chat message that comprise the full prompt

Then I added that the models don't even care about typos anymore, which works out for me, because I'm the typo king.

That was a gut answer, so this morning I checked it against my own setup. I had my agent measure the last two weeks of my working sessions: 229 sessions, a little over a thousand messages from me. Everything I typed added up to about 2 percent of the text the model read. My typical message was 233 characters, roughly two sentences. The other 98 percent was assembled around my message: the agent's standing instructions and memory, the files it opened, the pages it searched, the output of every command it ran, and the conversation up to that point.

Two percent. And most prompting advice on the internet is still about that two percent.

The problem

Most people still treat prompting as a writing skill. Find the magic phrasing, save it in a prompt library, paste it when you need it. Pretend to be an expert. Take a deep breath. Think step by step. Put the important parts in capital letters so it listens.

In 2023 some of that helped. Models were worse at figuring out what you meant, so you compensated with wording. The whole prompt usually was the message you typed, so the message was where the leverage was.

Two things changed.

The models got good at reading intent. A study that attacked GPT-4 with deliberately chosen typos found it barely moved: "only 3.5% on GSM8K" (a grade-school math benchmark), a result the authors called "negligible." Small models in the same study dropped up to 13.6 percent. Today's frontier models are well past GPT-4. Anthropic now writes plainly in its engineering blog that "Claude can interpret the user's intent to get to the right answer." Your sloppy two sentences are fine.

The prompt stopped being your message. Same Anthropic post, published in July by the team that builds Claude Code: "when you send a message to Claude, the prompt is only a small part of the context it gets. Much of your context is assembled from your system prompt, Skills, CLAUDE.md files, memory, and other sources." The industry has settled on a name for getting that assembly right. It's called context engineering. Anthropic's definition: find "the smallest possible set of high-signal tokens" that gets the result you want.

Here's the part that should get your attention. The old tricks don't just do nothing now. Some of them hurt.

• Anthropic's current prompting docs say newer models "may now overtrigger" on aggressive language like "CRITICAL: You MUST use this tool." The fix is to dial it back to "Use this tool when..."
• OpenAI says the same about GPT-6 Astra. If you wrote hard boundaries to keep older models in line, "Astra could take it too seriously and may stop work where you'd actually be happy for it to continue." And: "overly specific guidance can now hinder results where it previously helped."
• The Opus 5.5 guide, which came out with the model yesterday, tells developers to delete "think carefully before answering" lines from chat setups. In Anthropic's testing, removing that line made replies start sooner "with no clear decline in the quality of the reply."
• Anthropic cut more than 80 percent of Claude Code's own system prompt for the Claude 5 models, "with no measurable loss on our coding evaluations." Their explanation: "we were overconstraining Claude."

So the skill moved. A year ago it was wording the message. Now it's deciding what the model sees around the message, when it sees it, and what shape it's in.

The shape of the data: what the Jev week proved

I told the group the "multi-day Jev hype" proved this, so here's the receipt.

Jev is the new model from TypeSafe. It doesn't write. You hand it a blob of data and a question with fixed answers, and it hands back a probability in well under a second, for a fraction of a cent. Launch week, the "193x faster, 444x cheaper" headline showed up in eight posts totalling 901,691 views. None of the eight mentioned the caveats TypeSafe had attached to its own benchmark.

Here's what TypeSafe's own documentation actually says about its model. The page is called "jaggedness", and every operator should read it, because it's the most honest description of a model I've seen from a vendor:

• "answers the question you wrote, not the one you meant."
• Ask about colors using hex codes and it does worse than if you use the English color names. Same information, different shape.
• "Jev suffers from context rot, so unrelated material in the state costs you accuracy." Extra data you didn't need makes it worse.
• Ask "is this a refund?" and "is this not a refund?" as two separate questions, and the answers add up to 1.19. They should add up to 1. How you frame the question changes the answer.

Jev is an extreme case because it can't talk back. There's no paragraph where it says "I think you meant..." But every model has a softer version of the same behavior. A Chroma study of 18 frontier models found performance drops as the input gets longer, well before you hit the context limit. Researchers have shown formatting changes that keep the meaning identical can swing accuracy by up to 76 points on an open model. Bigger models are more robust to this, but none of them are immune.

One of our members is using Jev to check about a thousand resale leads, confirming the retailer's product actually matches the Amazon listing. He told the group he'd been changing the formatting and the instructions while also switching sample leads, so he couldn't tell what had actually helped. My answer that night was the whole lesson in two lines: anchor your prompt and your input packet, then literally change one word, one value, one thing at a time, and compare against answers you already know are right. If the input isn't the same every time, you have no way to know whether the evaluation was trustworthy.

That discipline has nothing to do with clever wording. It's about how the data is packaged.

What the model actually reads

When you hit enter in a modern AI tool, the model gets a stack. Roughly, from bottom to top:

1. The system prompt. The vendor's instructions for that product. You mostly don't control this in a chat app. You do if you build your own agent.
2. Standing instructions. Custom instructions, project instructions, a context card, CLAUDE.md or AGENTS.md files, skills. Anything that loads every time without you pasting it.
3. Memory. What the tool has remembered about you across chats.
4. Tools. Every connector and tool you've switched on comes with a description the model reads, whether it uses the tool or not. Anthropic measured a five-server setup at 58 tools and about 55,000 tokens "before the conversation even starts." Loading tools only when needed raised one model's accuracy from 49 to 74 percent on their tests.
5. Material. Files, pasted emails, spreadsheets, search results, tool output. In my sessions this was by far the biggest slice.
6. History. Everything earlier in the conversation.
7. Your message. The part everyone optimizes.

Each layer can help or hurt. The failures I see most often come from the layers people never look at.

Where the context comes from

Look at layer 5 again. Most operators fill it by hand: the price sheet, the customer's history, the notes from last month's call, the reason you stopped offering that service. You copy and paste it, or you retype it from memory, every time.

The better pattern has a name in Anthropic's engineering guidance: "just in time" context. Instead of loading everything up front, the agent keeps "lightweight identifiers (file paths, stored queries, web links, etc.)" and uses them "to dynamically load data into context at runtime." In plain English, the agent knows where your things live and goes to get the right piece when the job needs it. That fetch is part of your prompt now. You just didn't have to type it.

That makes where you keep your business information a prompting decision. There are roughly four kinds of source, simplest first:

• A folder of markdown files. Plain text notes with headings: your SOPs, your pricing rules, a page per customer or per job. Every AI tool can read them, they cost nothing, and they'll outlive whatever app is popular this year. Obsidian is the common way to keep one. It's a notes app sitting on top of an ordinary folder of markdown, and there are connectors that let an agent search and read the whole vault.
• Structured files. Spreadsheets, CSVs, JSON. Good for anything with rows: price lists, inventory, leads. The agent can pull the three rows the question needs instead of reading all three thousand.
• Databases. The same idea at a bigger scale. The agent writes a query and gets back just the answer. Anthropic describes Claude Code working this way on large databases, analyzing big data "without ever loading the full data objects into context."
• The systems you already run. Email, calendar, CRM, accounting, your storefront. Connectors let the agent look there directly. This is the source of the Opus 5.5 advice to explore first: the rule that matters is often sitting in an email thread nobody pointed the agent at.

Then there's a layer that sits on top of all of that: a context layer, sometimes called a second brain or a company brain. I run one called GBrain, an open-source project from Garry Tan at Y Combinator. It's a searchable memory of my businesses: people, companies, projects, meetings, decisions, and my own ideas in my own words. It's a little over thirteen thousand pages at this point. My agent checks it before answering anything where history could matter, and pulls back the handful of pages that are relevant, so I don't paste anything. When I mention a customer, it already knows the job history. When I ask about a decision, it finds the day I made it and why. This article started that way. The first things my agent did were pull my exact comments from our Discord archive and search the brain for everything I'd said about prompting before. It found notes on the subject going back months.

I'm not going to squeeze this into one section. A good context layer can be absolutely transformative. It changed how I work more than any single model upgrade has. It's also real setup and real upkeep, and bad information in a brain comes back out sounding confident. It deserves its own treatment, and it's getting one: we're starting a series on context layers, and another on how to store your business data so an agent can actually use it. For now I just want it on your map. A well organized folder the agent can reach will beat a clever prompt most days.

How to identify it

You're still prompting like it's 2024 if any of these sound familiar:

• You re-explain your business at the top of every chat. That belongs in layer 2, written once.
• You have a saved "mega prompt" with capital letters in it. CRITICAL, NEVER, ALWAYS, YOU MUST. On current models that tends to overcorrect, not steer.
• Your standing instructions contradict each other. Anthropic found exactly this in its own internal transcripts: "leave documentation as appropriate" in one place, "DO NOT add comments" in another, and the user saying something else entirely. The model has to spend effort sorting out the conflict before it can do the work.
• You paste the whole thing. The full 40-page PDF, the entire email thread, the spreadsheet with 30 columns when the question needs four.
• Every connector is switched on, all the time, for every chat.
• The chat has been going for three days and the answers are getting stranger.
• The answer lives in your head or a pile of PDFs. If the agent can't reach your price list, customer history, or SOPs on its own, you are the context layer, and you'll be pasting forever.
• When the answer is wrong, you rephrase the question. Usually the fix is in what you gave it, not how you asked.
• Your repeated job gets a slightly different input each time. Different columns, different order, different wording. Then you can't tell a bad answer from a bad input.

How to fix it

Five rules. None of them involve finding better adjectives.

1. Write the standing stuff down once, and keep it short. Your business, your role, your rules, the facts that must stay true. I gave you a template for this in August, the context card, and that was me "kinda sorta" writing this article the first time. Put it wherever your tool loads it automatically: custom instructions, a project, a CLAUDE.md or AGENTS.md file. Short beats complete. Anthropic's current advice for these files is to skip anything the model can figure out on its own and spend the words on the gotchas.

2. Explain why instead of shouting. "Never use abbreviations" works worse than "this gets read aloud by a text-to-speech tool, so spell things out." Anthropic's own example makes this exact point: give the reason, and the model generalizes from it. A reason covers cases your rule never thought of. Capital letters don't.

3. Shape the data before you hand it over. Send only what the question needs. Use plain words over codes (the Jev color lesson). Do math and date comparisons in a spreadsheet or in code, not in the model. Put long documents first and your question last. When you paste someone else's text (a customer email, a web page), label it as pasted so the model doesn't treat instructions buried in it as yours. Opus 5.5's guide now has a specific pattern for exactly this.

4. Load things when they're needed, not all up front. The industry term is progressive disclosure. It starts with keeping your information somewhere the agent can reach on its own (the folder, the spreadsheet, the database, the brain from the section above), so it can fetch the right piece instead of you pasting all of it. In practice: turn on the connectors a job needs, not all of them. Start a fresh chat for a new job instead of dragging three days of history along. Keep reference material in files the model can open when relevant, instead of pasting everything in at the start. And for jobs that span your email, docs and CRM, tell it to look around first. Anthropic found that one sentence ("explore broadly... including ones the task does not explicitly mention") got noticeably more multi-app tasks done correctly, because the rule that mattered was often sitting in an old email thread the request never mentioned.

5. Anchor anything you repeat. If a job runs more than a few times (scoring leads, sorting tickets, drafting follow-ups), freeze the input format and the instructions. Keep a handful of cases where you already know the right answer. Change one thing at a time and check it against those. This is how you get a cheap model like Jev to be useful, and it works just as well on the expensive ones.

And the message you type? Still worth thirty seconds. Say what you want, what done looks like, and why. Skip the costume, the capital letters, and the proofreading.

Where I've been burned

Honest ledger, because I don't want this to read like I got it all right.

History poisoned a fresh model. In July I brought a new model into a multi-day engineering session and it refused before reading a word of what I actually asked. The request was harmless. But the conversation before it was days of security-hardening talk about races, spoofing, and attack surfaces, all defensive and all legitimate. Handed that whole history, the new model pattern-matched it as something sketchier and declined. The fix wasn't rewording the request. It was a clean session with only the documents it needed.

Instructions the system couldn't see. During an audit of my own agent setup, we found 59 skills described in prose inside an instruction file. The routing only recognized a structured table. So all 59 were invisible, and had been for a while. I had written the instructions. The system could not read them.

My own bloated config. My agent's standing instructions grew the way everyone's do: every time something went wrong, I added a paragraph. Every one of those paragraphs loads into every session and takes up room before any work starts. The best fix I've made to that file was collapsing a page of policy into one clear sentence with the reason attached.

The typo king stays the typo king. I type fast and badly, and I'm not changing. The two percent can be messy. The other ninety-eight can't.

Your move

Twenty minutes, this week. Open whichever AI tool you use most.

1. Find your layer 2. Custom instructions, project instructions, your context card, any CLAUDE.md or AGENTS.md. If you don't have one, write the context card from the link above. That's your whole assignment.
2. If you do have one, read it like a stranger. Circle every CAPITAL-LETTER rule, every rule without a reason, and every pair of rules that contradict each other. Rewrite or delete each one.
3. Count your connectors. Switch off every one that the job you do most doesn't use.
4. Pick your most repeated job and freeze its input. Same fields, same order, same wording, every time. Save three examples where you already know the right answer.

If you do step 2 honestly, you'll find at least one instruction you wrote for a model you don't use anymore. I found several.

The playbook: put your context where your harness looks for it

Operators: most of you are running Hermes, OpenClaw, Codex, or Claude Code now. Each one already has an opinion about where context lives, what loads every turn, what loads on demand, and how much it will hold before it quietly cuts something. The worst move is building a parallel "context folder" your harness doesn't know about. The right move is learning the slots your harness already has and filling them on purpose.

Everything below comes from each harness's current docs and, where the docs were unclear, its source code, checked this week. These tools ship changes monthly, so if something below doesn't match what you see, trust the inspection commands in Part 3 over this page.

Part 1: the map

Seven kinds of context, and where each one goes.

Two rules that hold across all four:

• Procedures go in skills, not in the always-loaded files. Every harness now lists skills as a one-line name and description, then reads the full skill only when the job comes up. That's progressive disclosure built in. A pricing procedure in AGENTS.md or CLAUDE.md costs you on every turn, including the turns about payroll. In a skill, it costs one line until it's needed.
• Hard rules don't go in prose at all. "Never send without approval" in a markdown file is a suggestion. Codex has rules, hooks, and sandbox settings. Claude Code has PreToolUse hooks and permissions.deny. OpenClaw has approvals and tool policy, and its own docs say memory "does not enforce policy." Hermes has approval settings and toolset controls. Put the wall in the harness, and use the markdown to explain why the wall is there. (Longtime readers: this is rope or a wall again, applied to context.)

Part 2: the budgets that bite

Every harness caps what it will load. None of them are loud about it when you go over.

The Codex one is the nastiest on the list: the most specific rules, the ones closest to the work, are the first to disappear, and the model never knows they existed.

This isn't theoretical. While my agent was researching this issue, it stepped into the Hermes source folder, whose own developer AGENTS.md is about 32,500 characters. The subfolder cap is 32,000. It loaded with the middle cut out. The team that wrote the limit tripped it.

Part 3: see what's actually loaded

Stop guessing. Every harness now has a way to show you the stack.

My own numbers, so you have something to compare against. Claude Code on my machine, fresh session, before I typed a word: 26,300 tokens loaded. The system prompt was 2,000 of that. The one-line listings for about 60 installed skills were 9,300, more than four times the system prompt. I installed most of those skills once to try them and forgot them. Every session since has paid for them.

Run the command for your harness today and write down the number. That's your baseline.

Part 4: the traps, by harness

Hermes - Using memory as a filing cabinet. Price lists and procedures in MEMORY.md blow the 2,200-character cap fast and ride along on every turn. The rule in Hermes's own source is "skills come first; memory is the narrow exception" for facts that apply to every session. - Writing memory as commands. "Always do X" gets re-read in later sessions as an instruction and can override what you're asking for today. Write it as a fact: "The customer prefers email." - Collisions. Only one project-context type loads. A .hermes.md silently hides your AGENTS.md. /context shows which one won. - Trusting "I'll remember that." If there was no memory tool call, nothing was saved. Check the file.

OpenClaw - Old files on a new build. On current versions TOOLS.md and HEARTBEAT.md are retired and QMD memory is gone. Tool notes now go in a ## Tools section of AGENTS.md. If you're on an older build, update, then run openclaw doctor --fix to migrate. - Business rules in MEMORY.md. They vanish in group chats and sub-agents. Anything that must hold everywhere goes in AGENTS.md. - Profile facts in MEMORY.md instead of USER.md. The docs keep them separate for a reason: USER.md is about you, MEMORY.md is everything else. - Setting a context-engine plugin in config without installing it. OpenClaw quietly falls back to the default engine.

Codex - One giant AGENTS.md. See the 32 KiB rule above. Keep the root file short and point to docs the agent can open. - Business rules in the global file. ~/.codex/AGENTS.md loads in every repo. If you run two businesses, the second one inherits the first one's rules. - Carrying last-generation hand-holding into GPT-6 Astra. "Read these five files before every edit" and capitalized "ask before anything" rules now make it stop early and waste context. OpenAI's own guidance is to audit your files and make each skill's root "a minimal router." - Treating Memories as the rulebook. They're off by default, generated in the background, lag by hours, and inject only a short summary. Rules go in AGENTS.md.

Claude Code - The 600-line CLAUDE.md brain dump. Anthropic's own blog calls the "central repository for every known practice" idea "a common myth." Keep the gotchas; move procedures to skills. - Thinking @imports save space. They load in full at startup. Reorganizing isn't shrinking. Only path-scoped rules, subfolder CLAUDE.md files, and skills load on demand. - Guardrails in prose. CLAUDE.md is delivered as a user message, not a lock. Use hooks and permissions.deny. - Skill sprawl. See my 9,300 tokens above.

Claude or ChatGPT in the browser (Projects). If you aren't in a CLI harness yet, the project instructions field is your always-loaded file and project knowledge is your data. In Claude, the project description is for humans only; Claude never sees it, so rules typed there do nothing.

Part 5: wiring in your data, just in time

This is where the context layer from the free section plugs in. Four patterns, and every harness supports at least three:

1. A skill that runs a script. The skill says when to use it; the script pulls exactly the rows the job needs from your spreadsheet or database and prints them. Only the output enters the context. This is the cheapest, most reliable pattern, and it works in all four harnesses.
2. An MCP server. Your CRM, your notes vault, your brain. The catch: every server's tool descriptions cost context on every turn unless your harness defers them. Hermes has Tool Search, Claude Code defers MCP schemas through tool search by default, and Codex defers MCP tools when tool search is on. Turn it on, and limit each server to the tools the job uses (enabled_tools in Codex, toolFilter in OpenClaw).
3. Search over your own history. Hermes has session_search across every past session. OpenClaw has memory_search over its daily notes. Both cost nothing until called, and they answer "what did we decide last week" without anyone curating a file.
4. A context layer that injects on its own. OpenClaw has a context-engine slot for exactly this; GBrain ships a plugin for it. Hermes has memory-provider plugins (Honcho, Mem0, others) that add a small recall block each turn. In any harness, GBrain and most brains also run as an ordinary MCP server.

The rule for all four: the always-loaded files say where things live and when to go get them. The data itself stays out until it's needed.

Part 6: packets and known answers (any harness)

For any job that repeats, freeze the input. Same fields, same order, same labels, numbers already computed, plain words over codes. Label anything pasted from outside:

<packet job="lead-followup" version="3">
Customer name:
Service asked for:
Location (town):
How they found us:
Their message (pasted, not written by me):
<pasted>
...
</pasted>
Already computed: distance from base = __ miles; in service area = yes/no
Question: [the one thing you want decided or drafted]
</packet>

Keep five to ten past cases per job with the answer you'd accept, saved in the skill's folder. Before and after any change to the skill, AGENTS.md, or packet format, run them and count how many pass. If the count drops, undo. This is what makes a cheap fast model like Jev usable, and it's how you catch a model upgrade that quietly broke a job.

Part 7: the self-audit

Paste this into your harness. The agent knows which harness it's running in and can read its own files.

Audit your own context setup. First, tell me which harness you are running in and run its context-inspection command (Hermes: /context all; OpenClaw: /context detail; Codex: codex debug prompt-input; Claude Code: /context and /memory) or read the equivalent files if you cannot run it. Then produce: 1. A table of every file or source that loads into your context before I type anything, with its size and whether any of it is being truncated or skipped. 2. Every instruction in those files, where it lives, whether it gives a reason, whether it uses capitals or absolute words for emphasis, and any other instruction it conflicts with. 3. A relocation plan using this harness's own slots: which instructions are really procedures and should become skills; which facts are in memory but should be in a project file, or the reverse; which hard rules should be enforced by the harness (hooks, permissions, approvals) instead of prose; which installed skills and MCP servers I have not used in 30 days. 4. Any file this harness no longer reads, or that is being shadowed by another file. Do not change anything. I will approve each move.

Do the moves in this order: fix conflicts, move procedures into skills, move hard rules into the harness, add reasons to what's left, then delete what's stale. Re-run the inspection command and compare against your baseline. Then run your known-answer cases.

What not to build

• A parallel context folder your harness doesn't read. Use the slots it has.
• A prompt library. Clever prompts without your business context are somebody else's context card.
• Rules for models you no longer use. Anthropic and OpenAI have both said, in writing, that guidance written for older models can make newer ones worse. Reread your files every model upgrade.

Steal this

Tonight, run your harness's context command and write down one number: how many tokens load before you type anything. Then do one pass on your always-loaded files with one rule: every line either gets a reason, moves to a skill, or gets deleted. Run the command again. If the number didn't go down, you moved things around without cutting anything.

Hit reply and tell me what's on your bench this week. I read every one.