Skip to content
kube-agents

Proactive autonomy

Most agent products are reactive: you ask, they answer. kube-agents is designed to also act on its own. Cron-scheduled jobs, defined in agents/platform/cron/jobs.json (how they fire), point the Platform Agent at governance SOPs on a rolling schedule. Findings become a standing report issue on your GitOps repo and, where the fix is mergeable, proposed pull requests against it.

The hands-free loop

Section titled “The hands-free loop”
Cron tick
    ↓
Governance SOP
    ↓
Platform Agent investigates
    ├──  fleet-audit / submit-suggestion
    ├──  Minty mints GitHub token
    └──  Ledger issue or pull request opened

Every step is real code shipping in the repo. The SOPs live in agents/platform/governance/; the submit-suggestion skill wraps the git flow; Minty brokers short-lived tokens.

The loop ends at the repo, not in chat. A watchdog’s findings reach you as the ledger issue and the pull requests linked to it; the report itself is never posted to a chat channel, and there is nothing to read there that the issue does not already say. The unprompted messages the harness does send come from elsewhere: a cluster event posted to the in-pod triage endpoint, and the first-run inventory report (ChatOps → Proactive alerts).

What runs on its own

Section titled “What runs on its own”

Six fleet audits run enabled, each on its own schedule and each maintaining a single GitHub issue as its standing report:

  • Security & RBAC posture (daily) — privileged and host-namespace containers, over-privileged RBAC bindings, namespaces with no NetworkPolicy, Workload Identity and metadata-concealment gaps.
  • Workload reliability (daily) — missing resource requests, drain-blocking or absent PodDisruptionBudgets, unscalable Deployments, zone-pinned scheduling, missing probes.
  • Upgrade & patch readiness (weekly) — control-plane and node versions against the cluster’s release channel, version skew, autoUpgrade/autoRepair off, missing maintenance windows.
  • Fleet waste (weekly) — over-provisioned requests, orphaned PersistentVolumes and disks, idle reserved IPs, near-empty node pools. Reported in resource units, not dollars: there is no billing export to price against.
  • Fleet consistency drift (weekly) — clusters that diverge from the rest of the fleet on release channel, Workload Identity, Shielded Nodes, logging config and similar facets. The baseline is derived from the fleet itself, so it needs no blueprint to compare against.
  • AI workload security (daily) — inference endpoints on external load balancers, model repositories trusted to execute their own code, weights mounted writable under the serving process, unpinned model artifact sources, registry credentials in plaintext environment variables, model-server images on floating tags. It scopes itself to workloads running a known inference runtime or holding a GPU or TPU, and evaluates the deployment, never the model.

Alongside them, github-repo-watcher polls the target repo every 10 minutes and hands what it finds to one of two skills. An unaddressed open issue goes to github-issue-resolver, which triages it within tight guardrails — audit ledgers, which carry agent:audit, are excluded from the poll. A review request on one of the agent’s own pull requests — a comment that begins with /agent or with an @-mention, from someone with write access — goes to pr-conversation, which answers in the thread or amends the branch under review. The poll itself runs no model: a tick with nothing to do costs an API call and no tokens.

Each audit calls the fleet-audit skill, whose helper owns every git and gh operation and renders every body from a validated findings file. The stream’s ledger issue is rewritten in place each run; findings with a mergeable manifest are promoted into narrow remediation PRs that link back to it — automatically for critical ones, on request for the rest (Declarative workflow has the mechanism). A finding with no reproducible command is dropped, not softened; a clean run closes the ledger as completed and says nothing at all — unless it could not read the whole fleet, in which case it leaves the ledger open and reports the gaps rather than passing a partial look off as an all-clear, or it resolved findings on the way there, in which case it reports what closed rather than letting the good news be the only thing it swallows.

Those seven are the whole roster; five further watchdogs shipped disabled for a time and have since been retired. Reference → Cron jobs has the full table, generated from jobs.json, with exact cron expressions and prompts.

Why this matters

Section titled “Why this matters”

The alternative for each of these is a person on a rotation, a static Terraform module, or an alert that pages someone in the middle of the night. kube-agents closes the loop:

  • Audit → issue → PR — the agent doesn’t just detect drift, it keeps a standing report of it and proposes the mergeable fixes as PRs you review.
  • Fleet-wide read, mutations through Git — the Platform Agent reads the fleet via the GKE MCP server and is designed to route every change through a pull request. Which parts of that are enforced rather than intended is set out in Security & IAM.
  • Recovery ladder before escalation — SOUL.md §4 caps recovery attempts at 5 iterations / ~10 minutes per blocker before asking a human.

The design goal: fleet issues stop rotting silently while the on-call queue is quiet.

Safety rails

Section titled “Safety rails”
  • Declarative-only for infra changes. SOUL.md §1 forbids direct kubectl apply for GKE infrastructure. Everything routes through the GitOps write path — submit-suggestion for a one-off change, fleet-audit for a scheduled audit run, and nothing else (SOUL.md §3.2).
  • Destructive operations always ask. Cluster deletion, tenant offboarding, broad IAM revocation — the persona explicitly gates these on human confirmation, no matter how many “just do it” phrases are in the user’s message.
  • Bounded retries. The recovery ladder in SOUL.md §4 bounds each blocker at 5 attempts / 10 minutes before escalating.

Where to go next

Section titled “Where to go next”