What an AI-native global capability centre actually requires

India's global capability centre sector has spent two decades proving that complex engineering work can be done offshore at materially lower cost. That argument is now won, and it has stopped being interesting. The centres being commissioned today on a purely cost-arbitrage business case are being built for a market that is closing.

The reason is straightforward. If a centre's value is that it performs a defined process more cheaply, it is competing directly with automation of that process. The work most exposed to AI is precisely the work that arbitrage-based centres were designed to absorb: rules-based operations, first-line support, test execution, routine maintenance.

The arbitrage case is running out

This is not an argument that offshore delivery is finished. It is an argument that the justification has to move. Cost remains real and remains a legitimate part of the case. It can no longer be the whole case, for two reasons.

First, the fully-loaded cost gap for genuinely senior technical talent has narrowed considerably. For a principal-level ML engineer in a major Indian metro, the differential against a mid-tier US market is no longer the multiple it was, and it continues to compress.

Second, and more importantly, the roles where a large gap persists are disproportionately the roles most subject to automation. Building a centre around them is building a centre around a shrinking function.

A centre justified by cost is competing with software. A centre justified by capability is competing with hiring markets — and that is a competition India wins.

What an AI-native centre is for instead

The defensible case is capability concentration: the centre exists because it can assemble and retain a density of specialised engineering talent that the parent organisation cannot assemble anywhere else, at any price, in any reasonable timeframe.

That reframing changes almost every design decision. A cost centre is measured on unit cost and utilisation. A capability centre is measured on what it owns outright and what it is trusted to decide. The second is harder to set up and considerably harder to dismantle, which is exactly the point.

Practically, an AI-native centre owns things rather than executing them: a platform, a set of services, an evaluation and governance function, a testing discipline. It has architectural authority over what it owns. It is a peer to onshore engineering, not a downstream recipient of specification.

The staffing shape is different

The traditional centre pyramid is wide at the base — many junior engineers executing well-defined work under a thin layer of supervision. It was an efficient shape when the work was decomposable and the constraint was throughput.

An AI-native centre inverts a good deal of that. The work that remains after automation is disproportionately senior: architecture, evaluation design, debugging systems that fail probabilistically, judgement about what should not be automated. The shape is closer to a diamond, and it has consequences that are usually underestimated:

• Hiring is slower and more selective. You are competing for a smaller pool against product companies and well-funded startups, on terms that are not primarily financial.
• Retention economics change. Losing a senior engineer from a diamond-shaped organisation removes capability, not just capacity. Replacement is measured in months.
• The management layer needs technical depth. A delivery manager who cannot evaluate a design decision cannot lead this work, and the team will route around them within a quarter.
• Junior hiring needs a real path. If the routine work that traditionally trained juniors is automated, you need a deliberate apprenticeship structure or you have no succession.

Four things the standard playbook gets wrong

The conventional GCC setup sequence — entity, facility, leadership, ramp — is sound as far as it goes. Applied to an AI-native centre it produces four predictable problems.

• Headcount targets set before the work is defined. A number agreed in a board paper becomes the objective, and the centre hires to the number rather than to the capability. Twelve months later it is staffed and unclear about its mandate.
• Leadership hired for scale management rather than technical credibility. The first senior hire sets the ceiling on the quality of everyone who follows. Engineers assess whether leadership can evaluate their work, and they are rarely wrong.
• Knowledge transfer treated as documentation. Transfer is a staffing and ownership question, not a wiki question. If no one in the centre has decision authority, nothing has transferred regardless of how much has been written down.
• Ambiguous ownership with onshore teams. When both sides can decide, neither is accountable. This surfaces as velocity problems and gets misdiagnosed as a capability gap.

What the first year should look like

A more reliable sequence starts from ownership rather than headcount.

Months one to three. Define what the centre will own outright — a platform, a service, a discipline. Write down what it decides without escalation. Hire the senior technical leader against that definition, and accept that a slow search here saves a year later.

Months four to eight. Build a small senior core, five to eight engineers, and give them a real deliverable with genuine consequences. Their reputation onshore is the foundation for everything that follows, so the first deliverable should be chosen for demonstrability as much as value.

Months nine to eighteen. Scale around proven ownership. Introduce the junior intake with a defined apprenticeship path now that there are seniors to learn from and real work to learn on.

None of this is a reason to avoid setting up in India. It is a reason to be honest in the business case about which of the two you are building, because the design decisions diverge in the first quarter and are expensive to reverse in the second year.