AI Agents for DevOps: Fixing Pipelines and RBAC Nobody Owns

Every DevOps team has a version of the same three problems. The deploy pipeline works, but only because one engineer knows which environment variable silently breaks the staging build, and that engineer is on vacation this week. Incident response exists as a runbook, except the runbook is a pinned Slack thread from fourteen months ago that references a load balancer that was decommissioned in March. And the Kubernetes RBAC model has 340 role bindings, nobody remembers why half of them exist, and the last person who could explain the cluster-admin grants left the company. None of this is hypothetical. It is the default state of infrastructure at any company past its first eighteen months, because pipelines and access models are built under deadline pressure and audited only when something breaks or a compliance auditor asks a question nobody can answer. Generic AI tools are not built to fix this, because fixing it requires reading the actual state of your systems before proposing anything, not generating plausible YAML from a prompt.

Why ChatGPT and Cursor both fail at this job

Ask ChatGPT or Claude.ai to "review our CI/CD pipeline for security issues" and it will produce a generic checklist: rotate secrets, pin dependency versions, add a manual approval gate before production. All correct in the abstract, all useless in practice, because none of it is grounded in your actual pipeline. A generalist chatbot has never seen your .gitlab-ci.yml, has no idea your build step shells out to a script that SSHes into a bastion host, and cannot tell you that your deploy job has been retrying silently for six months because someone added continue-on-error: true to unblock a release and never removed it. It will happily write you a beautiful, wrong Kubernetes RBAC policy from scratch, one that has no relationship to the 340 bindings actually sitting in your cluster and the workloads that depend on them staying exactly as broken as they currently are.

Cursor and GitHub Copilot solve a narrower and different problem. They are excellent at finishing a Terraform resource block or suggesting the next line of a Helm values file while you have the file open. But DevOps and platform work is rarely about the next line in one file. It is about tracing a deploy from git push to production across four YAML files, a Dockerfile, a registry, and a cluster, and understanding where the actual risk sits. An autocomplete tool has no mechanism for reading your pipeline end to end, flagging that your test stage is not actually blocking on failure, and telling you that before it suggests a fix. Autocomplete finishes what you are already typing. It does not go look at your cluster's RBAC bindings unprompted and tell you twelve service accounts have cluster-admin they do not need.

Relay, Forge, and Kube: agents that read your infrastructure first

Tonone's Relay is the DevOps engineer of the team, built around CI/CD, deployments, GitOps, and developer experience. It does not start by writing a pipeline. It starts by reading the one you already have. The relay-recon skill maps the full pipeline end to end, triggers, build stage, test stage, deploy flow, with a risk assessment attached, so Relay knows what it is looking at before it recommends anything. From there, relay-audit goes deeper: it audits an existing CI/CD pipeline specifically for slowness, security issues, and reliability gaps, the kind of audit most teams intend to do quarterly and actually do never. When the fix requires more than patching, relay-pipeline builds a full CI/CD pipeline from scratch, and relay-deploy sets up the complete deployment configuration, Dockerfile, deployment manifest, environment config, and rollback procedure, so a deploy failure has an actual recovery path instead of a scramble.

Tonone's Relay audits an existing CI/CD pipeline for slowness, security issues, and reliability gaps before proposing a rebuild, not instead of understanding it.

Relay does not work alone on infrastructure that spans beyond the pipeline. Forge, Tonone's infrastructure engineer, owns cloud services, networking, and infrastructure as code. forge-recon inventories every cloud resource and maps the connections between them, and forge-audit checks that inventory for security issues, waste, and misconfigurations, the kind of finding that shows up in a cost review six months later as "why do we have four unused load balancers." When the platform team's real problem is a Kubernetes cluster nobody trusts, Kube takes over. kube-recon audits an existing cluster for misconfigurations, security gaps, and resource issues, and kube-rbac designs or audits the RBAC model specifically, roles, bindings, service accounts, and the least-privilege model that should have existed since day one. Three agents, three domains, one shared discipline: read the actual system before touching it.

Worked example: Vantage Freight's pipeline and RBAC cleanup

Vantage Freight is a 14-person logistics SaaS team running a Node backend on GKE, with a deploy pipeline that one engineer, Marcus, built two years ago and has been the only person confident enough to modify since. The pipeline takes 47 minutes end to end, has a flaky integration test stage that gets re-run manually about four times a week, and includes a deploy step that SSHes into a jump box to run a migration script Marcus wrote before the team adopted a proper migration tool. Separately, the platform lead flags that the GKE cluster has 340 RBAC bindings, twelve service accounts hold cluster-admin, and the last audit was done ahead of a SOC 2 readiness review fourteen months ago. Nobody currently on the team can say with confidence which of those twelve service accounts actually need that level of access.

The team runs relay-recon first. It reads the .gitlab-ci.yml, the Dockerfile, and the deploy scripts, and maps the pipeline stage by stage: lint, unit test, integration test (flaky, no retry logic, silently allowed to fail via allow_failure: true), build, push to registry, and the SSH-based migration step with no logging on failure. The recon output flags three risks before any redesign starts: the integration test stage is not actually gating deploys, the migration step has no rollback path, and there is no environment parity check between staging and production before the deploy job runs. relay-audit then scores the pipeline against reliability and security baselines and confirms the SSH-based deploy step is the single largest risk, one bad key rotation away from a broken release process with no one but Marcus able to diagnose it.

Relay, Pipeline Audit: Vantage Freight
Recon: GitLab CI, 47min avg run, SSH-based migration step, allow_failure on integration tests.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Findings:
  1. Integration tests marked allow_failure, deploys proceed regardless
     of test outcome. Severity: high.
  2. Migration step runs via SSH to a bastion host with no audit log
     on failure and no rollback procedure. Severity: high.
  3. No staging/production parity check. Config drift between
     environments has caused 2 of the last 5 incidents. Severity: medium.
  4. Single point of knowledge: one engineer has made 90% of the
     commits to the pipeline config in the last 12 months. Severity: medium.

Recommendation: relay-pipeline rebuild, containerized migration step,
remove allow_failure, add parity gate. Estimated pipeline time after
fix: ~18min (from 47min), tests actually blocking.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Kube, RBAC Audit: Vantage Freight GKE cluster
Recon: 340 bindings, 12 service accounts with cluster-admin, last
audited 14 months ago.

Findings:
  1. 9 of 12 cluster-admin service accounts only need namespace-scoped
     edit access based on actual workload behavior over 30 days.
  2. 1 service account has cluster-admin and has not been used in
     90+ days, tied to a decommissioned CI runner.
  3. No RoleBinding review process exists, bindings are added ad hoc
     and never removed.

Recommendation: kube-rbac redesign to least-privilege, remove the
stale binding, add a quarterly review skill trigger.

Based on that finding, relay-pipeline rebuilds the deploy flow: the migration step moves into a containerized job with proper logging and a rollback command, allow_failure is removed so a red test suite actually blocks a deploy, and a staging-to-production parity check runs before the deploy job fires. The rebuilt pipeline runs in roughly 18 minutes instead of 47, mostly because the flaky integration tests were flaky due to a shared test database race condition that recon surfaced and the redesign fixes directly. In parallel, Kube runs kube-rbac against the cluster's actual usage patterns over a 30-day window, not a theoretical least-privilege model, and finds that nine of the twelve cluster-admin service accounts only ever touch resources in their own namespace. The RBAC redesign scopes those nine down to namespace-level edit access, removes the one binding tied to a decommissioned CI runner entirely, and leaves a documented review process so this does not silently drift back to 340 ungoverned bindings in another fourteen months.

Tonone's Kube audits Kubernetes RBAC against actual service account usage, not a theoretical policy, so the least-privilege model matches what the cluster actually needs.

Relay vs generalist AI vs Cursor for DevOps work

The pattern holds for any platform team carrying this kind of debt. The pipeline that only one person understands, the incident runbook that lives in a Slack thread instead of a document, the RBAC model that has drifted for over a year, these are not problems a generic AI assistant can meaningfully touch, because the fix depends entirely on reading the specific, messy state of your specific systems first. Relay, Forge, and Kube are built to do that reading as the first step, not an afterthought, so what comes back is a redesign grounded in your actual pipeline and your actual cluster, not a plausible-sounding rewrite that ignores both.

Tonone is free and MIT-licensed. Installing it once gives you access to all 100 agents, including Relay, Forge, and Kube, directly inside Claude Code. You only pay for the Claude Code token usage while the agents work.