The False Choice Holding Back Enterprise AI: Flexibility or Control

Enterprise AI has moved beyond the adoption problem.

McKinsey’s 2026 survey found that nearly nine in ten organizations are using AI. Eighty percent say it improves individual productivity, and half say it helps people make better decisions. Yet only 37% report a positive EBIT contribution from AI.

Companies still need people to experiment. That is how they find where AI works, which data matters, and how decisions actually get made.

But executives are under increasing pressure to move useful AI into production and show a return ... and that's where the problem changes.

A productivity tool can rely on a person to interpret the output. Once AI becomes embedded in analytics, applications, and business workflows, more of the data, definitions, logic, permissions, and operating knowledge behind a decision must become explicit.

The challenge is no longer simply getting AI to work. It is taking what works in one team and making it trusted, repeatable, and reusable across more of the business. If every pilot requires another round of data preparation, integration, governance, and process redesign before it can go into production, cost can outpace return.

Enterprises that have successfully driven rapid AI experiments find business value compounds over time. Early learnings shorten the time to move experiments to production, reduce duplicative analytical and governance work, and lay the data elements in place to broaden the scope of insights and decisions the enterprise can automate.

That leaves enterprises facing what looks like a hard choice: let teams move quickly, or add enough centralized control to make AI governable, repeatable, and scalable (see Figure 1 below).

Figure 1. Trading off flexibility for control creates a different set of constraints.

But, the good news is that this forced choice is a false one.

The missing layer between flexibility and control is context.

Teams move quickly because they already know the context: which data to trust, what a metric means, which exceptions matter, and when normal rules don't apply. Scaling AI requires making enough of that knowledge explicit for software to use, too.

Context bridges flexibility and control

Context is the semantics and business meaning, current state, rules and policies, and judgment humans or machines need to make a decision and be allowed to act.

For an enterprise, context comes from two directions.

• Bottom-up context is discovered through the people doing the work: which signals matter, which exceptions recur, what analyses prove useful, and where human judgment changes the outcome. For example, an analyst may find a better way to segment customers, a support manager may uncover data that better predicts escalation risk, or a manager may decide when it is OK to bypass the standard process.
• Top-down context is defined through shared definitions, semantics, policies, permissions, and business rules. For example, embedding customer-risk analysis into the renewal process. The business requires being explicit about which signals matter, which data is trusted, how risk is measured, what actions are allowed, and where approval or escalation is still required.

The bottom line is that the architecture must support both. The goal is to capture what should be reusable without blocking the flexibility teams need to discover better ways of working.

Shared context does not mean one giant context model

Most enterprises already have useful context spread across semantic models, data platforms, CRM and ERP systems, documents, prior analyses, notebooks, and the knowledge of the people doing the work. Trying to recreate all of that in one system simply creates yet one more large architecture and governance project.

A more practical approach is to layer what should be reused from what needs to be added for the decision at hand (see Figure 2).

• Shared business context: the business knowledge that should stay consistent across groups or organizations, including definitions, entities, semantics, metrics, relationships, permissions, and common business logic.
• Situational context: what matters for the decision and the objective at hand, including the current state (e.g., process stage), relevant history, exceptions, and other domain-specific information.
• Learned context: what the organization discovers through use, including trusted analyses, expert guidance, recurring questions, known exceptions, common practices, interventions, and feedback.

Figure 2. Context can come from top-down standards or bottom-up learning, but it should be assembled into the shared, situational, and learned context needed to drive insight or automate a decision.

The point is not to centralize all three layers, but to reuse what should stay common and bring in the rest as needed. This allows an enterprise to start with a bounded use case, reuse what is already trusted, add local context where needed, and improve the shared foundation as teams learn what works.

Start with the minimum context required for the task

Many AI programs become too complicated because teams try to solve the context problem for the entire enterprise at once. Start smaller by picking one analytical task, workflow, or decision. Ask what the user, application, or AI system needs to know, what actions it can take, and how you'll measure success. The goal is to assemble the smallest context package that can reliably support the analysis or decision.

That context may include shared meaning, current operating state, permissions and constraints, expert knowledge, and feedback from previous decisions. But those elements do not need to live in one system. Context may come from CRM, operational state from ERP, policy from governance systems, and analytical context from the data platform.

Constellation Research recommends a federated context approach, where the architecture can reliably pull the right context from the systems that already own it and assemble what it needs for the analysis or decision at hand.

That ability to assemble reliable context becomes more valuable as additional AI initiatives move into production.

The first use case may require substantial work. Teams have to find the right data, agree on definitions, document the logic, test the outputs, and determine what people need to trust the result. The second use case does not have to rebuild all of that. Each successful initiative should then add reusable definitions, logic, controls, and operating knowledge to the foundation.

The first AI use case may pay much of the context tax, where the next ten can begin to amortize it.

Ultimately, that means faster movement from AI experiment to production, less duplicated analytical and governance work, and more decisions the enterprise can automate.

LangChain shows how flexibility can improve control

LangChain is an interesting example because its team faced the operational challenge of balancing flexibility and control as they tried to scale AI and self-service analytics. Different teams could access the data, but through different tools and workflows, with uneven ability to share, govern, and reuse the work. Its data was spread across Segment, BigQuery, dbt, Salesforce, and other tools. Nontechnical employees depended on the data team for answers. Technical users could query the warehouse directly with Python or Claude Code. The company had flexibility, but it still lacked a consistent way to turn that work into trusted, reusable context for the rest of the business.

To address these issues, LangChain adopted Hex as its AI analytics platform. Technical users could keep using the tools they preferred, while Hex gave the company a place to publish work, apply shared context, and share results. Business teams could answer more questions self-service, while the data team gained visibility into what people were asking and where the underlying context needed improvement.

The key point is that teams could keep working the way they wanted, while the rest of the company could more easily reuse the analysis, definitions, and context.

As a result, the data team shifted from daily firefighting to investing time in improving their data foundation, expanding the depth and richness of available data, and capturing more context in data glossaries and guides. The team built a learning loop where more use led to better context, making self-service and AI-driven insights more reliable.

Interestingly, LangChain’s own context-engineering philosophy mirrors what they accomplished with Hex: assemble context for the task rather than treating context as one fixed block of information.

The business implication: scale what works, don’t scale friction

Better self-service, less duplicated work, and greater overall organizational trust in your AI initiatives are great goals, but the bigger payoff from shared context is that it changes the economics of scaling AI.

Building the first use case is the hardest. Teams have to find the data, reconcile definitions, build semantics, document business logic, ensure guardrails and controls, and decide where they still need to insert a human. That means the second use case, and the next, can build on those learnings.

As costs and time to embed AI-driven analytics and automation into production decrease, several operational changes happen.

Central data and AI teams spend less time acting as human middleware for every request and more time improving the shared foundation. Governance shifts from a gate at the end of a project to reusable policy and runtime controls that provide clarity and accelerate future AI deployment. More decisions can move from analysis to recommendation, and eventually to execution, without rebuilding the same foundation each time.

More interesting are the longer-term implications of context.

Leaders from Ali Ghodsi at Databricks to Satya Nadella of Microsoft have argued that context is part of a company’s intellectual property. Models, agents, harnesses, and applications will keep changing. But an enterprise’s accumulated understanding of what its data means, how the business operates, and which tradeoffs and priorities shape its decisions can carry forward across those technology shifts.

At the end of the day, flexibility helps teams discover what works, and shared context lets the business reuse it to ultimately turn isolated AI productivity gains into greater decision velocity.