One agent or a thousand.
Running one agent is a script. Running a fleet — scheduled, triggered, budgeted, watched — is infrastructure. Fleet will make the hundredth agent as easy to start as the first, with the capacity underneath governed rather than assumed.
Run a workforce, not a wall of boxes.
Going from one agent to many usually means orchestration you build and then babysit. Fleet will make that part of the deployment — start them, schedule them, cap them, and read them from one board that never leaves your network.
One or a thousand, same motion
Starting the thousandth agent should feel like starting the first — a number, not a migration. What changes at scale is the governance around them, not the way you launch one.
Schedules and triggers
Agents that wake on a cron, an event or a webhook — running when there is work and quiet when there isn't. You describe when; the fleet layer handles the waking.
Capacity governed, not assumed
A private deployment has a finite amount of hardware, so a hundred agents waking at once is a scheduling problem with a right answer. Per-agent caps, fair shares and admission control keep one workload from starving the rest.
A board, not a battle
What is running, what finished, what needs a human, what each agent spent — in one place, inside the boundary. A fleet should be something you read, not something you firefight.
Inside deployments. The furthest out.
Fleet is one piece of Deployments — Layer 03, the top of the stack. The layers beneath it are further along, and the bottom one is deployed and serving traffic inside customer boundaries today.
Scale is a governance problem before it is a scheduling one.
Who may start an agent, what it is allowed to spend, which team answers for it — the shape of a fleet is decided by those answers. If you are already planning for a hundred, we want to hear it.