A six-minute companion to thelong-form analysis. Read this if you have ten minutes and a calendar full of other meetings. Read the long-form if you have an hour and a strategy decision to make.

The 30-Second Version

Uber’s engineering team has published material describing a working internal platform that, by their own numbers, supports around sixty thousand weekly AI tasks flowing through a single governed gateway, with around ten thousand internal services exposed as agent-callable tools. The architectural pattern — a Model Context Protocol-centred fabric with a tool registry, central governance and auto-converted tool wrappers — is reproducible. The protocol is open.

Indian IT outsourcing — TCS, Infosys, Wipro, HCLTech, LTIMindtree, Cognizant, Tech Mahindra, Mphasis, Coforge — is the natural beneficiary of the same architecture applied to client estates rather than a single internal estate. The decisive question is not whether to build the platform. It is whether the firms that build it have the commercial nerve to convert the technical capability into a different deal shape. The technology is the easy part. The conversation about who gets paid is harder.

This brief covers the three things that matter most for an executive reading on a Tuesday: where the industry sits on the maturity curve, why the incentive conflict is the real constraint, and what the rollout looks like on a real account.

Where The Industry Sits On The Curve

Most outsourcers operate large client accounts at Stage 1 or Stage 2 today. RPA bots and per-tool copilots are useful, but they arepoint automation — each new tool or workflow improves one workflow. They do not compound.

Stage 3 is where compounding starts. An MCP-centred gateway with a tool registry, central governance, and auto-converted tool wrappers means every new tool exposed makes every existing agent more capable. The investment shape changes from “build a copilot” to “build a platform that produces copilots”. This is the published state inside Uber.

Stages 4 and 5 are where the commercial model shifts to outcome-billed delivery. Nobody is there at scale yet.

The honest gap from Stage 2 to Stage 3 is two to four quarters of platform work plus an unglamorous data-hygiene investment — CMDB cleanup, knowledge-base curation, ticket-taxonomy normalisation. The gap from Stage 3 to Stage 5 is not technical at all. It is the incentive problem.

The Incentive Problem Is The Real Constraint

This is the part of the thesis that gets understated in most conversations, including the original long-form draft of this analysis.

Outsourcing revenue is FTE-shaped. Contracts are priced as a stack of named roles multiplied by billing rates and headcounts. Reduce the headcount required to deliver a service and the immediate effect is a smaller bill to the customer. That is revenue cannibalisation, and it cuts against the platform business case.

The same effect applies inside the firm. A tower lead’s standing is shaped partly by tower size. A practice head’s position is shaped partly by billable headcount. The people who would have to champion the platform are also the people whose internal position it weakens. This is not a moral failing — it is rational behaviour given how the firm rewards them.

Four commercial paths through this, each failing in a different way.

Productivity dividend. Keep the FTE count, use the gains to expand scope or absorb new work without growing the team. Lowest internal resistance. Often produces no measurable customer benefit and therefore no commercial differentiation.

Margin retention. Hold the customer price, reduce delivery cost through automation, retain the margin. Works in shorter contracts. Creates trust issues at renewal — customers eventually see the AI talking points elsewhere and ask why they are paying yesterday’s price for tomorrow’s delivery model.

Outcome repricing. Move new contracts to per-ticket, per-incident or per-user pricing. The structural prize. Requires the commercial nerve to renegotiate large contracts, and the conversation is uncomfortable.

Productivity-billed sharing. Open-book pricing where automation gains are explicitly shared between vendor and customer. Mature, durable, hard to negotiate. Only viable in the small minority of high-trust accounts.

Customers also resist — not all, but a meaningful share — particularly in regulated industries, in accounts with hard data-sovereignty constraints, and where the customer’s own IT organisation has a vested interest in keeping the outsourcer’s headcount visible.

The firms that win will build the platformand have the commercial conversation. The firms that build the platform without the conversation will end up with a quietly impressive internal capability that does not show up in revenue.

What This Looks Like For A Real Account

A composite client. Eighty thousand endpoints across thirty countries. Around four hundred and fifty named FTEs across all towers (a typical 1:175 endpoint-to-FTE ratio). Around ninety-five thousand monthly tickets, of which roughly forty-two thousand are repetitive L1 categories. Five-year contract with a single Indian outsourcer. Moderate CMDB hygiene. Well-maintained ServiceNow; inconsistent integration with endpoint management.

Phase 1 (months 0–3). MCP gateway stood up. Three tools exposed: ServiceNow, Active Directory, Intune. One agent built: L1 password-reset and account-unlock automation. No-code builder wired. Baseline measured. Six gateway calls per minute by week ten.

Phase 2 (months 3–9). Orchestrator agent and VDI-triage workflow live. SCCM, Splunk, vSphere, NetBackup exposed. Fifteen SDMs and twenty senior engineers trained on the builder. L1 auto-resolution stabilises around 22 percent. Headcount has not changed yet, but queue depth has dropped by around 30 percent and customer satisfaction has lifted by single-digit points.

Phase 3 (months 9–18). Onboarding workflow live. Emergency patch workflow live. Asset and license reconciliation agents live. L1 auto-resolution stabilises around 32 percent. The customer asks why the monthly report has improved so visibly. The renewal conversation opens.

Phase 4 (months 18–24). Renewal lands on a hybrid commercial model — partial FTE billing plus a per-ticket envelope. Around four percent of the original FTE base is redeployed to other accounts. Another eight percent shifts to higher-value advisory work. The remainder continues in delivery roles. The vendor’s blended margin on the account improves by approximately two to four percentage points despite a lower headline contract value. Customer-side, cost-per-incident reduces by around 18 to 22 percent.

The metrics that actually decide success are not the headline ticket numbers. They are therenewal terms and theredeployment ratio. The renewal tells you whether the platform investment converted into a defensible commercial position. The redeployment ratio tells you whether the firm managed the internal political conversation well enough to keep its experienced people inside the business.

The bank is fictional. The numbers should be read as illustrative.

What To Do This Quarter

Three concrete actions for the executive reading this with a calendar full of other meetings.

One. Pick a single client account and a single process. Stand up an MCP-centred gateway against it. Two-quarter timeline. Real money — somewhere between $500K and $2M depending on starting position and tool count. Password reset and account unlock are the canonical starting workflows because the volume is enormous and the failure modes are well-understood.

Two. Open the commercial conversation in parallel with the technical build. Do not wait for delivery. Renewal cycles are long, and the conversation about deal shape needs months of customer education before it can convert. The technical platform and the commercial repositioning are two sides of the same investment.

Three. Pick the right SDM and the right tower lead to champion the rollout. The wrong choice will produce technical success and commercial failure. The internal politics of automation are as important as the architecture — possibly more.

Where To Go Deeper

The full analysis — protocol-versus-platform distinction, competitive landscape, role taxonomy, three concrete workflows in detail, the risks landscape, the five-phase rollout path — is in the long-form companion piece:From Service Desk to Agent Fabric.

The work that distinguishes the firms that win from the firms that wait is the execution discipline applied to both halves of the problem. The platform is the easier half. The conversation about who gets paid for the productivity is the harder half. Both must happen at the same time.

Uber’s engineering team has published material describing a meaningful shift in how they operate AI inside the company. They have moved Model Context Protocol (MCP) from a pilot into a standardised internal platform. Their published numbers — in the engineering blog and the accompanying conference talk linked at the foot of this post — describe in the order of sixty thousand weekly AI tasks flowing through a centralised gateway, with around ten thousand internal services exposed as agent-callable tools. Engineers and non-technical staff compose those tools into workflows through either a no-code builder or SDKs, with governance, redaction and access control inside the platform rather than in each agent.

That is interesting on its own technical merits. It becomes much more interesting if you sit in Bangalore, Pune, Hyderabad, Chennai or Noida and run a large infrastructure-delivery organisation for global clients. The pattern Uber has industrialised internally is, in shape, the same pattern that Indian IT outsourcing has been circling around for years without quite landing.

This article walks through what Uber appears to have built, separates that confirmed picture from my own extrapolation into the outsourcing world, places it in a maturity model, and addresses the political and commercial reasons why the rollout is harder than the architecture diagrams suggest.

If you only have six minutes, there is acompanion executive briefing covering the maturity model, the incentive conflict and the bank case study. This is the long form.

What’s Verified, What’s Mine

Before going further: what Uber has publicly described — the gateway pattern, the auto-conversion of service endpoints into MCP tools, the no-code builder, the weekly-task and service-count numbers — is treated here as theconfirmed picture, citable to their public material. The specific figures (60,000 weekly tasks, 10,000 services) come from Uber and should be verified against the linked sources rather than taken on my authority.

Everything that follows about Indian IT outsourcing — the role taxonomy, the workflow examples, the economic envelope, the rollout phases, the incentive analysis, the bank case study — ismy extrapolation, informed by fifteen years inside the industry. It is not an Uber statement and should not be read as one.

That separation matters because the Uber numbers travel well — they get repeated in pitch decks and LinkedIn posts without the surrounding caveats — and outsourcing-specific claims get attributed back to Uber in ways that misrepresent what they actually said.

Protocol Versus Platform

A precision point worth getting right up front, because technical readers will object if it is left fuzzy.

MCP itself is a protocol. It specifies how an AI agent describes tools, calls them, and consumes their results. It is open, broadly adopted, and useful. The protocol on its own does not build a platform. HTTP is a protocol — the World Wide Web is the vast set of conventions, infrastructure and tooling built on top of it. MCP sits in the same relationship to a platform like the one Uber has built.

What Uber has built is not “MCP”. It is agateway, registry, governance and builder platform that uses MCP as its interface contract. The protocol is the load-bearing standard. The platform around it is where most of the engineering investment sits.

For the rest of this article, when I say “the Uber MCP stack” or “an MCP-centred fabric”, I mean the protocol-and-platform combination. When I mean the protocol itself, I will say “the MCP specification”.

Uber’s Build, In Four Pieces

Before standardising MCP, Uber’s AI initiatives looked like most large engineering organisations’ — multiple teams, multiple stacks, multiple ways of calling internal services, and every new agent requiring hand-wired integrations against an estate of around ten thousand services. Governance was worse: each integration had its own access pattern and (often non-existent) data-redaction story. Uber has been candid in their public material that this was the state they were trying to change.

What they built has four moving parts.

Agateway sits between every agent and every internal service. AI traffic terminates there. Authentication, authorisation, rate-limiting, logging and PII redaction happen at a single layer, so that sensitive-data handling is done once rather than once per agent.

Aregistry catalogues the tools an agent can call. The decisive design choice — and the source of most of the engineering value — is that Uber did not require every team to hand-write an MCP tool definition. Their toolingauto-converts existing service endpoints into MCP tools. New service ships, new tool appears, agents pick it up.

Ascanning and access-control layer runs inside the gateway. Every tool registered goes through risk scanning. Every call is bound to a named identity with scoped permissions and is logged.

Abuilder layer sits on top: a no-code workflow composer for non-engineers, and SDKs for engineers. Both produce workflows that run through the same gateway against the same registry. There is no second-class tier of tools or governance.

Uber’s material also describes a future direction — askills repository that curates and shares verified multi-step workflows across the organisation, on the model of an internal app store.

What’s Actually Novel

Most of the individual components are not new. API gateways are decades old. Tool registries exist in many forms. Governance is well-trodden territory. What is distinctive is thecombination at scale, with one open protocol as the contract, and with auto-generation of tools from existing service definitions.

Specifically: the auto-conversion of endpoints into MCP tools is the multiplier. Without it, exposing ten thousand services as agent-callable would be a years-long manual programme, and most organisations stop at a few hundred. With it, the marginal cost of bringing a new service into the agent surface area drops close to zero, and the platform compounds.Every new tool added makes every existing agent more capable. That compounding is the architectural insight most observers miss.

The single governance chokepoint is the second distinguishing characteristic. Many enterprises have built point AI integrations; few have built one place through which every AI call passes, logged, audited and scoped. That single chokepoint is what makes the platform credible to a public-company audit function.

What It Bought Them

The published numbers — around sixty thousand weekly AI tasks and ten thousand services exposed — are the headline. The qualitative outcomes Uber describes matter as much: governance moving from per-project negotiation to platform property, every new tool exposed making every existing agent more capable, and the population of people able to compose workflows expanding well beyond the AI engineering team.

Verify the methodology against the linked engineering blog and conference talk before quoting these figures further. The definitions of “task” and “service” matter, and pitch-deck repetition tends to lose the qualifiers.

Why MCP And Not An Existing Platform

A reasonable question: why would an outsourcer build an MCP-centred fabric rather than adopt one of the existing platforms already in this space?

ServiceNow’s AI agents and Workflow Studio are strong when ServiceNow is the system of record, weaker when the client estate is multi-vendor.

Microsoft Copilot Studio is excellent if the estate is heavily M365/Azure-centric. The trade-off is platform lock-in and a relatively closed extensibility model.

Moveworks and Aisera are specialist L1-automation vendors — strong out-of-the-box for tickets and natural-language ITSM, less flexible beyond the service desk.

PagerDuty AIOps targets incident response and on-call; not designed as an estate-wide fabric.

UiPath, Automation Anywhere and Blue Prism are RPA platforms with AI features layered in; they work, particularly for legacy systems without APIs, but were not designed around the agent-orchestration model.

Atlassian Rovo, Cortex, and OpenAI operator-style systems are credible newer entrants, worth tracking particularly when the underlying platform is already in use.

The case for an MCP-centred fabric is specifically protocol-openness and multi-tenant flexibility. An Indian outsourcer running infrastructure for thirty different clients does not want to bet on each client’s chosen vendor stack. They want a fabric that can wrap any client’s tool surface — ServiceNow at client A, BMC at client B, Cherwell at client C — into the same agent-callable shape. MCP is the only protocol-level standard that makes that portable.

The honest counterpoint: the MCP ecosystem is younger than any of the platforms above, and the per-tool engineering effort to build wrappers is real. The right answer for most outsourcers is probablyboth — use Copilot Studio or ServiceNow AI inside specific engagements where platform fit is strong, and stand up an MCP-centred fabric as the cross-client integration substrate that owns multi-tenant governance.

The Outsourcing Mirror

Replace “Uber’s ten thousand internal services” with“a client’s BigFix, SCCM, Intune, ServiceNow, Active Directory, Azure, vSphere, NetBackup, Splunk, CrowdStrike, Citrix DaaS and forty other tools” and the structural picture is the same. Indian IT outsourcing companies run the infrastructure for a large share of the Global 2000. The same constellation of vendor tools, the same heavy ITIL process layer, the same delivery pyramid of engineers operating that process at scale.

A typical infrastructure engagement touches forty to one hundred discrete tools, most with an API and none currently agent-safe. ITIL workflows are structured, repeatable and multi-system — the exact shape an orchestration platform is designed to industrialise. A large outsourcing tower processes hundreds of thousands of tickets a month, of which a meaningful proportion is highly repetitive.

The genuinely difficult difference is multi-tenancy. Uber operates one estate. An outsourcer operates many. The platform has to be multi-tenant by design — strong client isolation, separate audit boundaries, per-client data sovereignty. That is materially harder than the Uber single-tenant build.

The Service Desk Becomes A Routing Layer

A working taxonomy of roles inside a typical infrastructure outsourcing tower, sorted by how aggressively the MCP-centred pattern can be applied.

Fully automated covers password resets, account unlocks, drive and printer mappings, mailbox quota requests, software-catalogue requests, license assignment, standard patch deployment, backup-job verification, daily dashboards, and joiner-leaver provisioning. Structured inputs, well-defined steps, known failure modes. Agents run them; humans review the exception queue.

Agent-led with human approval covers production change execution, privileged access grants, firewall rule additions, DNS changes — anything that would have gone through a CAB. The agent drafts the change record, attaches the technical justification, runs pre-change validation, and produces the back-out plan. A human approves with a click.

Human-led with agent assist covers L2 and L3 incident analysis, root cause analysis, architecture review, capacity planning, vendor escalation, major-incident communications and service-review preparation. The agent gathers diagnostics, summarises logs, retrieves relevant knowledge-base material, and drafts a first version. The human applies judgment, two to four times faster.

Human-only, at least for now, covers Sev-1 crisis leadership with customer C-suite involvement, contract negotiation, performance management, and the conversations that require reading what is not being said. The agent can prepare the brief; the conversation is yours.

The role that changes most is theL1 engineer. Most of the L1 queue today is repetitive triage; after MCP, most of that volume is auto-resolved before reaching a human. The L1 engineer ends up doing what L2 does today — the genuinely novel cases. The role population shrinks but the people in it operate at a higher level.

Thepatch-management engineer moves from running deployments to owning strategy. Theasset and license manager shifts from reconciliation to vendor negotiation. TheSDM stops stitching reports together and starts having strategic conversations.L3 specialists are the least affected in volume but the most augmented in capability — the same person designing a thirty-thousand-endpoint patching strategy, with a domain agent at their side that knows every Fixlet and every advisory.

Three Workflows In Detail

Three concrete workflows, each composed from agents calling registered tools through the gateway. Every system referenced is one Indian outsourcers already run for clients.

A — VDI session won’t connect

Today, a ticket of this shape sits in the L1 queue for fifteen to forty-five minutes before an engineer picks it up, asks for basic information the user has not provided, checks four or five systems by hand, and either resolves it or escalates.

With an MCP-centred fabric, the ticket arrives at an orchestrator agent that recognises the symptom class and dispatches in parallel — an Active Directory agent checks account status and recent authentication failures; an Intune agent checks device compliance and last-seen timestamp; a Citrix agent checks session-host availability and active maintenance windows. Within seconds the orchestrator has a structured diagnostic.

If the issue is a known pattern, the orchestrator resolves directly or routes the user to the right self-service path. If the diagnostic shows something unusual, the orchestrator escalates to L2 with the full brief pre-attached. The L2 engineer reads a one-paragraph summary and makes a decision, rather than starting from zero in four different tools.

B — New joiner onboarding

HR fires a “new hire confirmed” event. An onboarding orchestrator reads the role profile and location. An identity agent creates the AD account and provisions the M365 mailbox. A licensing agent assigns the right SKUs. An endpoint agent triggers the laptop build. A collaboration agent adds the new joiner to relevant Teams and SharePoint sites. A VPN agent provisions remote access. A notification agent sends the welcome packet and notifies the manager.

Every step is logged. Every approval that requires a human — sensitive group memberships, elevated privileges, anything outside policy — is routed as a single one-click decision. What used to be a three-to-five-day, twelve-touchpoint process across three teams becomes a four-to-eight-hour automated workflow with a clean audit trail.

C — Emergency patch deployment

A vendor publishes a critical advisory. A vulnerability agent parses it. A CMDB agent identifies affected assets. A risk agent calculates the blast radius. A change agent drafts the emergency CAB record — justification, test plan, back-out plan, customer notification — and routes for one-click approval. A patch agent executes the pilot deployment. A monitoring agent watches for regressions. If no regressions, broader rollout proceeds in stages. A reporting agent generates the customer report at each stage.

The patch-management engineer’s role here is to set the strategy, define the pilot group, review the monitoring envelope, and approve the rollout cadence. One engineer, around an engineer-hour in the loop and four-to-eight hours of wall-clock execution, on a workflow that previously consumed two to three engineers across one-and-a-half days.

From FTE Arbitrage To Outcome Arbitrage

The strategic case is more persuasive with numbers. The figures below aredirectional, my own estimates based on what I have seen in infrastructure delivery — not Uber numbers and not benchmarks. Real client engagements will move these by a factor of two or three either way depending on tower maturity, tool quality and data hygiene.

These are platform-success-case figures, not industry averages. Realistic deployments will hit the lower bound of the “after” column unless three conditions are met: clean CMDB hygiene, well-classified ticket taxonomy, and an MCP-centred fabric covering at least 60 percent of L1 ticket categories. The “before” column reflects mid-range offshore-billed contracts; US- and Europe-billed contracts run two to three times higher on the L1 cost line.

Metric	Today (typical)	With MCP-centred fabric
Password reset, end-to-end	8–15 min	1–2 min
L1 ticket auto-resolution rate	5–15%	25–40%
MTTR, repetitive L1 incident	30–60 min	2–5 min
MTTR, L2 incident	90–240 min	60–180 min
New-joiner onboarding cycle	3–5 business days	4–12 hours
Emergency patch deployment	2–3 engineer-days	1 engineer-hour (4–8 hr wall-clock)
L1 ticket cost (fully-burdened, offshore)	$5–$25	$0.50–$1.50
Change-record drafting	30–60 min	5–10 min
SDM reporting overhead (per week)	6–10 hours	2–3 hours
License optimisation cycle	quarterly manual	continuous

The L1 auto-resolution rate is the line worth interrogating most carefully. Public Moveworks and Aisera figures advertise 40–60 percent on flagship deployments, but the deployed-average across their customer base is closer to 25–35 percent. The 25–40 percent range above reflects that deployed-average reality, not the marketing number.

The commercial implication, if these numbers hold even directionally, is the structural shift from billed-FTE to billed-outcome. That shift has been talked about in this industry for a decade. The MCP-centred pattern is the first thing I have seen that makes it plausibly executable. Whether the industry actually executes it is a different question — and the most interesting one in this whole article.

The Incentive Problem

The hardest problem here is not technical. It is commercial and political, and the previous version of this article underplayed it.

Outsourcing revenue is FTE-shaped. A typical infrastructure deal is priced as a stack of named roles — L1 engineers, L2 engineers, L3 specialists, SDMs, project managers, change managers — multiplied by a billing rate and a headcount, with volume commitments and tiered SLAs layered on top. When an outsourcer reduces the headcount required to deliver a given service, the immediate effect is a smaller bill to the customer. That is revenue cannibalisation, and it cuts directly against the platform business case.

The same is true at the individual delivery-team level. A tower lead’s annual review is partly shaped by the size of the tower. A practice head’s standing inside the firm is partly shaped by the practice’s billable headcount. When automation reduces both, the people who would have to champion the platform are also the people whose internal position it weakens. This is not a moral failing on their part — it is rational behaviour given how the firm rewards them.

There are four paths through this, and they tend to fail in different ways.

Path one — productivity dividend. Keep the FTE count and use the productivity gains to expand scope or accept new work without growing the team. This is the path of least internal resistance but the one most likely to produce no measurable customer benefit and therefore no commercial differentiation.

Path two — margin retention. Hold the customer price flat, reduce the delivery cost through automation, retain the margin. This works in shorter contracts but creates trust issues at renewal — customers eventually see the AI talking points elsewhere and ask why they are paying yesterday’s price for tomorrow’s delivery model.

Path three — outcome repricing. Move new contracts to per-ticket, per-incident or per-user pricing where automation directly drives margin. This is the structural prize but requires commercial nerve, and the renegotiation conversation is uncomfortable. Existing customers will ask why their renewal terms are changing; new customers will ask whether the model has been proven elsewhere first.

Path four — productivity-billed sharing. Open-book pricing where automation gains are explicitly shared between vendor and customer. Mature, durable, hard to negotiate. Requires the kind of trust relationship that exists in a small minority of outsourcing accounts.

Customers will also resist. Not all customers, but a meaningful share — particularly in regulated industries where automated change execution is uncomfortable, where data-sovereignty constraints make agentic processing politically difficult, or where the customer’s own IT organisation has a vested interest in keeping the outsourcer’s headcount visible and known.

None of this is a reason not to build the platform. It is a reason to plan the commercial conversation as carefully as the technical one. The firms that succeed will be the ones that build the platformand have the commercial discipline to convert the technical capability into a different deal shape. The firms that build the platform but cannot have the conversation will end up with a quietly impressive internal capability that does not show up in revenue.

Where This Can Go Wrong

The first version of this article underplayed operational complexity. The honest list of failure modes.

Automation blast radius. An agent that can change firewall rules across an estate can break that estate at machine speed. Mitigations: layered approvals, staged rollouts, kill switches, per-action blast-radius modelling.

Incorrect remediations. The agent confidently executes a fix that is wrong for the specific environment. Mitigations: bias toward propose-not-execute for production actions, confidence scoring on every action, source attribution.

Data quality dependency. The platform is only as good as the data it relies on. The CMDB problem is the most visible — agents need accurate asset inventory for identification, blast-radius calculation and change correlation, and most long-running outsourcing engagements have CMDB hygiene problems that have been tolerated for years. Beyond CMDB, the same applies toknowledge-base quality (agents grounded in stale or contradictory KB articles produce confidently wrong answers),ticket-taxonomy quality (poorly classified incident categories destroy the orchestrator’s routing accuracy),inconsistent naming and tagging (the same server appearing as three different identities across tools), and thetribal-knowledge problem (the senior engineer who knows the one production server that must not be patched on Wednesdays because of a quirk that was never documented). Standing up the fabric forces these issues into daylight, which is uncomfortable in the short term and necessary in the long term.

Privilege escalation. Scopes too broad means agent compromise gives lateral movement. Mitigations: minimum-privilege per workflow, separate identities per agent, secret rotation, prompt-injection defences.

Audit, legal and data sovereignty. Cross-border inference is a real audit issue; contracts often constrain where prompts can travel. Mitigations: region-pinned gateway, sovereign model selection, redaction before any cross-border hop.

AI-induced outage. Tool-wrapper regression, model behaviour change, or workflow loop can cascade. Mitigations: canary tool deploys, per-client model pinning, workflow tests in CI, clear rollback story.

Over-automation. Removing humans from too many steps removes the implicit knowledge transfer that keeps L2 and L3 engineers sharp. The L1-to-L2 promotion path was always partly about pattern recognition built up over thousands of tickets. Mitigations: rotate humans through agent-handled work for training, design agent output as a learning surface rather than a black box.

Integration brittleness. Auto-generated tool wrappers are not always semantically correct — the wrapper might technically work but get the underlying business logic subtly wrong. Mitigations: human review of high-stakes wrappers, regression test suites at the tool level, a tiered trust model (draft → verified → skills-grade).

None of these is a reason not to build the platform. All are reasons to build it with the operational discipline that distinguishes a working enterprise platform from a clever demo.

A Maturity Model

The pattern fits into a broader six-stage model that locates outsourcers against where the industry is heading.

Stage	Capability	Where it sits
0	Scripts (PowerShell, Bash, ad-hoc)	Legacy operations
1	RPA (UiPath, Blue Prism — UI-driven)	Most outsourcers today
2	Copilots (Moveworks, Aisera, Copilot Studio — per-tool LLM helpers)	A growing share of leading-edge engagements
3	MCP gateway (single chokepoint, registry, governed tools)	Uber’s published state
4	Multi-agent workflows (orchestrators, specialists, skills repository)	Very few in production at scale
5	Outcome-billed delivery (per-ticket, per-incident, per-user pricing)	None at scale yet

The ceiling between Stage 2 and Stage 3 is where the platform investment matters. Everything before Stage 3 is point automation — useful, productive, but not compounding. Stage 3 is where every new tool exposed makes every existing agent more capable, and where governance becomes a property of the platform rather than the agent. Stages 4 and 5 are where the commercial model shifts.

Most outsourcers reading this article sit at Stage 1 or 2 for their largest accounts. The honest gap to Stage 3 is two to four quarters of platform work plus the unglamorous data-hygiene investment described in the risks section. The gap from 3 to 5 is the incentive problem above.

Case Study: An 80,000-Endpoint Bank

To anchor the abstractions, a fictional but representative client journey.

A global bank with 80,000 endpoints across thirty countries, currently outsourced to a single Indian IT provider on a five-year contract. The current delivery footprint is roughly 450 named FTEs across all towers (service desk, endpoint, identity, cloud, network, security operations) — an endpoint-to-FTE ratio of around 1:175, which is typical for a well-run but not bleeding-edge tower. Monthly ticket volume sits around 95,000, of which roughly 42,000 are repetitive L1 categories. The customer’s CMDB hygiene is moderate; their ITSM (ServiceNow) is well-maintained but the integration with their endpoint management estate (a mix of SCCM and Intune) is inconsistent.

Phase 1 (months 0–3). Stand up the MCP gateway. Expose three tools: ServiceNow, Active Directory, Intune. Build one agent: L1 password-reset and account-unlock automation. Wire the no-code builder. Measure baseline. Six gateway calls per minute by week ten.

Phase 2 (months 3–9). Expose SCCM, Splunk, vSphere, NetBackup. Build the orchestrator agent and the VDI-triage workflow. Train fifteen SDMs and twenty senior engineers on the builder. By month nine, around 22 percent of L1 volume auto-resolves; the L1 headcount has not changed yet, but the queue depth has dropped by around 30 percent and customer satisfaction has lifted by single-digit points.

Phase 3 (months 9–18). New-joiner onboarding workflow goes live. Emergency patch workflow goes live. Asset and license reconciliation agents go live. The L1 auto-resolution rate stabilises around 32 percent. The bank’s customer asks why the SDM monthly report has improved so visibly. The renewal conversation begins.

Phase 4 (months 18–24). Renewal lands on a hybrid model — partial FTE billing plus a per-ticket envelope. Around four percent of the original FTE base is redeployed to other accounts; another eight percent shifts to higher-value advisory work; the remainder continues in delivery roles. The vendor’s blended margin on the account improves by approximately 2–4 percentage points despite the lower headline contract value. Customer-side, the cost-per-incident reduces by around 18–22 percent.

The interesting metrics in this case are not the headline ticket numbers. They are the renewal terms and the redeployment ratio. The renewal is what tells you whether the platform investment converted into a defensible commercial position. The redeployment ratio is what tells you whether the firm managed the internal political conversation well enough to keep its experienced people inside the business.

The fictional bank is a composite, not a real client, and the numbers should be read as illustrative rather than predictive.

The Rollout Path

A staged path for an outsourcer starting today. The phases are deliberately conservative.

Phase 1 (months 0–3). Pick one client, one process. Stand up a per-client MCP gateway. Expose three to five tools. Build governance from day one: scanning, redaction, audit logging, scoped access, secret rotation. Build one specialist agent. Measure baseline before anything is turned on.

Phase 2 (months 3–6). Build the no-code builder layer. Train ten SDMs and ten senior engineers. Compose the first three workflows — password reset, account unlock, basic VDI triage. Publish the numbers internally.

Phase 3 (months 6–12). Expose the rest of the client’s estate. Build specialist agents per major tool. Compose the next ten workflows. Begin the internal skills-repository pattern, curated rather than free-for-all.

Phase 4 (year 2). Replicate the platform pattern to the next two or three clients. Each new client engagement still requires substantial per-client work — tenant isolation, data sovereignty, CMDB onboarding, integration with each client’s specific tool versions, contract renegotiation, change management with the client’s IT organisation. Implementation time improves from quarters to a few months, not weeks.

Phase 5 (year 3+). Outcome-billed contracts begin to make sense with two or three reference clients in production. The commercial nerve to renegotiate large multi-year contracts on a new basis is as important as the technology by this point.

The substantial work that remains, even after the platform pattern is established, includes identity federation across client tenants, robust RBAC for multi-tenant agent access, rollback safety for agent-executed changes, hallucination containment in production conditions, change-governance integration with each client’s existing CAB, observability across the full stack, and workflow determinism for processes with regulatory SLAs. These are the issues that determine whether the platform delivers in production or merely demos well.

The Third Wave

Indian IT outsourcing has been through three waves. Offshoring in the 1990s and early 2000s — moving work from where it was expensive to where it was cheap. Digital transformation in the 2010s — moving customers from legacy stacks to cloud, mobile and modern collaboration. The third wave is automation-led services — moving the unit of delivery from the FTE to the agent-augmented workflow.

The companies that build a credible MCP-centred fabric first will set the terms for the decade that follows. The ones that wait will negotiate with customers who have done the math and know what the cost-per-ticket should be in a world where an agent handles a meaningful share of the volume.

Uber’s published material is the most usable public case study to date of what such a platform looks like in production at scale. The architecture is reproducible. The protocol is open. The operational discipline required is well within what mature outsourcing organisations already have. The incentive conversation is harder than the engineering, and it is the part that decides who wins.

The technology has been ready for two years. The platform pattern is now visible. The work that remains is execution, and the conversation about who gets paid for it.

Sources & Notes

Uber claims in this article reference the company’s publicly available engineering material on MCP:

• The conference talk:https://youtu.be/yVqMxBahjfA
• Uber’s engineering blog athttps://www.uber.com/blog/engineering/ — search for their MCP and AI platform posts.
• The Model Context Protocol specification athttps://modelcontextprotocol.io

Vendor capabilities in the competitive-landscape section reflect publicly available product documentation as of 2026 and move quickly; verify with vendors directly before procurement decisions.

Economic envelope figures, the role taxonomy, the workflow examples, the maturity model, the bank case study and the incentive analysis are my extrapolation based on fifteen years in infrastructure delivery. Not benchmarked, not audited, not validated by any of the firms named. Treat as a starting hypothesis for a client-specific business case, not as a benchmark.

Where the article uses “could”, “would” or “should”, that is deliberate hedging. The MCP-centred pattern is a working architecture inside Uber; whether it works equivalently inside a multi-tenant outsourcing environment is a thesis I find credible but cannot yet point to a published reference for.

Feedback, corrections and counter-evidence are welcomed.

Ask a general-purpose LLM how to deploy an emergency Microsoft patch to ten thousand endpoints through HCL BigFix Workspace+, and you will get a plausible answer. Read it carefully and you will also find quietly invented menu paths, mis-named Fixlet sites, and “best practices” that no BigFix administrator has ever followed. The model has clearly seen the product once or twice during pre-training, just not enough to be useful when the deployment window opens at 10pm on a Tuesday.

This is the gap that specialist agents are meant to close. Not by retraining a foundation model — that is expensive, slow, and almost never the right tool — but bygrounding a capable general model in a curated body of authoritative product knowledge that you control. The interesting part is that the body of knowledge required to make a model genuinely competent in a specific product is, for most enterprise vendors, already public. Administration guides, release notes, knowledge centre articles, support bulletins, hardening guides, command references — all of it sits on the vendor’s documentation site, free to read and free to index.

This post walks through a working proof-of-concept I built around exactly that idea:the BigFix Workspace+ Expert Agent, a Retrieval-Augmented Generation (RAG) specialist trained on public BigFix documentation. It is small enough to run on a laptop and good enough at its domain to demonstrate where this pattern earns its keep. More importantly, the architecture is product-agnostic — swap the knowledge base, change the system prompt, and the same pattern produces a specialist for VMware Horizon, ServiceNow ITSM, Citrix DaaS, Microsoft Intune, or any other vendor whose docs you can legally crawl.

Why General LLMs Are Not Good Enough For Product Depth

A general-purpose LLM pushed into vendor-specific territory tends to fail in the same five ways every time. A RAG-based specialist agent attacks all five at once — the knowledge base sits outside the model, can be refreshed when the vendor publishes a new release, retrieves verbatim passages instead of synthesising from memory, returns the source documents alongside every answer, and refuses to leave its declared domain.

The Premise — Public Vendor Data Is The Training Set

Enterprise software vendors publish an enormous amount of high-quality technical content for one reason: their customers cannot deploy or operate the product without it. HCL, Microsoft, VMware, Citrix, Red Hat, ServiceNow — all of them maintain extensive documentation sites and most also publish support knowledge bases, community forums, and architecture reference papers.

Three categories matter most for a support and architecture agent:

The first isproduct documentation — administration guides, deployment guides, console references, API references. This is your “how does the product work” layer. It is structured, versioned, and authoritative.

The second isknowledge base and support articles — the “how do you fix this when it breaks” layer. These articles are written by support engineers for symptoms that real customers have actually hit. They are gold for a troubleshooting agent.

The third isarchitecture and best-practice content — reference architectures, sizing guides, hardening guides, integration playbooks. This is your “how should you actually deploy it” layer.

Once you have those three corpora indexed, you have something that no general LLM has natively: a tight, current, citable body of knowledge with the depth that real practitioners need.

The Case Study — BigFix Workspace+ Expert Agent

HCL BigFix Workspace+ is a unified endpoint management platform — agent-based endpoint discovery, patch management for Windows / macOS / Linux / 100+ third-party apps, software distribution, CIS and STIG compliance scanning, and workspace analytics. It is a serious enterprise product and a representative target: the kind of platform where a general LLM is only superficially useful and where a specialist agent has obvious value for L1/L2 support, internal enablement, and architecture sanity-checks.

The POC ingests a curated set of public BigFix Workspace+ documentation across six domains:

1. Product overview and architecture
2. Patch management
3. Troubleshooting
4. Security and compliance
5. Software distribution
6. Workspace analytics

Each domain is a markdown document. In the POC the documents are hand-curated extracts; in a production deployment you would point the same pipeline at the vendor’s Knowledge Center, scrape it on a schedule, and feed the output straight through.

The Tech Stack along with production Swap:

Cost to run a demo session sits well under ten cents in API calls. The whole system fits in a single repository and runs on a laptop with a Python virtual environment.

Architecture

The pipeline is the standard RAG topology, split into an offline ingestion stage (runs when the knowledge base is built or refreshed) and a runtime query stage (runs for every user question). The vector store is the shared component that bridges the two.

The Ingestion Pipeline

Three steps: load, chunk, embed.

Loading is mechanical — read every markdown file in the knowledge base directory, attach source metadata (filename plus adomain tag so multiple products can share a database later), and return a list of documents.

Chunking is where most of the retrieval quality is actually won or lost. The POC uses LangChain’sRecursiveCharacterTextSplitter with separators ordered from most to least semantic — heading-level breaks first, then paragraph breaks, then sentences, then words:

splitter=RecursiveCharacterTextSplitter(chunk_size=1000,chunk_overlap=200,separators=["\n## ","\n### ","\n#### ","\n\n","\n",". "," "],)

The reason for this ordering matters. Technical documentation is dense with structured headings — “Creating a Patch Action”, “Patch Discovery”, “Maintenance Windows” — and a chunk that respects those boundaries reads as a coherent unit. A chunk that arbitrarily splits a numbered procedure in half does not. The 200-character overlap is there so that a sentence at the boundary still appears in both chunks; this materially improves recall when a user’s query phrasing matches text near a chunk edge.

Embeddings are produced withtext-embedding-3-small — fast, cheap, and accurate enough for technical English. For a knowledge base of around six hundred lines of markdown the entire ingestion runs in under five seconds and produces roughly eighty to a hundred chunks.

The Agent

Two things make the agent specialised: thesystem prompt and theretrieval contract.

The system prompt establishes the agent’s persona, the rules of engagement, and — critically — the refusal policy. The relevant parts:

You are the BigFix Workspace+ Expert Agent, a specialist AI assistant forHCL BigFix Workspace+ — a unified endpoint management platform.Rules:1. ONLY answer questions related to HCL BigFix Workspace+. If a question is outside your domain, politely redirect.2. Base your answers on the provided context. If the context doesn't contain enough information, say so honestly rather than guessing.3. When providing steps or commands, be specific and include the exact paths, commands, or navigation instructions.4. Always cite which area of BigFix your answer relates to.

The agent is told, explicitly, not to extrapolate. This is the lever that turns a chatty general-purpose model into something that behaves like a knowledgeable but appropriately humble support engineer. If the retrieved context does not address the question, the model is instructed to acknowledge the limitation rather than synthesise an answer from its parametric memory.

The retrieval contract is the second half of the specialisation. For every query, the agent retrieves the top-k chunks (k=4 in the POC) above a relevance threshold of 0.3, concatenates them into a single context block, and passes the question and context into the LLM. If retrieval returns nothing above threshold, the agent short-circuits and returns a polite “I do not have that in my knowledge base” response without ever calling the LLM. This is a small detail with a large effect — it prevents the model from confabulating answers when it has no evidence.

Confidence Scoring And Escalation

One of the design decisions I am most happy with is the explicit confidence score on every response. After generating an answer, the agent makes a second LLM call asking the model to rate how well the retrieved context actually addressed the question, on a scale of zero to one. If the score falls below a configurable threshold (default 0.7), the response carries an “escalation recommended” flag — surfaced in the UI as a coloured badge and, in production, used to route the question to a human L2 engineer or to a higher-tier orchestrator agent.

The result is a system that fails gracefully. It says “I don’t have that in my knowledge base” when retrieval comes back empty, and it raises a hand when retrieval succeeded but the response did not quite land. Very few naive RAG systems have either of those properties — most will confidently invent an answer either way.

Domain Guardrails

Ask the agent “what is the weather today” and it will not answer — not because it cannot, but because it has been instructed not to. The system prompt enforces a hard scope: BigFix Workspace+ questions only, everything else is politely redirected.

This sounds like a small thing. It is not. Domain isolation is the property that makes a specialist agenttrustworthy in an enterprise setting. A general assistant that wanders out of its lane is a liability — it will eventually answer a question that the organisation needs answered by a different specialist team, or worse, by a human with accountability. A specialist agent that refuses to leave its lane is the agentic equivalent of a senior engineer who knows what they know and is honest about what they do not.

This pattern also composes. Run a BigFix agent, a ServiceNow agent, an Intune agent, and a VMware Horizon agent in the same workspace, and give an orchestrator agent the job of routing incoming questions to whichever specialist is best placed to answer. The result is something that starts to look like a real virtual support organisation.

What This Approach Actually Buys You Over A General LLM

Five things, concretely.

The first iscurrency. The knowledge base can be refreshed on whatever cadence the vendor publishes new content — daily for an actively maintained product, weekly for everything else. The model itself never has to be retrained. Re-running ingestion against an updated set of source documents is the entire change-management process.

The second isaccuracy on product specifics. The answers come from passages that the vendor actually wrote, retrieved verbatim and handed to the LLM as context. The model still synthesises the response, but it is synthesising from authoritative source material rather than reaching into its compressed memory.

The third isauditability. Every response in the POC includes the list of source chunks that informed it, with relevance scores. A user — or an internal audit — can click into the sources and verify the claim against the underlying documentation.

The fourth isscope control. A general LLM will answer any question; a specialist agent answers only questions inside its declared domain. This is a feature, not a limitation. It is what makes the agent safe to deploy to a wide internal audience without needing to babysit its outputs.

The fifth isgraceful failure. The combination of a relevance threshold on retrieval, an explicit “I don’t have that in my knowledge base” response when nothing scores above the threshold, and a confidence score on every answer means the agent fails by saying “I don’t know” rather than by inventing an answer.

From POC To Production

The POC deliberately stops short of production. Six things would have to change to take this into an enterprise environment, and none of them are difficult — they are all standard enterprise-platform substitutions.

The first is theLLM provider. Swap OpenAI for Azure OpenAI to get enterprise compliance, data residency, and an enterprise SLA. The LangChain code already supports both — flipping between them is an environment-variable change.

The second is thevector store. ChromaDB is excellent for local development; for production you want Azure AI Search or Pinecone, both of which give you horizontal scale, snapshotting, and managed availability. The retrieval interface is identical.

The third isauthentication and access control. The Flask web UI is replaced with an Azure Bot Framework bot connected to MS Teams. The bot inherits Azure AD identity, which means every query is now tied to a named user, and access can be scoped per agent.

The fourth isobservability. Add LangSmith or a custom logging layer to capture query, retrieved chunks, confidence, response, and user identity for every interaction. This becomes the dataset that drives knowledge-base improvement — every time the agent says “I don’t know”, that is a gap to fill.

The fifth isautomated knowledge-base updates. Replace the manualpython ingest.py invocation with a scheduled pipeline that crawls the vendor’s documentation site, diffs against the last snapshot, and reindexes only what changed.

The sixth is themulti-agent layer. Once you have a second specialist agent (say, ServiceNow ITSM), you introduce an orchestrator agent — built on LangGraph — whose job is to read the incoming question, decide which specialist is best placed to answer, and route accordingly. This is where the architecture starts to earn its name as an “agentic library”.

Generalising The Pattern

The thing I want to draw out here is that almost nothing in the architecture above is specific to BigFix. The system prompt names the product, the knowledge base contains BigFix documentation, and the UI says “BigFix Workspace+ Agent” at the top. Everything else — the ingestion pipeline, the retrieval logic, the confidence scoring, the escalation flag, the domain guardrails — is the same for any vendor whose documentation you can index.

That is it. The same six steps produce a Citrix DaaS architecture agent, a ServiceNow ITSM workflow assistant, a VMware Horizon troubleshooting bot, a Microsoft Intune compliance helper, a Red Hat OpenShift operator’s companion. Pick the product, find the docs, run the pipeline.

Closing Thought

The interesting shift here is not technical. The technical pattern — retrieval-augmented generation — has been in production at large enterprises for two years. What is interesting is thatthe data you need to make a specialist agent meaningfully better than a general LLM at a specific vendor product is already free and public. The vendor put it there because their customers need it to operate the product. We have spent twenty years building search engines, knowledge bases, and support portals on top of that documentation. A specialist agent is the natural next layer — one that reads those same documents, understands the question being asked, and answers in the form the user actually wanted.

For me, the BigFix POC is one node in a larger experiment around what an agentic IT support and architecture function could look like. A specialist agent per product, an orchestrator on top, a confidence-aware escalation path into human L2 / L3 — all of it grounded in the documentation that already exists. None of the individual pieces are exotic. The interesting thing is what happens when you assemble them.

If you operate a workplace or infrastructure team and you have a product domain where the same questions get asked over and over by the same engineers, this is a weekend’s worth of work. The vendor has already written your training set.

Automation isn’t coming. It’s already here — and it’s accelerating faster than most organisations have planned for.

In the past two years, generative AI has moved from a novelty to a core part of how knowledge work gets done. Writing, coding, analysis, summarisation, customer interaction — tasks that once required specialists can now be initiated with a prompt. The World Economic Forum estimates that85 million jobs will be disrupted by 2025, while97 million new roles will emerge that require humans and machines to work together.

The uncomfortable truth is that the skills that made someone valuable in 2020 are not sufficient for 2030. Not because the work is disappearing entirely — but because the baseline has shifted. The tasks AI handles well are the ones most easily measured, most easily automated. What remains irreducibly human — and what organisations are now actively hiring for — are harder to fake, harder to code, and harder to scale.

The research is consistent across sources: theWorld Economic Forum Future of Jobs 2025 report, McKinsey’s workforce transition analyses, and a growing body of peer-reviewed evidence all point to the same cluster of capabilities. Not technical skills alone. Not soft skills alone. A specific combination of cognitive, interpersonal, leadership, and AI-fluency skills that together define effectiveness in an AI-augmented world.

This article walks through all 17 of them — drawn from a research-validated framework built on those primary sources — with enough detail to understand what each skill actually means and where to start building it.

The Framework: Four Categories, 17 Skills

The 17 skills fall into four categories:Cognitive Skills,Interpersonal & Human Skills,Leadership & Character Traits, andTechnical AI Skills. The split is intentional — effective performance in an AI-integrated workplace requires all four working together. Technical fluency without critical thinking produces prompt-execution without judgment. Interpersonal strength without resilience collapses under constant change. Leadership without integrity erodes trust at exactly the moment organisations need it most.

Part 1 — Cognitive Skills

Five cognitive skills define how you process information, communicate insight, and keep pace with change. These are the mental habits that determine whether you use AI as a tool or become dependent on it without understanding what it produces.

Critical Thinking

Critical thinking is the ability to analyse information objectively, identify assumptions, evaluate evidence, and reach reasoned conclusions — independent of what an AI, a manager, or a source claims. In an environment where AI can produce confident-sounding content that is factually wrong, this skill is no longer optional. The person who can interrogate an AI output, spot the flaw in a logical chain, and decide what actually holds up is the person who adds value above the model.

Storytelling

Data without narrative is noise. Storytelling is the capacity to take complex, technical, or ambiguous information and shape it into a form that moves people to understand and act. AI can draft a summary — it cannot yet understand which detail changes a room. The ability to read an audience, choose the right frame, and make information land is a persistent human advantage.

Learnability

Learnability is the drive and ability to continuously acquire new skills as conditions change. The half-life of technical knowledge is shortening — what was cutting-edge 18 months ago is now a commodity. The differentiator is not what you currently know but how quickly you can absorb, apply, and discard what you need. This is a learnable habit in itself: building structured routines around learning, reflection, and experimentation.

Financial Literacy

Financial literacy in this context means understanding the business logic behind decisions — how resources are allocated, how ROI is calculated, what the cost of inaction looks like. As AI tools proliferate, more people in non-finance roles are being asked to build business cases, evaluate vendor proposals, and justify investment. The person who can read a P&L and understand what it signals is better positioned to influence outcomes.

Metacognition

Metacognition is thinking about your own thinking. It’s the ability to notice when your reasoning is flawed, when a cognitive bias is operating, when you’re avoiding an uncomfortable conclusion. In fast-moving environments with incomplete information, this self-awareness separates people who course-correct early from those who double down on bad decisions. It’s also the foundation for using AI well — recognising where your own knowledge ends and where you need to verify.

Part 2 — Interpersonal & Human Skills

Five interpersonal skills define how you operate in relationship with others — colleagues, clients, teams, and the people impacted by your decisions. These are the skills most resistant to automation because they depend on presence, trust, and genuine human connection.

Human Behaviour

Understanding human behaviour — what motivates people, what creates resistance, how group dynamics operate — is the basis for effective collaboration, change management, and leadership. AI can analyse sentiment at scale; it cannot read the room in a difficult meeting or sense when a team is quietly disengaged. This skill is about developing the perceptual vocabulary to see what’s actually happening between people.

Empathy & Compassion

Empathy is not softness — it is a strategic capability. The ability to genuinely understand another person’s perspective, priorities, and constraints leads to better decisions, stronger relationships, and more effective communication. In a world where AI handles routine interactions, the interactions that remain human are the ones that matter most — and they require real presence.

Feedback Fluency

Feedback fluency is the ability to give, receive, and act on feedback without ego interference. Most organisations say they value feedback but have cultures where it rarely happens well. The people who can deliver honest assessment with care, receive difficult feedback without defensiveness, and build feedback loops into everyday work are significantly more effective — and make the teams around them more effective too.

Emotional Vulnerability

Emotional vulnerability is the willingness to admit uncertainty, acknowledge mistakes, and show up as a full human being in professional contexts. This is different from oversharing. It’s the courage to say “I don’t know,” “I got that wrong,” or “this is hard” — and in doing so, create the psychological safety that allows teams to do their best work. AI cannot model vulnerability. Leaders who can are rare and disproportionately effective.

Conflict Resolution

Conflict is not the problem — unresolved conflict is. The ability to navigate disagreement, surface the underlying interests beneath stated positions, and find workable outcomes without destroying relationships is essential in any organisation dealing with change. As AI accelerates the pace of change, the frequency and intensity of conflict around priorities, roles, and resources will increase. The people who can move through it constructively are invaluable.

Part 3 — Leadership & Character Traits

Five leadership traits define the character dimension of effectiveness. These are not competencies you can train in a weekend — they develop through sustained practice, reflection, and deliberate choices over time. They are also increasingly rare, and therefore increasingly valuable.

Patience

Patience is the capacity to maintain focus and composure in the face of delays, ambiguity, and setbacks — without becoming disengaged or reactive. In environments of rapid change, impatience is expensive: it leads to premature decisions, burned relationships, and abandoned initiatives just before they would have worked. Patience is not passivity; it’s the ability to sustain effort through the parts of the process that feel unproductive.

Resilience

Resilience is the ability to recover from setbacks, adapt to change, and keep going under sustained pressure — without losing effectiveness or identity. The pace of change in AI-adjacent industries means that failure, revision, and disruption are constant features of the work. Resilience is what separates people who iterate from those who stall. It can be built: through deliberate recovery practices, social support, and a relationship with failure that treats it as information rather than verdict.

Self-Reflection

Self-reflection is the regular practice of examining your own behaviour, decisions, and impacts — not to judge but to learn. Leaders who reflect are more consistent, more honest about their limitations, and more capable of genuine growth. In an environment where AI can surface patterns in your work that you would never notice, the people with strong self-reflection practices will use those insights productively rather than defensively.

Public Service Drive

Public service drive is the motivation to contribute beyond personal gain — to the organisation, the community, or the broader world. This is increasingly relevant as AI raises the stakes for decisions about automation, displacement, and the ethical use of technology. People who are driven by purpose beyond their own advancement make different choices, communicate differently, and attract different levels of trust from the people around them.

Integrity

Integrity is the alignment between your values and your actions — and the willingness to maintain that alignment when it’s costly. As AI systems enable new forms of data manipulation, synthetic content, and opaque decision-making, integrity becomes a competitive differentiator. Organisations that can demonstrate trustworthiness will command a premium. The people inside those organisations who model integrity shape the culture that makes that trustworthiness real.

Part 4 — Technical AI Skills

Two technical skills round out the framework. These are the most rapidly evolving — and the ones with the clearest immediate return on investment. Job postings referencing AI fluency rose7x between 2022 and 2024. The WEF projects 170 million new roles that require humans to collaborate effectively with AI systems. The floor for technical AI competence is rising.

Prompting & Vibe Coding

Prompting is the ability to communicate effectively with AI systems to get useful, accurate, and appropriately scoped outputs. This is not a trivial skill — it requires understanding how language models interpret instructions, how to provide context, how to structure multi-step tasks, and how to verify outputs critically. Vibe coding extends this to software development: describing what you want in natural language, iterating with an AI model, and producing working code without traditional programming expertise. Both capabilities are now teachable, testable, and directly applicable to most knowledge-work roles.

AI Workflow Integration

AI workflow integration is the ability to identify where AI can improve or replace steps in an existing process — and then actually implement that change. This requires both the technical literacy to understand what tools can do and the process thinking to redesign workflows around them. The people who are most effective here are not necessarily the most technically sophisticated; they are the ones who understand the work deeply enough to see where the leverage is.

Where to Start: Free Learning Paths

The final slide is a course directory — every course listed is free to audit on Coursera, mapped to the skill categories above. The path from “aware of these skills” to “actively developing them” starts with picking one. Not the most impressive one. The one that feels most relevant to where you’re working right now.

The Summary

The 17 skills above are not a checklist for becoming superhuman. They are a map of where the real work is — the capabilities that AI cannot replicate, that organisations are actively competing for, and that compound over time in ways that technical knowledge alone does not.

The division is useful:Cognitive skills shape how you think.Interpersonal skills shape how you connect.Leadership traits shape who you are under pressure.Technical AI skills shape how you extend your own capabilities. All four matter. The people who develop all four will have a meaningful advantage — not despite AI, but because of it.

The tools are available. The research is clear. The only question is where you start.

Sources: World Economic Forum Future of Jobs Report 2025; McKinsey Global Institute Workforce Transition Research; peer-reviewed literature on human skills in AI-augmented workplaces.

Credit: Idea for this presentation inspired by thispodcast.

Hi, I’m Ajay Walia

I’ve spent more than two and a half decades in the technology space. Started as an educator — teaching software engineering to HP/Compaq technical support in a call centre — then moved through Exchange, Wintel, datacentre, virtualisation, cloud, and digital workplace. The past couple of years have been all about transition and transformation of DWP, and now the same T&T remit has expanded acrossHybrid Cloud,Networks,Datacentre,Digital Workplace, andApplications.

Over the past 25 years I’ve experienced the shifts from client-server to web, physical infrastructure to virtualization, virtualization to cloud, and workplace computing to digital experiences.The next transition is AI. Much of my writing explores how AI will reshape enterprise technology, operating models, service delivery, and the way organizations create value.

Career Highlights

• 25+ years in enterprise technology
• Led transformation across APMEA, Europe, and global enterprise environments
• Built and scaled technology practices, Centres of Excellence, and consulting capabilities
• Navigated major technology transitions: Datacentre → Virtualization → Cloud → Digital Workplace → AI
• Architected and modernized enterprise platforms spanning cloud, workplace, infrastructure, and operations
• Exploring how AI agents and automation will reshape enterprise technology over the next decade

View full career history →

Education

• PGDBA, Management — Institute of Management Technology, Ghaziabad · 2011–2013
• Professional Diploma in Software Technology & System Management — NIIT · 1996–1999
• B.Com, Commerce — Delhi University · 1995–1998
• Advanced Diploma in German — Delhi University · 1997–1998

Selected Certifications

Cloud — AWS, Azure, Google Cloud

Microsoft — MCSE, MCSA, MCTS

VMware — VCP 3–6, VCA, AirWatch

Architecture — TOGAF

Delivery — Prince2, Scrum, ITIL

AI — Agentic AI, IBM GenAI, AWS GenAI

View full certification list →

Languages

English — Full professional proficiency
German — Limited working proficiency

Before This Blog

I’ve been writing about technology since 2006 — starting with atechnical reference blog where I posted concepts and notes for colleagues. CuriousBit is the current iteration: cleaner, more focused, and built in the open.

I’m also a contributor toWhatMatrix — an independent community-driven comparison platform for enterprise technology. My contributions include theDaaS (Desktop as a Service) comparison matrix.

Thesource code for this site is public under an MIT licence. It was built with Hugo and Tailwind CSS, using AI tooling to accelerate the frontend work — an experiment in eating my own cooking.

Get in Touch

Find me onLinkedIn orInstagram, or explore theKnowledge Base for longer-form thinking.