AI arrived promising a level playing field. For the first time, the corner shop and the conglomerate buy the same intelligence at the same monthly price; the models don’t care how big you are. Yet two years into the adoption wave the results are anything but level: most companies have little to show for their subscriptions, while a minority compound an advantage on exactly the same tools. At the centre of that gap sits something almost embarrassingly unglamorous: the businesses getting real value from AI are the ones that have written down how they actually operate.

I learned this lesson long before AI could read. When I started Vertical Leap I followed Michael Gerber’s E-Myth principles to the letter. I drew the org chart with my name in every box, then documented each process until someone else could run it. The business grew for seventeen years and eventually sold partly because it ran without me. I’ll admit the documenting was the discipline that slipped first whenever things got busy; it’s the work everyone agrees matters and few of us protect. What’s changed since then is who reads the manual. We wrote ours for people. Hand the same operating knowledge to an AI agent and it becomes the difference between a tool that guesses and a tool that does the job the way your business does it.

The people running thousands of agents agree

Amazon has built thousands of AI agents across its organisations since 2025, and when its engineers published the lessons from that experience earlier this year, the striking thing was how little of the write-up concerned models. What decided whether an agent succeeded was the quality of the material it was handed: how tools were described, the examples agents were tested against, the standards that kept thousands of teams describing their systems the same way. A vaguely described tool leaves an agent guessing: it picks the wrong one, drags irrelevant information into its working context, slows down and costs more.

LinkedIn reached the same conclusion from a different direction. Its coding agents were plenty capable but knew nothing about LinkedIn — its thousands of microservices, its internal frameworks, the particular way things get done there — so its engineers built CAPT (contextual agent playbooks and tools): playbooks that encode, step by step, the rules, conventions and verification habits experienced engineers normally carry in their heads. Given a customer-issue ticket, one playbook has the agent read the description, pull the relevant logs, search past incidents and write its findings back into the ticket, so the next person starts with the context already assembled. Initial triage times fell by roughly 70% in many areas, and data analysis now runs about three times faster. Same models as everyone else; the gains came from the writing-down.

The lesson holds well beyond engineering teams. An agent chasing overdue invoices needs to know which ledger is authoritative, what counts as overdue and who approves the reminder, none of which lives in any model. The New Stack recently catalogued the knowledge bases being built to hold exactly this sort of thing, and underneath the labels it’s mundane stuff: runbooks, schemas, escalation paths, an agreed definition of “revenue” that every agent has to use. An Amazon engineer quoted in the piece put it better than I could: “The knowledge base isn’t there to help the agent be creative. It’s there to keep it inside the lines.”

The moat, and how long it holds

The labs are signalling the same priority. When OpenAI launched GPT-5.4 in March, a headline feature was tool search: a mechanism that lets the model look up tool definitions on demand instead of carrying every tool in its context window from the start. OpenAI’s evaluation across 250 benchmark tasks found a 47% cut in token usage with no loss of accuracy. Tokens are most of what you pay for when you run agents, so at any real scale that’s the difference between a pilot parked on cost grounds and one that earns a rollout. The saving lands with whoever has described their tools and processes well enough for a model to find and trust them on demand.

This is why documented operating knowledge works as a moat when the models themselves cannot. A competitor can buy your model subscription this afternoon; there’s no subscription for the years of processes, edge cases and customer language sitting behind your operation. The moat does need maintaining to hold. A neglected folder of procedures defends nothing. The real asset is the organisational habit of turning experience into tested, owned operating knowledge, improved every time an agent exposes another gap. How long the moat lasts, I’m honestly not sure. A future model given raw access to your systems may infer most of it unaided one day; I wouldn’t plan a business around that day arriving soon.

I’ve written before about why 80% of companies get nothing from AI, and the conclusion there — that the failures are execution failures — applies squarely here. The minority getting a return put their processes on paper, standardise their definitions, give the documents owners, and test their agents against real workflows rather than demos. Most companies won’t, because heads are where operating knowledge stays when nobody makes time to move it. If you’re prepared to do the boring work, that inertia is your opportunity, and it compounds: every process you document makes the next agent cheaper to deploy.

Where to start

None of this requires enterprise tooling; LinkedIn’s playbooks are, structurally, well-organised documents. If context engineering is the individual skill of giving AI the right information, this is its organisational counterpart:

  1. Start with one process: choose something frequent and painful — client onboarding, monthly reporting, quote preparation — and document it end to end before touching anything else. One genuinely agent-ready process beats fifty half-written ones.
  2. Write for a reader with no context: an agent, like a new employee on day one, knows nothing you don’t tell it. Spell out the steps, the exceptions, the systems involved and what “done” looks like. If a temp couldn’t follow it, an agent can’t either — and the same goes for your tools, because an agent chooses between them by their descriptions.
  3. Give every definition one home: when three spreadsheets hold three versions of “monthly revenue”, an agent will happily pick the wrong one. Agree the definition once and point everything else at the same source.
  4. Version it and own it: a knowledge base nobody maintains decays into a liability. Give each document an owner and a review date, and keep it somewhere versioned rather than scattered across inboxes and chat threads.
  5. Test it on an agent: the fastest way to find the gaps in your documentation is to hand it to an AI and ask it to do the job. Where the agent stumbles, a human has been filling the gap from memory — that’s the knowledge you haven’t captured yet.

Gerber taught a generation of us that a business worth owning is one that runs on paper rather than in the founder’s head. By picking one process this month and writing it down properly, we get both halves of the reward: agents that work the way our businesses actually work, and — AI or no AI — a company that’s calmer and stronger for knowing itself.