Does this replace our GitOps flow?

No. Agents open pull requests against the repositories Argo CD or your pipeline already deploys from. Nothing bypasses Git.

What access does it need?

Read-only access to the clusters and repositories you choose. Changes go through pull requests unless your policy grants more for a namespace.

Can agents change a cluster without a person?

Only where your policy allows it. Most teams start with diagnosis and pull requests, then let agents restart or scale workloads in low-risk namespaces.

How do version upgrades work?

Agents check deprecated APIs, add-on versions and node groups against the target version, then open the plan as a pull request. Your team runs it on a non-production cluster first.

AWS Partner

SOC 2 Reports

Frontier Resolutionfor Kubernetes Operations

Day-2 EKS work like upgrades, drift and capacity handled by agents.

Connect your EKS clusters and the repositories that define them. Agents take the day-2 work off your platform team: failing workloads, version upgrades, config drift and capacity. Each issue arrives with the cause and the manifest change that fixes it. Upgrades come planned, tested and ready to approve.

Book a Demo See how it works

Kubernetes eventroot cause found

payments/api-gateway in CrashLoopBackOff

Signals: 14 restarts in 20m, exit code 137, node pressure normal
Change: Helm release 4.2.0 added a JVM agent at 08:31
Root cause: Memory limit 512Mi. Heap plus agent peaks at 690Mi
Evidence: OOMKilled events, container metrics, chart diff
Fix: Raise limit to 768Mi in values.yaml. Pull request opened

Investigated in 1m 12s. Waiting for platform approval

[The work behind every cluster]

Clusters change every day.Day-2 work never makes the roadmap.

01The manual work

Operate

Platform engineers chase crashing pods, read deprecation notes before every upgrade and hunt drift between Git and what is running.

02The agent handoff

Change ready

Frontier agents find the cause, plan the upgrade or fix and open the manifest change for your team to review.

03Your engineers’ role

Approve

Set what agents may change and where. Review the pull request and decide what rolls out.

[Where CloudThinker fits]

Your stack stays.Agents work inside it.

01Clusters

Wherever you run Kubernetes

Amazon EKSClusters, node groups and add-ons
Azure Kubernetes ServiceClusters and node pools
Google Kubernetes EngineStandard and Autopilot clusters
Self-managed KubernetesOn-prem and edge clusters
Prometheus and GrafanaCluster and workload metrics

No agent to install per node

02Delivery

Your system of record

Argo CDDesired state and sync history
HelmCharts and release values
TerraformCluster and node group config
GitHub and GitLabManifests, pull requests, reviews

Git stays the source of truth

03Day-2 work

CloudThinker

Diagnose workloadsCrash loops, OOM kills, failing probes
Plan upgradesDeprecated APIs, add-ons, version skew
Right-sizeRequests, limits and node capacity
Fix through GitPull requests your team reviews

Changes land as pull requests

04Response

Merged, then verified

GitHubPull request with the evidence
SlackSummary in the platform channel
JiraUpgrade plan tracked per cluster
PagerDutyPaged only when it needs a person

Merge runs on approval

Logos show common stacks. CloudThinker connects to each cluster through scoped, read-only access you approve.

[Example scenario]

Monday, 08:40. A payments pod keeps crashing.The upgrade window is Thursday.

A 5-person platform team running 4 EKS clusters for 30 product teams, with Helm, Argo CD and Prometheus. EKS 1.29 leaves standard support this quarter.

08:40
Pod in CrashLoopBackOffSignal
Prometheus alert: payments/api-gateway restarted 14 times in 20 minutes on prod-eks-2.
08:41
Cause tracedAgent
OOMKilled with exit code 137. Helm release 4.2.0 added a JVM agent at 08:31. Heap plus agent peaks at 690Mi against a 512Mi limit.
08:42
Pull request openedAgent
Raises the memory limit to 768Mi in values.yaml for payments only. Linked: OOM events, container metrics, chart diff.
08:55
Platform engineer mergesYour team
Reviews the diff, merges. Argo CD syncs and the pods stay healthy.
09:30
Upgrade plan draftedAgent
Checks all 4 clusters for APIs removed in 1.30, finds 2 charts to update, and drafts the upgrade order with add-on versions.
09:45
Team lead approves the planYour team
Approves upgrading staging on Wednesday and production on Thursday, one cluster at a time.

#platform-ops4 messages

Alertmanager08:40
KubePodCrashLooping: payments/api-gateway on prod-eks-2 (14 restarts).
CloudThinker08:42
OOMKilled after Helm 4.2.0 added a JVM agent. Peak 690Mi, limit 512Mi. Opened PR #418 raising the limit to 768Mi for payments only.
Platform engineer08:55
Merged. Can you check the 1.30 upgrade while you are at it?
CloudThinker09:30
Upgrade plan ready: 2 charts use removed APIs, 3 add-ons need new versions. Staging first, then prod one cluster at a time.

from crash loop to pull request: 2 min
clusters checked for the upgrade: 4
of upgrade prep turned into a review: 1 day

An illustrative example. Team, systems and times are representative, not a specific customer.

[Frontier resolution agents]

Agents handle the day-2 work.Your platform team builds the platform.

Agents work every cluster on the same policy, so a failing workload arrives already diagnosed, and an upgrade arrives as a tested plan, not a research project.

Fix failing workloads: Crash loops, OOM kills, failed probes and pending pods traced to the change or limit behind them.
Plan the upgrade: Deprecated APIs, add-on versions and node group changes checked before every EKS version upgrade.
Catch the drift: What is running compared with what is in Git, with a change to bring them back in line.
Right-size capacity: Requests, limits and node pools tuned to real usage, with each change sized and reversible.

[What changes]

Same team. Same tools.Far less of the work by hand.

Moment	Today	With frontier agents
A failing pod	kubectl, logs and guesswork	Cause and fix ready in minutes
Version upgrades	Weeks of reading release notes	A tested plan with every blocker listed
Config drift	Found during the next outage	Flagged with a change to fix it
Requests and limits	Set once, never revisited	Tuned to real usage over time
Platform team time	Spent on tickets and toil	Spent on the platform roadmap

[Integrations]

Connects to the rest of your stack.Read-only to start.

Amazon EKS
Kubernetes
Helm
Argo CD
Terraform
Amazon CloudWatch
Prometheus
Grafana
Datadog
Kubecost
OpenCost
GitHub
GitLab
PagerDuty
Slack

[Adoption path]

One pilot.Then company-wide.

The rollout follows the four phases of the AWS Cloud Adoption Framework, so it fits the plan your cloud team already runs.

01Envision
Pick one non-production cluster
Connect one cluster read-only and let agents diagnose issues in shadow mode. Compare their findings with your team’s.
02Align
Agree the change policy
Decide which namespaces agents may touch, which changes go through pull requests, and who approves.
03Launch
Roll out cluster by cluster
Add production clusters on the same policies, GitOps flow and audit trail.
04Scale
Make it the default
New clusters launch with agents attached. Upgrades and drift checks run on a schedule, not on a crisis.

[Customer proof]

NextPay.Results on the record.

NextPay upgraded its production EKS with zero downtime, cut RDS replica costs in half and added 24/7 proactive AI monitoring.

Read the case study

production EKS clusters upgraded with zero downtime: 3
cost reduction on RDS replicas: 50%

[AWS guidance]

Built the way AWS says to run it.Reviews start from a known reference.

[Trust and control]

Agents do the work.Your team keeps control.

You approve every change: Agents propose. Nothing touches production until someone on your team says yes, and you set that rule per system.
Every action on the record: Each step is logged, attributed and reversible, ready for your auditors.
Certified for enterprise: SOC 2 Type II and ISO 42001, with reports in our trust center.
Runs where you need it: In our cloud, through AWS Marketplace, or inside your own account.

[Questions]

What teams askbefore they start.

Does this replace our GitOps flow?: No. Agents open pull requests against the repositories Argo CD or your pipeline already deploys from. Nothing bypasses Git.
What access does it need?: Read-only access to the clusters and repositories you choose. Changes go through pull requests unless your policy grants more for a namespace.
Can agents change a cluster without a person?: Only where your policy allows it. Most teams start with diagnosis and pull requests, then let agents restart or scale workloads in low-risk namespaces.
How do version upgrades work?: Agents check deprecated APIs, add-on versions and node groups against the target version, then open the plan as a pull request. Your team runs it on a non-production cluster first.

[Go deeper]