Scheduled Autonomous AI SRE Agent as a Kubernetes Guardian
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
Transcript
Kubernetes starts the run, not a person
0:00 Hi everyone, I'm Henry. Most agent workflows start when a person sends a request or an alert fires. This demo is different. Kubernetes starts AURA on a schedule so it can check a workload and act when something is wrong.
Two scheduling models, and the cron job config
0:11 There are two ways to schedule work with AURA. A scheduler can send recurring requests to an always-running AURA service, or it can start a fresh AURA process for each run. This demo focuses on the second model. Each scheduled job starts AURA, runs one health check, writes the result to the job log, and exits.
The CronJob, with a config on the left-hand side of your screen, is configured for every two minutes, and overlapping runs are forbidden. I keep the local demo pause between recordings to bound model cost, and the demo command will enable it for exactly one scheduler-created run. The job runs the normal AURA image in one-shot mode.
The scheduled query and AURA's tools
0:51 This query tells AURA to inspect the checkout deployment, restore the expected replica count only when needed, verify the result, and then stop.
On the right-hand side of your screen you'll see the AURA config. AURA connects to a Kubernetes MCP server. Its tools let it inspect the deployment, pods, events, and logs. Its only mutation tool is resources_scale.
Two independent limits: prompt and Kubernetes role
1:18 In the system prompt, the instructions narrow the task further. AURA can operate only in this demo namespace. It can make at most one mutation, and it must verify the workload after acting.
The Kubernetes role independently enforces that boundary. The MCP service account can update only the named checkout deployment. It cannot update another deployment or delete resources.
Healthy baseline, then scaling checkout to zero
1:41 On the right-hand side of your screen, you can see the live kind cluster. The checkout deployment starts healthy with two desired replicas and two ready replicas. The Kubernetes MCP server is also running in the same namespace.
Now, I'll introduce a failure and let the real Kubernetes scheduler start AURA. This command scales checkout to zero replicas, then enables the CronJob and waits for Kubernetes to create the scheduled job.
Waiting for Kubernetes to create the job
2:13 The workload is now unhealthy. The CronJob is active, but there are still no AURA processes and no requests to an AURA API. Kubernetes owns the clock and will create the run.
This job came from the CronJob, not from a manual kubectl create job.
AURA inspects, scales back to two, and verifies
2:37 As soon as Kubernetes created it, the wrapper paused future schedules again. AURA is now running the schedule query inside this job. In the pods view you can see the AURA job pod and the checkout pods returning as AURA remediates the deployment.
AURA inspected the deployment and found that the desired replica count was zero. It used its one allowed mutation to scale checkout back to two. It then checked the deployment and pods again. Both pods are running and ready. So the run ends with: remediated: checkout was scaled to two replicas.
Final state, and what was not in the loop
3:13 The demo then verifies that the schedule is paused again, checks the permission boundaries, and prints the final workload state.
The live cluster is back to two desired replicas and two ready replicas. The clock trigger came from Kubernetes. Once AURA started it, it inspected the live state, decided whether remediation was needed, performed one bounded action, verified recovery, and exited.
There was no person, alert, webhook, or human approval step in that loop. This is AURA running as a scheduled autonomous Kubernetes guardian.
More videos
