Fleet · Agent execution
The pattern

Manage your agents
the way you manage your engineers.

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.

01

Why agentic delivery stalls

01

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.

02

Demonstrated, not operated

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.

03

The same foundation is rebuilt every time

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.

02

What Fleet is

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.

Application layer
What gets built on top. Each one is a different job for the same underlying machinery.
Software ticket execution Pipeline remediation Semantic model maintenance Migration and conversion work Governance and policy tasks Add yours
Execution layer · This is Fleet
The parts every agentic build needs anyway, built once and reused. This layer is where the value sits.
Pre-configured agent roles Durable work queue with state Agent execution sandbox Human approval gate Retry and escalation policy Branch, diff, merge Model Context Protocol interface
Platform layer
The environment it lives in. It supplies the compute, the models, the identity, and the data the agents work against.
Snowflake account Snowpark Container Services Cortex model layer Snowflake roles and single sign on Databricks AWS

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.

03

How it works

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.

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.
The approval gate

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.

Open to other agents

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.

04

What Fleet changes

Three things are different once it is running.

Change 01

Work that could not run, runs

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.

Change 02

Agent output becomes auditable

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.

Change 03

The backlog moves without headcount

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.

05

Fleet and Jira

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.

AxisWork management platformFleet
Where code executesVendor managed cloud sandboxThe organization's own account, no egress
What the agents sit next toWork artifacts and connected applicationsThe data estate, model layer, and governance
CustomizationConfigured within the product's modelWe own the code, so it bends to the client
Cost shapePer seat plus metered AI creditsCompute and tokens, against a build cost
Time to first valueAlready deployed and in useRequires an engagement to stand up
Reach beyond engineeringService management, finance, marketingEngineering and data work
EcosystemMature marketplace and connector estateModel Context Protocol, platform native
Scale behind the roadmapA public software companyHakkoda 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.

Together, 01

The tracker stays

Jira stays put. Work still gets written up, prioritized, and reported there, and none of that has to move.

Together, 02

Execution routes by sensitivity

Anything safe to run in a vendor cloud keeps running there. Anything touching regulated data or production pipelines goes to Fleet instead.

Together, 03

The two connect programmatically

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.

06

Where it fits

Fleet is right for a specific set of situations. It is worth being just as clear about the ones it is wrong for.

Fits
  • They are already on Snowflake and growing on it
  • An artificial intelligence project has already been blocked over data residency, egress, or a model provider review
  • They work in healthcare, financial services, energy, or government
  • A backlog full of repetitive, clearly specified data platform work
  • An agent pilot that worked and then stalled on the way to production
Does not fit
  • They want a tool they can license and run themselves
  • The need is coordinating work across teams, not executing it
  • There is no governed platform for it to live in
  • It has to be live next week with nobody engaged to build it
  • The conversation keeps coming back to seat count
07

What is proven

Fleet is early. The parts it is made of are not.

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, including with a major airline, and more clients have asked about it. We can name them once they say yes.
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. We are working out build cost, who maintains it, and compute against what seats and credits actually cost, to find where the lines cross.
08

What a client buys

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?

09

How to talk about it

Q
Why not just use Jira?
A
Most clients will keep it, and they should. Jira is where the work is tracked. Fleet is where work runs when it cannot leave the account. They connect. They are not fighting over the same job.
Q
Atlassian already has agents. What is different here?
A
Where they run, and what they run next to. Rovo Dev works inside Atlassian's cloud, on tickets and documents. Fleet works inside the client's own account, next to the data, the governance layer, and the semantic models. That is a different job, in a place Atlassian does not go.
Q
Is this a licensed product?
A
No, and there is no seat price. Fleet is the foundation underneath a build. What a client pays for is the engagement that stands it up and the work that runs on it afterward.
Q
Is it cheaper?
A
The cost works differently, which is not the same as always being lower. Seats and credits scale with headcount and usage. Fleet costs compute and tokens on infrastructure the client already pays for, against a build cost a licensed product does not have. We are working out where those lines cross.
Q
Where does it stand today?
A
Engagements are underway, including with a major airline, and more clients have asked. We can name them once they approve it. Separately, every part Fleet is made of is already running somewhere in production. IBM Consulting has orchestrated agents working client engagements today, and Hakkoda has applications live inside client Snowflake accounts.
10

Three key takeaways

01
The blocker is location, not capability.
Clients already want agentic delivery. What stops them is that the work cannot leave their account. Fleet runs it inside.
02
Everyone will have agents. Not everyone can run them next to the data.
Everyone gets to feature parity, and fast. Where the work runs, and what it runs beside, is the part nobody can copy.
03
You do not buy Fleet. We stand it up with you.
It goes into the client's environment with agents already set up for their stack. The foundation is the accelerator. What gets built on it is the engagement.
11

Sources

Detail on Fleet comes from the build itself. Everything here about Atlassian is public and dated below.