Fleet is essentially an engineering organization in a box. It allows teams to articulate work in plain language to agents. These agents analyze requests, create tasks, and execute on the work to be performed. On a higher level, the system provides visibility into all of it: what work needs to be done, what is in flight, and what has been completed.
01
What Fleet is.
Fleet is a centralized development environment that provides a single execution layer for teams to run agents and get work done.
Fleet serves as an architectural foundation for agentic work. It has been built, and can now be configured and resold across multiple clients.
02
What it does.
Fleet allows teams to collaborate, perform collective work, and run agent orchestration under one roof. A human, tech savvy or non, conveys the work they need done in plain language. An agent picks it up, reads the codebase, plans the change, writes it, tests it, and puts the result in front of a person for approval.
03
What it solves.
Problem
Why it halts work
What Fleet does
The same scaffolding, rebuilt
No foundation
Fleet is machinery we have already built. Each engagement configures it rather than starting from scratch.
Everyone runs their own agents
No shared view
Five engineers in Claude Code, and one is moving fast in a direction the other four cannot see. Fleet puts the work in one place and surfaces what each agent produced.
AI bought per seat
No cost control
Individual tools spread across the organization with no ceiling and no reporting. Fleet shows token cost per decision and per project.
Governance after the fact
No proof
All work has a named approver and an audit trail. Every rejection has a written reason. That record is what defends agentic delivery in compliance review.
04
How it works.
01
Create
Work described in plain language, with priority and scope.
02
Launch
An agent clones the repository and branches.
03
Execute
Implement, run the tests, commit.
04
Review
A person reads the diff. Approve, or reject with feedback.
05
Merge
Approved work merges and deploys.
On rejection
The agent picks the work back up carrying the reviewer's notes, so it is not starting over from nothing.
On failure
Three automatic retries. After that it goes to a person, flagged as stalled.
Throughput
Work runs in parallel, each item on its own branch, none of them waiting on the others.
05
Requirements.
Fleet needs three things from a platform. Any platform with those three can host it. Pattern travels. Nothing gets rebuilt.
Requirement
In plain terms
Why it matters
Container compute
Somewhere to run code
Agents need an isolated place to clone a repository, make changes, and run tests without touching anything else.
Governed model endpoint
A model API the platform controls
The models are reached through the platform's own controls, so calls never leave for a third-party service.
Enterprise identity
The company's existing logins and permissions
Agents run as a user and inherit that person's access. No separate key with permissions nobody granted.
06
The architecture.
Request enters the queue. An agent runs it in a sandbox against the client platform. A person approves. Approved work merges. All of it inside the client account.
07
What it connects to.
Fleet has chat and work tracking built in. A team can run it without Jira, Slack, or anything else. Nothing has to be bought or wired up first.
Where a client wants to keep the tools they already have, Fleet connects through the Model Context Protocol server. A ticket in Jira becomes a request in Fleet, and what the agent produced reads back into the ticket. Neither side changes. The same holds for Slack, GitHub, or any other trusted system.
Built in
Chat
Work tracking
Agent execution and sandbox
Human approval gate
Audit record and cost reporting
Connects to, if wanted
Jira
Slack
GitHub
Any system reachable over MCP
Agents running outside Fleet
Integration is a choice rather than a dependency. As Fleet takes on more of the work, a client may find a license they no longer need.
08
What changes.
Old world
Seam
New world
Who can file work
Engineers, in a ticket queue
Work waits on someone who can write the code.
Who can file work
Anyone
Technical and non-technical people file requests in plain language. Agents pick up requests, execute, and hand back a result for review.
Defensibility
Explain it in review
Agent output arrives with nothing attached. Compliance takes your word for it, or does not.
Defensibility
Outputs are auditable
Every merged change has a name on it. Every rejection has a reason attached. Agentic delivery arrives with receipts.
Visibility
Five people, five directions
Agent work happens in private. Nobody sees what anyone else is running.
Visibility
One shared view
What needs doing, what is in flight, what is done. Agent outputs surface where the team can see them.
Throughput
Gated on headcount
What ships is bottlenecked by engineer availability.
Throughput
Backlog moves without headcount
Clearly written work runs in parallel, around the clock.
09
What a client buys.
No license and no seat price. Fleet is stood up inside the client's environment and agents are configured for their stack, their coding standards, and how they run reviews.
Their repositories, coding standards, and review process, not a generic starting point.
A proven workload
Run before handover
Real work through the full loop, so day one is not a first attempt.
A runbook
Left behind
How to operate it, extend it, and hand it to the next team.
Cost
Build plus compute
Compute and tokens on infrastructure they already pay for, against a build cost a licensed product does not have. Token cost is visible per decision and per project. Where the lines cross is still being worked out.
The foundation is the accelerator. What gets built on top of it for that client is the work.
10
Where we are at.
Proven
Agentic execution at enterprise scale.IBM Consulting has orchestrated agents running against production work at airlines, hospitals, telecoms, and consumer goods companies, with the results on the record.
Proven
Applications built and run inside Snowflake.Hakkoda has put public facing applications into production on Snowpark and Streamlit, inside client accounts, in a matter of weeks.
Proven
Automation that returns engineering hours.Pipeline and framework work at healthcare and consumer goods clients, with confirmed numbers behind it.
In motion
First client deployments.Engagements are underway, with more clients asking. Names once they approve.
Pending
Instrumented throughput.We measure execution volume on the first production workload. No numbers go out before that measurement exists.
In modeling
Total cost of ownership.Build cost, who maintains it, and compute against what seats and credits actually cost, to find where the lines cross.
11
Three takeaways.
One execution layer for the whole team.
Work runs in one place instead of five people running agents privately. Collaboration replaces silos, and projects stop drifting apart.
The machinery has been built.
Fleet is configured per client rather than built from scratch. Each engagement tunes it to the client's stack, coding standards, and review process, so the first weeks go to their work.
Every decision carries a name and a cost.
Named approver, written reason for each rejection, and token spend visible per decision and per project. That record is what makes agentic delivery defensible.
Detail on Fleet comes from the build itself. Everything about Atlassian is public: Rovo Dev in Jira, Atlassian, April 2026. Rovo in Jira AI features, Atlassian, July 2026. Team '26 Teamwork Graph and agentic execution, SiliconANGLE, May 2026.
Jira list pricing is not quoted here. Verify against Atlassian directly before any figure goes into a deck.
Client names in section 10 are withheld pending approval. Section 08 claims come from the platform engineering lead and are not yet validated against the proof library.