OPINION | Context Engineering: The next IT services frontier

Without a new organizing principle, the services industry risks stagnation. Context engineering provides that new principle. It does more than replace old revenues: it expands the playing field altogether.

From IT services to enterprise services

In earlier eras, services firms focused almost exclusively on the IT department. They built applications, migrated workloads, and maintained infrastructure. Contextual computing changes that scope. Context lives across the enterprise, which means the services opportunity now extends to every major function.

• In customer support, context is the workflows teams use to resolve cases, the variations they apply for different segments, and the accumulated histories of past interactions.


• In legal departments, context is the redlined contracts, regulatory clauses, precedent cases, and negotiation trails. Without that context, an AI system can draft words but cannot deliver compliant, actionable advice.


• In software engineering, context is the code repositories, bug tickets, build pipelines, and problem-solving conversations that shape how systems are built and maintained.

For decades, services firms competed over the CIO’s IT budget. In the contextual era, the field widens dramatically. Compliance teams may fund real-time regulatory agents, HR departments may invest in onboarding assistants, and operations leaders may commission adaptive workflows.

This shift — from IT services to enterprise services — is what makes context engineering the next frontier. It doesn’t just change how services are delivered; it expands the addressable market by an order of magnitude.

What do we mean by context?

In practice, context is the sum of the data, rules, workflows, and tacit knowledge that make each enterprise unique. It is what enables a model to generate output that is not generic, but tailored to how an organization actually works.

Without this grounding, model output drifts toward the generic and unreliable. With it, they become accurate, efficient, compliant, and aligned with enterprise priorities.

Models at the center, context as the lever

This opportunity is not tied to today’s large language models. LLMs are simply the most visible architecture in the current wave of AI. Tomorrow, we may see multimodal systems that blend vision and speech, agentic models designed for continuous reasoning, domain-specific models optimized for healthcare or finance, or entirely new paradigms that displace transformers.

But the constant is not the model type. It is the role of the model in the enterprise computing stack. Whatever the architecture, the model becomes the central compute engine of the enterprise, and context is the raw material that makes it useful.

That is why the industry will orient around models at the center, and context as the lever of value. Just as code was the lever in the microprocessor era and workloads were the lever in the cloud era, context now defines the model era.

Because context lives across every business function, it also explains why the market for services expands so dramatically. Context engineering doesn’t just redefine delivery. It broadens the scope of who spends, moving services firms from competing for IT budgets to unlocking enterprise-wide budgets.

What is context engineering?

If context is the new raw material of computing, then context engineering is the craft of programming the model — not with lines of code, but with the data, rules, and workflows that shape its behavior.

In the microprocessor era, software engineers programmed machines by writing millions of lines of code. In the cloud era, consultants “programmed” platforms by deciding which workloads to migrate and how to orchestrate them.

In the model era, programming shifts again. Models don’t need every rule spelled out. They need context: policies, processes, case histories, and tacit know-how that make each business unique. Context engineers decide what to feed into the model so it can generate useful, enterprise-grade intelligence, and they refine and govern that context over time.

In practice, that could mean:

* For an insurer, capturing not just the written rules in a policy manual, but also how claims adjusters handle edge cases — the exceptions and judgment calls that never make it into the handbook.

* For a legal team, transforming a stack of redlined contracts and regulatory clauses into structured context the model can draw on, so its draft advice aligns with precedent instead of sounding generic.

* For a customer support operation, documenting not only the playbook but the nuanced variations agents apply for different customer segments, and using past case histories to guide the model.

* For a finance team, encoding the logic behind reconciliations, audit rules, and forecasting practices so the model mirrors real compliance standards.

* For a healthcare provider, grounding the model in treatment protocols and the handoff rules between doctors, nurses, and specialists.

These examples show that context engineering is not about writing new software. It is about translating how organizations really work into the raw material that makes models intelligent, trustworthy, and enterprise-grade.

Context engineering in action

Consider a Fortune 500 insurer facing regulatory pressure to improve its audit of policy endorsements. Traditionally, the firm could only review a small fraction of endorsements each year, leaving blind spots and compliance risks.

By applying context engineering, its services partner mapped not just the written policy rules but also the tacit execution context — how endorsement teams actually processed exceptions, escalated unusual cases, and applied judgment. That enriched context was fed into an AI audit agent.

The result: audit coverage expanded fivefold, false positives declined, costs dropped, and compliance risk was dramatically reduced.

No new application was coded. No legacy system was rewritten. The transformation came from capturing and feeding the right context into the model.

From IT budgets to enterprise budgets

The most profound implication of contextual computing is economic.

In the microprocessor era, services firms monetized code, which confined their scope largely to IT budgets. In the cloud era, they monetized workloads, still within the CIO’s domain.

Contextual computing breaks that boundary. The raw material is no longer just servers, applications, or workloads. It is the enterprise’s rules, processes, tacit knowledge, and culture. These assets reside not only in IT, but across every business function:

# Risk and Compliance teams that need real-time regulatory interpretation.

# Finance functions seeking grounded forecasting and audit.

# HR and Talent teams designing onboarding and learning agents.

# Operations and Supply Chain leaders orchestrating adaptive workflows.

# Customer Service and Sales groups deploying digital colleagues at the frontline.

Each of these functions commands its own significant budget, often independent of IT’s.

This is why context engineering is not simply another technology wave. It expands the pie. Services firms that learn to industrialize context pipelines are no longer limited to the CIO’s spending authority. They become partners to the entire enterprise, eligible to tap budgets across compliance, HR, finance, operations, and beyond.

Why IT Services firms are best positioned

If context is so central, why won’t enterprises simply do this themselves?

The answer lies in history. Few firms wrote all their own code in the microprocessor era. Few migrated all their own workloads in the cloud era. They relied on services firms that combined technical depth with domain expertise. The same logic applies today.

But in the context era, domain means something richer than ever before. It is not just knowing an industry’s regulations or vocabulary. It is understanding how work actually gets done in specific teams, functions, and sectors:

• The workflows through which a claims team processes exceptions.


• The nuanced handoffs in a hospital’s patient discharge process.


• The decision points in a bank’s credit adjudication workflow.


• The shortcuts and escalation patterns that only insiders know.

And here lies the key point: in the era of context, workflows and deep operational knowledge are not just helpful — they are the competitive moat. Services firms have spent decades building this expertise. By working across industries, implementing critical systems, and running essential business processes, they have absorbed the tacit knowledge of how industries function.

Now, for the first time, that accumulated knowledge moves from the margins to the spotlight. It becomes the raw material that must be fed into models to make them enterprise-grade.

This is why services firms are moving first. In a first for the entire computing industry, Cognizant and Workfabric AI recently announced a joint effort to deploy 1,000 context engineers, powered by the ContextFabric platform, to industrialize agentic AI. It is an early signal of how services firms will scale context engineering into a repeatable discipline.

Hyperscalers can provide the infrastructure. Model providers can deliver the engines. But IT services' firms combine scale in execution with deep domain knowledge.

In the era of context, that knowledge, once seen as peripheral consulting expertise becomes the very fuel of intelligent systems. It is the moat that allows services firms not just to survive this shift, but to lead it.

Implications for CXOs

For client organizations, contextual computing is not just a supplier shift. It is a leadership agenda. CXOs must rethink how they structure teams, allocate spend, and measure success.

Three imperatives stand out:

1) Reorient structure around context, not code: Traditional IT functions organized around application development and testing must evolve. New roles will emerge: context owners, domain curators, AI risk managers.

2) Shift spend from infrastructure to intelligence: In the cloud era, the focus was on migrating workloads. In the context era, the leverage point is pipelines, managed context operations, and reusable packs of domain knowledge.

3) Focus on outcomes, not deployments: The promise of contextual computing is not just faster projects but better results: reduced risk, adaptive compliance, augmented decision-making, improved customer satisfaction. CXOs must measure value in terms of business outcomes, not IT milestones.

This reorientation will be as profound for enterprises as the shift to context engineering is for services firms.

The next IT services frontier

Context engineering is not a side note. It is the organizing principle of the next decade of IT services.

It reimagines existing service lines, unlocks entirely new ones, and expands the addressable market from IT budgets to enterprise-wide budgets. It demands new skills, new offerings, and new leadership models.

For services firms, the opportunity is to industrialize context pipelines and deliver enterprise-grade agents at scale. For enterprises, the challenge is to embrace context as the new lever of value, and to reorganize leadership, spending, and priorities accordingly.

The winners will not be those who experiment with models, but those who master context. Whoever owns the context layer will own the future of IT services.

(Rohan N. Murty is CEO, Workfabric AI, and Ravi Kumar S is CEO, Cognizant.)

Views are personal and do not represent the stand of this publication.