What is context engineering, and what should I actually write down?
Context engineering is the work of writing down what you know so your AI can use it — your voice, your money boundaries, your sign-off rules, your confidentiality walls, and your definition of done. Those five files are the same whether you work alone or run five hundred people. What changes is not the writing but the agreeing: on your own, you write them in an afternoon and the only goal is that they exist.
Once a handful of people share the work, each file needs a named owner, because the real failure is several people quietly maintaining contradictory versions. Past about a hundred, it becomes governed infrastructure with access rules and review dates.
RSM’s 2026 survey of 1,030 mid-market executives found 97% are satisfied with AI’s business value while only 36% have it embedded in core processes — writing this down is most of what closes that gap.
Want this made concrete for your company? Ask me — or pick one:
Start here
Every article about AI now agrees on the same thing: context is the differentiator. The model is a commodity, your knowledge is not, whoever writes it down wins.
Then they stop. They tell you context matters and leave you looking at an empty folder.
That gap shows up in the numbers. RSM surveyed 1,030 mid-market executives this July and found 97% are satisfied with AI’s business value — but only 36% have it embedded in their core processes. People are happy with AI and still not running on it. The distance between those two figures is almost entirely undone writing.
So this article skips the argument. We have made the case elsewhere for why context is the thing worth keeping. This one is the recipe: the five files, what goes in each, and what changes as the work spreads.
One thing worth saying before the tiers, because it decides whether the rest is useful to you. The variable here is not headcount — it is how many people have to agree. A consultant working alone needs the same five files as a three-hundred-person firm; they are simply faster to write, because only one person has to be right. Everything that gets harder later gets harder for that reason and no other. If you are a professional doing this for your own work, you are not the beginner tier of somebody else’s framework. You are the clean case.
You can finish the first pass on a Monday morning, alone, without buying anything.
What context engineering actually is
Context engineering is the design of everything your AI reads before anyone types a request.
A prompt is what one person asks, once. Context is what the system already knows every time anyone asks anything — your standards, your history, your boundaries, your way of doing things. Prompting is a personal skill that leaves when the person leaves. Context is an asset that stays.
The practical version is less abstract than the phrase suggests. Context engineering is writing things down, in plain language, in files, in a structure that loads the right part at the right moment. That is genuinely most of it. The sophistication is in what you choose to write and who keeps it true — not in the tooling.
Which is why the market’s answer to this keeps missing. Search for how to do this and you get knowledge-management platforms: systems that promise to index the documents you already have and surface insights from them. Those tools are fine. But no tool can tell you what your pricing floor is, or who is allowed to approve an exception, or which client facts must never appear in another client’s room. That is not a retrieval problem. It is a writing-down problem, and it is yours.
The AI Briefing
Tuesdays. 500+ leaders. No hype, just what works.
The five files
This is the core of the whole method, and it does not change with size. Every context layer worth having answers the same five questions. Working alone, they are five short files in one folder. At five hundred people they are five domains with owners and review cycles. Same five questions, same order.
Two notes before you start writing.
Write the counter-examples. For every one of the five, the useful content is at the edges. “We are professional and friendly” tells the model nothing, because every company believes that. “We never use exclamation marks, we never say ‘excited to share’, and we never describe our own work as innovative” is instantly usable. The negative space defines the shape.
If you cannot answer one of the five, that is the finding. Most people find that one or two of these have never actually been decided — usually the money one and the sign-off one. The AI has been guessing at them, and so, quietly, have some of your people. Writing context down is a business exercise that happens to be useful to a machine.
When it’s just you — and up to about 25
If you are a solo owner, an executive doing this for your own work, or a company under twenty-five people, your entire job is to make the thing exist. Not to make it good. Elegance is the enemy here, because elegance is what people use as a reason to wait.
What to write. One folder. Five files, named for the five questions. Plain text or markdown — not a wiki, not a database, not a tool you have to evaluate first. If you are one person, this is genuinely an afternoon. If you are twenty people, it is an afternoon plus two conversations.
Start with how we sound and what “done” looks like, in that order. They produce a visible improvement in the AI’s output within minutes, which matters more than you would think — it is the thing that makes you keep going. Money and confidentiality can come on day two.
Who owns it. You. Not a committee, not “the team.” At this size the correct number of owners is one, and it should be whoever has the most opinions about the work being right. In most small firms that is the founder, which is inconvenient, because the founder is busy. It is still the answer: the context is mostly in your head, so the extraction has to come from you.
How it stays current. A standing note in your own calendar, monthly, fifteen minutes: what did I correct the AI on this month that I am going to have to correct again? Write that down. That single habit is the difference between a folder that compounds and a folder that rots.
How you know it’s working. Open a fresh AI session with no setup and ask it to draft something typical for your business — a client email, a proposal section, a scope note. If the output could have come from any company in your industry, your context isn’t loaded or isn’t specific enough. If it sounds like you on a good day, it’s working.
The failure mode at this tier is not building the wrong thing. It is building nothing while researching the right way to build it.
When more than one person has to agree — roughly 25 to 100
Somewhere around twenty-five people the problem changes character entirely, and most firms do not notice it happening.
Below that line, context is an extraction problem: it is in one head and it needs to get onto a page. Above it, context is an arbitration problem. It is in several heads, those heads disagree, and writing it down forces someone to decide who is right.
This is why shared-context projects stall in a way solo ones never do. It looks like a documentation exercise and it is actually a series of small, slightly political decisions. Sales thinks the discount floor is one number. Finance thinks it’s another. Nobody has been wrong until now, because nobody had to write it in a file that a machine would then apply a thousand times.
Below 25 people, writing context down is extraction. Above it, it’s arbitration — and the reason those projects stall is that nobody wants to be the one who decides whose version is canonical.
What to write. The same five files, now split by function. Sales has its own voice and money file; delivery has its own definition of done; finance has its own confidentiality wall. Plus one thing that did not exist when you were writing alone: a short shared file at the top that everyone’s AI reads, holding only what is true company-wide. Keep it genuinely short. This is the file that becomes a dumping ground if you let it.
You also start needing skills rather than just facts — encoded workflows, not only reference material. “Here is how we scope a project” as a repeatable procedure the AI can follow, not a description of scoping. That is the point where a context layer starts doing work rather than just informing work.
Who owns it. One named owner per domain, and this is the whole ballgame at this tier. Not “the sales team owns the sales context” — a person, by name, whose job description includes it. The most common failure at this stage is several teams each maintaining a private, contradictory version of the company, all of them confident, none of them canonical.
Give the top-level shared file a single owner too, with the authority to say no. Its job is to keep that file small.
How it stays current. A monthly review per domain, and one rule that matters more than the cadence: corrections go back into the file, not just into the chat. When someone fixes the AI’s output, the fix has to land somewhere it will apply next time. Without that, you have a document. With it, you have a system that gets better every time it’s used.
How you know it’s working. Ask two people in different departments to run the same request through their AI and compare. If the answers contradict each other on anything that should be company-wide, your shared file is either too thin or nobody is reading it.
Not sure where you stand?
Take the 90-second AI readiness read — five dimensions, a scored result, and a clear next step.
Take the readiness read →When you have to govern who sees what — past 100
Past a hundred people, the five files still exist, but they stop being documents and start being infrastructure. Three things become non-optional that you could safely ignore at smaller sizes.
Access. Not everyone should read everything. Finance context, HR context, and client-confidential context need real boundaries — and the important part is that the boundary must be structural, not advisory. Telling the AI “don’t reveal this to non-admins” is a convention, not a control. If the data is present, it is one clever prompt away from surfacing.
The pattern that works is to separate by container, not by exception: instead of one big shared space with sensitive corners hidden inside it, run a small number of separate spaces with their own membership, and let each person’s view be the union of the ones they belong to. The executive who needs the full picture mounts all of them. Nobody else assembles more than they should. It is a less clever design than fine-grained permissions, and it fails far less often.
Freshness. At this size the dangerous failure is not an empty context layer — it’s a full one that’s quietly wrong. A beautiful, comprehensive, eighteen-month-old system that nobody trusts is worse than three honest files, because people stop checking and start assuming. Every file needs an owner, a last-reviewed date, and a decay rule: if this hasn’t been confirmed in six months, it is flagged as stale rather than served as fact.
A named architect. Someone owns the shape of the whole thing — not the content of each file, but the structure, the loading rules, and the question of whether a new file should exist at all. Without that role you get the other failure at this scale: sprawl, where every team has built its own assistant and each one knows a different version of the company.
Progressive disclosure matters most here. Anthropic’s own guidance for its instruction files is to keep the always-loaded layer light and push detail into files that load when relevant — a tree, rather than one enormous document. Their words: “consider having a tree of files that can be loaded at the right time.” At a hundred people you cannot load everything for everyone; the structure has to do the choosing.
One caution that survives every tier. When Anthropic told people to simplify their instruction files, they added a clause almost everyone dropped: “except in highly important areas.” Money boundaries, confidentiality walls and sign-off rules are the important areas. They are verbose, they are repetitive, and they should stay exactly as they are. Simplify around them, never through them.
What changes, and what never does
| Just you, up to ~25 | Several people must agree (25–100) | An organization to govern (100+) | |
|---|---|---|---|
| The hard part | Extraction — it’s in one head | Arbitration — whose version is canonical | Authorization — who sees what |
| What to write | One folder, five files | Five files split by function + one short shared file | The same, plus access rules and decay dates |
| Who owns it | One person, usually the founder | A named owner per domain | Domain owners plus one architect |
| How it stays current | 15 minutes a month | Monthly per domain; corrections go back to the file | Review cadence with last-reviewed dates and stale flags |
| How you know it’s working | Output sounds like you, not your industry | Two departments get non-contradictory answers | People trust it enough to stop double-checking |
| The failure mode | Building nothing while researching how | Five private, contradictory versions | A beautiful stale system nobody trusts |
The five files never change. The owner count goes from one to several to several-plus-an-architect. And the difficulty moves from getting it out of someone’s head, to deciding whose head was right, to controlling who can see the answer.
Read across any row and you can see why copying the wrong tier hurts. A ten-person company that starts with access rules and review cadences will spend three months building governance for a folder that does not exist yet. A three-hundred-person company running on one shared document has no way to stop the sales team’s assistant from quoting the wrong discount floor to a customer.
What we run ourselves
We run our own firm on the kind of context layer this article describes, which is the only reason we can be specific about the failure modes: we have hit most of them.
The most useful thing we can tell you is what went wrong most recently. Two weeks ago we audited our own setup and found roughly fifteen hundred lines of context loading before any work began — every session, regardless of task. A session about a client proposal was reading the same material as a session about our accounting. We had two memory systems quietly overlapping, and two logs that had grown past a thousand lines each with no rule for when anything leaves.
None of that was built carelessly. Every piece was added for a reason. The reasons had just stopped being true, and nobody had gone back to check — which is the large-organization freshness problem arriving in a very small company, because we build ahead of our size.
What we did not touch: the money rules, the confidentiality boundaries, and the publish gates. Those are verbose and repetitive on purpose.
Where outside help fits
Most of this is genuinely self-serve, and you should not hire anyone to do the part you can do in an afternoon. The first pass in particular is a solved problem: open a folder, write five files, start.
Three things are harder from the inside, for structural reasons rather than technical ones.
The first is that arbitration is political. Deciding whose version of the discount floor is canonical means telling someone they have been doing it wrong. That conversation is easier when the person asking has no stake in the answer, which is most of what an outsider is actually for once several people share the work.
The second is pattern recognition. Knowing which of your five files will rot first, and which of your exceptions will become a real problem at ninety people, is a judgment that improves with having watched it happen elsewhere.
The third is the cadence. A one-time build decays. What keeps a context layer alive is a standing loop with a named owner, and most firms can design that loop but few sustain it unaided through the first two quarters.
The instinct to get help here is common, and it is well-founded: Pax8’s 2026 survey of 400 small-business leaders found 84% would trust an outside technology advisor to help implement AI. If you do bring someone in, apply one test to us or to anyone else — ask what you own at the end. If the answer is a set of files your team can read, edit and operate without the firm that built them, that is architecture work. If the answer is a dependency, you have bought a subscription to your own knowledge. That is the standard behind an AI operating system your company actually owns, and it should be the standard you hold any partner to.
Your first Monday
If you are under 25 people, or one person, the whole first pass looks like this.
Make a folder called context. Create five files named for the five questions. Set a timer for ninety minutes.
Write how we sound first, and write it as contrast — five things you would never say, then one real example rewritten badly and then properly. Write what “done” looks like second, for the single thing you produce most often. Those two will change your AI’s output today, which is what keeps you going.
Then write who we are in under a page, resisting every urge to make it a brochure. Write what things cost and who decides, including the number below which you walk away. Write what never leaves the room.
Point your AI at the folder. Ask it to draft the thing you were going to write this afternoon anyway. Fix what it gets wrong — and then put the fix in the file rather than only in the chat. That last move is the entire discipline, and it is the one people skip.
If you are past 25, do all of the above for one function first, not the whole company. Pick the team with the most repeatable output and the clearest owner. Prove it there, then let the other domains copy a structure that already works instead of designing five in parallel.
Write Your Five Files in One Sitting
Paste this into your AI assistant. It interviews you for the five non-derivables and gives you back the actual files — not a template, your version, in your words.
Context: I’m building a context layer for my company so my AI has the background it needs. We are a [INDUSTRY] company with [NUMBER] people. I want to end this session with five written files. Interview me one section at a time and don’t move on until my answer is specific enough to be usable. Push back if I give you a generic answer.
Step 1 — How we sound: Ask me for five things we would never say, then ask me to paste something we’ve published that sounds right and something that sounds wrong. Draft a voice file built on contrasts, not adjectives. Reject “professional,” “friendly” and “innovative” as answers and ask again.
Step 2 — What “done” looks like: Ask which one or two things we produce most often. For each, interview me until you can write a standard a reviewer could apply and reach the same verdict I would — not a list of steps.
Step 3 — Who we are: One page maximum. What we sell, to whom, what we deliberately don’t do, and the three things new hires always get wrong in their first month. Cut anything that reads like marketing copy.
Step 4 — Money and authority: Ask me our pricing, our discount authority, the floor below which we walk away, what needs a second signature, and what nobody may commit to without me. If I don’t know an answer, mark it UNDECIDED rather than guessing — that list is my real output from this step.
Step 5 — What never leaves the room: Which information crosses which wall. Client-to-client, internal-to-external, and anything regulated. Be concrete about named categories, not principles.
Output: Five separate files I can save into one folder, each one written in my words rather than yours, plus a short list of everything I marked UNDECIDED and a suggested owner and review date for each file.
The UNDECIDED list is the useful part, and it’s usually the shortest. Those are the questions your business hasn’t settled — which means your AI has been guessing at them, and so has everyone else. See where you stand →
Sources
- RSM Middle Market AI Survey 2026 — RSM US, July 21, 2026 (1,030 middle-market executives, 827 US and 203 Canada; 97% satisfied with AI’s business value, only 36% have it fully embedded in core processes; 34% cite data quality as a top barrier; 85% say leadership is more enthusiastic than employees)
- RSM Survey: The Middle Market Has Embraced AI. Now Comes the Hard Part. — PR Newswire, July 21, 2026 (survey methodology and sample detail)
- Pax8 Pulse SMB Technology Report — Pax8 / Propeller Insights, March 24, 2026 (400 US small-business leaders, companies of 5–499 employees; 84% would trust an outside technology advisor to help implement AI; 70% of functional leaders vs 56% of owners see AI as essential within three years)
- The new rules of context engineering for Claude 5 generation models — Thariq Shihipar, Anthropic, July 24, 2026 (progressive disclosure and the “tree of files that can be loaded at the right time”; keep instruction files lightweight and spend the tokens on gotchas; “avoid making them overconstrained, except in highly important areas”)
- Effective context engineering for AI agents — Anthropic, September 29, 2025 (context engineering as the natural progression of prompt engineering)
- VentureBeat Research: Where enterprise AI agent governance hasn’t caught up — VentureBeat, July 24, 2026 (the context layer named as one of five controls enterprises must build before trusting an agent)
- What Is Context Engineering? — IBM, 2026 (context selection, structuring, and management as discrete steps)
- The rise of “context engineering” — LangChain, June 23, 2025 (write / select / compress / isolate as context strategies)
- How Can AI Support Knowledge Management — APQC, February 18, 2026 (capture, organize and reuse as the knowledge-management frame)
- Anthropic Deleted 80% of Its Own Instructions. “Write Less” Is the Wrong Lesson. — bosio.digital, July 24, 2026 (the derivability test, and the five non-derivables this guide builds on)
Frequently Asked Questions
What is context engineering?
Context engineering is the design of everything an AI system reads before it answers — the files, standards, and boundaries that are in place before anyone types a request. In practice it means writing down what your company knows in plain language and structuring it so the right part loads at the right moment. Prompting is what one person asks once; context is what the system knows every time anyone asks anything.
What should I write down first?
How you sound, and what “done” looks like for the thing you produce most often. Both change your AI’s output immediately, which is what makes the habit stick. Money boundaries, confidentiality walls, and the orientation file can follow on day two. Starting with the orientation file is the most common mistake — it feels foundational but changes nothing you can see.
How much context does a small company actually need?
Less than you think, and it should exist before it is good. Under 25 people, one folder with five plain files is the entire answer. The failure at that size is almost never building the wrong thing — it is building nothing while researching the right way to build it. An afternoon of imperfect writing beats a quarter of planning.
Who should own AI context in a 50-person company?
One named person per domain, with the responsibility written into their role rather than assumed. At that size context splits by function — sales, delivery, finance — and the common failure is five departments each maintaining a private, contradictory version of the company. You also want a single owner for the short company-wide file, whose main job is keeping it short.
How do you keep AI context from going stale?
Give every file an owner, a last-reviewed date, and a decay rule that flags it as stale rather than serving it as fact. Then adopt the one habit that matters more than the cadence: when someone corrects the AI’s output, the correction goes back into the file, not just into the chat. A full but outdated context layer is more dangerous than a thin one, because people stop checking it.
Do we need a knowledge management platform, or is a folder enough?
At under 100 people a folder is genuinely enough, and most tools solve retrieval rather than authorship. No platform can tell you what your pricing floor is, who may approve an exception, or which client facts must never appear in another client’s work. Those have to be decided and written by you. Buy tooling when access control and freshness tracking become real problems — which is a large-organization concern, not a starting point.
What are context engineering best practices for a business rather than a codebase?
Write the five non-derivables — voice, money, sign-off, confidentiality, definition of done — and define each by counter-example rather than description. Keep the always-loaded layer small and push detail into files that load when relevant. Give every file a named owner and a review date. Route corrections back into the files. And leave your important areas verbose: Anthropic’s own guidance to simplify instruction files carries the clause “except in highly important areas,” and your money and confidentiality rules are those areas.
How is this different from the context engineering Anthropic writes about?
Anthropic’s guidance is written for coding agents, where a great deal can be inferred from the surrounding code and mistakes surface immediately through tests. Business context has neither property — your brand voice isn’t derivable from a logistics brief, and nothing goes red when the AI quotes a price below your floor. The structural lessons carry over; the assumption that the model can work it out does not. We covered that distinction in detail in our piece on what to delete and what to keep.
Want this scored against your business?
AI Strategy turns this into a prioritized roadmap — where AI pays off for you, and in what order. It grows into the CEO AI Program.
See AI Strategy → Not sure where to start? Take the 90-second readiness read →
