Agents on a Unified Layer: How Operations Starts to Remember

Remember the 2:14 a.m. payments incident from part one: three engineers, four tools and 86 minutes of investigation, for a failure the company had already written a postmortem about, with an early warning nobody trusted.

Every piece of information needed to stop that night already existed. It sat in a postmortem, in a deploy log and in an alert nobody trusted. Nothing connected them. This part of the Agentic IT Operational Excellence series is about what does: agents that do the investigation work, and the shared layer underneath them that lets them see the whole system at once.

What agents do in operations

The second edition of Google's Site Reliability Engineering describes AI as a productivity lever for SREs, with three main practices: help with incident triage and postmortem drafting, querying telemetry in natural language, and forecasting resource bottlenecks before they cause an incident.

I agree with that, on one condition: the decision stays with a person. And I'd add two capabilities that I think matter most over the long run. One is keeping knowledge in a structured form. The other is closing the prevention loop, so a lesson turns into a change instead of a line in a document.

Put together, the work looks like this.

01Triage

Every alert, on arrival

Related alerts are merged, so the real signal stops drowning in noise.

02Investigate

Evidence in parallel

Logs, metrics, traces, deploys and code, checked against what the company knows.

03Remember

A structured record

Symptom, evidence, cause, fix and approver, kept so it can be matched later.

04Prevent

Flag it at review

The same memory marks a change that looks like a past incident.

05Close the loop

Follow-up as a change

The postmortem is drafted and the prevention item becomes a change to review.

Triage. An agent assesses every alert as soon as it fires and merges the ones that belong together. That cuts noise, and noise is what buried the 1:00 alert.

Investigate. It gathers evidence in parallel across logs, metrics, traces, deploy history and source code, checks it against what the organization already knows, and returns a root cause with ranked hypotheses and a proposed fix. Nobody opens four dashboards in sequence. For how one of these runs step by step, see Inside an Investigation.

Remember. Every investigation leaves a structured record: symptom, evidence, cause, fix and who approved it. A postmortem stops being an archive document and becomes something you can match against.

Prevent. The same knowledge is applied at code review, so a change that looks like a past incident gets flagged before it ships.

Close the loop. The agent drafts the postmortem from the evidence it already collected, and turns the prevention item into a change an engineer can review. The prevention item no longer competes with the roadmap as a vague task. It arrives as a diff.

Agents need one context

There's a condition behind all five, and it's one human teams usually don't have: a single, unified context.

The default way to add AI to operations is to let each tool or each agent connect to each system on its own, or to keep asking engineers to open one dashboard after another. Either way, the context is assembled by hand, every time, and lost afterwards.

The alternative is to bring operational data from the tools you already run into one shared layer. We call it the unified layer. It links monitoring signals to code changes, deploy history, tickets and knowledge from past incidents, and it keeps a dependency map between components. Agents work on top of that layer, so one investigation can follow an incident across several systems and several teams in a single pass.

That's the shape of the CloudThinker Platform.

01Engineers

Stay where they work

• SlackIncidents and approvals in chat
• IDE and CLINext to the code
• WebWorkspaces, scorecards, history

Unchanged

02Agents

Do the work

• ReviewCode quality
• CyberSecurity
• ResolveUptime
• OptimizeCost
• CustomizeYour own scorecard

New

03Unified layer

Shared by every agent

• ConnectionsThe same access to cloud and code
• MemoryEvery fix makes the next one faster
• PolicyDecide once what agents may do
• AuditOne trail for every action
• ModelsModel Gateway, you choose the model

New

04Your stack

Stays as it is

• Any cloudAccounts, clusters, on-premise
• CodeRepositories, CI/CD
• ObservabilityMonitoring, logs, traces
• ToolsITSM, on-call, tickets

Unchanged

The unified layer carries five things, and every agent shares all of them:

• Connections. The same access to your cloud and code. A connection is the outer limit of what any agent can see or do. See Connections.
• Memory. Every fix makes the next one faster, because the next investigation starts from what the last one learned.
• Policy. You decide once what agents may do. Changes go through Auto Mode, so you choose what runs on its own and what waits for approval.
• Audit. One trail for every action, whichever agent took it. See A Receipt for Every Action.
• Models. The Model Gateway, so you choose the model.

Two things change, two stay

The architecture is easiest to read from the outside in.

Your engineers stay where they already work: Slack, the IDE, the CLI, the web. Nobody has to adopt a new place to live.

Your stack stays as it is: any cloud, your code, your observability, your tools. The unified layer connects to what you run. It doesn't replace it.

Two things are new. The agents, and the layer they share. You set intent and you approve. The agents do the investigation work.

That matters for a CIO deciding whether this is another migration. It isn't. Ten years of transformation built the bottom of that picture. This adds a layer on top of it.

Company memory

Here's what changes for the organization as a whole.

Agents deliver the root cause and the fix. Engineers make the decision, and their feedback makes the agents better. Every loop becomes company memory: every issue, every root cause, every fix, every decision.

Think about what that means against the three mechanisms from part two that keep knowledge fragmented. Knowledge lived in individual heads, so it left when they did. Postmortems were written to be filed, so nobody could search them mid-incident. Prevention items lost to the roadmap, so the same failure came back.

A structured record attacks all three. The knowledge isn't in one person, it's in the record. The record is built to be matched, not read. And the prevention item arrives as a change, ready to approve.

Your team will change. People take leave, move teams, work in other time zones, leave the company. The memory stays. Humans, agents and the company learn together, on every incident.

Memory has to be correctable, too. A lesson drawn from one incident can be wrong, and an engineer has to be able to fix or remove it. We wrote about how that works in Memory That Can Be Wrong.

Five agents, one goal

The work is split across five Frontier Investigation Agents. Each owns one of the problems that keep growing after transformation. Together they serve one goal: healthy production.

01Review

Checks every change

Code quality before production, matched against past incidents.

02Cyber

Attacks you first

Security weaknesses found and proven before someone else finds them.

03Resolve

Investigates every issue

Uptime. The root cause in minutes, with the evidence beside it.

04Optimize

Cuts cost, every day

Cloud spend reviewed continuously, not once a quarter.

05Customize

Build your own

Agents for the way your company works, with their own scorecard.

Review checks every change. Cyber attacks you first. Resolve investigates every issue. Optimize cuts cost every day. And Customize lets you build your own agents, for the way your company works.

They aren't five separate tools with five separate integrations. They sit on the same layer. When Resolve finds that a worker-count change drained a connection pool, Review knows it the next time someone changes a worker count. That's the practical meaning of "shared memory". For the thinking behind the agents themselves, see Frontier Investigation Agents.

The 2:14 incident, replayed

Now run the same night again with agents on a unified layer. The numbers below are illustrative, built from the composite incident in part one.

In the afternoon, at review. The change that doubles the worker count gets flagged at code review, because it matches the postmortem from six weeks earlier. Caught there, the incident never happens.

If it ships anyway, at 1:00. The connection pool alert fires. This time it isn't one of forty ignored alerts. It gets investigated and linked to the afternoon deploy.

At 2:14. The latency alert fires. The agent matches it to the known failure and proposes restoring the worker count. The on-call engineer checks the evidence, confirms and approves. The incident is fixed about nine minutes after the alert, with one engineer instead of three.

End to end, that's roughly 14 minutes instead of 99. Part one breaks the numbers down clock by clock. The short version: detection barely moves and the fix gets a little faster, but investigation drops from 86 minutes to 5. That's the clock we argued should be measured, and it's the one the unified layer moves.

The loop is the familiar one: detect, analyze, resolve, validate. What changes is that the analyze step no longer starts from a blank page.

What the evidence says so far

Benchmarks are useful for comparing approaches under controlled conditions. We've written up how we measure Resolve on SREGym, with the method and the numbers, in Your On-Call Has Not Met Astra Yet. A benchmark shows ceiling capability in a test setup, though. The stronger evidence comes from production.

• A technology company has agents investigating every daily incident, and its engineers review each conclusion before acting on it.
• A financial services company uses agents as the first line of response for every incident, from application to security, with the full set of controls applied from day one.
• An agriculture company cut penetration testing from several weeks to a few hours by running it with agents, which lets them test with every release.

The same pattern shows up in security operations. About 46% of alerts there turn out to be false positives (vendor-run survey), and analysts face the same overload SRE teams do. Different alerts, same structural problem: too much signal, assembled by hand, by people who are already tired.

None of this happens if the risk committee says no. An agent that can't be traced, scoped or stopped won't get production access, however accurate it is. That's the next part of the series.

Related reading

• After Ten Years of Transformation, the Next Chapter Is Operational Excellence
• Frontier Investigation Agents: The Hard Part Was Never the Fix
• Inside an Investigation
• Memory That Can Be Wrong
• CloudThinker Resolve

Sources

1. Google Cloud Blog, announcement of the second edition of Site Reliability Engineering, 2026. cloud.google.com
2. Microsoft and Omdia, State of the SOC 2026. (vendor-run survey)

The incident in this post is a composite. Company names are withheld under confidentiality agreements.