Unifying Your Production Operations Stack with CloudThinker

On Tuesday the cost tool's assistant rightsizes a node group and saves a few hundred dollars a month. On Wednesday a deploy goes out and p99 latency on checkout doubles. The incident tool's assistant opens a ticket. The on-call engineer's first question is "did anyone change capacity?", and nothing in the incident tool can answer it, because the rightsizing lives in a different product with a different login. Two hours later the rightsizing is reverted "to be safe", the latency doesn't move, and the real cause turns up in the deploy diff.

Coding agents such as Claude Code, OpenAI Codex, Cursor and Kiro have compressed software delivery from days to hours. Production operations hasn't kept pace. The work that follows the merge (cost management, security testing, incident response, code review and operational automation) is still spread across one tool per discipline, each with its own credentials, its own data, and its own AI assistant that can't see the others.

A typical 2026 stack has a cost dashboard, a security scanner plus a periodic penetration test, an incident management platform, a workflow builder for automation glue, a code review bot, and often an internal agent framework. Each tool is reasonable on its own. The integration between them is done by engineers, usually the most senior ones, usually during incidents, when fragmented context costs the most.

This post makes two arguments:

Automate the operations. The recurring work a production stack demands (cost review, security testing, incident investigation, merge-request gating, scheduled automation) can now be run by AI agents under human-defined policy.
Unify the agents. Those agents deliver the most value on one platform with shared connections, memory, policy and audit, not as separate assistants attached to each existing tool.

Where the platform sits

Coding agents own the work up to the merge. An operations platform owns what follows: review, deploy gating and production. CloudThinker is built around that boundary.

01Up to the merge

Coding agents

Claude Code, Codex, Cursor, KiroWrite the change on invocation
Pull or merge requestThe handoff point

Developer tools

02After the merge

CloudThinker

Review and deploy gatingAgainst incident and cost history
Incidents, cost, securityAgents as roles, not products
Scheduled automationGoverned operation tasks
Shared foundationConnections, memory, policy, audit

One runtime

03Production

Your stack

Cloud accountsAWS, Azure, Google Cloud
ClustersScoped, short-lived access
Observability and on-callStays where it is

Connected once

Coding agents own the work up to the merge. The operations platform owns what follows.

The disciplines in the middle column aren't separate products. They're specialized agents running on a shared foundation, and that distinction (shared runtime versus bundled products) is what the rest of this post is about.

Automate the operations, not only the code

Most recurring operational work follows one loop: observe system state, form a hypothesis, take a governed action, verify the result. Cost reviews, security tests, incident investigations and review gates all fit it. Until recently only the observation step was automated. Tools surfaced information, and people did the rest.

Coding agents don't close this gap, for structural rather than capability reasons. A coding agent is a development tool. It works in a workspace, on invocation, with a developer supervising. It doesn't run continuously against telemetry, hold least-privilege production credentials, enforce approval policy, or produce an audit trail fit for compliance review. Faster delivery also increases the operational load: more deployments to watch, more attack surface to test, more spend to govern, more changes to review. We look at that asymmetry in The future of SDLC: VibeOps with guardrails.

Operations agents close the full loop under policy. They detect idle capacity and open a rightsizing change for approval. They test each release and verify findings through safe, read-only exploitation before reporting. They investigate an alert and keep it open until telemetry confirms recovery. They review a change against the incident and cost history of the services it touches. The defining property isn't model capability. It's closing the loop under governance.

The business impact is direct:

Engineering capacity. Senior time spent coordinating across tools goes back to project work, without hiring.
Incident cost. Diagnosis typically takes 40 to 70% of incident time. An investigation that finishes in minutes rather than hours is the difference between a degraded window and an SLA breach.
Security assurance. Testing that runs per release, rather than once a year, surfaces findings while the responsible change is recent and the fix is a same-day merge request.

Why one agent per tool breaks down

There are two ways to bring agents into an operations stack: attach one to each existing tool, or run them on a shared foundation. Per-tool is the current market default, and it reproduces four known failure modes.

01Context

Partitioned

The incident agent can't see the cost tool's rightsizing from yesterday.

02Credentials

Sprawled

Every tool with production access holds its own broad, long-lived key.

03Automation

Ungoverned

Restart jobs and ticket flows pile up with no policy, audit or owner.

04Spend

Duplicated

Each vendor bills for an assistant confined to its own data.

An agent bolted onto each tool inherits each tool's boundaries.

Context partitioning. The incident agent can't see the cost tool's recent rightsizing; the security scanner can't see the review bot's approval. Cross-tool correlation falls back to people. The alternative, agents that share one memory of the system, is what we call AgenticOps.
Credential sprawl. Every tool with production access is a standing credential, usually broad, long-lived and rarely reviewed. That's a non-human identity risk before any AI is involved. Attaching an LLM to each tool's privileged access widens it.
Ungoverned automation. Ticket-filing flows, report summarizers and restart jobs pile up into an undocumented operations layer with no policy engine, no audit trail, and no owner once the author leaves.
Duplicated spend. Each vendor prices its AI assistant separately, and each assistant is confined to that vendor's data. Several isolated copilots don't add up to one operator that can carry a task from alert to verified resolution.

These map to measurable costs: outage minutes, breach exposure and audit effort, key-person risk, and AI spend that never compounds.

A unified platform is defined by what's shared:

One connection layer. Cloud, clusters, observability, source control and on-call systems are integrated once through governed connections with brokered credentials. Agents get scoped, short-lived access per task.
One memory. Investigations, cost decisions, security findings and review history persist in a shared store every agent can read.
One policy and autonomy layer. Graduated autonomy, enforced through policy as code. CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval.
One audit trail. Every agent action is recorded in a tamper-evident log suitable for compliance review and post-incident reconstruction.
Specialized agents on top. Cost, security, incident, review and custom agents run as roles on this foundation rather than as separately integrated products.

CloudThinker implements this architecture. Review, deploy gating, incident resolution, cost management and scheduled automation all run on the same connections, memory, policy engine and audit log. Adding a discipline means enabling an agent, not integrating another system.

What shared context changes in one incident

Go back to the opening. Tuesday: the cost agent rightsizes the general node group in the production cluster from m5.2xlarge to m5.xlarge and records why (average CPU allocation under 30% for 21 days). Wednesday: a checkout deploy goes out and p99 latency doubles. The details are illustrative, but the shape is common.

The incident agent starts with three readings, each with a different prediction:

Hypothesis	What it predicts	How it's checked
Capacity change	Nodes near CPU or memory limits, pods throttled or pending	Node allocation and the rightsizing record
The deploy	Latency rises exactly at rollout, on checkout only	Rollout history and the reviewed diff
A dependency	Latency in downstream calls, other callers affected too	Traces and the dependency's own metrics

Capacity. Because the rightsizing is in shared memory, the agent knows to look and what changed. It checks the node group and the nodes:

aws eks describe-nodegroup --cluster-name prod --nodegroup-name general \
  --query 'nodegroup.{types: instanceTypes, scaling: scalingConfig}'

kubectl top nodes -l eks.amazonaws.com/nodegroup=general
kubectl describe nodes -l eks.amazonaws.com/nodegroup=general | grep -A 8 "Allocated resources"

CPU requests sit around 60% allocated, nothing is pending, and nothing is throttled. Capacity is eliminated in seconds, and the rightsizing stays.

The deploy. kubectl rollout history deployment/checkout -n checkout shows the rollout at the minute latency rose. The review verdict for that merge request, also in shared memory, had already flagged a new synchronous call to the pricing service on the checkout path.

The finding. Latency comes from the new synchronous call. The proposal is a rollback with the fix linked back to the review comment, waiting for approval. Validation confirms recovery, and the next security assessment starts from the service's current topology instead of rediscovering it.

On a fragmented stack the same sequence takes hours of cross-dashboard correlation, often ends with the rightsizing reverted as a precaution, and leaves the next security assessment to map the topology again from scratch. The difference shows up in engineer hours, cloud spend and customer-facing minutes. We look at the effect in The compounding value of connected operations.

The security model is the precondition

Consolidation concentrates capability, so the security architecture decides whether the approach works in production. The requirements:

Brokered, short-lived credentials. Agents never hold raw keys. Access is scoped per task, centrally revocable and reviewed in one place.
Policy as code, evaluated before action. Permitted actions, environments and approval requirements are declared and versioned.
Autonomy you control. The team decides what runs on its own and what waits for a person. See human-in-the-loop vs human-on-the-loop.
Tamper-evident audit. Every action is recorded in a form that satisfies SOC 2 and equivalent regimes.
Bounded blast radius. Execution runs in CloudThinker's Sandbox, so an agent error is a contained event, not an outage. See What is agent blast radius?

Under this model, consolidation shrinks the attack surface compared with sprawl. One governed runtime with brokered credentials presents less standing exposure than several tools holding long-lived production access under separate guardrail designs.

Why this beats the per-tool approach

	One AI assistant per tool	One platform, shared foundation
Cross-domain questions	Answered by a person across tabs	Answered from shared memory
Production credentials	One standing key per tool	Brokered per task, revocable in one place
Approval policy	Different per vendor, if any	One gate: Auto Mode, with a full audit trail
Audit	Separate logs, separate formats	One tamper-evident trail
Adding a discipline	Buy, integrate, credential another tool	Enable an agent
AI spend	Billed per vendor, never compounds	One operator, context accumulates

The deeper difference is where the join happens. With one assistant per tool, every cross-domain question still lands on a senior engineer, who becomes the integration layer during the worst hour of the week. With a shared foundation, the join is the platform's job, and the engineer's job is the decision.

Customer results

Two published case studies show the approach in production. As with any deployment data, outcomes depend on the environment and the starting operational maturity.

F88, one of Vietnam's largest consumer-finance companies (millions of customers, more than 800 branches, and a hybrid AWS and on-premises estate), began with a limited read-only pilot and expanded scope as accuracy was demonstrated. Current results: 80% of daily manual operations automated, a 30% reduction in AWS spend through continuous optimization, 24/7 agent monitoring across critical lending applications, and incident root-cause analysis reduced from days to minutes.

Diaflow, a global AI SaaS platform, adopted the platform under compliance and growth requirements: SOC 2 and HIPAA mandates, cost control at global scale, and a 99.9% uptime target. Results: three-region infrastructure deployed in four weeks, SOC 2, HIPAA and GDPR compliance readiness in three weeks, an 80% reduction in operational task load, and 99.9% uptime sustained and verified.

Both followed the same path: automate the existing operational workload first, run the agents on one platform, and widen autonomy as measured accuracy justifies it.

A staged adoption path

Replacing an operations stack in one program isn't advisable. The sequence that works in practice:

01Start

One domain

Incidents, cost or security, read-only, measured before any write access.

02Extend

Adjacent domain

The first cross-domain answer proves shared context is paying off.

03Migrate

Automation glue

Move scheduled jobs into governed tasks and retire their standing keys.

04Customize

Your own agents

Organization-specific work on the same memory, policy and audit.

Each step is justified on its own. Together they replace the fragmented stack.

Start in the domain with the clearest need: incidents, cost or security. Connect the first agent read-only and measure its accuracy before granting any write access.
Add the adjacent domain. The first cross-domain result (an incident investigation citing a cost change, or review context shortening a diagnosis) is concrete evidence that shared context is paying off.
Migrate the automation glue. Move production-touching flows and scheduled jobs into governed operation tasks, retiring their standing credentials. The /automate catalog covers common patterns.
Extend with custom agents for organization-specific work (compliance evidence collection, migration runbooks, capacity reviews) using custom agents and skills, which inherit the platform's memory, policy and audit.

Getting started

Pick the domain from step 1 and ask in plain language:

"Look at the last 30 days of production incidents. For each one, list any cost, capacity or config change in the same window, and say whether it was related. Propose only, change nothing."

"Inventory every tool and integration that holds standing production credentials, with scope and last rotation date."

"Which scheduled jobs and workflow-builder flows touch production? Who owns each one, and what credential does it use?"

The second prompt usually makes the case for consolidation by itself.

FAQ

Is a single platform a single point of failure? Weigh concentration risk against the alternative: several tools with standing production access and separate guardrail designs. A consolidated runtime with brokered credentials, policy as code, per-environment autonomy and tamper-evident audit is a smaller, better-instrumented failure domain.

Does adoption mean replacing existing tools straight away? No. Observability, on-call and source control stay in place; the platform connects to them. Adoption starts with one domain, read-only, and expands as accuracy is demonstrated.

Can this be built with a workflow builder and an LLM? For non-production automation, a workflow builder is a reasonable choice. It doesn't provide cross-domain memory, brokered credentials, policy enforcement, autonomy controls or audit. Building those is a multi-year platform-engineering effort, analysed in Build vs Buy: The 24-Month TCO of an Agentic Operations Platform.

Are coding agents enough? Coding agents and an operations platform are complementary. Development agents don't monitor telemetry, hold governed production access or work under operational policy, and the faster they make delivery, the bigger the operational load they create.

Where does CloudThinker run? SaaS by default, with sovereign deployment options for BFSI, government and data-residency-constrained environments. See SaaS vs Sovereign AI SRE.