Most enterprise AI agent programmes do not fail because the model is too weak. They fail because nobody decided, in advance, what the agent is allowed to know at the moment it acts. That decision has a name now: context engineering. A BARC study published on 3 September 2026 found that organisations which formalise it are four times more likely to qualify as AI leaders than those that do not.
What is context engineering?
Context engineering is the discipline of assembling the right information, tools, instructions and history for an AI model at the moment it reasons or acts. It replaces the older habit of tweaking a single prompt. For an enterprise, it is the layer that turns a generic model into an agent that knows your policies, data and limits.
The clearest definition comes from Shirshanka Das, co-founder and CTO of DataHub, in the BARC release: context engineering is the practice of assembling the right inputs for a single AI agent call, while context management is the enterprise discipline of governing those inputs across many agents and data sources at scale. Both belong on a board agenda, because one decides whether a pilot works and the other decides whether it can be repeated.
The analogy that has stuck in the industry comes from Andrej Karpathy, who framed the large language model as a CPU and its context window as RAM. A CPU with the wrong data in memory produces the wrong answer regardless of its clock speed. That is why a department head who upgraded from one frontier model to the next and saw no improvement in agent reliability was probably looking at a memory problem, not a processor problem.
The context window itself is a finite budget. Anthropic's engineering guide on effective context engineering for AI agents describes the goal as finding the smallest possible set of high-signal tokens that maximises the likelihood of the outcome you want. Every policy document, tool description and chat turn you stuff into the window competes for the model's attention, and model performance degrades as the window fills. More context is not better context.
Why does context engineering matter for Hong Kong enterprises in 2026?
Hong Kong enterprises are moving agents into production while the PCPD tightens expectations on agentic AI. Agents that act on emails, contracts and customer records in three written languages need governed context to stay accurate and compliant. The competitive gap is opening between firms that treat context as infrastructure and firms that treat it as a prompt.
The BARC study, "Context Engineering for Agentic AI: Architecture, Use Cases, and Principles for Success", surveyed 285 data, AI, IT and business stakeholders worldwide. It classified 42% of respondents as context leaders, meaning they had implemented, formalised or optimised six foundational elements: data integration, workflow orchestration, retrieval methods, federated metadata, prompt engineering and the semantic layer. Among those leaders, 49% also qualified as AI leaders. Among everyone else, the figure was 12%.
The same study exposes where most organisations still are. Forty-four percent manage context inside a single agent, team or platform, while 43% manage it across teams, platforms or the whole enterprise. The second group can reuse a definition of "active client" or "approved supplier" across finance, operations and compliance agents. The first group rebuilds it every time, and every rebuild is a chance for two agents to disagree.
Hong Kong adds two local pressures. On 25 August 2026, the Office of the Privacy Commissioner for Personal Data published guidance on protecting personal data in the use of agentic AI, supplementing its 2024 Model Personal Data Protection Framework. The guidance treats agentic AI as a distinct risk category because of the access and autonomy granted to agents. Deciding what an agent can see is therefore no longer only an engineering choice; it is a PDPO data-minimisation decision. Separately, Hong Kong's working documents mix English, Traditional Chinese and Simplified Chinese, which means retrieval that works in a US demo often misses half of a Hong Kong contract archive.
How does context engineering differ from prompt engineering and RAG?
Prompt engineering writes better instructions for one request. Retrieval-augmented generation fetches documents to ground one answer. Context engineering governs everything the model sees across a whole task: instructions, retrieved data, tool definitions, memory and prior steps. Prompting and RAG are components inside it, not alternatives to it.
The distinction matters because many Hong Kong enterprises ran a RAG pilot in 2024 or 2025 and concluded that "AI is not accurate enough for us". In most of the post-mortems we have seen, the retrieval component worked; the problem was that the agent also received stale tool outputs, an over-long system prompt and no rule for when to look things up. According to Redis's State of Context Engineering 2026 report, 82% of IT and data leaders agree that prompt engineering alone is no longer sufficient to power AI at scale.
A practical way to brief your leadership team is to name the four inputs an agent receives on every step:
--- Instructions: the system prompt, policies and tone rules. These should be specific enough to guide behaviour but not so rigid that they break on edge cases.
--- Knowledge: documents, records and metrics retrieved for this task, ideally pulled just in time rather than pre-loaded in bulk.
--- Tools: the systems the agent can call, each with a description tight enough that the model never has to guess which one to use.
--- History: what has happened so far in this task, compacted so that the important decisions survive and the noise does not.
If your vendor can only talk about the first input, you are buying prompt engineering with a new label.
What does a mature context engineering framework include?
A mature framework has six governed elements according to BARC: data integration, workflow orchestration, retrieval methods, federated metadata, prompt engineering and a semantic layer. The semantic layer carries shared business definitions; federated metadata carries ownership and permissions. Without those two, every agent invents its own version of the truth.
For a COO or Head of Digital Transformation, the six elements translate into questions you can put to any internal team or vendor:
--- Data integration: which systems can the agent read, and is the connection live or a quarterly export?
--- Workflow orchestration: when a task needs three steps across two systems, who decides the order, and where is that logic recorded?
--- Retrieval methods: does the agent pull documents by keyword, by meaning, by metadata filter, or by a combination, and can you test which one is failing?
--- Federated metadata: is there a record of who owns each dataset and which roles may expose it to an agent?
--- Prompt engineering: are instructions versioned, tested and reviewed like any other controlled document?
--- Semantic layer: does "revenue", "headcount" or "client" mean the same thing to the finance agent and the operations agent?
The BARC respondents' priorities show what the framework is for. Thirty-eight percent named consistency and reliability as their top priority, 34% named accuracy, and only 12% named cost reduction, although BARC expects cost to rise as token consumption grows. Reliability leads because an agent that is right 80% of the time and confidently wrong 20% of the time cannot be trusted with anything that touches a customer or a ledger.
Anthropic's engineering guidance adds three operational patterns that belong in any framework document: just-in-time retrieval, where the agent keeps lightweight references and loads full documents only when needed; compaction, where long histories are summarised so that the window is not exhausted mid-task; and sub-agent architectures, where specialised agents each hold a clean, narrow context and pass back condensed results. These are the mechanics behind the phrase "governed context".
How does context engineering play out in a Hong Kong enterprise?
Consider a 400-person Hong Kong logistics group deploying an agent to answer customer delivery queries. The pilot fails when the agent quotes last quarter's cut-off times. The fix is not a better model but a context rule: retrieve the live schedule at query time, tag it with its effective date, and forbid the agent from answering without it.
In that logistics scenario, the first version loaded a 90-page operations manual into every conversation. Accuracy was poor and cost per query was high, because the manual crowded out the customer's actual question. The second version kept a two-line index of the manual and retrieved the relevant section only when a query touched it. Accuracy rose, cost fell, and the team gained something more valuable: a log of exactly which section the agent relied on for each answer, which is what an auditor asks for.
A professional services firm faces a different problem. Its agent drafts engagement letters from precedents stored in English and Traditional Chinese. Retrieval that matches only on the query language misses half the precedent bank. The context engineering answer is a bilingual metadata layer, so that a precedent tagged "limitation of liability" in either language is retrievable from a prompt in either language, and a permission rule so that precedents from client A are never surfaced when drafting for client B.
A regional bank's compliance team illustrates the governance side. Under the PCPD's agentic AI guidance, the bank must be able to explain what personal data its agent accessed and why. A context management layer that records each retrieval, its source and the permission that authorised it gives the compliance officer a defensible answer. A prompt does not.
What are the most common context engineering mistakes?
The five most common mistakes are loading everything into the window, letting each team define context separately, leaving tool descriptions vague, never compacting history, and treating instructions as untracked text. Each produces the same symptom, an agent that is confidently wrong, and each is cheaper to fix in design than after deployment.
The first mistake is the most expensive. Teams assume that a one-million-token window means they can include the whole policy library. Performance drops, cost per call rises, and the agent starts citing the wrong document because two similar ones sat side by side. Anthropic's guidance calls this out directly: the aim is the smallest high-signal set, not the largest possible set.
The second mistake is organisational. BARC found 44% of organisations manage context within a single agent or team. In practice that means the HR agent and the finance agent hold different definitions of "employee", and when both are asked about headcount cost, leadership gets two numbers. The remedy is a shared semantic layer owned centrally and consumed locally, what DataHub's State of Context Management Report 2026 found 93% of organisations say they are likely to treat as shared infrastructure.
The third and fourth mistakes are technical but visible to the business. Vague tool descriptions make agents pick the wrong system, for instance querying the CRM when the answer lives in the ERP. Uncompacted history makes long tasks fail at step nine of twelve, which shows up in operations as "the agent works for simple cases only".
The fifth mistake is treating prompts as informal text. If a system prompt can be edited by anyone without review, you have an uncontrolled policy document driving actions on your systems. Version it, test it and review it like a standard operating procedure, because that is what it is.
How should you present context engineering to your board or CFO?
Present it as the difference between an AI budget that scales and one that resets every project. Use the BARC figure, 49% versus 12%, to show that governed context predicts AI leadership. Then ask for funding for shared infrastructure, a semantic layer and metadata ownership, rather than for another isolated pilot.
Boards respond to three framings. The first is repeatability: every agent built on shared context costs less than the last, while every agent built in isolation costs the same as the first. The second is auditability: governed context produces a record of what the agent knew and why, which is what the PCPD's agentic AI guidance and your internal audit committee both want. The third is optionality: a context layer is model-agnostic, so when the next frontier model arrives, or when a vendor slows its release cadence, your investment carries over instead of being rebuilt.
The CFO conversation should include what context engineering does not do. It does not remove hallucination entirely; it reduces the space in which hallucination can occur. It does not replace data quality work; BARC's respondents named data quality and preparation as the top challenge at 49%, ahead of model limitations at 29% and governance gaps at 25%. A credible business case says so, and budgets for the data work alongside the agent work.
If you have already read about the shift toward forward-deployed engineers or about enterprise data-retention safeguards, context engineering is the layer that connects them: it is what the engineer builds, and it is the data the safeguards protect. For the hands-on side of the same idea, the practical guide to structuring prompts with XML tags covers the single-call mechanics.
Conclusion: what should an enterprise leader do next?
Treat context as infrastructure, not as a prompt. Inventory what your agents currently see, appoint owners for the definitions and datasets they rely on, and fund a shared semantic and metadata layer before the next pilot. The organisations pulling ahead in the BARC data did exactly that, and their agents are the ones that can be trusted with real work.
The uncomfortable truth in the 2026 data is that model capability is now the cheapest part of an agent programme to acquire and the least likely reason a programme fails. What separates the 49% from the 12% is the patient work of deciding what an agent is allowed to know, recording who owns that knowledge, and keeping it current. That work is unglamorous, and it is exactly the work a 28-year Hong Kong technology partner has been doing for enterprises long before anyone called it context engineering.
We understand AI. We understand you. With UD by your side, AI never feels cold.
Reviewed by the UD enterprise AI team. Sources: BARC and DataHub, "Context Engineering for Agentic AI" (3 September 2026); Anthropic Engineering, "Effective Context Engineering for AI Agents"; Redis, "State of Context Engineering 2026"; DataHub, "State of Context Management Report 2026"; PCPD, agentic AI guidance (25 August 2026).
Ready to Build the Context Layer Your Agents Need?
Now that you have the framework, the next step is identifying where governed context will pay back fastest in your organisation. We'll walk you through every step, from an AI readiness assessment and data inventory to agent design, deployment and performance tracking, backed by 28 years of enterprise service in Hong Kong.
