Context Is the New Headcount

There's a question I now ask before almost any other, when a team tells me they want to put AI on a piece of work: not "which model," not "how will you prompt it," but "what does this task need to know that isn't written down anywhere?" On the team I've spent the most time embedded with, the answer to that question turned out to predict, almost perfectly, which tasks the rollout would help and which ones it would quietly sabotage.

This wasn't obvious to us at the start. We assumed, the way most rollouts assume, that the limiting factor would be model capability — that some tasks were simply too hard for the tool yet, and the rest would work fine once we picked the right one and wrote decent prompts. Capability turned out to matter far less than something much more mundane: how much of the unwritten institutional knowledge a task depended on, and whether we had any way of getting that knowledge in front of the model at all.

The task that should have worked and didn't

The clearest example was a client-communications drafting task — routine emails, status updates, the kind of writing a mid-level account manager does dozens of times a week. On paper this looked like an ideal AI task: repetitive, well-structured, low ambiguity. The pilot on this task underperformed every other pilot we ran that quarter, and for weeks nobody could explain why.

The answer, once we found it, was almost embarrassingly simple. A good status update from an experienced account manager doesn't just report facts. It carries a huge amount of relationship context that lives nowhere except in that person's head: this particular client gets anxious about timeline slippage and needs reassurance framed a specific way; this other client prefers blunt numbers with no hedging; a third client had a bad experience eighteen months ago with a similar project and any update touching that topic needs a specific, careful tone. None of that was written down. All of it was, in a very real sense, part of the account manager's job description, even though it appeared on no document the model could ever see.

"The task looked simple because the hard part of it had never been written down. It lived entirely in one person's head, and we'd assumed 'simple' meant 'the model has what it needs.'"

The model, with none of that context, produced technically correct, tonally generic updates that were, for the anxious client especially, actively worse than what a rushed human would have written from memory — because the rushed human, even distracted, still carried the relationship context by default. The AI carried none of it, and had no way to know it was missing anything.

What "context" actually means here

I want to be precise about the word, because "give the model more context" has become a phrase people say without meaning much by it. In this case, context split cleanly into three categories, and they required completely different fixes.

Only the first category is a genuinely technical problem. The second is a management problem wearing a technical disguise — it requires someone to sit down with the account manager and extract knowledge that was never going to write itself down otherwise. The third is a capability boundary, and drawing it honestly is itself valuable, because it tells you exactly where not to automate.

Staffing the context, not the task

Once we reframed it this way, the planning conversation for every new AI task changed shape. Instead of asking "can the model do this," we started asking "who on this team currently holds the context this task depends on, and what would it cost to make that context legible?" That is, functionally, a staffing question. It has the same shape as asking whether you have the headcount to cover a gap — except the gap isn't a role, it's a body of tacit knowledge that happens to currently live inside one person's judgment.

Plot every task we'd piloted that quarter on a single axis — how much of its required context was already documented versus how much sat in someone's head — and the pattern was almost too clean to be believable at first. The pilots that succeeded clustered tightly where documented context was high. The pilots that quietly underperformed, the drafting task among them, clustered just as tightly where tacit context dominated and nobody had budgeted time to extract it. We didn't need a sophisticated model to predict which pilots would struggle. We needed that one axis, and nobody had thought to draw it before the quarter was half over.

The account-management team eventually fixed the drafting task, but not with a better model. They spent three weeks having the two most experienced account managers write down, explicitly, the relationship-handling rules they'd never had to articulate before — a short brief per major client, covering tone, sensitivities, and history. That brief became the context the model was missing, and once it existed, the same drafting task that had underperformed for a quarter started producing updates the clients themselves couldn't distinguish from the senior account manager's own writing.

"We didn't upgrade the model. We took three weeks of a senior person's time and turned tacit judgment into a document. That document was the actual missing infrastructure."

The second team, and why they didn't hit the wall

I want to describe one contrast case, because a single failure story can read as an indictment of AI drafting tools generally, and that's not the lesson. A different function on the same firm — technical documentation for internal tooling — ran a nearly identical pilot in the same quarter and hit almost none of the problems the account-management team hit. The obvious explanation is that documentation is a more mechanical task than client communication, and there's some truth to that, but it isn't the real reason.

The real reason is that the documentation team had, for unrelated reasons, spent the previous eighteen months building out a rigorous internal wiki — every system's quirks, every non-obvious dependency, every "don't touch this without reading that" warning, written down because a previous outage had made the cost of not writing it down extremely visible. None of that wiki was built with AI in mind. It existed because a different, earlier management failure had taught the team that tacit knowledge concentrated in two senior engineers was a liability regardless of tooling. By the time the AI pilot started, the documentation task's context was already almost entirely in the first category from the list above — documented but scattered — which meant retrieval, a genuinely technical fix, did almost all of the remaining work.

The lesson generalises in a way I find genuinely useful for planning: the tasks where AI adoption will be cheap and fast are, disproportionately, the tasks where some earlier, unrelated discipline already forced tacit knowledge into writing. You can predict, with reasonable accuracy, which parts of an organisation will take to AI drafting quickly just by asking which teams already have good documentation habits for reasons that have nothing to do with AI. The rollout doesn't create that discipline. It reveals, sharply and sometimes expensively, where the discipline was already missing.

"The documentation team didn't get lucky with an easier task. They got lucky with an earlier outage that had already forced them to write everything down."

The budget line nobody puts in the plan

The uncomfortable conclusion, and the one I keep repeating to leadership teams now, is that the real cost of a serious AI rollout isn't the licence fee. It's the time cost of making tacit context legible — which is senior people's time, the scarcest and most expensive resource on any services team, spent not doing their normal work but sitting down and articulating the rules they follow without thinking about it. That cost doesn't show up on a vendor's pricing page and it rarely shows up in a rollout budget, because it looks like "meetings" rather than "infrastructure," and meetings are the first thing a stretched team cuts when the calendar gets tight.

Treat it as a staffing line instead, the same way you'd budget headcount for a new function, and the rollout plan looks completely different. You start by mapping which tasks depend on context that's already documented — cheap, fast, technical — and which depend on tacit knowledge that only your most senior people carry — expensive, slow, and entirely a matter of whether you're willing to spend their time making it legible before you spend their time doing the work by hand forever. Skip that mapping, assume the model just needs "more context" in the abstract, and you get exactly what that first pilot got: technically fluent output that's missing the one thing that actually made the human version worth reading.

I no longer let a rollout plan reach my desk without that mapping exercise attached, because every time I've skipped it, the failure has looked identical to that first pilot: plausible on paper, quietly wrong in production, and blamed on the model when the actual gap was three weeks of a senior person's unspent time. Context, in this sense, isn't a technical parameter you tune. It's a resource you staff for, the same way you'd staff a gap in coverage — and until a rollout plan has a line item for whose tacit knowledge needs to become a document before the model can touch the work, it isn't actually a plan yet. It's a hope that the easy parts of the job were the whole job.