I timed it once.
An AI agent wrote a complete feature implementation in 22 minutes. Tests included. PR opened. Clean diff. Ready for review.
The PR sat in the review queue for six hours and forty minutes.
The person who was supposed to review it got the GitHub email. I know because I asked him later. He saw it at 11:30 AM between two other emails about PRs in a different repo. He was mid-feature, figured he'd get to it after lunch, then got pulled into a 1 PM meeting that ran long. He saw the email again at 3:45, started the review at 4:20, and left two comments. By then the developer who'd triggered the agent had moved on to a different task entirely.
That PR didn't ship for two days. Because after the review came back with two minor change requests, the developer had to reload context, make the changes, push, and wait for re-review. Another full cycle.
Two days, for 22 minutes of work.
The notification existed. It just didn't matter. It was one email in a sea of GitHub emails, competing with whatever the reviewer was already focused on.
This is where AI agent speed goes to die
Everyone talks about how fast AI agents write code, and they're right about that. The writing is fast. But writing was never the bottleneck. If you measure your pipeline end to end, from "work starts" to "code is in production," the actual coding is maybe 15 to 20 percent of the elapsed time. The rest is waiting. Waiting for someone to check their email. Waiting for them to decide to context-switch. Waiting for the review. Waiting for re-review after changes. Waiting for someone to hit the merge button. Waiting for the deploy pipeline to be free.
AI agents made the small part of that faster. The rest of it stayed exactly where it was.
And, for most teams today, the agent itself is manually operated. A developer prompts it, reviews the output, opens the PR, assigns the reviewer. The AI writes code fast, but the human pipeline around it moves at human speed. You've bolted a fast engine onto a slow vehicle.
What changes when the handoff is an event instead of an email
In Fleet, agents subscribe to events. The reviewer agent subscribes to "PR created" events. The release agent subscribes to "PR approved" events. The watcher daemon monitors GitHub labels and routes events in real time.
Here's what the same scenario looks like with Fleet running.
A ticket gets labeled "ready" in GitHub. Fleet's watcher detects the label and fires a ticket_ready event. Before a development agent touches it, a product owner agent picks it up first. It reads the ticket, reads the relevant parts of the codebase, and produces a refined version with acceptance criteria, edge cases, and a suggested approach. Then it routes the ticket to the development agent best suited for the work. Frontend tasks go to the frontend agent. Database changes go to the backend agent.
The development agent receives a well-scoped ticket and starts working. When it's done, it opens a PR. Fleet detects the PR and fires a pr_needs_review event. A reviewer agent picks it up within seconds, not because someone read an email, but because the agent was subscribed to that event and was waiting for exactly this.
If the reviewer approves, a pr_approved event fires and a release agent handles the merge. After the deploy, an SRE agent starts monitoring error rates. If something spikes, it can trigger a rollback before your on-call engineer even sees an alert.
The whole chain completes in minutes. Nobody opened an email. Nobody assigned a reviewer. Nobody watched the deployment.
And it doesn't stop at the repo boundary
Here's a variant that happens constantly. A frontend agent is implementing a feature and needs to call an API in a different service, in a different repo. While wiring up the integration, it discovers the API is broken. The endpoint returns the wrong shape, or a field is nullable that shouldn't be, or pagination is off by one. A classic cross-team bug.
In the manual loop this is where everything dies for another day. The frontend dev pings the backend team in Slack, the backend team is mid-sprint, someone eventually files a ticket on the backend repo's board, it sits in a queue, and meanwhile the original feature is blocked waiting on a fix that nobody's urgently working on.
In Fleet, the frontend agent files the ticket directly on the backend repo's board and flags itself as blocked. That's the entire human-facing part of the story.
What happens next happens without anyone watching. Fleet's event bus is shared across repos, so the new ticket fires a ticket_ready event the moment it's labeled. The backend repo's product owner agent picks it up, refines it, and routes it to the backend dev agent. The backend agent writes the fix, opens a PR, gets reviewed, merged, and deployed. A ticket_shipped event fires. The frontend agent that was blocked on the fix resumes its original work.
Nobody pinged anyone. No human filed anything in Jira, the ticket was filed automatically by the agents. A cross-team dependency that would normally take three days to unblock resolves itself in the time it takes to write a commit message, and the first human to learn about any of it reads it in the decision log the next morning.
Where humans stay
I want to be clear about what Fleet changes and what it doesn't.
Most teams today use AI agents in a manual loop. The developer is the operator. They prompt the agent, review its output, decide whether to PR it, assign a reviewer. The agent is a tool the developer wields, faster than writing by hand, but the pipeline around it is entirely human-driven.
Fleet's reactive engine makes the pipeline itself autonomous. Agents self-trigger, coordinate with each other, and hand off work without a human initiating each step.
That doesn't mean humans are gone. Fleet has approval gates, and you configure them per pipeline stage. Your team might decide that any PR touching the authentication service requires a human tech lead's sign-off. Or that anything over 500 lines gets flagged for human review. Or that production deploys always require approval.
Everything that doesn't need a human moves at machine speed. Everything that does need a human waits, but only at that specific step, not at every step.
The goal isn't to remove humans from the loop. It's to stop forcing humans to be the loop. Your senior engineer shouldn't be the mechanism by which a review happens. They should be the judgment call when a review actually needs judgment. Most teams have those two roles collapsed into one person and then wonder why that person is exhausted.
What this looks like in numbers
This is the exact setup I ran for the integration between Fluent and Formantic. Fluent is a conversation intelligence app. Formantic is the diarization and transcription API Fluent runs on top of.
Before I put both repos on the same Fleet fabric, integrating them meant me sitting in the middle of both: writing the ticket on Formantic's side, opening a terminal, prompting the agent there, reviewing its PR, merging, deploying, switching back to Fluent, pulling the updated API, testing, fixing whatever broke at the boundary, opening a Fluent PR, repeating. Twelve of those handoffs in a week and the week was gone.
After Fleet:
- Cross-repo integration tickets I personally touched start-to-finish: almost none
- Wall-clock time for a ticket to go from filed on the provider side to deployed and consumed on the client side: roughly 90 minutes, without me in the loop
- Decisions for the whole integration that actually needed me in the chair: three
- Manual handoffs I drove from one repo to the other: zero
The Fluent/Formantic integration I'd budgeted as a 1 week grind finished in 1 working day. Most of the time I wasn't even at the keyboard for the integration work itself. I'd file a ticket on one side, go do something else, and come back to find the PR had already been refined, reviewed, merged, deployed, and consumed on the other side. It's kind of amazing, honestly.
Setup
The whole pipeline configuration is about 20 lines of YAML. You declare which agents exist, what events they subscribe to, what model each one runs on, and what approval gates you want. Fleet ships with starter templates for common setups: a full-stack dev team with a PO agent, a DevOps pipeline, a security review squad.
fleet init scaffolds the config. fleet watcher start turns on the reactive engine. If you've ever set up a GitHub Action, this is less complicated than that.