Newsletter Article
Imagine asking an AI assistant:
“Why did customer satisfaction decline last week?”
The system might retrieve:
- customer satisfaction scores
- call volumes
- average handle time
- abandonment
- workforce schedules
- agent availability
- customer complaints
- system outages
- queue performance
- previous weeks’ results
But retrieving this information is only the beginning.
The system still needs to establish relationships.
Did satisfaction decline across every queue or only one?
Did the decline begin before or after abandonment increased?
Were specific agents, products or customer segments disproportionately affected?
Was there an unusual volume spike?
Did a system outage create longer handling times?
Was staffing below forecast? Was the CSAT methodology changed?
Is the decline statistically meaningful or normal variation?
Without those relationships, AI is effectively being asked to determine business meaning from correlation.
The Semantic Problem
This becomes even more challenging when AI directly interrogates enterprise databases.
Database schemas were usually designed for systems and developers — not natural-language interpretation.
- Table names may be abbreviated.
- Fields may carry legacy terminology.
- Business logic may exist inside applications rather than databases.
A metric such as “active customer” might depend on four different conditions that are invisible from the underlying field names.
Emerging research is demonstrating why that matters.
A 2026 paired benchmark testing natural-language analytics across three frontier AI models
— Claude Opus 4.7, Claude Sonnet 4.6 and GPT-5.4 —
found that providing explicit business semantics alongside a database schema improved accuracy by
17 to 23 percentage points
compared with providing the schema alone.
The implication is important.
Sometimes the limitation is not the intelligence of the model.
It is what the model has been told about the business.
Context engineering
This is contributing to the emergence of another discipline: context engineering.
Prompt engineering concentrates on the question being given to the model.
Context engineering looks at the wider information environment surrounding that question.
- What information should the AI receive?
- Which systems should it search?
- Which business definitions apply?
- What history matters?
- What can the user access?
- Which data should take precedence?
- What should the AI ignore?
As AI systems become more autonomous, those questions become increasingly architectural rather than conversational.
This shift is no longer speculative.
In 2026, Gartner formally distinguished context engineering from prompt engineering, describing it as the discipline that gives AI systems “the situational awareness needed to act with relevance and precision.”
Gartner has also recommended that organizations treat context engineering as a core enterprise capability rather than an individual skill — language that typically signals a discipline is moving from experimentation toward standard practice. A small number of large enterprises, including Adobe, have already created dedicated context engineering roles.
We expect that trajectory to continue.
Today, context is largely engineered project by project: each new AI initiative rebuilds its own understanding of what the business’s data means. That approach will not scale. As the number of AI agents, copilots and natural-language tools inside an enterprise multiplies, so does the cost of re-explaining the business to each one.
The more durable model looks closer to how organizations already treat data governance or information security — owned by a function, supported by shared infrastructure, and applied consistently, rather than reinvented for every project.
For data and analytics leaders, that suggests three practical starting points:
- Centralize ownership before the discipline fragments. Assign clear accountability for how business definitions, metrics and relationships are maintained — inside data engineering, architecture or governance — rather than allowing every AI project to define its own.
- Build the context layer once. Treat semantic definitions, lineage and permissions as reusable infrastructure that can serve dashboards, analysts and AI agents alike, not a one-off input prepared for a single model.
- Instrument it like any other production system. As context pipelines start influencing real decisions, they need monitoring, versioning and testing — not just initial setup — so that degraded or stale context can be caught before it reaches a decision-maker.
Organizations that start treating context as infrastructure now are likely to spend the next two years extending AI reliably across the business.
Organizations that leave it as a per-project afterthought are likely to spend that time re-explaining themselves to every new model.
