Ask most consulting firms whether AI is paying off and the answer is awkward. The tools are everywhere, the results are not. The problem is not the technology. It is the absence of written context - decision rationale, process knowledge, client understanding - the things an agent needs but almost nobody records.
Ask most consulting firms whether AI is paying off and the answer is awkward. The tools are everywhere. Pilots are running. Licences are being bought. Yet results remain stubbornly mediocre.
The standard explanations - wrong tools, bad use cases, early days - miss the real issue. AI is only as good as the context it receives, and in most firms that context barely exists in a usable form. What AI actually needs is a written record of how the firm thinks, decides, and works - one that an agent can find their way through.
In practice, that comes down to three things: decision rationale, process knowledge, and client context.
Decision rationale is the reasoning behind choices, written down at the time and attached to the work it relates to. Not a thread in a Teams channel that nobody can find. Not a post-project retrospective six months later. The note lives next to the thing it explains - in the project folder, the engagement record, wherever a future AI agent or a new team member would go looking. It doesn't need to be long. "We recommended the phased approach because the client's budget cycle wouldn't support a single commitment - agreed with Partner X on 14 April" is sufficient.
A new team member joining an engagement mid-stream can read back through the engagement record and understand why the project is where it is, without needing a briefing call.
The answer to "why did we do it this way?" is "you'd need to ask Sarah, she was on the original pitch." When Sarah leaves, it leaves with her.
Process knowledge is how the firm actually runs engagements - not the methodology deck used in pitches, and not the ISO documentation that lives in a shared drive. The real procedure: how a new engagement gets scoped, how deliverables get reviewed, what happens when a client pushes back on a recommendation. Written in plain language, specific enough that someone who has never done it before could follow it. The test: if you handed it to a capable contractor on day one, would they make roughly the same decisions an experienced team member would?
This is harder to build than decision rationale because much of it has never been made explicit. Writing it down surfaces assumptions senior staff didn't realise they were making. That discomfort is part of the value.
The process is written at the level of actual decisions, not intentions. Not "conduct stakeholder interviews" but "by week two, you should have spoken to the client lead and at least one occupant representative; if you haven't, the scoping was wrong and the project director needs to know."
The process lives in the heads of the three most experienced people, gets transmitted through osmosis, and degrades every time one of them leaves or is pulled onto another project.
This is the accumulated knowledge of how to work with a specific client: what they care about, what they push back on, how decisions actually get made, what worked last time and what failed. It exists in every firm but it rarely gets written down, instead living in the relationship lead's memory and the fragments of a handover call nobody recorded.
When a new manager takes over a relationship, they can read a brief that tells them what the client cares about, what they've pushed back on before, and what the firm has learned about how to work with them - without needing a two-hour handover call with their predecessor.
The handover call happens, covers about 60% of what matters, and the rest gets rediscovered the hard way over the first six months.
All three of these - decision rationale, process knowledge, client context - have one thing in common: they only work if they're findable. The requirement is modest. Consistent location, consistent naming, and enough linking that someone can follow a thread from question to answer without already knowing where to look. This is not a six-month systems project. It doesn't require a new platform, a formal taxonomy exercise, or a knowledge programme. It requires consistent habits.
A survey of nearly 6,000 senior business executives found that despite 69% of firms actively using AI, nine in ten reported no current productivity impact on their own business. The same executives predicted productivity gains of 1.4% within three years - which implies they believe something will change, but can't say what. The gap between those two positions points at the context, not the tools.
The MIT study that tested 41 AI models across 11,000 real workplace tasks found that models produced "minimally acceptable" outputs not because they lacked capability, but because they were handed a job description with no process, no steps, and no success criteria. The study didn't test what AI can do with a well-structured knowledge base. It tested what AI does in the absence of one. Most firms are running exactly that experiment on their real work.
Tiago Forte summarised the problem neatly in a recent newsletter: "Most failures of AI these days are not due to limitations in the technology. They are context failures." The temptation is to dump everything into an AI tool and hope. In practice, quality depends on selecting and structuring the right context.
This piece is a companion to Agents cannot do osmosis, which focused on the demand side - why AI agents need explicit written context and cannot acquire it simply by being in the room. That post asked why agents need written context. This one describes what it should contain.
?
Pick a significant decision from a project that completed twelve months ago. Can you find, in under five minutes, a written record of why that decision was made - without asking anyone?
The three components above are a systems description, but the reason most firms don't have them is not always a systems problem.
People don't fail to record decisions because they lack a filing convention. They fail because there is no time at the end of an engagement, no modelled behaviour from leadership, and no cultural signal that it matters. Process knowledge doesn't get documented because the directors who carry it are also the people least likely to sit down and write it out - and because doing so feels like admitting the firm runs on individual expertise rather than repeatable capability. Client context doesn't get recorded because the relationship manager considers it theirs.
The practical implication is that building a context substrate is not an IT project or a knowledge management initiative. It is a change in how the firm's most senior people behave, and what they visibly expect from everyone else.
Pick a significant decision from a project that completed twelve months ago. Can you find, in under five minutes, a written record of why that decision was made - without asking anyone?
If yes, you have the beginning of something. If no, you have the most common AI problem in consulting, and it isn't the AI.
If you would like to find out more about working effectively with AI, please do get in touch.