Context engineering: when meaning became the scarce resource.

There is a familiar progression in enterprise AI. First the model was the constraint, and it was obvious that a better model produced better results. Then the data was the constraint. Then it became integration, then workflow, then adoption. Each constraint was real while it was real, and each was superseded as the industry improved.

The current constraint is context — and it is less discussed because it is less comfortable. Context is not a technical artefact you can buy. It is the accumulated, current, authoritative meaning of your organisation, and nobody can sell you that.

What context actually means

Context is the material assembled and handed to a model for a particular task. It sounds trivial. It is not, because assembling it correctly requires answering four questions that most enterprises have never asked about their own information:

• Which source governs this question? When two documents conflict, which one applies — here, to this jurisdiction, to this customer type, at this date?
• What is the relationship between these facts? A policy, an obligation, a customer and an exception are connected. If the connection is not modelled, the model has to infer it, and inference at this level of consequence is not good enough.
• Which parts are relevant, and which are noise? Context is finite. Deciding what the model does not see is as consequential as deciding what it does.
• How do we know the context was right? When an answer is wrong, was the model at fault, or was it given the wrong material? Without this distinction, you cannot fix the system.

The six disciplines

1. Authority

Authority is the declaration of which source speaks for which question. It has to be explicit, because implicit authority is always resolved by whatever the retrieval layer happened to rank first. In practice this means governance data — provenance, jurisdiction, product scope, status, effective dates, owner — travelling with the content itself rather than living in a separate system that nobody joins.

2. Freshness

A confident answer from a superseded policy is worse than no answer, because it is actionable and wrong. Freshness needs to be a first-class attribute with real consequences: stale material excluded, flagged, or escalated. This is uncomfortable work, because it means actively retiring knowledge rather than accumulating it.

3. Structure

Flat vector search finds documents that are textually similar. Ontology resolves questions that depend on relationships. Where the answer requires traversing a customer to a policy to an obligation to a jurisdiction, structured resolution is not a refinement — it is the difference between working and not working.

4. Retrieval discipline

What gets assembled into the prompt should be designed, tested and measured rather than left to a default top-k. That means evaluating retrieval separately from generation: if the right material was not retrieved, the answer is lost regardless of how capable the model is.

5. Context budgeting

Attention is finite, and the marginal value of context is not linear. The right context for a task is deliberately selected — relevant, current, authoritative, and minimal. This is where cost, latency and accuracy converge, and it is why context design has direct commercial value rather than being a technical nicety.

6. Evaluation of the given

Most evaluations measure whether the answer was right. Far fewer measure whether the system was given the right material to be right. Both matter, and they lead to different fixes. An answer error with correct context points at the model or the prompt. A context error points at retrieval, governance or freshness — and no amount of model work will fix it.

Why this changes the economics

Context engineering is usually described as an accuracy technique. It is more valuable than that, for three reasons.

It compounds. The semantic foundation built for the first use case is inherited by every subsequent one. Delivery cost falls steeply with portfolio size, and this is the effect that makes an AI programme's business case improve rather than plateau.

It is model-agnostic. A well-structured, governed context layer works with whichever model is most capable at the time. That is genuine strategic optionality — you are not making a vendor bet to get accuracy, and you can change models without rebuilding your foundations.

It is hard to copy. Your data is available to your competitors; your explicit, owned, current ontology is not. If you want a defensible position in enterprise AI, the semantic layer is where it lives.

Where context engineering is done

It spans five stages, and skipping any of them leaves a gap that shows up later as an accuracy problem with no obvious cause:

1. Capture — extracting what the organisation knows from the people who hold it and from the artefacts they leave behind.
2. Model — representing it as entities, rules and relationships with named ownership.
3. Retrieve — designing and operating the retrieval layer, including managed GraphRAG where the answer requires traversing relationships.
4. Deliver — getting the resolved material to the person or agent, through copilots, embedded search, or an API the workflow calls.
5. Measure — coverage, resolution rate, citation integrity and grounding impact, so the layer can be improved on evidence rather than intuition.

Cyberwisdom's own tooling follows this shape: ontology-based knowledge management for the modelled estate, enterprise GraphRAG management for the retrieval layer, and a knowledge copilot for delivery to users at the point of work.

The organisational prerequisite

There is a precondition that does not appear in most engineering plans: somebody has to own the meaning. Not the data, not the models — the meaning. Typically this is distributed across business owners who have never been asked to formalise it, and it surfaces disagreements nobody has had to resolve before.

This is genuinely the hardest part of context engineering, and it is the part most likely to be skipped. It is also the part that determines whether the work is worth doing at all. An ontology with no accountable owner becomes an archaeological record within a year, and an archaeological record does not ground anything.

What to do on Monday

Three practical moves, in order:

1. Pick a domain that matters and is bounded. Not the enterprise. One process where the answer matters and the rules are knowable. You need to finish, because an unfinished semantic foundation is worth nothing.
2. Go and find the disagreements. Ask two teams to define the same concept. The differences are your first, most valuable findings — because those differences are already costing you, right now, whether or not anyone has noticed.
3. Instrument before you build. Measure what the system is given, alongside what it produces. Without both, you will spend the next year guessing which half of the problem you are looking at.