AI can make GitOps better, but only if Git remains the decision record.
The bad version of AI-assisted GitOps is an agent that sees an alert, edits a live cluster, and explains itself afterward. The good version gathers current evidence, proposes a declarative change, opens a reviewable diff, waits for approval, and verifies what the reconciler actually did.
GitOps gives an AI agent a strong operating boundary: desired state is declarative and versioned, changes are reviewable, and a controller continuously reconciles the environment. Infrastructure as code extends the same idea across cloud resources, identity, networking, databases, and other managed services.
The agent should accelerate the loop, not bypass it.
The seven-step operating loop
observe -> explain -> propose -> validate -> review -> reconcile -> verify
Each step produces evidence for the next.
1. Observe live state
Before changing code, inspect the actual environment:
- Git revision currently deployed.
- Reconciler health and last successful sync.
- Kubernetes events and workload status.
- Image digests and configuration.
- Cloud resources connected to the workload.
- Recent incidents, deployments, and manual interventions.
This prevents the agent from treating the repository as a perfect map when production has drifted or a reconciliation is already failing.
2. Explain the difference
Ask the agent to separate symptoms, evidence, and inference.
Symptom: checkout pods are restarting
Evidence: OOMKilled events began after image digest sha256:...
Desired state: memory limit is 512Mi in Git
Observed state: workload is reconciled to that limit
Inference: the current release needs more memory or contains a regression
Unknown: whether traffic or per-request memory changed
That explanation is reviewable. "Increase memory" is only a guess.
3. Propose the smallest declarative change
The agent can draft a patch to Helm values, Kustomize overlays, Terraform, OpenTofu, Pulumi, Bicep, or another authoritative source.
Require it to include:
- The exact files and resources affected.
- Why each change is needed.
- Expected create, update, and delete operations.
- Security, cost, and availability impact.
- Rollback path.
- Evidence that would prove success.
Avoid broad cleanup while responding to an incident. Small diffs are easier to understand and reverse.
4. Validate before review
Run the checks appropriate to the repository:
- Syntax and schema validation.
- Unit and integration tests.
- Helm template or Kustomize build.
- Terraform/OpenTofu plan or cloud-native preview.
- Policy checks.
- Diff checks for accidental deletes, replacements, or permission expansion.
An AI explanation does not replace the native plan. It should summarize the plan and point reviewers to the authoritative output.
5. Put the change in a pull request
The pull request should be the handoff between agent speed and human accountability.
Include:
- Incident or request link.
- Live-state evidence.
- Declarative diff.
- Validation output.
- Risk and rollback.
- Named reviewer or approval policy.
Some GitOps tools support automation that writes changes back to Git. Flux, for example, documents image automation that can update manifests and push to a separate branch, allowing CI or a pull request flow to preserve manual approval before cluster reconciliation.
6. Let the normal reconciler act
After approval and merge, Flux, Argo CD, or the chosen delivery system should reconcile the declared state. Do not let the agent secretly apply a parallel live patch unless the organization's incident process explicitly allows it and records the exception.
The delivery system remains authoritative. The agent is a participant, not a second control plane.
7. Verify the outcome
Merge is not recovery. Reconciliation success is not application health.
Verify:
- The intended revision reached the intended environment.
- The reconciler reports healthy state.
- Workloads are ready and stable.
- Error, latency, saturation, and business signals recovered.
- Cost and security posture did not regress.
- No unrelated resources changed.
Use the same evidence sources from the initial investigation so the before-and-after comparison is honest.
What AI should do in GitOps
AI is useful for:
- Correlating repository, cluster, cloud, and incident evidence.
- Explaining drift and reconciliation failures.
- Drafting the smallest declarative patch.
- Generating a pull request summary from authoritative plans.
- Finding missing validation, rollback, or observability steps.
- Classifying routine changes versus high-risk changes.
- Verifying the result and packaging exceptions.
What AI should not do by default
Keep these behind explicit approval:
- Direct production mutations that bypass Git.
- IaC apply operations.
- Resource deletion or replacement.
- Identity, permission, secret, and network-boundary changes.
- Reconciliation of an unexplained large diff.
- Automatic conflict resolution that changes policy or ownership.
- "Fix everything" refactors during an incident.
The issue is not whether an agent can execute the command. It is whether the team can understand, authorize, and reverse the outcome.
Where Clanker DevOps fits
Clanker DevOps gives people and MCP-connected agents a workspace for live cloud, Kubernetes, GitHub, deployment, cost, and security context. Clanker CLI uses local provider credentials for its normal infrastructure path, so the agent can inspect current state without turning raw cloud keys into prompt material.
Use it to prepare the evidence and reviewed plan around the existing GitOps system:
Compare the live cluster with the main branch and the reconciler status. Explain drift, draft the smallest manifest change, run the repository validation, and prepare a pull request. Do not mutate the cluster or merge.
That is the right ambition for an AI-assisted GitOps platform: fewer hours assembling context, faster and clearer diffs, and the same deliberate control over production.
Sources
Give your agent live infrastructure context
Download Clanker Cloud, expose the local MCP surface, and let coding agents work from current cloud, Kubernetes, GitHub, and cost state instead of guesses.