Context engineering went from a niche term to the center of enterprise AI strategy in under a year. Andrej Karpathy coined it in June 2025 as “the delicate art and science of filling the context window with just the right information for the next step.” Shopify’s Tobi Lütke championed the concept the same summer. By November, Forrester published a report titled “The Year Context Became King.” Gartner followed with research calling context the new essential infrastructure for agentic systems.
The term is everywhere. The playbook for actually doing it — especially at enterprise scale — is not. We wrote about the context engineering challenge no one talks about back in January; this post is the follow-up for CDOs who’ve moved past “why it matters” and are now asking “how do we actually build this?”
This blog post gives a brief intro into the topic: what context engineering is and why it’s so important for data and analytics, why it sits on the CDO’s desk, a framework for thinking about the different pieces of context and how they interact, and an enterprise framework for leveraging existing investments for accelerated context engineering.
What context engineering actually is
Context engineering is the practice of making your organization’s institutional knowledge — business rules, definitions, relationships, decision patterns — usable by AI at scale.
It’s not prompt engineering. Prompt engineering is tactical: optimizing one interaction between a user and a model. Context engineering is architectural: building the system that dynamically assembles the right information for every user, every agent, every question, in real time.
As CIO.com put it: “Early generative AI was stateless, handling isolated interactions where prompt engineering was sufficient. However, autonomous agents are fundamentally different.” Agents don’t get hand-crafted prompts for each question. They need a context infrastructure that assembles business definitions, access policies, semantic logic, and prior-query memory on the fly.
This matters most for data and analytics. Agents are already succeeding in domains with simpler context requirements — code assistants, customer support, document summarization. Analytics is where they stall. BARC’s 2026 Trend Monitorfound that 50% of organizations have AI agents in production, but only 27% use them for BI and analytics. The reason: analytics accuracy depends on business definitions, metric logic, join paths, and institutional knowledge that most enterprises haven’t made machine-readable yet. We dug into that gap in a companion post on analytics agents.
The 2026 AI & Data Leadership Benchmark Survey makes the gap explicit at the organization level: firms with AI in production at scale jumped from 5% to 39% in two years, but only 54% report high or significant business value from those investments. Deployment is accelerating. Accuracy isn’t keeping up. Most AI initiatives aren’t stalling because the technology isn’t ready — they’re stalling because the context layer is missing. Context engineering is how you close that gap.
Why context engineering is now on the CDO’s desk
70% of CDAOs now lead their organization’s AI strategy, according to Gartner’s 2025 CDAO Survey — and 86% of CDOs describe their primary mandate as innovation and business growth, up from 62% three years ago. The mandate landed on the CDO’s desk because context engineering requires three things no other role in the enterprise fully owns:
Business knowledge. The semantic layer, business definitions, and tribal knowledge that make AI accurate come from the business, not from IT. Someone has to translate what “revenue” means to the CFO into a machine-readable rule an AI agent can apply consistently.
Governance authority. Unifying context means resolving conflicts — competing definitions across business units, inconsistent metric calculations, overlapping access policies. Resolving those conflicts requires organizational authority that goes beyond any single team. (Most of the governance mistakes that doom AI initiatives trace back to this exact unresolved-authority problem.)
Cross-functional coordination. Context lives everywhere. Finance owns some of it. Sales owns some. Operations owns some. The analyst who’s been at the company for ten years owns a lot of it. Making that knowledge explicit and accessible requires coordination across every function — and political navigation no other executive has the mandate to do.
This is why context engineering has become the CDO’s mandate rather than the CTO’s or CIO’s. It’s also why Gartner predicts that by 2027, 75% of CDAOs who fail to demonstrate AI’s positive impact will be reassigned or removed from the C-suite.
Multi-dimensional context engineering
The instinct when people first hear “context engineering” is to treat it as one thing — build a glossary, or a semantic layer, or a better catalog, and the AI will follow. It doesn’t work that way. Getting AI accurate at enterprise scale requires multiple kinds of context, each contributing something distinct, each reinforcing the others.
There are five dimensions that matter, and the accuracy of any AI-generated answer depends on how well they compose. Miss one, and the model fills the gap with a plausible-sounding guess.
Technical metadata. Schemas, data types, table structures. Most enterprises have this well-covered. On its own, nowhere near enough: AI can find the data but has no idea what it means.
Relationships. Join paths, foreign keys, cardinality rules. How tables and systems actually connect. Often undocumented or locked in ERD diagrams that aren’t machine-readable. A meaningful improvement, but results still need heavy manual review.
Business definitions. Glossaries, certified terms, ownership. What “revenue” or “customer” actually means in your organization. Partially captured in data catalogs, but coverage is typically incomplete. This is where AI answers start feeling directionally right — useful, but not yet trustworthy enough for decisions.
Semantic layer. Metric calculations, fiscal calendars, dimensional hierarchies, business rules. Locked inside individual BI tools and often inconsistent across them. At this level, AI accuracy becomes genuinely useful — reliable enough that business users start trusting it for real work.
Tribal knowledge and memory. User intent, query patterns, persona preferences, decision precedents. Lives almost entirely in people’s heads. The hardest dimension to capture, and the one that closes the remaining gap — producing answers that match what your best analyst would give.
These aren’t strictly a hierarchy — they interact. A strong semantic layer without tribal knowledge answers standard metrics correctly but misses the nuance in ambiguous questions. Robust business definitions without a proper semantic layer produce directionally right answers that still need manual review. Technical metadata on its own finds the data but can’t interpret it. Accuracy comes from composing the dimensions, not from solving any one of them in isolation.
The pattern we see in most enterprises: the dimensions closest to raw data are well-covered. The dimensions closest to business meaning are sparse, fragmented, and largely invisible to AI. Most organizations plateau in the middle — they’ve solved for the technical side but haven’t addressed business meaning and institutional memory. Context engineering is the discipline of closing that gap — and the underlying data structure that pulls these dimensions together at query time is what the industry now calls a context graph. If you’re trying to sort out how that differs from the investments you may already have, we compared context graphs, knowledge graphs, and data catalogs in a dedicated post, and our Complete Guide to Context Graphs for Enterprise AI goes deeper on the architecture itself.
Context engineering in the enterprise
Here’s what makes enterprise context engineering different from the generic version: most enterprises have spent decades and tens of millions of dollars building out their data architecture. Cloud warehouses. Data catalogs. BI semantic layers. Governance programs. dbt models. Master data management. Data quality pipelines. That investment is real, and it represents a significant head start — if you can leverage what has already been built in the past.
The instinct when facing a context engineering initiative is to document everything from scratch — catalog every table, define every term, map every relationship before going live. That approach takes 6-12 months per domain in most enterprise environments. For an organization with 15-20 business domains, that’s a multi-year program before the board sees a return.
The better approach is aggregation, not reconstruction — extracting the context that already lives in your BI tools, catalogs, semantic models, and governance frameworks; resolving the inconsistencies between them; and letting the system get smarter through actual usage. (We wrote about the practical side of that approach in How to Start Building a Context Graph Without Boiling the Ocean.) Here’s the four-phase enterprise framework we use with customers:
Phase 1 — Anchor. Pick one high-visibility domain where business definitions already exist in some form, where domain experts can validate results, and where people are already frustrated. Aggregate the context your existing tools have captured, fill the critical gaps, and prove accuracy measurably improves on real business questions.
Phase 2 — Operationalize. Turn the anchor into a sustainable capability — feedback loops that capture user corrections, conflict resolution for competing definitions across business units, and governance embedded in the architecture rather than bolted on as a review process. This is where context engineering shifts from a project to a capability.
Phase 3 — Scale. Expand to adjacent domains. Each one should be faster than the last, because shared context — fiscal calendars, customer definitions, regional hierarchies, access policies — carries over rather than being rebuilt. Cross-domain relationships emerge through usage: the system learns how Finance’s revenue data relates to Sales’ pipeline data without anyone pre-mapping it.
Phase 4 — Compound. Let the flywheel work. Every query teaches the system something about intent. Every correction refines a definition. Every new user adds a perspective. The context layer stops requiring dedicated building effort and starts improving through normal usage.
The phases are sequential, but how long each takes depends on approach. Manual context engineering — starting from scratch instead of leveraging what you already have — runs 6-12 months per domain. A platform-accelerated approach that aggregates existing metadata, automates relationship discovery, and learns from usage can compress Phase 1 from months to weeks. That’s the premise behind our 360° Context Hub — treat your existing data architecture as an asset rather than something to replace.
Why context is the real moat
AI models are commoditizing. The performance gap between frontier models narrows with every release. The model that was state-of-the-art six months ago is available as an API at a fraction of the cost today. Within two years, the difference between the best available model and the fifth-best will be negligible for most enterprise use cases.
What your competitors don’t have access to is your context — how you define revenue, how you segment customers, how your fiscal calendar works, which join paths produce valid results, how your best analysts interpret ambiguous questions. It was built over years of decisions, corrections, and accumulated experience. It can’t be downloaded, licensed, or replicated. (Why talking to your business data is harder than it looks is worth reading if you’re still skeptical that the model is the easy part.)
The organizations that invest in context engineering now don’t just get a head start. They get a compounding advantage: accuracy drives adoption, adoption generates signal, signal builds richer context, richer context drives better accuracy. The flywheel runs itself — and the gap with competitors widens every quarter.
Get the full playbook
The full guide expands every section of this post — including the board-ready business case for context engineering, where your existing investments (catalogs, BI semantic layers, governance frameworks) get you and where they fall short, the operating model for distributed contribution with centralized governance, and the architecture evaluation framework for choosing between consolidation and a unification-layer approach.
Written for the CDO who needs to act now, not after another year of pilots.
SHARE THIS:
