From Single Agents to a Shared Platform

The first agent pilot works. The on-call team sees investigations finish in minutes, the postmortems match, and the risk committee signs off on the controls. Within a quarter, three more teams want their own agent.

This is the moment most organizations get wrong. Getting an agent through a pilot is hard. Once it's through, the next risk is the speed of the rollout itself.

This post is part of the series on Agentic IT Operational Excellence. The earlier parts covered where incident time goes, why investigation is slow, and the controls an agent needs before it touches production. This one is about what happens when the second, third and tenth team arrive.

Agents multiply faster than anyone governs them

The surveys show the curve. Gravitee's 2026 research found the number of agents inside enterprises doubled in just four months, while 48% of the agents running in production weren't monitored or protected (vendor-run survey). KPMG found that the complexity of coordinating many agents had become the main bottleneck when moving from pilot to production.

The cause is usually the same. Each team builds its own agent. It writes its own connections, defines its own permissions and stores its own knowledge. Every new team adds the same cost and the same risk again, so both grow in a straight line with the number of teams.

01Connections

Written once per team

Every team wires its own access to cloud, code, observability and ITSM.

02Permissions

Defined once per team

Security reviews the same kind of access again for every new agent.

03Knowledge

Stored once per team

Lessons from one team never reach the agent of the team next door.

04Visibility

Stops at the team boundary

An incident that crosses teams crosses agents, and the handoff comes back.

Agent sprawl. Cost and risk grow with every team, and the old silos come back in software.

The cost is the visible part. The bigger problem is that sprawl rebuilds the silos that made investigation slow in the first place.

Sprawl rebuilds the silos in software

In why incident investigation is slow I described how organizations split teams by service or by technical layer, each with its own tools, dashboards and knowledge. That structure works for building software. It breaks during incidents, because incidents rarely respect team boundaries.

Take the 2:14 a.m. payments incident again. Its evidence sat across three teams: the application team's deploy, the database team's pool metrics and the payments team's alert.

Now give each of those teams its own agent. The payments agent sees latency. The database agent sees pool exhaustion. The application agent sees a deploy that passed its checks. Each agent observes its own part of the system well, and none of them can follow the incident across the boundary. The handoff you wanted to remove is back, only now it's between agents instead of between people.

Adding more agents per team rarely improves MTTI at the organization level, for the same reason adding more people or tools per team rarely did.

Standardize once, at the platform layer

The more durable approach is to standardize the reusable parts once, at the platform layer, and let every team inherit them.

01Connections

Cloud to ITSM

Cloud, on-premise systems, observability, source code and ITSM tools.

02Policy templates

Approved by security

What agents may read, propose and run, agreed once and reused.

03Runbooks

Verified

Procedures that have been checked against real incidents.

04Company knowledge

Root causes and lessons

What the organization learned, available to every investigation.

05Detectors

With evaluation data

Detectors plus the datasets that show how accurate they are.

What a platform team standardizes once, so every team inherits it.

These are the pieces that cost the most to get right and the least to reuse:

Connections to cloud, on-premise systems, observability, source code and ITSM tools. In CloudThinker these are Connections, set up once and shared by every agent.
Policy templates that security has already approved, so a new team starts from an agreed boundary instead of a blank one. Changes go through Auto Mode, so you decide once what runs on its own and what waits for approval.
Verified runbooks that have been checked against real incidents.
Company knowledge of root causes and lessons, so an investigation in one team can use what another team already learned. See incident memory that can be wrong for why that knowledge has to stay correctable.
Detectors and evaluation datasets, so accuracy is measured the same way everywhere.

On the CloudThinker Platform this is the unified layer every agent shares: the same connections, the same memory, the same policy, one audit trail for every action, and a Model Gateway so you choose the model. The Frontier Investigation Agents (Review, Cyber, Resolve, Optimize and Customize) all sit on top of it. When a team needs an agent for the way it works, it builds one with Customize on the same layer, without starting from scratch.

Isolate per team, share knowledge under control

Standardizing doesn't mean pooling everything. The balance that matters is between isolation and sharing.

Each team keeps its own workspace, its own permissions and its own approval flow. A team running payments shouldn't be able to approve changes to the data platform, and an agent working for one team shouldn't carry another team's credentials.

What gets shared, under control, is knowledge: root causes, lessons and the dependency map between components. That's what lets an agent trace an incident across teams without waiting for a manual handoff.

01Teams

Isolated

Own workspaceOne per team
Own permissionsScoped to what the team runs
Own approvalsThe team decides what changes

Each team keeps control

02Agents

Across the chain

InvestigateAlong the whole dependency chain
RememberEvery cause and every fix
PreventFlag changes that match past incidents

No manual handoff between teams

03Shared platform

Standardized once

ConnectionsBuilt once, inherited by every team
Knowledge and dependency mapShared under control
Policy templates and auditApproved once, recorded always

Owned by the platform team

04Existing systems

Unchanged

Any cloudAnd on-premise
ObservabilityMonitoring, logs, traces
Code and ITSMRepositories, CI/CD, tickets

Your stack stays as it is

Isolated per team, knowledge shared under control. Agents follow an incident across teams without waiting for a handoff.

Replay the 2:14 a.m. incident on this model. The worker-count change would have been flagged at review, because it matched a postmortem from six weeks earlier that any team's agent could read. If it shipped anyway, the agent investigating the payments alert could follow the dependency map to the database pool and back to the deploy, inside one investigation. The payments team approves the fix in its own workspace. Nobody had to find out who owns the pool at three in the morning.

The first team pays, every team after inherits

With this approach, the first team carries most of the setup cost. It connects the systems, agrees the policy templates with security and builds the first body of knowledge.

From the second team on, the marginal cost falls. Rollout gets shorter, because the connections and policies already exist. Safety goes up, because the new team inherits a set of controls that have already been proven.

Per-team agents work the other way. Every new team repeats the setup, the security review starts again, and the knowledge stays in one place. That's why I think investing in a shared platform pays off for longer than investing in single agents.

Who owns what

Scaling also needs clear ownership. Without it, the shared layer becomes everybody's dependency and nobody's job. The model I've seen work best splits it four ways.

Role	Owns
CIO	Sponsors the programme, owns the metrics and decides where the recovered time goes
Platform team	The shared layer: connections, identity, policy templates and audit
Head of engineering	Each team's policy and the order in which teams roll out
Each team	Its workspace, its approval flow and its knowledge

Two parts of this table get skipped most often.

The first is the platform team. If nobody owns connections, identity, policy templates and audit, each team will build its own, and you're back to sprawl. Name this owner before the second team starts, not after the fifth.

The second is the CIO's decision about recovered time. Time an agent gives back gets absorbed by default. If nobody decides that it goes to prevention items, platform work or the roadmap, it disappears into the next queue. The economics of operational excellence covers how to measure it.

How junior engineers still learn

A question rarely asked, and an important one: how do junior engineers grow when agents do most of the investigation?

On-call has always been where engineers learned how a system really behaves. You got paged, you got lost, a senior engineer talked you through it, and next time you knew where to look. Take the investigation away and that path looks like it disappears.

The answer is in the investigation records themselves. Every investigation leaves a structured record: the symptom, the evidence, the hypotheses that were ruled out, the cause, the fix and who approved it. You can see what one looks like in inside an investigation. Each record is a real case from your own systems.

That makes them good teaching material. A junior engineer can work a past incident from the symptom forward, form their own hypotheses, then compare their reasoning with the record. A lead can use the same records to assess whether someone is ready for on-call, and to mentor against concrete cases instead of war stories. In my view that works better than the traditional model of learning through on-call, where what you learn depends on which incidents happen to land on your shift.

The engineer's job also shifts. On-call starts from a finished investigation and moves from searching to judging. Judging a verdict well (is the evidence enough, does the fix match the cause) is a skill juniors need to learn early, and the records give them hundreds of chances to practise it.

Where to start

If you're past your first pilot, three moves keep the next ten teams from becoming ten separate projects:

Assign an owner for the shared platform. Give the platform team responsibility for connections, identity, policy templates and audit before a second team builds its own.
Decide what's isolated and what's shared. Workspaces, permissions and approvals stay per team. Root causes, lessons and the dependency map are shared under control.
Pick the rollout order on purpose. Start the second team where incidents most often cross a boundary with the first, so the shared knowledge pays off early.

Sources

Gravitee, The State of AI Agent Security 2026, updated April 2026, survey of 750 technology leaders (vendor-run survey).
KPMG, 2026 enterprise survey, cited in "Runtime Governance for AI Agents", arXiv 2603.16586.