Ask a room of business owners about AI and within minutes the conversation lands on the same question: which model? GPT or Claude? Is Gemini better for spreadsheets? Should we hold off until the next release? It feels like a decision you could get wrong and regret, and the noise around every launch makes it feel bigger still. But two years of watching companies wrestle with AI adoption has convinced me the model debate is mostly a distraction, because the companies getting real value from AI are the ones that did the unglamorous work of writing down how they actually operate — whichever model they picked.

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 at all. The problems that determined whether an agent succeeded lived elsewhere: in how tools were described, the examples agents were tested against, and the standards that kept thousands of teams describing their systems the same way. A vaguely described tool, they found, leaves the agent guessing: it picks the wrong one, drags irrelevant information into its working context, slows down and costs more. When an agent underperformed, the fault usually sat in the description of the business the agent had been handed.

LinkedIn reached the same conclusion from a different direction. Its engineers found that AI 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 they built CAPT (contextual agent playbooks and tools), a framework that gives agents access to internal systems along with playbooks: step-by-step encodings of the rules, conventions, procedures and verification steps that experienced engineers normally carry in their heads.

Given a customer-issue ticket, for instance, one playbook has the agent read the description, pull the relevant logs, search past incidents, identify likely causes and the most relevant code paths, then write its findings back into the ticket so the next person starts with the context already assembled. (A separate review workflow can take a pull request with comments and propose the code changes that address them.) LinkedIn reports initial triage times down by roughly 70% in many areas and data analysis running about three times faster. Those gains came from writing institutional knowledge down in a form an agent can follow, using the same models available to everyone else.

The same lesson holds well beyond engineering teams. Ask an agent to chase overdue invoices and it 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.”

What GPT-5.4’s tool search signals

The AI labs have started behaving as though they’ve reached the same conclusion. When OpenAI launched GPT-5.4 in March, one of its headline features was something called tool search — a mechanism that lets the model look up tool definitions on demand instead of having every tool loaded into its context window from the start. OpenAI’s own evaluation, across 250 benchmark tasks, found it cut total token usage by 47% with no loss of accuracy. In that benchmark, nearly half the token usage simply disappeared, and the saving came entirely from better-organised information around the model. 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, and it lands with whoever has described their tools and processes well enough for a model to find and trust them on demand.

Why the documentation never gets done

So why haven’t more companies done it? Everything described above — playbooks, schemas, one agreed definition of revenue — is documentation, and documentation is the work everyone agrees matters and almost nobody does. There’s no launch date attached to it, and nobody applauds when a runbook gets finished.

I know the pull of that neglect first-hand. 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 and documented every process until someone else could run it. The business grew for seventeen years and eventually sold partly because it ran without me — and even so, the documenting was the discipline that slipped first whenever things got busy. What’s changed since then is who reads the manual. Everything we wrote down was written for people; hand the same operating knowledge to an agent and it becomes the difference between AI that guesses and AI that does the job the way your business does it.

That’s precisely why this works as a moat: a competitor can buy the same model subscription as you this afternoon, but there’s no subscription for the years of documented processes, edge cases and customer language sitting behind your operation. A neglected folder of procedures defends nothing, mind — the moat is the organisational habit of turning experience into maintained, testable operating knowledge, and improving it every time an agent exposes another gap. How long that holds, I’m not sure: a future model given raw access to your systems may one day infer most of it. I wouldn’t bet the business on it, though.

I’ve written before about why 80% of companies get nothing from AI, and the conclusion there was that the failures come down to execution. Thin institutional knowledge is exactly that kind of failure, and the minority getting a return look different in predictable ways: they get 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 do any of that: they’ll carry on debating models and running pilots while their operational knowledge stays in people’s heads, because that’s the path of least resistance. If you’re prepared to do the boring work anyway, that inertia becomes your opportunity, and it compounds — every process you document makes the next agent cheaper to deploy.

What agent-ready knowledge actually looks like

The encouraging part for smaller businesses is that none of this requires enterprise tooling. LinkedIn’s playbooks are, structurally, well-organised documents, and if context engineering is the individual skill of giving AI the right information for a task, this is its organisational counterpart. Some practical starting points:

  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, so say what each one is for.
  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 quietly filling the gap from memory — that’s the knowledge you haven’t captured yet.

Whichever process you start with, the work pays twice: agents get cheaper and more reliable as the knowledge base grows, and there’s a comfort Gerber understood decades before anyone deployed an agent — a business that’s written down how it works is a better business, whether or not an AI ever reads a word of it.