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 operations agent, and it changed how I think about the whole category.
What an operations agent does
An operations agent doesn't write code. It reacts to things. Specifically, it subscribes to events on the fleet bus, and when one fires, it does whatever its prompt tells it to do.
In Fleet, every agent — regardless of role — subscribes to fabric events via the subscribes_to field. When a PR ships, the watcher publishes a ticket_shipped event. When CI fails, it publishes ci_fail. An agent subscribed to one of those events starts up with the event in its context, and from there its behavior is driven entirely by its prompt. You can instruct it to:
- Comment on the issue or PR with a summary of what just shipped
- Open a follow-up ticket if the change touched something it's been told to keep an eye on
- Post a note to the fleet log so the next human or agent has full context
All of this happens without a human being paged to stare at a dashboard and decide whether anything needs doing. The agent reads the event, follows its instructions, and writes its conclusion into the audit log.
Why this completes the story
If you're an engineering leader evaluating Fleet, the operations agent is what makes the autonomous chain easier to trust.
Without it, your chain ends at "code merged." The PR is approved, the release-manager merges, the ticket_shipped event fires, and then nothing else happens automatically. That's where most automation stories stop, and it's the exact point where engineering leaders get nervous. Who notices that it shipped? Who writes down what changed? Who files the follow-up?
With an operations agent subscribed to ticket_shipped, the chain extends past the merge. The PR merges, the event fires, the agent wakes up with that event in its context, and it does the after-the-merge work you'd otherwise have to remember to do yourself — summarize the change, file a follow-up, record it in the log.
A note on scope: Fleet itself does not deploy your code, watch production error rates, or roll anything back. Those are jobs for your CI/CD system and your monitoring stack. What Fleet gives you is an agent that reacts to the events Fleet actually emits — chain milestones like ticket_shipped and ci_fail — and runs whatever follow-up its prompt describes.
The configuration
agents:
- name: ops-watcher
role: infrastructure
model: claude-haiku # follow-up work doesn't need an expensive model
subscribes_to:
- ticket_shipped
- ci_fail
That's the whole config. There's no special watch block, no threshold field, no built-in rollback action — Fleet doesn't have those. The agent's behavior lives entirely in its prompt. subscribes_to decides which events wake it up; the prompt decides what it does when it wakes.
The operations agent runs on Haiku because it doesn't need to be smart. It needs to be fast, cheap, and boringly reliable. It's reading an event and following a short, deterministic set of instructions.
Other things an operations agent can do
A ticket_shipped follow-up is the obvious use case, but once you have one agent reacting to events, the same pattern extends to a lot of other things — all of it driven by the agent's prompt, not by extra config.
CI triage. Subscribe to ci_fail. When a check fails, the agent reads the failure, comments on the PR with a first-pass diagnosis, and labels it so the responsible developer picks it up faster.
Release notes. Subscribe to ticket_shipped. The agent collects what merged and drafts a changelog entry so nobody has to assemble one by hand.
Dependency hygiene. There's no built-in lockfile watcher or dependency advisory in Fleet, but you can instruct an agent — for example on a scheduled run — to check your manifest for outdated or flagged packages and open a PR to bump them. That's a task you tell the agent to do, not a feature Fleet performs on its own.
Housekeeping after a ship. Tell the agent to close the originating issue, post to the fleet log, and notify the relevant org agent. Mundane, easy to forget, exactly the kind of thing a cheap fast model handles well.
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 operations agent remembers.
The bigger point
AI agents aren't only useful for writing code. They're also operational glue. The operations agent pattern (subscribe to an event, look at what happened, take the follow-up action your prompt describes) applies to a lot more than shipping a PR.
Anything where the pattern is "an event fires, decide what it means, do the follow-up" 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 writes to the same audit log. The events Fleet emits are about your code-delivery chain — ticket_ready, pr_created, pr_approved, ci_pass, ci_fail, ticket_shipped — so the natural home for an operations agent is reacting to those, not watching production telemetry Fleet never sees.
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.