Satya Nadella’s recent essay, “A frontier without an ecosystem is not stable”, is a useful way to look past the usual question of which AI model is winning this week.

His argument is that companies need to build two kinds of capital. The first is human capital: the judgment, relationships, domain knowledge and pattern recognition of their people. The second is token capital: AI capability that the company builds and owns. The opportunity is not to trade one for the other. It is to make them compound.

That is a bigger idea than it first appears.

If a company simply rents a capable model and puts a chat interface in front of it, it may gain productivity. But it has not necessarily built an advantage. The provider can change prices, capabilities or terms; a competitor can buy the same model tomorrow; and the company’s best operational knowledge can remain scattered across people, tickets, documents and one-off conversations.

The durable asset is the learning loop around the model: the workflows, context, tools, permissions, evaluations and feedback that turn repeated work into a system that gets better.

Open-weight models make that architecture much more practical.

Open weight does not mean open source

It is worth being precise here. An open-weight model makes its trained parameters available to download and run. That can give an organization much more control over deployment and adaptation, but it does not automatically mean that the training code, data, licence, or every right associated with the model is open.

Still, access to the weights changes the enterprise conversation. A company can run a model in its own environment, evaluate it against its own work, adapt it where the licence permits, and decide when it should be upgraded or replaced. Microsoft’s open-weights letter makes this case explicitly: organizations can match the model to the job and keep control of their data and accumulated capability.

This does not mean that every company should self-host every model. It does mean that the model layer is becoming more negotiable.

A sensible enterprise architecture will often be hybrid:

  • A frontier model for difficult or low-volume tasks where the extra capability is worth paying for.
  • A smaller or open-weight model for high-volume, well-understood and privacy-sensitive work.
  • A routing, evaluation and observability layer that can decide between them and prove that the choice is working.

The important design principle is that the company’s context and workflow harness should not be welded to one model provider. Nadella makes the same point in a recent investor discussion: products will use multiple models, so the harness and context layer need to remain decoupled from the model layer.

Why this is good news for consulting firms

This shift should be particularly interesting for firms such as TCS, Wipro, Infosys and HCLTech. They are unlikely to compete with frontier labs by training the largest general-purpose model. Nor do they need to.

Their advantage has always been closer to the customer: deep delivery capacity, access to enterprise systems, industry knowledge and the ability to operate technology in environments where reliability, security and change management matter as much as a benchmark score.

Open weights expand the amount of valuable work around that advantage. A serious enterprise deployment now needs help with:

  • Selecting and evaluating models for a specific workflow instead of accepting a generic leaderboard.
  • Preparing data and context while respecting privacy, residency and access controls.
  • Building private-cloud or on-premises deployments where those controls are necessary.
  • Fine-tuning, quantizing and serving models when the economics justify it.
  • Connecting agents to the systems where work actually happens: CRMs, ERPs, service desks, knowledge bases and internal tools.
  • Designing permissions, audit trails, fallback paths and human approval for consequential actions.
  • Creating private evaluations from real business outcomes, then improving the system using the traces it produces.

None of this is a model-training race. It is implementation, integration and ongoing operation at enterprise scale.

In that sense, open weights could do for AI services what open-source infrastructure did for the last generation of technology services. The underlying software became widely available; the difficult, high-value work moved to making it useful, reliable and specific to a business.

There is a catch. Open weights do not automatically protect the traditional services model. They also make implementation work more repeatable and easier to automate. A firm whose value is measured mainly in billable effort will face pressure as agents absorb parts of development, testing, support and documentation.

The firms that benefit will be the ones that turn delivery into reusable capability: industry-specific evaluation suites, secure agent patterns, integration accelerators, operating playbooks and teams that can take responsibility for an outcome. The goal cannot be to sell more hands around a model. It has to be to help the client own a system that improves.

The FDE becomes a strategic role

This is also why the Forward Deployed Engineer (FDE) model matters more in the open-weight era.

An FDE works close to a customer’s real environment. The work is not simply to demonstrate a model; it is to find the workflow where a system can create value, understand the exceptions, integrate with the existing stack and ship something that people can trust.

For AI work, that role sits exactly at the point where human capital becomes token capital.

The best FDE engagements will do a few things well:

  • Identify a narrow, valuable workflow rather than start with a vague request to “use AI.”
  • Capture the decisions, edge cases and evidence that experienced operators use.
  • Convert that knowledge into tools, structured context and evaluation cases.
  • Keep the model swappable through a clear interface and measured routing policy.
  • Leave the client with a maintainable system, not a dependency on an individual engineer or vendor.

That last point is important. An FDE should not merely extract customer knowledge so that a vendor’s general model becomes more useful. The better outcome is for the customer to retain a governed, model-independent representation of its own expertise.

This makes FDE work a blend of product judgment, software engineering, systems integration and domain learning. It is much harder to commoditize than prompt-writing or a generic proof of concept, because the output is not just an application. It is a new operational capability inside the customer.

The learning loop is the product

There is a temptation to read the open-weight discussion as a debate about ideology: open versus closed. For enterprises, the more useful question is architectural.

Can we change models without losing our expertise? Can we prove that an AI system is improving on the outcomes we care about? Can we keep sensitive data and high-impact decisions inside the boundaries we choose? Can a new employee benefit from the judgment accumulated by the people who came before them?

If the answer is no, the company may be using AI but it is not yet building token capital.

Open-weight models are not a complete answer. They bring their own licence, security, safety and operational responsibilities. They also do not remove the need for frontier models. But they make a healthier division of labour possible: models can become more interchangeable, while enterprise knowledge, workflow design and accountable implementation become more valuable.

That is the opportunity behind Nadella’s argument. The next durable AI businesses may not be the ones that own the only capable model. They may be the ones that help every other company turn what it already knows into a learning system it can actually own.