Execution happens outside the perimeter
Most agent platforms run the work in a vendor cloud. In a regulated business that turns an engineering decision into a security review, and the review usually lands well after the budget has been spent.
You used to manage your engineers with Jira. Now you can do the same with your agents. Fleet is the pattern and the underlying architecture for running agent work inside an organization's own environment, where the data already lives.
Most agent platforms run the work in a vendor cloud. In a regulated business that turns an engineering decision into a security review, and the review usually lands well after the budget has been spent.
One impressive run in a demo does not make a system. There is no durable state, no approval trail, no retry policy, and nobody gets told when the work stalls at two in the morning. None of it holds up in an audit.
Queue, sandbox, approval gate, source control integration, escalation. Every agentic build starts by putting the same scaffolding back up, so the first few months of a program go to plumbing instead of the work it was funded for. Build that foundation once and it carries into every engagement after it, turning a cost repeated on each project into a repeatable revenue base across clients.
Fleet is where agent work actually runs when it cannot leave the building. Other tools keep track of the work. This one does it.
You buy a packaged product, configure it inside the box the vendor drew, and use it as shipped. Fleet works differently. It is an architecture other things get built on, and a pattern we repeat from one client to the next. There is an interface, and it is the smallest part of the story. What matters sits in the layer underneath it.
Fleet asks three things of the environment it runs in: container compute, a governed model endpoint, and enterprise identity. Anywhere that offers those can host it. Snowflake is where it is built and running today. Moving it elsewhere is a port of the same pattern, not a rebuild.
Someone writes up the work the way they would write a ticket. An agent picks it up, reads the codebase, plans the change, writes it, tests it, and puts the result in front of a person. Nothing merges until somebody approves it.
Work described in plain language, with priority and scope.
An agent clones the repository and branches.
Implement, run the tests, commit.
A person reads the diff. Approve, or reject with feedback.
Approved work merges and deploys.
Nobody is trying to take the human out of the loop. Every change has a named person who approved it, and every rejection is written down with the reason. That record is what lets you defend agentic delivery when someone in compliance asks.
Fleet runs a Model Context Protocol server, so agents outside it can create work, kick it off, and read back what happened. It slots underneath the tools a business already runs instead of asking anyone to switch.
Three things are different once it is running.
Projects that were sitting behind data residency, egress, or a model provider review can move, because nothing ever leaves the account. The architecture answers the security question once, instead of you negotiating it every time.
Every merged change has a name on it. Every rejection has a reason attached. Agentic delivery stops being the thing you have to defend in review and starts being the thing with receipts.
Clearly written work runs in parallel, around the clock. What you can ship stops being decided by how many engineers happen to be free that week.
Jira, from Atlassian, is where most engineering teams keep their work: tickets, priorities, assignees, sprints, reporting. Almost every client already runs it, and Fleet is not asking anyone to give it up.
Jira does more than track work now. Atlassian's Rovo Dev takes a ticket and runs it: plans the change, updates the code, runs the tests, and opens a pull request ready to merge, all inside a sandbox Atlassian hosts. You assign an agent the same way you assign a person. That shipped broadly in May 2026.
The difference is not the feature. On features this converges, and quickly. The difference is where execution happens, what it sits next to, and how it is paid for.
| Axis | Work management platform | Fleet |
|---|---|---|
| Where code executes | Vendor managed cloud sandbox | The organization's own account, no egress |
| What the agents sit next to | Work artifacts and connected applications | The data estate, model layer, and governance |
| Customization | Configured within the product's model | We own the code, so it bends to the client |
| Cost shape | Per seat plus metered AI credits | Compute and tokens, against a build cost |
| Time to first value | Already deployed and in use | Requires an engagement to stand up |
| Reach beyond engineering | Service management, finance, marketing | Engineering and data work |
| Ecosystem | Mature marketplace and connector estate | Model Context Protocol, platform native |
| Scale behind the roadmap | A public software company | Hakkoda and IBM |
Jira leads for good reasons. It is already in the building, it works for teams well outside engineering, and its connector ecosystem has had years to mature. Fleet is not trying to win any of that. It wins on the one thing a regulated business cannot bend on, which is where the work is allowed to run.
Jira stays put. Work still gets written up, prioritized, and reported there, and none of that has to move.
Anything safe to run in a vendor cloud keeps running there. Anything touching regulated data or production pipelines goes to Fleet instead.
Model Context Protocol is the join between them. An agent on the Jira side can open work in Fleet, start it, and read back what came out.
Fleet is right for a specific set of situations. It is worth being just as clear about the ones it is wrong for.
Fleet is early. The parts it is made of are not.
There is no license and no seat price.
We stand Fleet up inside the client's environment and hand over agents already set up for their stack, their coding standards, and how they run reviews. That last part is what separates a framework from something doing useful work in the first week. We run a real workload through it before handover and leave a runbook behind.
The foundation is the accelerator. What gets built on top of it for that client is the work.
There is one question that qualifies an account: has an artificial intelligence project already stalled here because the work could not leave the account?
Detail on Fleet comes from the build itself. Everything here about Atlassian is public and dated below.