Cognizant said Monday it is putting more than 18,000 staff behind Google's Gemini, forming a Gemini Frontier Capability Group with Google Cloud. The group starts in four areas: modernizing legacy software, developer tooling, business process automation, and cyber defence. Cognizant cites an unnamed retailer that got 40% developer productivity gains and 35% cost cuts. Those figures have not been independently checked, which is worth stating plainly when a vendor is the only source.
Eighteen thousand people is a large number. It is roughly the population of a mid-size town being pointed at agent construction. Whether it is a bet or a hedge I cannot tell from outside. What I can tell you is the question those clients will ask six months in, and it will not be about token throughput. It will be about what happened to the on-call rotation.
The reliability paradox
Bain surveyed 293 tech and engineering leaders in April 2026. Executives expect around a 150% improvement in engineering speed and throughput over the next year or two. Of every metric the survey measured, expected gains in operational resilience ranked last.
That gap is the story. AI compresses the cost of building software and can inflate the cost of running it. Ten times more change flows into an operating model that was built for humans writing code at human speed. You get a faster enterprise that stumbles more often.
The survey shows where attention is going. Almost two-thirds of executives ranked applying AI to coding, testing, and reviewing as the most important lever for productivity. Observability and incident automation came near the bottom, cited by roughly one in five. That is a predictable result when the coding demo is visible in a sprint and the incident tooling shows up as a pager alert at 3am.
Netflix is the useful counterexample. Its data platform team wired a rule-based error classifier to a machine learning model that predicts whether a failed big data job will succeed on retry, picks the correct configuration, and applies it automatically. Netflix reports the system resolves about 56% of memory configuration errors with no human intervention and cuts associated costs by roughly 50%. That is one class of failure absorbed by the run organization. Not a demo, not a pilot, just a category of pager noise that stopped existing.
Only about 2% of organizations in the Bain survey call their engineering function autonomous-first. Most are piloting or integrating early workflows. Anyone claiming otherwise is selling something.
Small agents, existing systems of record
Pete Johnson's CIO piece describes the pattern I keep seeing in teams that actually ship. Five agents, each with a one-sentence job: Jira ticket to GitHub issue, GitHub issues to point poker to sprint organization, coding, pull request merging, system testing.
The agents are independent. Not one brain with five subroutines. Five separate agents touching adjacent records, each narrow enough that a mistake is contained. An agent scoped to sprint organization cannot ship bad code. It can misfile a story and you find out at standup. That is the blast radius argument, and it maps cleanly onto change failure rate: you address failure at the stage where the change happens instead of measuring it at the end of a pipeline where you can no longer identify the broken step.
The part most agent discourse gets wrong is where the interface lives. The instinct is to build a console, a new pane of glass where you watch the agents work. The better move is to put the agent behind the pane your people already watch. Jira is already that pane. Human-in-the-loop supervision fails less often because people refuse to supervise and more often because the supervision got moved somewhere they do not live.
One retailer running this pattern cut idea-to-production time by a factor of five over nine months. Note the metric boundary: it starts when a business stakeholder files the request, not at commit. DORA's change lead time starts the clock at commit, which misses the ticket refinement, estimation, and sequencing work where these agents do most of their damage. The wider boundary is the honest one for agentic work.
What I would do with 18,000 engineers
Do not buy a platform and point it at a three-tier manual triage ladder. That produces a faster version of a process that no longer fits. The Bain brief is blunt about this and it is right.
Build the boring prerequisites first. Unified observability across metrics, logs, and traces. A service knowledge graph covering topology, ownership, dependencies, change history, and past incidents. Machine-readable runbooks. Enough environment standardization that a fix applied in one system stays safe in the rest. Without those four things, your agent is an alert summarizer with a confident tone.
Treat risk as the design constraint rather than an afterthought. Letting an agent restart a service or roll back a release in production is a different risk class from letting one draft code behind a reviewer. Google's SRE tooling handles this by making agents fetch an approved runbook through a function call instead of issuing freeform commands. Policy as code, confidence thresholds that gate action, full auditability of every tool call and decision.
Then change what you measure. MTTR can improve while the system quietly accumulates fragility, because a system that resolves incidents faster is not the same as a system with fewer incidents. Track autonomous resolution rate, cost, and business outcomes alongside velocity. Measure the human-plus-agent team as one unit rather than trying to attribute each action to one side.
The compounding piece is the one I would bet on. Every incident an agent resolves and documents becomes context for the next fix. A human triage team cannot do that; its knowledge leaves with attrition. Close the loop and the run organization stops scaling with complexity.
Cognizant has made a large bet that agent construction is a services business. Fair enough. The pager will tell them whether it worked.