Each story follows one real-world situation. It starts with the first signal and ends with the merge request (MR) on your desk. You see what the assistant looks at, how it reasons, and which checks it runs before you see the change. You also see what the MR says. The examples are illustrative and use fictional names. The mechanics are the ones the assistant runs.
The assistant reads every changelog between your version and the newest release. It checks which breaking changes affect your values. It stops at the right version boundary.
Read the story →The assistant writes Flux v2 replacements that keep your values unchanged. It migrates first and deletes second. It never does both in one MR.
Read the story →The assistant finds missing resource requests, security-context gaps and storage classes that drifted. It opens one small, clean MR for each finding.
Read the story →The assistant classifies thirty days of real usage and applies safety clamps. Then it proposes a change to resource requests and limits, with the numbers in the MR.
Read the story →The assistant finds idle volumes, hibernated databases and forgotten environments. It shows the evidence.
Read the story →Cloud providers reclaim spot nodes (cheap nodes that can disappear). Disruption budgets, topology spread and replicas keep the service up when that happens.
Read the story →An alert fires. The assistant investigates with read-only access and finds the cause. Then it asks whether a manifest change would have prevented the alert.
Read the story →The assistant groups failed Velero and CNPG backups into one issue with a diagnosis. You see it before you need a restore.
Read the story →You declare maintenance windows in git with an end time. Your CI applies them. The assistant lints and audits them.
Read the story →The assistant brings hand-applied workloads and old Tiller (Helm v2) releases into git. It copies them from their live state, so the first reconcile changes nothing.
Read the story →Fifty warnings with one root cause become one issue. The assistant closes the issue when the warnings stop.
Read the story →The assistant bases each rename on what the file contains. It never guesses from neighbouring files.
Read the story →The assistant replaces committed Secrets with ExternalSecrets backed by Vault. It catches broken references before a restart.
Read the story →The assistant groups denials in the Vault audit log and classifies them. It then proposes a narrow policy change. When the fix is not simple, it opens an issue.
Read the story →The assistant writes posture reports mapped to compliance controls. It also checks image provenance and the posture of your forge, cloud and edge. You get findings, not surprise changes.
Read the story →Policies, auth methods and roles live in git, and CI applies them. The assistant lints them for escalation risks and dangling references before they merge.
Read the story →The assistant starts from a metrics port that nobody scrapes. It adds a ServiceMonitor (a rule that tells Prometheus what to scrape). Then it builds a Grafana dashboard where every panel is shown to return data.
Read the story →Several reviewer personas review your own MRs. Each one names its AI model. A second, independent reviewer also checks every MR that the assistant opens.
Read the story →Ask about a workload in a thread and get a draft MR back. You can also tell the assistant to leave something alone.
Read the story →The assistant answers comments on MRs. The comments also change how the agents behave on your infrastructure.
Read the story →Add a POLICY.md or a skip annotation, and every agent follows it.
Read the story →The assistant checks every record against live ingresses and load balancers. It removes dangling records in the same wave as the retirement.
Read the story →Playbooks and inventories become first-class targets. The assistant handles upgrades and hygiene, and triages failures from the CI job log.
Read the story →The assistant joins NetBox, the network, Ansible, Kubernetes and cloud KMS into one picture. It finds the root cause where it really is.
Read the story →The assistant opens draft MRs on GitLab, and support for GitHub and Forgejo is in development. Cluster access goes through the GitLab agent (KAS), with no direct path to the API server.
Read the story →The assistant first runs a sealed, read-only assessment of your new clusters. This assessment physically cannot send anything out. Full support follows. Argo CD is on the roadmap.
Read the story →Your own GPUs handle sensitive work. Cloud AI models see masked identifiers. You choose the route for each task.
Read the story →