Enterprise Agentic AI Grows Up: Pilot to 200-Agent Suites

What shipped this month

May 2026 was, on the evidence of the announcements alone, the month enterprise agentic AI moved from slideware to a product category. Five of the largest names in enterprise software and services each put a flag in the ground within a few weeks of one another. Taken individually, every one of these is a routine product launch. Taken together, they describe an industry-wide pivot — and, read carefully, an industry-wide confession.

Look down that table and notice what is, and is not, being sold. Google is selling silicon and a model platform. But ServiceNow's headline launch is not a model — it is a programme to put engineers inside customer buildings. Cognizant's launch is not a model — it is a services line for securing and governing agents someone else built. IBM's Content Cortex is not a model — it is plumbing to get enterprise content into a state agents can actually use. Three of the five flagship moves are explicitly about the work that surrounds the model. That is the story.

The bottleneck was never the model

For two years the public conversation about agentic AI has been a conversation about capability — context windows, reasoning benchmarks, tool-use reliability. Those things matter, and they have improved fast. But ask anyone who has tried to put an agent into a real enterprise where their pilot actually stalled, and the answer is almost never "the model could not reason well enough". It is "the agent could not reach the system of record", or "legal would not sign off without an audit trail", or "the data the agent needed was scattered across four applications with incompatible permissions".

The bottleneck, in other words, is integration and governance. It is the unglamorous middle layer between a capable model and a production workflow: connecting the agent to enterprise resource planning, customer relationship management and IT service management systems; resolving who is allowed to see and change what; building the evaluation harnesses that let a risk committee trust an autonomous process; and producing the logs that an auditor or a regulator will later demand.

This is why the recurring shape of the May announcements is so revealing. A forward-deployed engineering programme is not a model upgrade. A secure-AI services line is not a model upgrade. A content-services system to "prepare and govern" enterprise content is not a model upgrade. These are the industry's biggest vendors collectively admitting — through their product strategy rather than their marketing copy — that pilots stall on plumbing, and that someone has to be paid to lay the plumbing. SAP's framing makes the same point from the other direction: a roadmap of more than 200 agents across five domains is only valuable if those agents can be governed as a fleet, which is a platform-and-process problem long before it is a model problem.

Why forward-deployed engineering is having a moment

The single most interesting word in the May announcements is "forward-deployed". A forward-deployed engineer (FDE) does not build a product in a vendor's office and ship it. The FDE sits inside the customer's environment, learns the customer's systems, and builds the integration there, in context. The ServiceNow and Accenture programme is explicitly this: ServiceNow's AI-native engineers and Accenture's forward-deployed engineers working together inside customer environments to build agentic workflows natively on the ServiceNow AI Platform.

The reason the model is spreading is straightforward once you accept that integration is the bottleneck. Integration cannot be done remotely from a product backlog, because the hard knowledge — which legacy system holds the authoritative customer record, which approval chain a workflow must respect, which data cannot leave a particular jurisdiction — lives inside the customer organisation and nowhere else. You have to put a capable engineer where that knowledge is.

For Indian readers, this should sound deeply familiar. The forward-deployed model is, in its essentials, the model India's IT-services sector has run for three decades: skilled engineers embedded with a client, delivering inside the client's environment and to the client's constraints. The agentic-AI version raises the skill bar — it is closer to consulting-grade systems work than to staff augmentation — but the operating shape is one Indian services firms understand structurally. That is a genuine advantage, and it is worth naming plainly rather than treating this as an entirely new game. For UK enterprise adopters — banks, insurers, retailers, public-sector bodies — the same model is what makes agentic AI tractable at all, because it is the only way the vendor's agent expertise and the customer's institutional knowledge end up in the same room.

The governance problem gets harder with every agent added

SAP's announced roadmap — more than 200 agents and over 50 assistants across five domains — is the clearest illustration of a problem the whole category now faces. A single agent automating a single workflow is a contained risk. A fleet of 200 agents acting across procurement, finance, supply chain and customer operations is a different kind of system. Agents call other agents. One agent's output becomes another's input. A small error or a subtle policy gap does not stay local; it propagates.

This is why Cognizant Secure AI Services and IBM's Content Cortex are not side dishes. Securing and governing agentic systems, and getting enterprise content into a governed, machine-usable state, are the load-bearing problems once you move past a handful of agents. The questions a UK financial regulator or an Indian enterprise risk committee will ask are not about benchmark scores. They are: which agent took this action, on whose authority, against what version of the policy, and where is the log. An organisation that cannot answer those questions cannot scale agents, however good the underlying models are.

The practical implication for enterprises is that a single governance and evaluation layer matters more than any individual platform choice. Agents are launching inside the systems enterprises already run — ServiceNow for IT service management, SAP for ERP, Google for cloud and data. Most large organisations will therefore end up with agents on more than one platform. What they cannot afford is a separate, incompatible way of observing and auditing each one. We went through the mechanics of building reliable, well-scoped agents in our guide on how to build a production AI agent, and the framework question — which orchestration layer ties multi-agent systems together — in our comparison of LangGraph, CrewAI, PydanticAI and Microsoft's agent stack.

Where the builder jobs and skills actually sit

This is the question that matters most to AI Tech Connect's audience. An enterprise-agent gold rush is, for builders, only as valuable as the roles it creates. Read the May announcements as a hiring signal and four distinct skill areas come into focus. None of them is "train a frontier model" — that work belongs to a handful of labs. The demand is in the layer the announcements are actually about.

Forward-deployed engineering. As above, this is the embedded-engineer role: discovery, integration and governed delivery inside customer environments. It rewards builders who can combine technical depth with the consulting instincts to navigate an unfamiliar organisation. For India's services sector this maps onto an existing operating model; the work is to raise the individual skill bar from staff augmentation to genuine systems engineering. For UK builders it is increasingly the entry point into the highest-value enterprise AI work.

Agent integration. Connecting agents to systems of record — ERP, CRM, ITSM, data warehouses — and handling authentication, permissions, and the messy reality of legacy interfaces. This is unglamorous and in heavy demand precisely because it is the bottleneck. A builder who can reliably wire an agent into an SAP or ServiceNow back end, respecting the customer's permission model, is solving the problem that stalls pilots.

Evaluation and governance. Building the test harnesses, monitoring and audit trails that let an autonomous process be trusted and signed off. As agent fleets grow, this becomes a specialism in its own right — part engineering, part risk discipline. It is also the most regulation-exposed role, and therefore one of the most durable. UK builders working under FCA-regulated employers, and Indian builders in RBI-supervised lenders or in firms selling into the EU, are well placed to develop exactly this expertise.

Platform specialisation. Deep fluency in one major ecosystem — ServiceNow, SAP or the Google Cloud agent stack. Vague familiarity with "AI agents" is now common; certified, demonstrable depth in the platform a target employer has standardised on is not. Specialisation is a credible way for an individual builder to stand out, because every one of these vendors needs a partner ecosystem far larger than its own headcount.

The honest summary for a builder planning the next two years: the enterprise-agent market is hiring for the integration-and-governance layer, not the model layer. That is good news, because it is a layer where shipped, demonstrable experience counts for more than a research pedigree. The fastest model news of the moment — covered in our look at Gemini 3.5 Flash, Spark and Google's agent push — sets the ceiling on what is possible. The jobs are in closing the gap between that ceiling and a workflow a regulated enterprise will actually run.

What to do about it

For enterprise leaders in India and the UK, the takeaway from May 2026 is not "buy an agent platform". It is to be honest about why your own pilots have stalled. If the answer is integration and governance — and it usually is — then the budget, the hiring and the partner conversations should be aimed squarely at that layer, not at chasing the next model release. A forward-deployed engagement, whether with a vendor programme or with a strong services partner, is a reasonable way to cross the gap, provided you treat the embedded engineers as a route to building internal capability rather than a permanent dependency.

For builders, the move is to specialise deliberately. Pick one of the four areas above, get demonstrable depth, and make the evidence visible. The enterprises now standing up agent programmes are not short of model access. They are short of people who can integrate, govern and operate agents inside a real organisation with real constraints. That shortage is the opportunity, and it is one that plays to the strengths of the Indian and UK builder communities alike.

Primary sources are worth reading directly: the ServiceNow newsroom, the IBM newsroom, the SAP news centre, and the Google Cloud blog all carry the official write-ups of the announcements summarised here.