Scheduled Autonomous AI SRE Agent as a Kubernetes Guardian: AURA

Some agent work should pause for a person. This is the other case: a health check every two minutes, one bounded action, and a result nobody approved.

Learn more about AURA → https://www.mezmo.com/aura
Get started today → https://github.com/mezmo/aura
Get deployment help → https://www.mezmo.com/contact

Each scheduled run starts the normal AURA image in one-shot mode: check one workload, act if something is wrong, write the result to the job log, and exit. Overlapping runs are forbidden.

Henry covers the two ways to schedule work with AURA, recurring requests to an always-running service or a fresh process per run, and why this demo uses the second. The config connects to a Kubernetes MCP server with inspect access to deployments, pods, events, and logs, and exactly one mutation tool: resources scale.

Two limits apply independently. The system prompt narrows AURA to the demo namespace, one mutation, and mandatory verification after acting. The Kubernetes role enforces the same boundary from the cluster side, where the MCP service account can update only the named checkout deployment and cannot update another deployment or delete resources.

The failure is introduced by scaling checkout to zero replicas. Kubernetes creates the scheduled job on its own clock. AURA finds the desired replica count at zero, uses its one allowed mutation to scale back to two, re-checks the deployment and pods, and reports the deployment remediated.

Chapters:

0:00 Kubernetes starts the run, not a person

0:11 Two scheduling models, and the cron job config

0:51 The scheduled query and AURA's tools

1:18 Two independent limits: prompt and Kubernetes role

1:41 Healthy baseline, then scaling checkout to zero

2:13 Waiting for Kubernetes to create the job

2:37 AURA inspects, scales back to two, and verifies

3:13 Final state, and what was not in the loop

#Kubernetes #SRE #AIAgents #DevOps #Observability