Most people think of AI agents as code writers. Write features, open PRs, maybe do some review. That's how I thought about them for the first six months of building Fleet.
Then I set up an SRE agent, and it changed how I think about the whole category.
What an SRE agent does
An SRE agent doesn't write code. It watches things. Specifically, it watches your deployments, your error rates, and your service health, and when something looks wrong, it acts.
In Fleet, an SRE agent subscribes to deployment events. When a release agent merges and deploys a PR, the SRE agent starts monitoring. It watches error rates for the next 30 minutes. If rates spike above a threshold you define, it can do any of the following:
- Alert your on-call channel
- Open a rollback PR automatically
- Quarantine the agent that produced the bad code
- Log the incident in the fleet log with full context
All of this happens without a human being paged at 2 AM to stare at a dashboard and decide whether the spike is real.
Why this completes the story
If you're an engineering leader evaluating Fleet, the SRE agent is the feature that makes the autonomous pipeline actually trustworthy.
Without it, your pipeline ends at "code merged and deployed." That's where most automation stories stop, and it's the exact point where engineering leaders get nervous. What happens if the deploy breaks something? If the team is in a meeting, or it's 3 AM, or nobody happens to be watching the monitors?
With an SRE agent, the pipeline extends through the deployment and into monitoring. The deploy happens, the SRE agent watches it, and if something goes wrong, the response starts before any human is aware there's a problem.
You've gone from automating the code pipeline to automating the whole delivery pipeline end to end. That second version is what lets engineering leaders actually sleep at night while agents are shipping code for them.
The configuration
agents:
- name: sre-watcher
role: sre
model: claude-haiku # monitoring doesn't need expensive models
subscriptions:
- deployment_complete
watch:
error_threshold: 0.05 # 5% error rate triggers action
watch_window: 30m
actions:
- alert
- rollback_pr
The SRE agent runs on Haiku because it doesn't need to be smart. It needs to be fast, cheap, and boringly reliable. It's reading metrics and making a binary decision about whether they're above threshold.
Other things SRE agents can watch
Deployments are the obvious use case, but once you have one running, the same pattern extends to a lot of other things.
Build times. If a build that normally takes four minutes suddenly takes twelve, something changed. The agent flags it.
Test flakiness. If a test suite that passes 98 percent of the time drops to 90, the agent opens a ticket.
Dependency vulnerabilities. When a security advisory drops for a package in your lockfile, the agent can open a PR to bump the version.
Service health after changes. Monitor CPU, memory, and response times for 30 minutes after any deploy. If a metric deviates from its baseline, flag it.
None of these tasks require an expensive model. All of them run comfortably on Haiku. And all of them are the kind of thing that either doesn't get done today, or requires a human to remember to check. The SRE agent remembers.
The bigger point
AI agents aren't only useful for writing code. They're also operational infrastructure. The SRE agent pattern (subscribe to an event, monitor an outcome, take action if the outcome is off) applies to a lot more than deployments.
Compliance monitoring. Cost anomaly detection. API uptime checks. Log analysis. Security scanning. Anything where the pattern is "watch something, decide if it's normal, act if it isn't" is a task a cheap fast model on an event subscription can handle. Fleet makes setting these up easy because every agent, regardless of role, plugs into the same event bus and the same audit log.
Your fleet shouldn't be all developers and reviewers. Some of the most useful agents on a team are the ones that never write a line of code.