It is one thing to list what Burrow can do and another to see a day of it. So let me walk through what operating a live app through your AI coding agent actually feels like, from morning coffee to signing off. This is an illustrative day, not a war story from a real outage, but every command and behavior in it is real and shipped. The point is to show the texture: what you say, what the agent does, and where it comes back to you.
Morning: ship the thing you finished last night
You wrap up a feature and you are ready to put it out. You do not open a dashboard. You tell your agent to deploy it.
Behind the scenes, the agent builds a fresh image, gives it a new climbing version tag, and pushes it to your registry. Then it deploys by reference through its scoped command surface:
burrow-agent deploy web --image ghcr.io/you/web:2.3.0
It reads the result back to you in plain language: the release is up, one replica, healthy. You did not touch YAML, you did not watch a build log scroll by, you just said ship it and got a clear confirmation. Your code went the normal way, through your registry, and never through the agent's connection.
You ask it to double check, and it does:
burrow-agent status web
1/1 replicas ready, available. Good. On with your day.
Midmorning: something looks off
An hour later you notice the app feels slower than usual, and a couple of requests errored. You do not go digging through logs yourself. You ask the agent what is going on.
It reads the recent output:
burrow-agent logs web
and, because you installed the logs addon a while back, it can search across time rather than just the last few lines:
burrow-agent logs-query 'error'
It comes back with a plain answer: a specific endpoint is throwing, and the errors all trace to a database query timing out. It even checks the database health, since your metrics addon scrapes Postgres automatically, and confirms the database itself is fine, it is one slow query doing the damage.
If you want to see the numbers yourself, the same door is open to the agent for metrics. It can pull a specific series rather than eyeball a log:
burrow-agent metrics-query 'rate(http_requests_total{app="web",status="500"}[5m])'
The error rate ticked up right when the latency did, which lines the story up: one endpoint, one slow query, a handful of failed requests. The agent is not guessing from the shape of your code. It is reading what the running app actually did and what the numbers actually say. It can see past the editor.
This is the part that used to be the hard part. When operations meant a dashboard you had to go read, the agent could write the fix but could not see the symptom, so you were the sensor. Now the agent has eyes on the running system, and the diagnosis is something it can do rather than something it hands back to you half done.
You also notice, while it is in there, that traffic is up today, more than the single copy of the app is comfortable serving. You ask the agent to give it more room, and it scales the app out:
burrow-agent scale web 3
Three copies now share the load. Scaling is its own action, separate from deploying, so this does not disturb the release that is running, it just adds hands. If today's bump were the start of a lasting trend rather than a spike, you could ask the agent to set up autoscaling between a floor and a ceiling instead, so the number of copies rises and falls with demand on its own, within bounds you set. For a one day bump, a manual scale is the right call, and it is one line.
Midday: the fix, and a guardrail doing its job
The agent proposes a fix: a small change to the slow query, plus an index. It writes the code, builds a new image, and gets ready to deploy to prod.
But you set prod deploys to hold for your sign off, because prod is where you slow down. So when the agent reaches for the prod deploy, it does not just go. It comes back to you:
outcome: held_for_confirmation
operation: deploy
code: app.deploy
message: guardrail holds prod deploy for confirmation
The agent relays that to you, in its own words: it wants to deploy version 2.3.1 to prod to fix the slow query, and it is waiting on your approval. You look at the change, it is sensible, and you approve. Only then does the deploy go through. The agent did all the work and stopped at exactly the line you drew. That is the whole deal: it moves fast right up to the moves that matter, and those it brings to you.
Early afternoon: the fix was not quite right
The deploy goes out, and for thirty seconds it looks fine. Then, under real traffic, a different endpoint starts erroring, because the index change had a side effect nobody saw coming. This is the classic bad deploy: looked healthy, misbehaved under load.
You do not need the agent to diagnose the whole thing before you are safe. You get back to a known good state first, then investigate calmly. You tell it to roll back:
burrow-agent rollback web
Because Burrow kept the previous release warm, traffic shifts back to the version that was healthy a minute ago almost immediately. No rebuild, no cold start. Your app is serving again while the failing version is still right there to read. Recovery and investigation are two separate steps now, and the stressful one is already done.
Notice what just happened, because it is the heart of why this is workable. The agent's fix was wrong, and it did not matter much. A wrong fix used to mean an outage that lasted until you figured out how to undo it. Here it meant thirty seconds of trouble and one command to get back. The warm rollback turned "the agent made a mistake in prod" from a scary sentence into a minor one. That safety net under everything is a big part of what lets you hand real work to an agent at all: not that it never gets things wrong, but that when it does, getting back is cheap.
The agent then looks at the failing version's logs, works out that the new index changed a query plan it did not expect, and proposes a cleaner fix. This time you take a backup of the database before anything touches it, because the change is more involved:
burrow-agent addon backup postgres web
Then the corrected version goes out, you approve the prod deploy again, and it holds this time. Crisis over, and it cost you a few minutes and two approvals, not an afternoon.
Late afternoon: a small operational task
With the fire out, you handle a bit of housekeeping. A data migration needs to run against prod. Instead of copying credentials into a script, you have the agent run it as a one off task in the app's own environment, so it connects to the same database the app uses:
burrow-agent run web -- ./migrate up
It runs, reports success, and cleans itself up. One command, no credential shuffling, no separate deploy just to run a script.
Evening: check what happened, and sign off
Before you close the laptop, you want to see the record of the day. Every guarded, mutating operation is written to an append only log, so you ask the agent to show you what it did:
burrow-agent audit --app web
There is the day in order: the morning deploy, the held prod deploy you approved, the rollback, the backup, the migration, the corrected deploy. Who did it, what it was, and how it resolved, whether it executed, held, or was refused. Nothing the agent did is a mystery, because none of it was hidden. You did not have to trust that it behaved. You can read that it did.
What can go wrong, and how it fails safe
A clean narrative can make a day look tidier than real life. So here are the rough edges you will actually hit, and what happens at each one, because the point is not that nothing goes wrong, it is that when something does, it fails toward safe.
The agent tries to deploy to the wrong environment. This is the classic scary one, a fix meant for staging landing on prod. It does not happen quietly, because the agent's environment target is explicit and sticky: a mutating operation runs against the environment you last set, and it will not silently drift to another. If the agent's current target is staging, the prod deploy is a separate, deliberate act, and prod's own guardrail holds it for you regardless. There is no "oops, that went to prod" path here.
The agent reaches for a secret value. It cannot get one. There is no command in burrow-agent that reads a secret's value, so a plan that depends on the agent knowing your database password simply cannot execute. The agent can confirm the key exists and wire the app to it, and that is the whole of its reach. If it ever needs the value itself, that is your cue that a step belongs at your terminal, not in the agent's hands.
A guarded operation gets stuck waiting. When the agent proposes a prod deploy and you are away from the keyboard, it holds, it does not time out into running. The held state is the safe state. You approve it when you are back, and only then does it go. The agent never self approves and cannot retry its way past a hold: a repeated attempt without your explicit approval holds again, every time.
A build or push fails before any deploy. Because your code moves through the registry and not the agent's channel, a failed build or a bad push is a registry error that surfaces before Burrow is ever asked to deploy. The running app is untouched. You fix the image and try again, and nothing in production moved in the meantime.
A short FAQ
Does the agent need my kubeconfig or cluster credentials? No. It drives burrow-agent, which holds no cluster credentials at all. The control plane you installed holds the credentials and does the talking to Kubernetes. That is the point: the agent operates the app without ever holding the keys to the cluster.
Can I do all of this from my own terminal too? Yes. Everything the agent does through burrow-agent has a human equivalent in the burrow CLI (burrow app deploy, burrow app status, burrow app rollback, burrow app scale, burrow app run, burrow audit, and so on). The agent surface is the same operations, scoped down and JSON first so an agent can compose the result.
What if I want the app to scale on its own instead of setting a number by hand? Ask for autoscaling and it sets a floor and a ceiling, so the replica count rises and falls with demand within bounds you choose:
burrow-agent autoscale web
Turn it back off when you want a fixed count again with the off form on the human CLI (burrow app autoscale web off), and set an exact number with burrow app scale web 3.
Can I check whether the app is actually reachable from outside? Yes, that is its own quick question the agent can answer without you opening a browser:
burrow-agent reachability web
It reports whether the app is serving where it should be, which is handy right after a deploy or a domain change.
What the day added up to
Notice the division of labor across the whole day. The agent did the volume of work: building images, reading logs and metrics, diagnosing, writing fixes, running tasks. You did the deciding: approving the prod deploys, calling the rollback, choosing to back up before the risky change. That split is the point. You were not doing operations by hand, and you were not handing an agent the keys and hoping. You were operating a real production app by talking, while the guardrails you set kept the important choices yours.
Worth noticing too: not once in the day did you open a dashboard, write YAML, or SSH into a machine. You operated a live production app entirely by talking, and the moments that needed a human were surfaced to you as clear, specific decisions, not buried in a console you had to go hunting through. The friction landed exactly where it should, on the handful of choices that mattered, and nowhere else.
That is a normal day with Burrow. Most of it is quiet. The interesting moments are the ones where the agent hits a line you drew and comes back to ask, and where a warm rollback turns a bad deploy into a few calm minutes. The rest is just your app running, on your cluster, with you in the loop for exactly the parts that deserve it.