"India's IT model is out of date. Can the industry reinvent itself?" (The Economic Times, July 19, 2026, paywall) argues that AI is upending the pyramid model on which Indian IT service companies were built — large teams of engineers executing repeatable tasks at scale. Phil Fersht puts it plainly in the piece: the model worked brilliantly when the constraint was access to affordable skilled labor, and AI changes that equation. On this, we agree.
Where we part ways is with the gloom that has settled over the industry's prospects. The obituaries are premature because IT service companies' most valuable asset was never the pyramid itself. It is the knowledge the pyramid accumulated, and, done right, the knowledge it can keep accumulating long after the pyramid is gone. The next IT services business model may be less about scaling headcount and more about converting decades of accumulated knowledge into executable, continuously improving knowledge assets.
Over three decades of supporting enterprises in banking and financial services, healthcare, retail, energy, and manufacturing, IT services companies have built three assets that few possess:
- Deep Domain Knowledge
- First-hand familiarity with each client's Company Language
- Operating Knowledge: the undocumented understanding of how a client's business actually runs, which exceptions are routine, which approvals really matter, which system-of-record wins when two disagree.
These assets have always been largely implicit, embedded in delivery teams and rarely written down anywhere. Domain Knowledge is different from the other two: it reflects industry-wide terminology, standards, relationships, and practices that can often be codified and reused across clients. Company Language and Operating Knowledge, by contrast, describe a specific client's business and remain that client's property wherever they are codified. In the age of agentic AI, all three become far more valuable because they can be made explicit, governed, and put to work as context for AI. Here's why.
One of the biggest barriers to enterprise AI adoption is trust. Large language models are fluent, but when they do not fully understand a query, they may produce confident, plausible, wrong answers (hallucinations). This is not a fringe concern. Anthropic's recent study of 81,000 AI users across 159 countries found reliability worries cutting across professions; nearly half of the lawyers surveyed reported encountering AI unreliability firsthand.
Consider a simple business question: "How much mud did we sell to our loyal customers last year?" In oil and gas, "mud" is not dirt. It is drilling fluid, a well-defined product category. "Loyal customer" might mean three-plus purchases in 90 days at one company, a 12-month subscription at another, rewards-program enrollment at a third. And "year" could be the calendar year, the fiscal year, or a work week year. A general-purpose model, missing all three definitions, will happily compute an answer — the wrong one. Supplied with those definitions as context, the model has the information it needs to understand the question correctly rather than guessing.
What we mean by Domain Knowledge, Company Language, and Operating Knowledge
Every industry has a language of its own — terms, abbreviations, and relationships that carry precise meaning for practitioners and mislead everyone else. In oil and gas, completion, casing, and perforating are specific engineering concepts. In healthcare, admission, encounter, and visit are not interchangeable; each carries its own clinical workflow, documentation requirements, and billing codes.
This is Domain Knowledge: industry-wide, shared by every player in the sector, and the easiest of the three to formalize, because it is at least partially documented in standards and regulation.
Even two companies in the same industry, following the same ontology, speak differently. Company Language grows out of internal processes, historical naming conventions, proprietary metrics, and three-letter acronyms. Crucially, this vocabulary rarely appears in public documentation, which means it is absent from the data on which foundation models are trained. Simply scaling the model does not supply private, company-specific knowledge that was never available to it; that knowledge has to be supplied and governed client by client.
Operating Knowledge goes a step further, and is the hardest of the three to capture, because most of it exists only in the heads of the people who run the account. It is not what a term means but how the business actually behaves: which invoice exceptions get approved without escalation, which regional office ignores the official process, which vendor relationship has an unwritten side agreement. This is the knowledge that gets generated fresh, every day, in the normal course of running a client's operations, and it is where the flywheel matters most.
Why IT services companies — and why the threat is real, not just the opportunity
Supplying this is engineering work, not magic: eliciting definitions from business owners, encoding them as ontologies and knowledge graphs, versioning them, wiring them into data platforms as governed context at query time. This is precisely the kind of disciplined, client-embedded engineering that IT services companies have delivered over thirty years. Doing so responsibly also requires permissions, provenance, versioning, access controls, and clear boundaries around client-confidential knowledge.
Here is the catch: none of this is reserved for them. AI-native consultancies are being built from scratch to do exactly this work. The hyperscalers' services teams are already sitting next to the data platforms where all this knowledge has to end up. Vertical software vendors are shipping industry models with the domain layer baked in. And the client can always decide to do it themselves — it's their knowledge, after all.
What the incumbents have is a head start, not a lock: years of relationships and hard-won context. Head starts run out if you don't turn them into something that lasts. Knowledge that is written down, versioned, and ready to run is what lasts.
The flywheel, not just the inventory
The deepest mistake would be to treat this as a one-time knowledge harvest: document what you already know, package it, move on. The real opportunity compounds, and it compounds from more than just routine operation. Every day of running a client's account generates small innovations that rarely get formally counted as innovation at all. A support engineer works out a faster way to triage a recurring ticket type. A delivery lead finds a better sequence for a monthly close process. An account manager learns which framing lands with a particular stakeholder and which doesn't.
All of it is knowledge about process and method — how the work gets done, not what a client's proprietary data contains. And today, almost all of it evaporates the moment the person who discovered it moves to another account or leaves the company. Captured systematically instead, each of these small discoveries can be codified, put into execution, and learnt from in turn. Each one feeds back into the same knowledge layer that made the interaction possible, making the next interaction faster and more accurate still. Client-specific learning enriches that client's own knowledge layer; what generalizes across accounts is the method, abstracted from any one client.
This is a flywheel, and its defining property is that it rewards duration. The longer a provider runs a client's AI-augmented operations, the more knowledge it accumulates, big and small, formal and tacit. That accumulation must be governed: client-specific knowledge stays inside the client's environment under the client's ownership and access controls, and what a provider carries forward across accounts is industry-level knowledge and its own delivery methods. The longer that accumulation runs, the harder the advantage becomes for a new entrant, however well-funded, to replicate from a standing start.
Automating this flywheel is itself one of the largest advantages in this transition. It means building systems that capture, codify, and redeploy this daily stream of small innovations within the client's own boundary wherever the knowledge is client-specific, rather than relying on someone remembering to write it down. A knowledge asset that only gets curated once is inventory. A knowledge asset that keeps getting enriched by every day of operation, and every small improvement anyone on the account makes, is a moat that widens with tenure rather than eroding with it.
From Scaling Headcount to Scaling Knowledge
We do not pretend this answers the Economic Times article's hardest question: what happens to the workforce pyramid. The reinvention we describe does not preserve the traditional pyramid; it changes what drives growth. In the traditional model, revenue grows largely by adding people. In the model we describe, reusable knowledge, managed knowledge services, and outcome-based pricing can allow revenue to grow without a proportional increase in headcount.
Reusable industry knowledge can become licensable intellectual property, while client-specific knowledge engineering can be delivered as a managed service and can increasingly be priced around outcomes rather than headcount. This model requires knowledge engineers and domain modelers, while reducing dependence on the large delivery teams on which the traditional pyramid depended. That is exactly the reinvention the moment demands: a shift from scaling through headcount to creating value from decades of accumulated knowledge.
The commercial model can take several forms. Reusable Domain Knowledge can become licensable intellectual property deployed across multiple clients in an industry. This is industry and ecosystem knowledge, terminology, standards, and shared sector practice, never a client's proprietary definitions, data, or processes. Client-specific knowledge engineering can become a managed service for that client, with ongoing enrichment and governance creating recurring revenue.
And as AI assumes more of the execution, providers can increasingly price around business outcomes and the knowledge assets that enable them rather than the number of people assigned to an account.
Done well, this creates a win-win-win. Enterprises get trustworthy AI grounded in their own definitions, growing more accurate the longer it runs. IT services companies convert an implicit, static asset into a compounding revenue line. And AI technology providers see their models finally deliver in production.
At DaaX, we have begun implementing this model in practice. We package codified knowledge as Domain Knowledge Cartridges, which carry an industry's terminology, concepts, and relationships, and Company Language Cartridges, which carry a single organization's acronyms, products, metrics, and internal vocabulary. Both load into our products — LAKEer for natural language search over documents, SQLer for natural language to SQL — as governed context at query time, with no model training required. Operating Knowledge gets no cartridge of its own: client-specific learning enriches that client's Company Language and operational context, while generalized lessons that contain no client-proprietary information can contribute to reusable Domain Knowledge.
We have built Domain Knowledge Cartridges for oil and gas, and for agentic commerce. For other industries we rely on partners — system integrators, consulting firms, and software vendors — to develop, package, and monetize them. Fission Labs is the inaugural partner in our Domain Knowledge Cartridge ecosystem. The Domain Knowledge Cartridge remains the partner's asset. Company Language Cartridges are each client's own IP and are never reused for anyone else. For both we supply the engine that makes them executable and the verification layer that shows which piece of grounded knowledge produced each answer.
Better results lead to more AI projects, which lead to more knowledge capture, which lead to better results still. We believe this virtuous cycle offers IT services companies a path to replace — and potentially exceed — some of the billings lost to AI-accelerated software development. The pyramid may be out of date. What it learned along the way, and what it will keep learning, is anything but.
See how codified knowledge becomes executable context in the DaaX technology overview, or read more about Domain Knowledge and Company Language.