Context engineering is emerging as organizations embed AI -- particularly agentic AI -- into enterprise software platforms such as ERP, CRM, HR and collaboration tools. At a high level, it's a reframing of traditional data management discipline for the AI and agentic age. The big shift now is the growing recognition that ontology -- what the data means -- is becoming critical for realizing ROI across all AI projects.
Under the hood, context engineering is the discipline of making enterprise systems' meaning -- and not just their data -- available to the processes that need it. Data architects have pursued this goal for decades, with limited results or adoption. Now, however, enterprises are discovering that fragmented context limits the utility of AI apps. Emerging AI models and processes can also help fill in these gaps.
AI system developers are using these techniques to optimize how they bring together the right data for a given query or process while managing token budgets. It also needs to strike the right balance between the flexibility of probabilistic large language models and the speed and accuracy of deterministic enterprise systems.
Investing in new AI tools only solves part of the problem. Ameet Ubhayaker, director of enterprise data analytics and AI at Protiviti, said, "Leadership is realizing they can buy AI models, but they have to build the context." This work was previously buried in data engineering tickets. Bringing it together means developing strategic policies for data definitions, entity resolution and access policies as a strategic AI dependency.
Context engineering brings together relatively new prompt engineering and older master data management (MDM) disciplines. Prompt engineering emerged with AI chatbots to improve the way a generative AI model interprets instructions. MDM and semantic-based ontologies help create a canonical record of what business entities and relationships mean, along with processes for encoding them into data integration pipelines.
Hugh Mulligan, associate director of cyber risk and governance at S-RM, said the discipline is "mostly a case of old principles working with new constraints."
Growing enterprise priority
Two recent trends are making context engineering a growing enterprise priority. First, agents are becoming a new type of consumer for enterprise data. Second, emerging AI techniques are helping automate previously manual processes for building context graphs.
Adnan Masood, Ph.D., chief AI architect at digital services company UST, said that when leadership names context engineering a priority, ownership becomes less haphazard. He has walked into rooms with three different definitions of "active customer" hardcoded into three different agents, written by three different teams -- none of whom knew the others existed. The key takeaway is that raw data access is not context. Many enterprises give agents a database connection and call it done. "That's like hiring a rockstar analyst, handing them a SQL login and never telling them what the company does," quipped Masood.
Traditional data infrastructure was built to deliver value through analytics surfaced in spreadsheets, dashboards and presentations. Agents require a different kind of data infrastructure that reveals relationships, freshness signals and provenance. They need to know not just what a customer's status is, but also how it was derived and which compliance processes must be followed when acting on that information. A fundamental challenge is that different context engineering-related processes can live across different departments and disciplines or be buried in shadow AI projects.
Who owns enterprise context?
As AI agents increasingly operate across ERP, CRM, HR and collaboration platforms, organizations are realizing that context ownership is a shared enterprise capability that requires both centralized governance and distributed accountability.
In many organizations, the CIO or chief data officer is responsible for overseeing the broader strategy. This includes establishing standards and governance models, ensuring semantic consistency and coordinating across platforms. However, business leaders ultimately define the meaning behind enterprise data and what terms such as "active customer," "high-risk supplier" or "productive employee" mean within the organization.
Enterprise architecture, data governance and platform teams translate those definitions into working systems using metadata structures, integration rules, identity mapping and policy controls. At the same time, product and AI teams increasingly own context quality within specific workflows and agents. This includes managing retrieval logic, enforcing policies and measuring whether agents actually improve business outcomes.
The main challenge is organizational rather than technical. As AI systems move across applications and departments, enterprises should consider context not just a byproduct of software but a shared operational infrastructure that requires ongoing governance, accountability and executive oversight.
The cross-system gap
All major enterprise software platforms for CRM, ERP and HR are making progress in building out the underlying knowledge graph to improve context management within their ecosystems. Masood said that problems start to emerge the second an agent crosses a vendor boundary.
For example, a revenue operations agent needs access to a Salesforce pipeline, SAP inventory, Snowflake behavioral history and dbt Labs metric definition, simultaneously and within a single reasoning loop. "No vendor will harmonize identity, semantics and policy across their three biggest competitors," said Masood.
This can lead to embarrassing problems. Masood worked with one global industrial manufacturer whose Salesforce agent only had visibility into a customer's record of an upcoming renewal date and kicked off a cheerful renewal email. Meanwhile, in SAP, that same customer had an open compliance hold and a stuck container, both of which their CFO had personally escalated 48 hours earlier. The customer's CFO forwarded the cheerful Salesforce-generated email to the vendor's CEO with one line: "Is this a joke?" That single email kicked off a major cross-system context architecture program at the vendor.
Context should not be a standalone department; it should be the connective tissue inside a product team.
Ameet UbhayakerDirector of enterprise data analytics and AI, Protiviti
Context engineering-related problems can also show up when the same thing means different things in different systems. "In technical terms, the reasoning falls apart at the 'semantic seams' where definitions diverge across systems," said Ubhayaker.
For example, in the life sciences industry, an agent might retrieve drug data correctly but fail to distinguish between approved and investigational indications. In this scenario, failure can result in a compliance violation rather than a wrong answer.
Similarly, in HR or CRM environments, Ubhayaker sees entity resolution failures. An agent querying an applicant tracking system and an HR information system might treat a "candidate" and "employee" as two different people -- or worse, merge them incorrectly. The lesson is that missing context is rarely about raw data and more about business semantics.
Developing a context engineering capability
Context engineering needs to be approached as a strategic capability rather than a one-off tool or process. This means CEOs and CFOs need to align budgets, requests for proposal (RFPs) and program stewardship. The cost of moving too slowly could starve AI projects or create new problems, but there are also risks in moving too quickly.
A good place to start is the investment ratio. Fear of missing out on the AI wave has resulted in a tendency to prioritize AI spending on compute and model access. This needs to be balanced with complementary investment in context engineering, which can significantly reduce model inference costs and improve performance in production systems.
Masood has seen disciplined context engineering work cut inference costs roughly 10-fold and reduce latency four-fold. "The savings live in the harness, not the model," he said. "CFOs need to fund the harness."
RFPs for AI procurement should also include discussions on context engineering and adjacent topics. Mulligan said most of today's AI RFPs typically focus on model performance and integration depth. They should also ask: Does the vendor expose what context the model is using? Can you bring your own retrieval and data sources? Where does the context layer actually live -- your tenant or theirs? What's the migration path if you decide to leave? Mulligan said he has not seen any RFPs that answer those questions yet from the work he does with procurement teams.
Scoping is another commonly missed dimension, Mulligan added. "AI initiatives are usually scoped around 'build or buy this capability' with adoption metrics," he said. "The work that determines whether that capability actually performs is often assumed to be already in place."
"We are seeing success not in 'context committees' but in data product managers," said Ubhayaker. These individuals own the end-to-end outcome: the agent, the data it consumes, the access policies and the evaluation metrics. Context should not be a standalone department; it should be the connective tissue inside a product team.
Ubhayaker also warns that inaction is likely to result in AI initiatives that never leave the pilot phase. Without engineered context, agents produce "plausibly wrong" outputs at scale, creating a compounding reputational tax that is often irretrievable. It's also important to be vigilant about overhyping context engineering, which can lead to context bureaucracy. "Context engineering should be an enabling function: a way to ship faster business-relevant artifacts, not a destination in itself," he said.
George Lawton is a journalist based in London. Over the last 30 years, he has written more than 3,000 stories about computers, communications, knowledge management, business, health and other areas that interest him.
