Barry... Botman.

The company CEO has just created Barry to be their new ‘virtual Chief of Staff’.

Barry prepares board updates. He summarises leadership meetings. He tracks strategic priorities, drafts internal briefings, chases unresolved decisions, coordinates with specialist agents, works twenty-four hours a day. And he has never once asked whether the current operating model is, perhaps, a tiny bit deranged.

For a while, for all of the above reasons as far as the CEO is concerned, Barry is thought to be bloody marvellous.

Until, that is, Barry starts getting... a bit weird.

Old priorities resurface in new briefings. Leadership decisions blur together. Board updates sound plausible, but wrong. An action from three months ago appears as if it were agreed yesterday. Then there was that time when a cancelled “we don’t talk about that anymore” initiative wandered into a meeting agenda pretending it still had budget.

The temptation, of course, is to place the blame on... well, the AI. The agent. Obviously.

“The AI is rubbish.” “The model needs fixing.”

“Barry, you bloody imbecile.”

Except, it would be a mistake to blame Barry himself.

Why?

Because Barry isn’t real.

There is no ‘virtual Chief of Staff’. There never was.

Anthropomorphised perceptions of AI agents as actual ‘workers’ with an attached sense of personhood and sentient intelligence are, undeniably, a convenient abstraction. They let non-technical executives quickly grasp the functional value of agentic AI applied to business.

But they also act as a hugely misleading – and increasingly dangerous – wrong turn for most knowledge work industries trying to grapple with the value that AI actually offers to business operations.

This is an article about that wrong turn, and what course correction looks like. From “out-of-the-box AI is human-equivalent intelligence, therefore representing displacement of human labour” to “AI is system intelligence that has a huge role to play in assisting and enhancing pre-existing human labour (without threatening it)”.

And this isn’t a thought experiment.

The New Zealand government is currently cutting nearly 9,000 public-sector roles under a restructuring programme that names accelerated AI adoption as part of its official rationale. The political debate has focused on austerity, ideology, and employment. Almost nobody is asking the operational question underneath: what exactly will these AI systems be executing against?

So first, back to Barry. If you’re not real... what are you (not)?

What Barry actually is. Not.

Strip the name away.

At the simplest level of explanatory abstraction, Barry is essentially:

A large language model (e.g. Opus 4.7, GPT 5.5, choose your poison) pointed at a slice of organisational context – documents, instructions, workflows, tools, constraints, and source knowledge – which then triggers system execution against the contents of that organisational context (’go here, follow these steps, use this tool, run this script, produce x, followed by y, in order to synthesise z’).

That is the workflow. That is what is running.

The foundation capability layer is the raw capability of the model: generate, classify, extract, transform, reason, synthesise. Powerful, but generic. It knows nothing of your organisation.

The agentic execution layer is the operational machinery around that capability: skills, workflows, agents, orchestration, tools, permissions, routing, observability, escalation.

The context layer is the thing between them. The system of understanding – comprised of the substance, structure, and operational governance that turns organisational knowledge into something machine-operable.

Models provide capability. Context provides meaning. Agentic systems provide execution.

Now, there’s no doubting that the sense of there really ‘being’ an agent on the other side of the screen – that acts, produces, decides, routes, judges – is felt as real.

But the source reality creating that effect is: an LLM parsed through whatever organisational context it was given as inputs, producing outputs that mirror the input’s nature.

Add a cheerful name (or ‘Barry’), plus just enough projected personality flourishes to make it feel less weird, and there it is. You’ve ‘created’ your agent.

This is the first perceptual breakthrough leadership teams need to make if they're going to grasp what they're actually building – and what they're making decisions over.

Meaningful intelligence lives in the organisational context layer – the webpages, marketing collateral, policies, strategy docs, meeting notes, dashboards, and all the weird-and-wonderful strategic detritus that accumulates anywhere humans gather to do "human worker stuff". Not in the AI model itself.

The distinction matters enormously. Not just because it deepens leadership understanding of what’s inside the agentic AI black box – but because it’s the difference between two very different internal conversations.

The first: “I know at a systems level what agentic AI is, and I get that it would be dangerous to treat this as an immediate trigger for human labour replacement within our business.”

The second: “I genuinely believe these are intelligent virtual workers. This is magic! We’ve entered the age of AGI, folks, how soon could we reduce our workforce by 35%?”

Perceiving agents as actual virtual colleagues leads to the latter response.

If you think Barry is a virtual colleague, you train him, coach him, manage his performance – and start quietly thinking of him as a cheaper replacement for human labour.

This is the agent delusion.

If you understand Barry as a reasoning processor layer pointed at organisational context, you’re more likely to see AI as augmenting human labour, not replacing it. You don’t inspect ‘the agent’ when things go south (because there is no embodied agent to inspect) – you inspect the human-made context that’s feeding the effect of agentic intelligence.

This is the agent reality.

And no prizes for guessing which lens the New Zealand cuts are being made through.

The context layer: where intelligence actually lives

Right. So if it’s not the model, and it’s not the orchestration – what is the context layer, and why does it carry the load?

Three properties. Substance. Structure. Governance. Get all three right and agentic AI systems start behaving like the intelligence leadership thought they were hiring (albeit, grounded in an understanding of what’s actually at play).

Get any of them wrong, and the agent behaves like… Barry.

Substance is the meaning itself. The actual operational truth of what the organisation knows, intends, claims, sells, promises, and decides. Substance is what you mean. It lives in webpages, marketing collateral, policies, strategy decks, customer-facing artefacts, knowledge bases, training materials, sales enablement, internal documentation – every place an organisation stores its understanding of itself.

To take a concrete operational example: if you’re building a customer support knowledge system, the first substantive work is editorial substance. Which knowledge base articles are canonical and which are duplicative or redundant? What’s cruft that should never go near an agent at all? What’s written to style guide and what isn’t? Which definitions actually describe current product reality and which describe a feature that was deprecated eighteen months ago?

This is the human, judgement-led discipline of deciding what the organisation actually knows and means in this area, and getting it into a form a system can reliably point at.

Structure is how that meaning gets encoded so a system can actually work with it. Taxonomies, content models, metadata, definitions, entity relationships, knowledge graphs. The discipline of making meaning machine-operable. This is the territory the semantic engineering field has owned for decades, and it matters more now than ever.

Structure determines whether an agent retrieving a policy can also retrieve the related policy, the superseding policy, the exception to the policy, and the canonical definition of the term the policy turns on. Without structure, Barry retrieves documents. With structure, Barry retrieves meaning.

Governance is what keeps substance and structure true over time. Ownership. Lifecycle workflows. Standards. Update cadences. The roles, responsibilities, and routines that catch drift before it propagates. Organisational meaning is not static; it changes constantly as products evolve, strategies pivot, positioning sharpens, policies update, people move. The agent doesn’t know the document is six months out of date. It just executes against whatever is provided to it. The governance layer is the difference between a context layer that keeps working and one that steadily turns into a liability.

(Made considerably worse, of course, if you built the liability on top of cutting the human workforce that’s now required to fix it. Oops.)

Substance. Structure. Governance.

A healthy context layer has all three. A broken one is broken in at least one of them – and usually broken across all three at once, because organisations that haven’t invested in substance also haven’t built the structure, and don’t have the governance routines to maintain either.

This is what I increasingly refer to as content system design work. The discipline of building and maintaining a context layer (composed of not only structural semantic relationship mapping, but editorial source truth and an operational content governance model) deliberate enough, stable enough, and current enough to point a probabilistic system at without inheriting compound failure.

Different business contexts get different content systems to be designed for corresponding AI use cases – marketing, product, customer experience, internal operations – but the underlying anatomy is the same.

Substance, structure, governance. Maintained as a live operational asset, not a one-off implementation project.

That is what sits underneath the agent. Not out of the box intelligence. And not merely a knowledge base with a nicer name. A designed operational environment for meaning to dynamically move between human and machine consumers.

The danger of the anthropomorphised AI system

A large language model is a probabilistic, pattern-spotting system. It generates plausible continuations against whatever context it has been given.

Point a probabilistic system at ambiguous organisational context and expect deterministic operational reliability from the output, and you are making a category error at the foundation of your AI strategy.

The better the agent feels like a colleague, the harder it becomes to inspect the system underneath; the more convincing the ‘virtual colleague’ framing, the easier it is to forget the system is only ever acting through the context it can access.

That isn’t just a technical concern. It’s commercial. It’s strategic. And in knowledge industries currently betting their cost base on AI workforce replacement, it’s existential.

Most organisations don’t have enough stable operational meaning to support deterministic execution from a probabilistic system.

The model is a growing commodity. The agent is the visible behaviour. The context layer underneath both is where competitive advantage actually lives – and where it can also disappear in ways no one is currently set up to notice.

The agent is not underperforming in the way the leadership team thinks it is.

The agent is reflecting the context layer it was pointed at.

When an AI agent recommends a decision based on an old document, the first question is not “why did the agent do that?”

The first question is: why was that document included as a plausible source of truth within our content system the AI is feeding from?

When the agent blurs together two versions of the same strategy, the first question is not “does the model need better instructions?”

The first question is: why did the organisation have two live versions of the strategy?

So the next time someone presents an agent architecture, ask the missing-layer question.

Not only: how does the system coordinate and orchestrate execution?

But: what context layer is it executing against?

What does the organisation’s informing content actually mean, intend, expect, and need?

Where is that meaning defined? How is it encoded? Who maintains it? How is it validated when the organisation changes?

Between the raw capability of AI models and the sophisticated execution of agentic systems sits the layer now revealing itself as the most difficult – and most strategically decisive – part of the stack:

organisational context.

Which is expressed through the organisation’s content.

And in most cases...

Ooph, what a mess.

I'm currently working on a set of designed content system templates that sit underneath agentic AI in knowledge-intensive organisations – the context layer the agents are actually executing against.

Watch this space. And if that’s something you’d like to chat more about, I’d be happy to hear from you.

You type a question, it gives you an answer. The quality varies. Sometimes it sounds clever. Sometimes it does a little LLM-vibed improv jazz solo when you least expect or need it. But the shape of the interaction is recognisable.

Using AI = chatting back-and-forth with a model.

If that’s AI basecamp, then advancement from here is where a lot of non-tech leaders start to feel the altitude hit.

‘Basic explainers for beginners’ often include concepts such as: neural networks, retrieval augmented generation, context windows, agentic orchestration, and ETL pipelines. Not exactly breezy.

The unspoken instinct in the room is usually some version of: sounds impressive... but I have no idea what we are actually talking about.

Everything and absolutely nothing. All at once.

At this point, AI stops feeling like a tool sitting on the desk and starts feeling more like the weather – everywhere, consequential, somehow shaping the day, but very difficult to point at.

Business leaders are not lacking literacy, here. They are being given the wrong explanation entirely, which gives them absolutely nothing tangible to point at.

What decision-makers need is to understand where AI is relevant to specific business goals.

Too often, they instead get abstract platitudes or plumbing specifications: promises about productivity on one side, technical taxonomies on the other.

The promise gets inflated before the business context has been made clear.

The end result: we’ve built a highly complex, frontier technical solution... now we just need to go and find a business/user problem to fit it.

The missing layer is business-context clarity: what kind of work AI systems can genuinely enhance or even transform, what internal knowledge those systems depend on for those value opportunities to be realised, and what would make them reliable enough to plan, judge, and govern.

That requires a different kind of taxonomy for conceptualising what AI is, not through the lens of its technical foundations, but through the lens of the practical business problems it helps to solve.

AI is not one thing

The phrase ‘AI’ is now carrying far more weight than any single phrase can responsibly carry.

Inside the same organisation it can mean:

• AI as an external-facing product – where the LLM capability is what the customer is buying, accessing, or being served by. The AI is the product, not an addition to it.

• AI as a product feature layer – where AI sits inside an existing product as an additive capability that enhances how the product works, but isn’t the reason the product exists.

• AI as an internal tool – where LLM capabilities are pointed at the work employees already do – retrieval, drafting, synthesis, analysis, internal Q&A. The user is the organisation, not the customer.

• AI as workflow automation – where the system moves work through a process with reduced human checking. This is where ‘agentic AI’ lives in operational terms, stripped of the theatre – and where the operational stakes of weak content infrastructure compound at machine speed.

These are not minor variations on a unified theme. They are wildly different bets, with different time horizons, different commercial logic, different operational risks, and very different demands on what the organisation already has underneath them.

But when everything sits under the same label, knowledge workers cannot tell which conversation they are actually participating in.

The opportunities to apply AI across marketing, product, customer experience, sales, and internal operations are so varied that any continuous discussion of ‘AI transformation’ as a singular programme of work at boardroom level is, in practice, absurd.

But this is exactly what is continuing to occur in a lot of meeting rooms right now. Two department heads are sat in the same meeting about the organisation’s AI strategy and are nodding along at the same sentence, seemingly in total agreement – but silently picturing different things in their heads.

One is imagining a customer-facing release in the next quarter. The other is imagining a year-long internal rollout of agentic-powered workflow automation.

Nobody explicitly disagrees on anything. Because nobody has been forced to be specific about the reality they’re internalising. The ‘unified strategy’ survives the meeting, then immediately starts dying in delivery.

This is one reason AI strategy so often sounds smooth at the leadership layer and fragmented at delivery. The vocabulary is doing the wrong job.

The vocabulary problem gets worse, not better, in the most-discussed corner of the field: agentic AI.

Agentic AI adds theatre to an already vague field

Agent language makes the situation worse, because it dresses up a fairly mechanical process – reading files, routing instructions, running scripts, calling tools – in human-like clothes.

That framing deepens the black-box theatre instead of explaining what the system is actually doing.

Sidenote: from a marketing perspective, this is nothing short of genius. Because it amplifies the sense of improbable alchemy around AI behaviour rather than revealing the more prosaic machinery underneath.

The ‘AI colleague’ or ‘AI team’ framing leads people to imagine a capability they cannot see being built: where its memory comes from, what it has access to, who decides when it stops, and what rules it follows.

None of these become clearer once the system has been personified to ‘act as your COO or executive assistant’.

Which is partly the point. The language is not trying to explain the magic. It is inviting everyone to get lost in it.

But strip the theatre back and the important questions are the same kind you would ask of any standard operating process.

• What can the system see?

• What is it allowed to do? What rules govern it?

• What tools does it have access to?

• What processes does it follow?

• Where is it supposed to escalate?

• Who notices when it goes wrong?

Those are not magical questions. They are pretty boring ones that have more to do with knowledge management and operational workflow definition than AI tool engineering. They also happen to be the questions that decide whether agentic work is safe enough to deploy at all.

The second split most AI conversations skip

AI becomes much easier to understand the moment it is described by the work it is doing in the business, rather than by the most impressive technical component sitting inside it.

But the four categories are not enough on their own.

An internal tool for Marketing is not the same strategic object as an internal tool for Product. Workflow automation in Customer Experience is not the same risk as workflow automation in Internal Knowledge Management. A feature layer can be harmless in one context and dangerously misleading in another, because the visible AI surface is only the final expression of the work underneath.

The business context changes the knowledge the system depends on, the risk it creates, who has to maintain it, and what would make the output reliable enough to use.

This is the layer of specificity most AI conversations skip.

An organisation does not adopt AI once. It considers many possible AI bets across different areas of work. The same umbrella label can cover cross-department knowledge retrieval, customer support, research synthesis, product documentation maintenance, and sales response support.

These are not five versions of the same implementation question. They are five completely different operating questions.

This is where the three-layer content infrastructure model becomes useful.

Substance is what the content says.

Structure is how that knowledge is organised.

Governance is how it is maintained.

Applied to typical business department contexts…

Internal Knowledge Management

Typical example: compliance and regulatory validation.
This is workflow automation, not retrieval – the system runs against communications, documents, or decisions automatically, flagging what falls outside policy. Governance carries the pressure: who owns the rule set, what gets escalated rather than actioned, and who keeps the validation logic current when regulations change. Substance decides whether the rules being enforced reflect what the regulator actually requires today, rather than what someone believed last year. Structure decides whether the right policy clauses, precedents, and evidence connect at speed. Without all three, the system either nods through breaches or floods the team with false positives – both expensive failures.

Customer Experience

Typical example: AI customer support agent.
This is an external-facing product – the customer is in a service relationship with the system, not just being served by it. Substance is acute because the system is answering customers in real time. If product details, policies, or troubleshooting steps in the source material are inconsistent or out of date, the AI scales those errors directly into customer conversations. Structure decides whether the right answer can be retrieved at the right moment of need. Governance decides what the system is allowed to commit to, when it escalates, and who maintains the source material that everything else depends on. The risk is that the organisation has exposed unresolved content problems directly to customers.

Marketing

Typical example: content repurposing and adaptation.
This is usually an internal tool. The visible appeal is straightforward – turn one piece of content into many, across audiences and channels. But Substance carries most of the pressure here. The system can only adapt what is there. If the source article is thin, the LinkedIn version is thinner. If brand voice is inconsistent across what already exists, the system amplifies the inconsistency at speed. Structure decides whether the system can tell approved sources from convenient drafts, and whether assets, claims, and audience mappings can be retrieved cleanly when needed. Governance decides whether the marketer using the tool is pulling from the approved library or from whatever happens to be lying in their inbox.

Product

Typical example: in-product contextual guidance.
This is a feature layer – AI sitting inside an existing product, surfacing help, prompts, or next-step suggestions tuned to where the user is in their journey. Structure carries the pressure: the system needs to know which features depend on which prerequisites, which problems map to which solutions, and how the user’s current state connects to the rest of the product surface. Substance decides whether the guidance is right when retrieved – out-of-date or contradictory help is worse than none. Governance decides who maintains the guidance as the product changes, and who notices when patterns reveal it has stopped working. Get this wrong and the AI feature becomes a friction multiplier for the users it was meant to help.

Sales Enablement

Typical example: RFP intelligence and approved response support.
This is an internal tool with unusually high commercial stakes. Substance and Governance carry the pressure together: the system needs approved claims, current case studies, accurate product language, and clear boundaries around what sales teams can promise. Structure determines whether the right proof point or response language can be found at the point of need. The failure mode is not usually dramatic. It is a proposal assembled from almost-right fragments, each reasonable in isolation, collectively nudging the organisation into a promise it cannot quite stand behind.

The four types tell you what kind of AI conversation you are in.

The business context tells you what the system depends on.

The infrastructure assessment tells you whether that dependency is strong enough to carry investment, and what would need to be built for the opportunity to succeed.

The point is not to create a more elaborate taxonomy for its own sake. It is to stop AI investment being discussed at a level where the words still sound coherent but the work underneath has already disappeared.

Once the work is visible, the question changes. Not “which AI tool should we adopt?” but “what kind of AI bet is this, where does it sit in the business, and what would have to be true underneath for it to work reliably?”

The gap knowledge workers are sensing

Knowledge workers who feel that more advanced AI remains elusive are not behind. They are responding sensibly to an explanation environment that has skipped a layer.

Non-coders do not need to master the builder’s vocabulary before they are allowed into the conversation. Their pre-existing judgement sits close to the heart of the matter:

Understanding what the system is trying to do, the underlying knowledge it depends on, and where the corresponding content needs reworking to make that knowledge reliable enough for the system to use.

People cannot responsibly sponsor, evaluate, or govern what they cannot tell apart. If ‘AI’ means four things to four departments, the organisation is not making four decisions. It is making one decision and trusting the differences will resolve themselves later. They won’t.

Make the work visible before making it advanced

The next stage of AI literacy won’t come from more prompting tips, more frontier announcements, or more architecture diagrams aimed at builders. It will come from surfacing a richer variety of AI opportunities through the pre-existing language of the knowledge work itself.

Example

In relation to [specific departmental function]…

• Intent: what valuable functions could the system actually perform for us?

• Operational knowledge: what knowledge will those functions depend on?

• AI scope: what precise actions will the system be allowed to take?

• Human scope: what will still need human-in-the-loop judgement?

• Content infrastructure dependency: what would have to be true about the underlying content for this to work reliably?

Rigorously answering each of these questions leads to a well-rounded spec for agentic capability within that business unit. But note: not one of the above questions is related to technical development, tool or feature build.

They are operating questions attached to content dependencies. Any reasonably experienced knowledge worker can answer them within their field of specialism. There is no good reason AI should be the exception to that rule.

Because once those questions are asked routinely, AI stops being weather. It becomes a set of distinguishable bets, each with its own demands, each open to assessment.

The chatbot remains the easy part. Everything beyond it becomes far easier to question, plan, and govern once it is described from the layer the work actually lives on.

Thanks for reading.

If this way of thinking about AI feels closer to the real work, the Knowledge AI Opportunity Map takes the next step. It maps thirty use cases across five business contexts, so the conversation moves from generic ambition to the actual opportunities, dependencies, and constraints in front of you.

Or if you’d like to discuss what practical AI investment looks like – calibrated against real organisational constraints rather than vendor theatre or hype – you can find me at examinedweb.com.

For two decades, organisations have been improving digital systems. Interfaces got better. Platforms got faster. Software became genuinely more usable. From the outside, it looks like steady progress – and in the places you can see, it largely was.

Underneath, very little changed.

The way organisations produce, structure, and maintain what they know – their documentation, their product information, their policies, their institutional expertise – remained fragmented, inconsistent, and largely ungoverned.

Content debt: Twenty years of shortcuts, past due

The result of two decades of ignoring the substrate has a name: content debt. The accumulated shortcuts, the fragmentation, the governance challenge that got kicked down the road for another time.

For a long time, that didn’t matter. Because there was a buffer: humans.

When a website was unclear, users (the technical jargon invented for when a human being has a screen in front of their face) navigated around it. When information conflicted, they reconciled it themselves. When content failed, they called support.

The system didn’t need to be completely coherent. It just needed to be good enough for a human to compensate for it being barely coherent.

That buffer is gone.

AI systems don’t navigate around ambiguity – they expose it. They cannot distinguish reliably between conflicting versions unless the source material carries governance signals that make those distinctions legible. They don’t compensate for weak source material. They operate on it, at scale, with outputs that appear confident regardless of whether they’re correct.

Which means something that was always true, but rarely consequential enough to fix, has become unavoidable: every digital system runs on a substrate, and in knowledge systems, that substrate is content.

This is where most organisations misdiagnose what’s happening. They’re treating language-based AI the same way they treated data systems – as an engineering problem. That works when the system processes numbers. It breaks when the system processes meaning.

Quantitative systems depend on data infrastructure: pipelines, warehouses, schemas. Improve those and performance improves.

Knowledge systems depend on something else entirely – the quality of the source material, how it’s organised, how it’s maintained over time. Structure doesn’t fix unclear thinking. Pipelines don’t fix inconsistency. Engineering cannot compensate for a lack of meaning.

The structural squeeze

Attention on AI initiatives gets pulled in two directions simultaneously: upward toward what’s visible (interfaces, demos, customer-facing features) and downward toward what can be built (models, platforms, custom infrastructure).

Between those two forces, the layer that actually determines whether any of it works gets missed entirely.

Organisation deploys an AI tool. Performs well in controlled conditions. Underperforms in production. Performance plateaus at 30, 40, 50 percent of what was projected.

There is now an accumulated body of research reporting on the high failure rates of AI implementation in enterprise. If you want the evidence in your hands: Google it. Or ask AI.

The shape of the failure is increasingly familiar.

Product names conflict across teams. Guidance exists in multiple versions. Ownership of accuracy is unclear. The system hasn’t failed. You might even say that it’s actually done a bloody good job of surfacing the state of the organisation’s knowledge.

The response – optimise the model, refine the prompts, increase the budget – doesn’t materially shift the outcome. The constraint was set before the system was deployed. It was set by the content infrastructure feeding it.

An LLM is optimised to sound confident and authoritative. Being correct is not what it’s actually doing.

The last thing you’ll ever get back from any AI model is this:

“I’m sorry, what you’re telling me doesn’t make much sense. I can’t work under these conditions.”

Give an LLM almost any prompt, no matter how incoherent, and its default behaviour is to work with it – to normalise it, extend it, and make it sound plausible. Stopping the exchange to say "this doesn't make sense" is not what these systems are built to do.

The same logic is why website redesigns so often produce a temporary lift rather than a lasting change.

You can redesign the surface as many times as you like. The ceiling is set underneath it.

Agentic systems remove the last checkpoint

Agentic systems make this significantly harder to ignore. A retrieval system that surfaces wrong information is an annoyance.

An agentic system that acts on it – planning, retrieving, analysing, executing, without a human checkpoint in between – is a different kind of problem.

Every inconsistency, every gap, every ambiguity compounds through the chain. In customer support workflows, that can mean a system confidently resolving a query against outdated policy logic, obsolete product guidance, or contradictory service rules.

None of this is a technology problem.

In every organisation, a knowledge system already exists – it’s just not designed. Marketing writes one version. Product writes another. Support maintains a third. Ownership is assumed rather than assigned. Standards are implicit rather than documented. Maintenance happens reactively, when something breaks badly enough that someone notices.

The organisations that understand this will approach the next phase differently.

They’ll start with the substrate – clarifying what’s actually known, structuring how it’s organised, defining how it’s maintained – before deploying systems on top of it. They do that because it’s the only way the systems perform.

The question is no longer what your system looks like. It’s what it knows, and whether that knowledge can be trusted.

Before the architecture conversation

That question has a methodology.

A content infrastructure diagnostic runs before the architecture conversation, before the vendor evaluation, before the first procurement decision.

It maps what the organisation actually knows – and what it would need to address before any system built on top of that knowledge could be trusted to perform.

Most organisations reach it in the post-mortem. It works considerably better at the start.

The company in question is a medium-sized enterprise in the knowledge industry. The tool that wowed them in the demo was supposed to revolutionise how the company accessed, shared, and collaborated on internal knowledge.

Instead, it scaled chaos. Incoherence. Inaccurate answers. More noise than signal.

The root cause? The knowledge base the tool was feeding from was itself chaotic. Contradictory terminology. Duplicated resources. Conflicting definitions and messaging across departments.

The AI faithfully synthesised everything it found – which is to say, it faithfully synthesised the confusion it was given to work from.

AI doesn’t create organisational knowledge. It reveals how well it already exists.

The recommended fixes from the vendor: better data quality upstream. Consider creating a knowledge graph.

Both are the right tools for a different class of problem to this one, though.

Data engineering is the right tool for AI applications that process quantitative data. Predictive analytics, financial forecasting, fraud detection, and so on.

It solves for quantitative systems: forecasting, fraud detection, optimisation.

But knowledge AI operates on language.

That’s a different class of problem.

Similarly, knowledge graphs only add value once the foundational fundamentals of canonical substance, clean taxonomy, and content modelling have been applied to the knowledge base.

If either condition is present, the constraint isn’t engineering.

It’s editorial.

Most knowledge-industry companies begin by framing AI investment decisions as an engineering conversation, with the first-order action being: build a system or procure one.

Then, when performance doesn’t meet expectation, they work backwards through failure layers until they reach the root cause: the organisation’s knowledge material is the bottleneck, not the AI itself.

The transformation they’re chasing is more epistemological than technical.

This is an article about the sequence that prevents that.

The sequence less-followed

There is a sequence to knowledge AI implementation that works. It runs in this order:

1. Editorial substance

Content is canonical, coherent, accurate, current, and consistent enough, not only for human users to easily understand and use it, but for AI users too. This is the foundational layer. It’s the least exciting investment, but nothing can actually be built above this foundation if it’s broken.

You cannot structure incoherence. You cannot retrieve meaning from noise.

2. Information architecture & content modelling

Once the substance is sound, this layer structurally organises it: mapping the territory so retrieval systems can navigate it. Information architecture sets the organising logic – category schema, taxonomy, navigational labelling, metadata. A content model defines what different types of content are, how they relate to each other, and what they mean within the broader business domain. Together, they produce the semantic architecture that knowledge representation can encode.

3. Knowledge representation

The encoding of that modelled content in formats that retrieval and AI systems can process: embeddings, indexes, knowledge graphs, context packages. This layer is where the engineering work begins – but it is entirely dependent on having something worth encoding.

4. Retrieval and context

The AI tool. The interface. The thing that gets demo’d in procurement conversations, evaluated by vendors, celebrated in launch announcements… and blamed in post-mortems.

The sequence matters because each layer is a prerequisite for the one above it.

Retrieval cannot outperform the knowledge representation feeding it. Knowledge representation cannot impose structure on content that has none. Content modelling cannot organise material that is incoherent at the substance level.

Remove the foundations and the ceiling drops. Categorically.

The tool doesn’t perform slightly worse. It fails in a way that no subsequent engineering investment can fix, because the constraint sits below the engineering layer entirely.

What’s happening instead

Almost nobody is currently following the sequence that would enable successful knowledge AI implementation.

In practice, the process runs in the opposite direction. An organisation identifies an AI technical capability (not necessarily analogous with an actual business opportunity) – usually through a vendor demonstration, a competitor announcement, or a board directive. Then, they procure a tool.

Layer 4 arrives first.

Layer 3 is addressed as implementation begins, when the tool’s appetite for structured data becomes apparent.

Layer 2 becomes visible when the retrieval results are incoherent and someone diagnoses a taxonomy problem.

Layer 1 – the substance layer – surfaces last, in the post-mortem. And even then, often misdiagnosed as a “data quality issue” in the absence of any content expertise sitting at the table.

By that point, the pattern is set.

The organisation has already invested in tooling and knowledge representation – building technical infrastructure on top of knowledge base content that was never assessed.

The fix requires going back to the beginning: what does this content actually say, and is it fit for purpose for the tool’s use case?

But that’s not what happens.

What happens is a doubling down on what the organisation already knows how to do: more engineering.

More structure. More systems. More attempts to impose order downstream.

The result: a second round of spend, a longer timeline, and the persistent belief that the problem must still be technical.

It isn’t.

The problem began before the engineering started.

Why the sequence produces a predictable outcome

The backwards pattern produces a specific failure mode that is observable, consistent, and well-documented – even if rarely diagnosed correctly.

When retrieval is built on fragmented content, the AI synthesises the fragmentation.

If Marketing uses five product names and Product uses two, and none of them overlap exactly, the tool will return contradictory answers because the source material is contradictory.

That’s not “hallucination”. The model is working correctly and within a perfectly manageable context window.

The problem is editorial source quality – which the technical post-mortem will call a data quality problem, because that’s the vocabulary available.

When knowledge representation is built before content modelling, the semantic architecture reflects whatever structure the content had when it was indexed – which is usually the structure of accumulated accident, not intentional design.

Adding embeddings on top of an unorganised, bloated knowledge base indexes the disorganisation and bloat.

And when content modelling is attempted without editorial substance underneath it, the taxonomy becomes an exercise in mapping multiple content items that shouldn’t be there in the first place.

You can assign ‘clean’ metadata to content that contradicts itself. You can seamlessly link relationships between thousands of content assets via a vector database and have it beautifully represented on a knowledge graph – even where half of the corpus added is irrelevant, contradictory, off-message, strategically at cross-purposes, outdated or just plain incorrect.

The structure works. The retrieval quality is excellent.

It’s the actual source content that’s the problem.

Why the backwards pattern keeps happening

The backwards sequence is a structural outcome of who leads AI implementation decisions and what vocabulary they use.

Many of the organisations advising enterprises on AI readiness – major consultancies, system integrators, and a lot of AI vendors – literally built their frameworks for quantitative applications and according to best practices defined through the lens of technical architecture.

Predictive analytics. Fraud detection. Recommendation engines. Process automation.

These are applications where “data quality” is precisely the right diagnosis. Where clean pipelines and normalised schemas directly determine performance.

Language-based AI – enterprise search, knowledge retrieval, document synthesis, question answering – is a different category.

The input isn’t numerical records. It’s the content of the corporate brain: knowledge bases, the website, reams of documentation, policies, external and internal communications assets, procedures, policies.

Whether that content is clear, consistent, and task-oriented is not a data engineering question. It’s an editorially-defined user experience question.

Consulting frameworks developed for the first category were applied to the second without adaptation.

And both the vocabulary and the frameworks they describe – data readiness, data governance, data quality – have been carried across, unchanged.

Because the vocabulary frames the diagnosis, the diagnosis stays in territory that data engineers can comfortably address – even when the actual problem sits way beyond what they can comfortably solve.

The actual builders of frontier AI models don’t actually have this problem. Quite the opposite.

Anthropic, OpenAI, Google, and the companies that train AI through human feedback – they value the role of content and knowledge management expertise as being at the heart of everything they’ve built. They hire content designers, content strategists, content reviewers, editors, linguists, academics, and subject domain experts.

Training AI to produce coherent outputs requires linguistic judgement and taste. The enterprises implementing those models face the same requirement.

But the consultants advising them come from a discipline that doesn’t have those capabilities – and so frames the problem in terms of the capabilities it does have.

This is how a rational system produces a consistent error. Every participant follows their own incentives correctly. The outcome is still illogical.

What this means for the next investment

Most organisations reading this have already been through at least one backwards implementation. Or are in the middle of one.

The instinct, coming out the other side, is to find a better tool. A more capable model. A vendor with a more robust retrieval architecture. These will not fix a substance problem. They will perform the same failure more expensively.

Before the next procurement decision, a content infrastructure assessment changes what gets measured. It works backwards from the question the AI will be asked – not the question of whether the technology is capable, but whether the content it will synthesise is capable.

Three things it surfaces:

Substance. Is the content coherent, consistent, and accurate enough for AI to synthesise without producing wrong answers? Are there conflicts between what Marketing says and what Product says? Are policies updated across all the documents that depend on them? Is the knowledge base 30% signal and 70% accumulated noise?

Structure. Is the content organised in a way that allows retrieval to work? Not “is there a taxonomy” – there usually is. Is the taxonomy doing the job: connecting related content, distinguishing overlapping concepts, making relationships machine-navigable?

Governance. Are there processes that will prevent the content from degrading the day after implementation? A knowledge base that passes a readiness assessment today will fail within six months without operational ownership. AI doesn’t improve content governance. It exposes its absence.

These questions should be asked before any retrieval architecture is specified, before any vendor is evaluated, before any contract is signed.

They’re not more important than the technical questions. This is not another ‘content-first’ rallying cry. Their answers determine whether the technical investment will land.

You cannot engineer your way out of a lack of editorial substance, coherence, and quality.

The engineering layer assumes quality exists. Content strategy creates it. These are not sequential options. They are a dependency chain.

The forward sequence

The backwards pattern is expensive to correct once you’re inside it. The forward sequence is not particularly complicated before you start.

Assess the content infrastructure before specifying the technical architecture. Understand what the AI will actually ingest before deciding how to encode it. Identify the editorial gaps before commissioning the retrieval system.

This sequence requires bringing content expertise into conversations that currently exclude it – not as a ‘nice-to-have supplement’ to the engineering conversation, but as the prerequisite upstream input that makes downstream engineering decisions meaningful.

It also changes the timeline. Organisations that follow the forward sequence spend longer in assessment before procurement. They invest earlier in work that has no interface, no demo, no vendor celebrating the contract.

It looks slower. It isn’t. It's simply the only way to build a system that actually works..

The implementations that deliver measurable return after twelve months are not the ones with the most sophisticated retrieval architecture.

They’re the ones that knew what their content could support before they built anything on top of it.

Most organisations try to fix AI at the system layer.

The constraint doesn’t live there.

It sits below it – in what the organisation actually knows, and how well it knows it.

Cloud computing took a decade to stabilise. DevOps sparked years of argument. Microservices still divides opinion at the edges.

But in every case, the disagreement was about implementation. The engineering community converged quickly on what the root problem was – even when how to solve it remained hotly contested.

NIST had a workable definition of cloud computing by 2011. DevOps arguments were fierce, but nobody was confused about the goal. Microservices debates were architectural – not definitional.

Engineering disciplines generate implementation debates that last years. What they don’t do is spend 24 months unable to stabilise the definition of the problem they’re solving.

Now look at AI implementation that runs on language models.

2024: prompt engineering – the problem is how you phrase the question.

2025: context engineering – no, hang on… the problem is how you architect the information environment.

And the sequence continues – in more niche corners, off-shoots of the same debate appear.

‘Intent engineering’ (no, the real skill is articulating the objectives and outcome constraints to your agent), and even ‘specification engineering’ (yes but also… let’s remember about precise specifications).

That’s not an implementation debate. It’s a discipline encountering a problem it doesn’t yet have the vocabulary to resolve.

Each new iteration a fresh attempt to name what the previous one couldn’t: the actual requirement in each case boils down to providing AI systems with coherent, relevant content assets that machines can read.

And the master skill in question is more editorial than architectural.

The category error hiding in plain sight

When disciplines fail to converge on problem definition, it usually means the problem sits outside the domain attempting to define it.

The divergence here – at the level of what the problem is – points toward a boundary condition: tools developed for one class of problems being applied to a fundamentally different class.

The current dominant term gives the game away.

Because context engineering contains a category error in its own name. Engineering implies construction – specify requirements, build components, assemble a system.

But ‘good context’ isn’t something you build. Context is what good content infrastructure produces.

You cannot engineer the output while skipping the process that generates it.

This is not an argument against context engineering. The technical discipline is real. The optimisation is legitimate.

But it operates downstream of something it cannot itself produce – and that upstream dependency is where most AI implementations hit their ceiling.

The name encodes the mistake. 18 months of core definitional language iteration, with no sign of convergence, encodes the proof.

The course correction that still can’t hold

Prompt engineering arrived first, and with confidence. Better inputs, better outputs. Courses launched overnight. Job titles appeared. The implicit assumption: the problem is how you phrase the question.

It didn’t hold. It couldn’t. Output quality turned out to depend far more on what the system could access than on how you asked.

Context engineering was the legitimate correction. The problem isn’t the question – it’s the information environment the system operates in. Retrieval architecture. Memory management. Knowledge graphs. The implicit assumption revised: fetch the model the right information, and it will produce the right output.

This is closer. It’s also the point where the unexamined premise becomes visible.

Context engineering presupposes that the information being retrieved is coherent, consistently structured, and organised in ways the system can navigate. When the underlying content contradicts itself across systems, sophisticated retrieval doesn’t solve the problem. It retrieves the contradiction efficiently.

The correction was real. The upstream assumption was still unexamined.

The engineering community hasn’t been secretly ‘doing content strategy’.

It’s been building technically legitimate systems that keep encountering the same upstream constraint – and reaching for new vocabulary each time it does.

That’s not a failure of engineering. It’s a boundary condition.

To understand the challenge of context engineering, let’s look at Pokémon.

Said no one, ever.

Oh hang on, except (checks notes)… Anthropic.

Anthropic’s guidance on context engineering is rigorous and precise. It defines the task of context engineering for AI agents as:

“Find the smallest possible set of high-signal tokens that maximise the likelihood of some desired outcome.”

That is a valid optimisation problem. Context windows are finite. Attention budgets degrade with scale. Token management matters.

But the formulation contains an unexamined premise.

High-signal… relative to what?

Signal doesn’t exist independently. It depends on coherence, consistency, and accuracy in the source material.

The guidance treats context as something to compress and route efficiently inside a model’s attention window. It does not address how that context is produced – or degraded – upstream.

The most revealing illustration appears in the article’s long-horizon task example: Claude playing Pokémon. The agent maintains detailed tallies across thousands of steps. Tracks objectives. Builds maps. After context resets, reads its notes and resumes multi-hour strategies without losing coherence.

Impressive. Except Pokémon is a completely closed system.

Every rule is defined. Every entity is specified. Terminology is perfectly consistent across the entire environment. The content infrastructure of a video game is structurally flawless.

Enterprise environments are not Pokémon.

Multiple departments. Conflicting terminology. Fragmented systems. Unclear ownership of accuracy. Policies that contradict each other.

Applying techniques proven in a perfectly specified environment to a structurally incoherent one – and expecting similar coherence – is not an engineering failure.

It is a domain mismatch.

The enterprise challenge isn’t just scale

The current engineering discourse handles the challenge of applying the principles of context engineering to enterprise scale with a kind of confident equivalence.

Solo practitioners: just get your file repos and docs into shape.

Enterprises: same challenge basically, just at a larger scale.

As if scale were the only difference. But the logical gap between them is the entire problem.

Taking a fragmented, multi-departmental, politically contested, terminologically inconsistent corpus of organisational knowledge accumulated over decades across incompatible systems – and making it coherent, consistent, and machine-readable – isn’t a ‘context engineering challenge’.

It’s a content infrastructure crisis.

The problem isn’t how you spec in work and ‘context assets’ to the agent. The problem is that the underlying content that defines context is usually not fit to be worked on by any agent.

The specification vocabulary describes what needs to happen. It has nothing to say about how.

You cannot specification-engineer your way out of thirty departments using different terminology for the same product.

You cannot intent-engineer around a substantial knowledge base when nobody owns organisational truth.

You cannot context-engineer coherent retrieval from content that contradicts itself across systems.

Why the loop keeps running

The problem iteration sequence has a structural explanation.

Engineering Bias is the first driver. When AI implementation fails, organisations reach for engineering solutions. Engineering has solved most technology adoption problems of the last three decades.

But knowledge-based AI failures aren’t technology problems. They’re editorial problems wearing technology symptoms.

The instinct to fix them technically is well-funded but consistently insufficient. The engineering quality is fantastic. It’s just applied to a problem that sits upstream of where engineering begins.

Interface Bias compounds it. Decision-makers evaluate AI by what’s visible: chatbot demos, generative interfaces, customer-facing features.

The operational applications where the majority of value lives have no demo, no vendor pitch, no competitive urgency. Investment follows visibility. Visibility is not the same as value.

Together, they guarantee that content infrastructure rarely gets assessed. Almost never prioritised.

Engineering Bias ensures the solution always stays technical.

Interface Bias ensures the problem being solved is always a visible one.

Neither registers content infrastructure as an urgent priority – so it never makes the agenda.

The problem definition iteration loop is what this compound blind spot looks like from inside a single discipline: making genuine progress, encountering the same upstream ceiling, reaching for another technical layer.

Coining another term when the reaching doesn’t land on anything solid.

The Anthropic guidance is what it looks like from the top of the stack: technically rigorous, beginning at the exact point where content infrastructure has been assumed into existence.

This is the mechanical explanation for why the majority of AI implementations stall.

Not inadequate engineering. Systemic oversight built on decades of institutional bias that favours engineering and visual design inputs over editorial judgement – even when mounting evidence shows that editorial judgement is the exact ‘hard skill’ unlock this moment requires.

Organisations investing in the engineering stack while the editorial foundation remains unassessed. Each correction technically sound. Each one discovering, eventually, that the prerequisite input expertise remained out of the picture, just as it was desperately needed the most.

The missing layer

The proliferating terms are the signal: the problem sits one layer above the domain attempting to solve it.

Engineering isn't the right domain for solving content problems. Content is.

Each iteration of the problem definition names a real prerequisite. But the pain lies in discovering each one after the expensive AI investment has been made, rather than before it.

Before deep-diving into context engineering or following the latest guidance on token efficiency – ask a more fundamental question: what can your content infrastructure actually deliver today, and what gap exists between that and your intended AI outcomes?

That’s a content infrastructure strategy question. The engineering community is multiple iterations into discovering the same thing, even if wrapped in language that makes it ‘sound engineering’.

Engineering isn’t failing to solve AI implementation.

It’s just discovering – one layer at a time – that the problem begins before engineering does.

But it isn’t the same thing.

To be clear, semantic layer engineering, linked metadata, structured context, taxonomy design, ontologies These are essential capabilities carried out by brilliant people.

They are also only one layer of the multi-faceted content ecosystem that I refer to as content infrastructure.

Content architecture or content engineering is an integral part of content infrastructure. It is not the whole of it.

Collapsing the two leads to an expensive category error. And right now, the collapse is what’s happening in most AI discourse.

Why architecture rose to the surface

AI strategy is currently shaped primarily by engineering disciplines. Not a criticism – an observation of a pattern that played out in the web era, too.

Engineering defines the technology. So engineering defines the vocabulary. And for a period, before adjacent disciplines catch up and assume authority over specific use cases, engineering effectively gatekeeps every aspect of how the technology gets applied.

The web went through this transition visibly.

1995: The internet is here. A team of developers will help us figure out how to build a website. They’ll manage it. They’ll own every aspect of it, in fact.

2005: A dedicated website team with no coding capability manages the website using a CMS. Obviously.

AI is at 1995.

When engineers evaluate what “content infrastructure” means, they pattern-match to what their discipline recognises. Semantic layers. Structured context. Taxonomy modelling. Linked data. Explicit knowledge representation. These have direct analogues in how engineers already think about systems. So they land immediately. “Ah right – LLMs require a semantic layer of engineering. Makes sense.”

“Editorially review, cut down, curate and revise your bloated, inconsistent, low-value knowledge base content” has no engineering analogue. Whatsoever.

It sounds like someone else’s job. It sounds like a much ‘softer’ job. A job without scientific rigour, at that.

In a system where funding, vocabulary, and decision rights sit inside engineering functions, architecture will always rise first. Not because it’s wrong – but because it’s most legible to the functions currently defining the vocabulary.

The result is a systematic distortion of what content infrastructure actually requires, driven not by evidence but by disciplinary resonance. Architecture rose to the surface because it speaks engineer. The other layers sank because they don’t.

This is Engineering Bias producing a measurable market outcome.

Rail infrastructure isn’t just tracks

Let’s (casually, as we all do every now and again when we’re in a philosophical mood, right?) think about what rail infrastructure actually is.

Tracks. Overhead cables. Stations. Vehicles. Maintenance schedules. Staff. Ticketing systems. Safety protocols. Operational governance.

Remove any one of those components and the system fails. No cables means no power. No maintenance schedules means vehicles break down. No operational governance means the whole thing runs erratically regardless of how well-laid the tracks are.

Content infrastructure works the same way. Three layers. Each dependent on the others.

Substance is the editorial layer – whether content is accurate, clear, consistent, relevant, and purposeful. Does the same product get described the same way across Marketing, Product, and Support – or does it have four names, three sets of specs, and two contradictory pricing structures? Can a system trust what it’s being fed?

Structure is the architectural layer – taxonomy, metadata, content models, information architecture. Whether content can be found, filtered, and connected. This is what content engineers build. It’s essential work.

Governance is the operational layer – who owns what, how content gets maintained, what happens when something changes. Without it, whatever you build in the Structure layer degrades the moment organisational reality asserts itself.

These layers operate in inter-dependence, rather than strict hierarchy or sequencing logic. They constrain and enable each other. Governance gaps degrade structure over time; structure gaps make substance harder to maintain at scale; substance failures mean the architecture is organising the wrong things.

Neglect any one layer while investing heavily in another and you’re not truly building infrastructure.

You cannot semantically engineer meaning out of nonsense

For most organisations, the root cause preventing their content from being fit for knowledge AI isn’t that it’s not semantically mapped.

It’s that the content (by machine standards if we’re being polite; but in all reality, by most human standards if we’re being truthful) is bad.

Not structurally lacking. Editorially lacking. The basics: unclear, bloated, circular, irrelevant, dense, impenetrable information. Half of which was the product of either internal politics or corporate vanity (or both), rather than the result of what anyone actually needed to know about, care about, or do anything with.

And if that’s the experience of a human reader on the average corporate website, customer support knowledge base, employee intranet – what chance does an AI stand of making sense out of it?

Linked data is a graph of semantic relationships between entities. An entity is a node. A node contains meaning.

What happens to the graph when the nodes contain the type of editorial bloat and waffle described above?

When information is inconsistent, unclear, duplicative across departments, contains non-canonical messaging, and conflicting definitions, and term variances, and basic discrepancies in core product and service names…

Is that a semantic connection and contextual retrieval problem? Yes. But more fundamentally? It’s a core meaning problem that originates in the basic production of the substance, not in the structure that’s wrapped around it.

Even an elegantly constructed semantic graph doesn’t resolve that.

Structure work amplifies whatever’s in the substance layer. Which is enormously valuable when the substance is sound. But a liability when it isn’t.

I’ve seen this in practice. Enterprise search tools deployed on content that contradicts itself across departments. The tool works. The results are reliably unreliable. Users stop trusting it within weeks. The implementation gets blamed. The real problem – that the actual substance of what’s being queried is itself, inherently incoherent – goes unexamined.

Increasing signal means decreasing noise

There’s a related insight that follows directly from this.

One of the most powerful things most organisations can do to prepare their content for knowledge AI isn’t necessarily to semantically map it. It’s to cut a significant proportion of it.

Semantic architecture applied to content bloat doesn’t resolve the bloat – it encodes and indexes it. AI retrieves the redundant alongside the relevant, synthesises across contradictions it has no way to reconcile, and produces output that faithfully reflects the input. At speed.

Humans compensated for this for decades. The redundant departmental update that nobody read or used in the first place… nor retired. The five-year-old policy document that still ranks in search. The three contradictory product descriptions that exist because Marketing, Product, and Support each wrote their own takes, in silo.

Human skimmed past all of it and extracted the signal anyway. In spite of the bloat. Inefficiently, but functionally.

AI can’t do that. Every orphaned asset, every politically-motivated page, every duplicate that survived a migration because deleting things ‘felt risky’ – all of it enters the corpus as signal.

It ingests with equal weight — no organisational memory, no basis to decide which of two contradictory descriptions is authoritative, no way to recognise an orphaned asset without a governance signal.

It will then produce output that looks like ‘bad AI’. It isn't. It's accurate AI, reporting faithfully on bad content. The AI says: you are bloat. Therefore, I will become bloat.

Increasing signal sometimes means decreasing noise. Not adding structure to it. That’s an editorial decision. It requires editorial judgement. No taxonomy schema or graph substitutes for someone deciding what the organisation actually needs to communicate – and retiring the rest.

Editorial curation is itself a form of context engineering. Maybe the most powerful form of context engineering available. But nobody’s really talking about it. Why? Because it doesn’t sound engineering enough.

The case for completeness

None of this is an argument against content engineering. The argument is for completeness.

Taxonomy design, IA, metadata systems, linked data – structure layer expertise is essential, and it requires specialist skill that most content strategists don’t have. The organisations doing this work well are ahead of most of the field.

An organisation that has invested seriously in semantic architecture – taxonomy design, linked metadata, content models – but left substance and governance untouched hasn’t completed its content infrastructure work. It has completed one layer of it.

The architecture will surface contradictions faster. It will make the substance problems more findable, not less. And without governance in place, the architectural work degrades the moment the organisation starts changing – which it always does.

Each layer makes the others work. Structure-layer engineering succeeds or fails based on what’s in the substance layer – and degrades over time without the governance layer maintaining what’s been built. That’s not a criticism of any particular layer. It’s a systems observation that each layer is important – and inter-dependent, for the whole to succeed.

Content infrastructure is a complete system. The discourse is describing one layer of it as if it were the whole – and organisations are making investment decisions on that basis.

The architecture will tell them what’s missing. It just won’t tell them in time.

Engineers built the infrastructure.
↓
Designers crafted the interface.
↓
Content got plugged in at the end.

This worked because interfaces were most of the value. A well-designed, intuitive website could succeed with mediocre content. Users forgave unclear copy if the experience was smooth. Content was important, but it was the 5% you sorted out once the ‘real work’ was done.

AI inverted this.

The flip

With AI, the interface is commodity. Every chatbot looks roughly the same. Every search box works similarly. The visible layer – what organisations obsess over in demos – is perhaps 20% of the value.

The other 80%? The content infrastructure underneath.

‘Content infrastructure’ isn’t a term that arrived with the AI hype cycle. It describes a specific, multi-layered system of capabilities.

Substance – the editorial quality layer

Where maturity starts.

• Do you have a consistent, coherent, relevant body of content to feed an AI system?

• Is the writing clear enough for AI to synthesise?

• Does terminology stay consistent across departments?

• Do marketing promises align with what support documentation actually says?

Without substance-layer maturity, nothing else works. You can’t structure what isn’t coherent. You can’t govern what nobody has made consistent. Most organisations stall here – they’ve never invested in making their content accurate, consistent, and current across the enterprise.

Bottom line: quality gaps at this layer set an absolute ceiling. No amount of technical tuning compensates for contradictory or outdated source material.

Structure – the semantic architecture layer

Once content is coherent, it needs to be organised for AI retrieval and understanding.

Is there a unified taxonomy and metdata schema, or do five departments use five different names for the same product?

Is content semantically mapped and modelled so AI can understand relationships between concepts?

This is where content architecture and knowledge engineering live. But this work presupposes that the substance layer is already sound.

Architecture organises meaning. It does not create it.

Bottom line: structural fragmentation means AI retrieves the wrong content – or nothing at all.

Governance – the content operations layer

Content needs governance to stay coherent over time. Who owns accuracy? What happens when products change – does documentation update, or does outdated content accumulate alongside current content? Are there workflows ensuring quality control?

Knowledge AI governance operates on two surfaces.

Organisational content governance covers the human ownership model: workflows, standards, and policies that define how content gets created, maintained, and kept current.

AI system context governance covers the system’s own operating parameters: role scope, skills, workflows, and guardrails that define how it executes within that organisational context.

Both are content governance problems. Both deteriorate without active ownership.

Bottom line: even when substance and structure are strong, governance gaps mean quality decreases. Performance isn’t just about current state – it’s about sustaining that state over time. Most organisations are managing neither surface.

The maturity sequence

Rather than being independent, these layers represent a sequential progression:

1. Substance first: Get content consistent, accurate, and current

2. Structure second: Architect content for AI retrieval and semantic understanding

3. Governance third: Establish the operations that keep it coherent over time

Most organisations want to jump straight to structure – hiring content architects and knowledge engineers to build taxonomies and ontologies.

But you cannot semantically engineer meaning out of incoherent source material. The sequence exists because each layer sets a limit on what the next can achieve.

A content infrastructure assessment reveals not just what’s broken, but which layer the problem originates in – and what sequence of work will actually address it.

The questions to ask:

• What does the AI learn from?

• How accurate and consistent is that knowledge?

• Who governs what’s authoritative?

• How do contradictions get resolved?

These questions didn’t matter much in the web era. A human could paper over inconsistencies. A support agent could interpret confusing documentation. A sales rep could translate between Marketing-speak and Engineering-speak.

AI can’t. It synthesises exactly what you feed it. Incoherent foundations produce incoherent outputs – at scale, instantly, to every user.

This is the inversion: content went from ‘the thing you plug in at the end’ to the infrastructure everything else plugs into.

Most organisations are still operating as if the old model applies. Still evaluating AI by interface quality. Still assuming content will sort itself out. Still treating the 80% as an afterthought.

Content debt: Twenty years of shortcuts

The inversion wouldn’t be so consequential if organisations had solid content foundations. Most don’t.

For two decades, content strategy was systematically squeezed out of digital investments. ‘Hire designers and engineers – content will happen.’

Every year, a little more fragmentation. A little more inconsistency. A little more debt accumulating.

Content debt – the accumulated cost of shortcuts, fragmentation, and underinvestment in content operations – compounds like financial debt. And like financial debt, you can ignore it for a surprisingly long time. Until you can’t.

Consider a mid-sized B2B software company evaluating AI-enhanced enterprise search. The interface demos cleanly. Results look instant. AI-powered ranking seems intelligent. The vendor promise is the same whether they’re buying an off-the-shelf product or building their own agentic search capability: make all your content findable, in days.

They commit £120,000.

Three months later, the project sits unused. Search results are incoherent. Employees still message colleagues on Slack to find anything. The implementation is quietly shelved.

Nothing was wrong with the technology. Nothing was wrong with the implementation team. The constraint applied regardless of the approach they chose – bought or built.

The problem: twenty years of content debt, now exposed.

• The same product described five different names across departments

• Contradictory information and messaging between departments

• No governance over what’s authoritative

• Metadata so inconsistent the AI couldn’t map relationships

The tool worked. It faithfully surfaced exactly what it found: chaos.

Content debt has been able to accumulate subtly. Marketing and product use slightly different terminology – nobody notices because the website still works.

Engineering documents in one system, support in another, sales in a third – nobody notices because each team finds their own materials.

A merger happens, two taxonomies collide, nobody reconciles them because there’s no budget. Years later: seven different definitions of ‘onboarding,’ three competing product terminologies, orphaned content everywhere.

Nobody paid attention because websites still worked. Suboptimal – users complained that content was hard to find, terminology was confusing, information contradictory. But functional.

The human buffer compensated. Users browsed broken navigation, reconciled contradictory information, called support when content fell short. That labour masked the constraint for decades.

AI removed the buffer. The debt has always been there. It’s the consequences that have changed.

The web-era cost of content debt was: suboptimal websites, confused customers, frustrated employees. Annoying, but manageable.

The AI-era cost of content debt is: failed six-figure implementations, missed opportunities, competitors who addressed their content foundations pulling ahead.

AI systems don’t just display content the way websites do. They ingest it, index it, retrieve it, synthesise it, generate responses from it.

When that content is fragmented, inconsistent, and ungoverned, AI has nothing coherent to work with. The technology works fine. The foundations don’t.

Twenty years of content debt. Now the bill is due.

The urgency trap

Every organisation is facing AI pressure. Boards asking ‘what’s our AI strategy?’ Competitors announcing initiatives. Vendors promising transformation in weeks.

That pressure creates urgency. And urgency is where the content debt trap deepens.

Organisations feel they must act on AI now – but without understanding what those investments actually demand of their content infrastructure, urgency compounds the problem rather than solving it. Interface quality doesn’t predict operational value.

Technical sophistication doesn’t compensate for substance-layer gaps. And implementations on unassessed foundations tend to surface the debt rather than sidestep it.

What organisations can do is get clear on what their AI investments will require before the contract is signed.

The organisations succeeding with AI are focused on sequencing correctly, rather than speed. Which starts with addressing the foundations of what AI readiness for language-based systems means.

Content isn’t the 5% you plug in at the end. It’s the 80% that everything else plugs into.

Coming up

This is the first of a series laying out a complete framework for understanding AI’s content-shaped performance constraints.

Coming in the series: why content infrastructure is being conflated with content architecture across AI strategy discourse, why the engineering community has spent 18 months iterating on problem definition rather than implementation, the backwards implementation pattern, two blindnesses and two wrong turns, the 29 knowledge AI opportunities most organisations don’t know exist, and the assessment methodology and investment sequence that works.

By the end, you’ll have a complete picture: why implementations fail, what organisations miss, and what the sequencing looks like when it works.

But something has been shifting. As understanding deepens about what knowledge AI systems actually require – context, strong organising schema, scaled governance of information quality – something the industry has been circling for two years is now unavoidable.

Knowledge AI has exposed something the industry overlooked for twenty years: enterprise content strategy was never optional infrastructure. It was deferred infrastructure.

Knowledge AI needs enterprise content strategy. Not the narrowed, interface-focused content design version or the ‘content strategy = marketing content strategy’ versions that came to dominate current practice.

I mean: the full-scope, cross-departmental, infrastructure-grade version of enterprise content strategy that the discipline was originally built to deliver.

The prompt engineering moment

If you had even a passing interest in AI business trends through 2024 and into 2025, you encountered prompt engineering. It was everywhere. LinkedIn courses, enterprise workshops, job titles.

The framing was seductive and intelligent: AI gives better outputs when you give it better inputs.

Prompt engineering was advice about how individuals should talk to chatbot interfaces for better results. And for individual use, it works. Anyone who has compared a vague prompt with a structured one knows the difference is real.

But the moment AI moves beyond individual productivity, the limitation appears: the system can only operate within the context it’s been provided.

If you wanted to start using AI to assist with actual project or organisational-scale operations, then it doesn’t matter how well individual employees can phrase a query. The system needs access to quality, well-structured, and maintained information as its starting point for any incoming prompts.

Enter context engineering.

The context engineering correction

By late 2025, the conversation had evolved. Context engineering emerged as the more robust answer to the question of how to feed an AI with the right set of background information it requires to perform the more sophisticated role it was being primed to perform.

This is the threshold moment where AI output quality switched from being a matter of individual tactics to a matter of infrastructure preparation.

Prompt engineering focused on the question, context engineering focused on the infrastructure that feeds AI the right information, at the right time (right information, at the right time... content professionals in the room: starting to sound familiar?).

This was a meaningful advance. Engineers correctly identified that the quality of an AI system’s outputs is determined far more by what it can access than by how you phrase the request. A perfectly prompted query against a poorly organised knowledge base still returns poor results. A mediocre query against well-structured, well-curated information returns something useful.

What the engineering conversation often leaves implicit is this: context isn’t something that just exists.

Context is in itself an outcome effect of providing the right information, at the right time, to achieve a stated goal or output. What is it, the source material, that’s defining that context at an infrastructure level? Content.

Context is downstream of content. The substance, structure, and governance of organisational content is what determines context quality at scale.

But before getting to that, it’s worth noting a historical parallel. Because this isn’t the first time an industry has discovered that content needs infrastructure-grade treatment.

A familiar pattern

If you were working in digital in the early 2000s, you watched something remarkably similar play out.

The first generation of web projects was technology-led. Build the CMS. Design the interface. Launch the site. Content was assumed to be available – something that would fill the containers once the real work of engineering and design was complete.

It wasn’t available. Or rather, it was available in the way that most enterprise content is available: scattered across departments, inconsistent in quality, contradictory in terminology, owned by nobody in particular. The sites launched. The content was a mess.

The last time the industry made this mistake, a discipline emerged to correct it.

Ann Rockley’s Managing Enterprise Content in 2002 and Kristina Halvorson’s Content Strategy for the Web in 2008 articulated the same core insight:

Content is not a commodity that fills containers. It’s a strategic asset requiring coordination, editorial standards, structural planning, and governance across organisational boundaries.

That insight was revolutionary. It was, in hindsight, also ahead of its market. Through the 2010s, the economics of digital product development favoured tactical focus.

Content design instead emerged as a more immediately actionable practice – crafting interface language, standardising product content patterns, streamlining task flows, aligning content with user journeys. This was the flavour of content work that the market favoured and rewarded.

Content strategy practitioners adapted accordingly. The enterprise-level lens – the cross-departmental editorial strategy, information architecture work, and content governance frameworks – gradually lost their organisational home.

Nothing to do with professional failure. Everything to do with rational market signals.

In the web application era, the cost of ungoverned enterprise content was high but largely tolerable. Users compensated for content gaps through their own effort – browsing, comparing, exercising judgement. The business case for enterprise-wide content coordination was theoretically sound – but practically difficult to quantify against the immediate, visible returns of optimising the performance of product user journeys.

The discipline contracted. The problems it was built to address didn’t go away. They accumulated.

And now – as with the early web – a new technology is exposing exactly what was left unaddressed.

What individual AI users are already discovering

Back to context engineering – and what’s happening as it matures beyond the engineering community.

Individual users are figuring something out. Not in theory, but through daily practice.

Anyone who has spent serious time using AI as a working tool – a research assistant, a writing partner, a thinking aid – has gone through a version of the same learning curve. Early on, you focus on prompts. How do I phrase this to get a better answer? That’s the prompt engineering phase. And it works, up to a point.

Because what happens next is that you start realising the bottleneck isn’t how you ask. It’s what the system has been given to work with before you ask a thing.

So you begin curating those materials. The context. You feed it past report examples so it understands the format you need. You provide writing guidelines so outputs match your voice. You upload organisational context – your personal website, blog articles, planning documents, branding, product specs – so the system has the reference material it needs to produce something genuinely useful rather than generically plausible.

In other words: you build a personal content infrastructure. A curated, organised, governed set of reference materials for your AI system to draw from and cohere against.

This skillset and effort may have quickly come to be known as context engineering – but anyone with any sort of background in content strategy knows: this is doing content strategy for a team of one.

Selecting what materials matter in support of stated goals (and vice versa), structuring it for the highest-signal consumption, and maintaining it as things change and feedback loops point to incremental improvement.

The content dependency is the lesson everyone learns: the quality of AI output is constrained by the quality, completeness, and coherence of the content you feed it. Not by the model. Not by the prompt. By the substrate.

Now let’s scale that realisation.

An individual curating context for their personal AI assistant is manageable. One person’s reference materials. One person’s quality standards. One person’s judgement about what’s current and what’s outdated.

An organisation with 2,000 employees across six departments and four geographies faces the same dependency at a completely different order of complexity.

The knowledge that feeds the enterprise AI system needs the same coherence that an individual user painstakingly builds for their personal setup – but across multiple content platforms, departmental boundaries, content ownership silos, inconsistent editorial standards, and two decades of accumulated, ungoverned material.

Gulp.

Nobody is curating the organisational equivalent. Nobody is governing the reference materials that the enterprise retrieval system treats as ground truth. Nobody is ensuring that the product definitions, organisational messaging, and knowledge base materials are consistent, accurate, relevant, and up-to-date across departments and global regions.

The individual user’s learning curve – prompt craft matters less than context quality, and context quality depends on content infrastructure – is a leading indicator of what enterprises are about to confront at scale.

The dependency is identical. The complexity scale difference is monumental.

But there’s a professional practice that is pre-qualified to address content substance, structure, and governance quality at that scale.

It’s just been dormant in the AI space up until now.

Enterprise content strategy.

Content as infrastructure: three layers, three performance ceilings

When you treat content not as a commodity output but as infrastructure that sets performance ceilings for knowledge AI systems, a different assessment framework emerges.

Quantitative AI – the kind that processes numerical data, detects patterns in structured datasets, optimises logistics – requires data infrastructure. Clean, structured, governed data. Most enterprises have invested decades in building this capability. Data engineering is a mature discipline with established practices, tooling, and organisational recognition.

Enterprises would never run quantitative AI on unclean, ungoverned data. And yet. They routinely deploy knowledge AI against unstructured, unowned, and unmaintained content — and are surprised when performance degrades.

Knowledge AI – the kind that processes qualitative content, retrieves information, synthesises guidance, generates responses grounded in organisational knowledge – requires content infrastructure. And most enterprises have built almost none of it.

Content infrastructure has three layers. Each sets a ceiling that determines what AI can achieve – and each constrains the layers above it.

Substance is the editorial foundation. Completeness, accuracy, readability, accessibility, strategic relevance, voice and tone consistency. This layer determines whether AI responses are meaningful, accurate, and useful. It’s the equivalent of data quality in quantitative AI – and it’s the layer most organisations assess least. An AI system grounded in incomplete, outdated, or contradictory content will produce incomplete, outdated, or contradictory outputs. No amount of architectural sophistication changes this.

Structure is the organising schema. Taxonomy, metadata, information architecture, content models, semantic relationship mapping. This layer determines whether retrieval is precise – whether the system consistently surfaces the right information in the right context rather than returning everything vaguely related. Structure is where context engineering and content infrastructure overlap, and where engineers most often discover gaps they didn’t anticipate. Without coherent structure, retrieval degrades from “find the answer” to “find twenty things that might contain the answer.”

Governance is the operational framework. Content ownership, standards and guidelines, workflows, maintenance cycles, cross-departmental coordination. This layer determines whether performance is sustained as the system scales and content evolves. It’s the most chronically neglected layer because it’s the least visible. Governance failures don’t produce dramatic crashes – they produce slow degradation. The AI that worked brilliantly in the pilot gradually becomes less reliable as ungoverned content drifts from accuracy.

The dependency logic matters: each layer constrains the one above it. You cannot meaningfully structure incoherent content – taxonomy applied to inconsistent terminology just organises the mess more neatly. You cannot govern what nobody owns – workflows for content maintenance require someone to maintain. And you cannot engineer around a lack of substance – retrieval architecture that efficiently surfaces poor-quality content just delivers poor quality faster.

Where this leads

Three implications follow from this.

First: any enterprise assessing “AI readiness” without assessing content infrastructure is likely running a glaringly incomplete diagnostic. Context engineering without content infrastructure is building a delivery system for cargo that hasn’t been loaded.

The most sophisticated retrieval architecture in the world cannot compensate for source material that’s incoherent, contradictory, or unmaintained. Readiness assessments that evaluate only technical architecture and data pipelines are answering half the question.

Second: the widely reported high failure rates of enterprise AI initiatives aren’t primarily a technology problem. The technology works. Context engineering works. What fails is the assumption – almost never examined – that organisational content is ready to be processed at scale. It rarely is.

Twenty years accumulation of content debt across platforms, departments, and business units, without the infrastructure-grade governance that’s applied to data, has produced exactly the foundation you’d expect.

Fragmented, inconsistent, ungoverned, and invisible to the teams making six-figure procurement decisions.

Third: the expertise required to assess and remediate content infrastructure exists and is available. It emerged from a discipline that contracted its scope during an era when the market didn’t reward the work. The market now demands it.

The question facing enterprises isn’t whether content infrastructure matters for knowledge AI – it does, structurally and unavoidably – but whether they recognise the gap before or after the next implementation underperforms.

The trajectory from prompt engineering through context engineering pointed in this direction all along. Each step got closer to the actual constraint.

The final step – acknowledging that content itself is infrastructure, with its own assessment requirements and its own performance ceilings – is the one the industry has yet to take.

It will. The industry will get there.

The only variable is how much underperformance happens first.

Months (or even years) later, the same constrained performance levels remain. Plans are made to remediate and optimise. And yet the structural constraint was never diagnosed.

The constraint is content.

Why content infrastructure stays invisible

Two inherited biases from the web era explain why content infrastructure stays invisible in transformation planning.

Interface Bias – organisations evaluate digital performance by what’s visible: redesigned homepages, chatbot demos, polished UI. Meanwhile, the operational layer where the majority of durable value lives – retrieval, synthesis, quality assurance, compliance, knowledge management – gets no demo, no vendor pitch, and no board attention.

Engineering Bias – when asked “how to transform,” organisations default to “how do we build?” – custom models, ML teams, proprietary infrastructure, platform migrations, semantic engineering. This focuses attention on technical infrastructure constraints whilst wider content infrastructure constraints remain unassessed.

The compound effect: attention flows to the visible layer, investment flows to the build layer, and the structural constraint remains untouched.

From commodity output to infrastructure foundation

When content is treated as a byproduct of digital products and services, it behaves like one – fragmented, reactive, chaotic.

When content is treated as infrastructure, a different assessment framework emerges. Content-as-infrastructure has three interdependent layers:

1. Substance

2. Structure

3. Governance

1. Substance

The content quality layer

Is core content accurate, complete, and internally consistent? Can downstream systems – websites, search engines, AI tools – trust what they’re being fed?

Quality gaps here set a hard ceiling. No amount of platform tuning or interface optimisation compensates for contradictory or outdated source material.

2. Structure

The semantic architecture layer

Is there a unified content model across domains? Are taxonomy, metadata, and information architecture aligned – or has each department built its own structural logic?

Structure determines whether information can be found, filtered, synthesised, and reused at scale. Without structural coherence, every digital surface becomes a manual assembly exercise.

3. Governance

The content operations layer

Who owns content across domains? What happens when positioning shifts, products evolve, policies update?

Digital content governance now operates on two surfaces:

1. Organisational governance – the human ownership models, workflows, and editorial standards that determine how content stays aligned

2. Platform governance – how tool configurations and encoded features and rules either enforce or undermine that coherence.

Without governance, substance and structure deteriorate. With it, they compound.

What this publication explores

This publication examines digital performance through the lens of content infrastructure.

We’ll start with knowledge AI – mapping the operational applications most organisations overlook, and the infrastructure constraints most AI strategies fail to measure.

From there, we’ll apply the same three-layer model to website and content platform transformation – explaining why redesign cycles plateau, why migrations replicate fragmentation, and what the structural alternatives look like.