> ## Documentation Index
> Fetch the complete documentation index at: https://hexelstudio.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Fleets
> How agents are grouped with shared runtime configuration for task execution.
A fleet is a named group of agents plus runtime configuration that governs how they execute. When you submit a task, it targets a fleet, which resolves to the agents that plan and carry out the work.
## Key concepts
| Term | Meaning |
| --------------------- | ---------------------------------------------------------- |
| **Fleet** | A group of agents with shared runtime configuration. |
| **Deployment mode** | How the fleet's compute capacity is provisioned. |
| **Routing policy** | How work is distributed across agents and locations. |
| **Capacity profile** | The warm-versus-cold tradeoff for responsiveness and cost. |
| **Isolation profile** | How fleet workloads are isolated from each other. |
| **Egress policy** | What outbound network access is permitted. |
## Configuration dimensions
Each dimension controls one aspect of fleet runtime behavior:
### Deployment mode
| Value | Behavior |
| ------------ | -------------------------------------------------------------------------------------------- |
| `serverless` | Compute spun up on demand, torn down after idle timeout. Lowest cost for sporadic workloads. |
| `fluid` | Pool of capacity that scales with load. Balances cost and latency. |
| `dedicated` | Fixed, always-running compute reserved for this fleet. Guarantees zero cold-start. |
### Routing policy
| Value | Behavior |
| ---------- | ------------------------------------------------------------------------------------------------ |
| `pinned` | All tasks for a given session route to the same agent instance. Required for stateful workflows. |
| `geo` | Tasks route to the nearest region based on request origin. Minimizes network latency. |
| `failover` | Routes to a primary region; if unavailable, falls back to secondary. |
### Capacity profile
| Value | Behavior |
| --------------- | ----------------------------------------------------------------------------------------------------- |
| `cold_start_ok` | No pre-warmed instances. First request incurs startup latency (typically 2-10s). |
| `warm_pool` | Maintains a minimum pool of ready instances. Reduces cold starts for the first N concurrent requests. |
| `always_on` | Instances run continuously. Zero cold-start, highest cost. |
### Isolation profile
| Value | Behavior |
| ---------- | ------------------------------------------------------------------------------------------------------------------------ |
| `shared` | Fleet workloads share compute infrastructure with other fleets in the organization. Default for non-sensitive workloads. |
| `enhanced` | Fleet runs with dedicated isolation boundaries. Workloads from other fleets cannot access its resources. |
| `vpc` | Fleet runs in a dedicated VPC. Full network isolation including private egress. Required for regulated workloads. |
### Egress policy
| Value | Behavior |
| -------------- | ------------------------------------------------------------------------------------------- |
| `standard` | Unrestricted outbound internet access. |
| `restricted` | Outbound access limited to an allow-list of domains/IPs configured at fleet level. |
| `private_only` | No public internet access. Agents can only reach private endpoints and Hexel internal APIs. |
## Deployment mode × Capacity profile interactions
Not all combinations are valid. The deployment mode constrains which capacity profiles are available:
| Deployment mode | Allowed capacity profiles | Reason |
| --------------- | ----------------------------------------- | --------------------------------------------------------------------------------------- |
| `serverless` | `cold_start_ok` only | Serverless tears down idle compute — warm pools and always-on conflict with that model. |
| `fluid` | `cold_start_ok`, `warm_pool` | Fluid can pre-warm a pool but is not designed for permanent allocation. |
| `dedicated` | `cold_start_ok`, `warm_pool`, `always_on` | Dedicated compute supports all profiles, including guaranteed zero cold-start. |
Setting `capacity_profile: always_on` with `deployment_mode: serverless` is rejected at fleet creation. If you need zero cold-start latency, use `dedicated` or `fluid` with `warm_pool`.
## How it works
When a task targets a fleet, the platform:
1. Resolves the fleet's attached agents.
2. Applies the deployment mode to provision capacity.
3. Uses the routing policy to select where work runs.
4. Enforces isolation and egress policies.
The same agent can participate in multiple fleets with different runtime behavior, without changes to the agent itself.
## Accessing fleets
```python theme={"dark"}
fleets = client.orchestrator.fleet.list()
fleet = client.orchestrator.fleet.get("YOUR_FLEET_ID")
```
```bash theme={"dark"}
```
The SDK provides `list` and `get` only. There is no fleet update endpoint; configuration changes are made through the Console.
## Related pages
Manage fleets via SDK and CLI.
Deployment modes and routing in depth.
How work runs across a fleet.
The units a fleet groups.
## Next steps
Continue to [Tasks & Workflows](/docs/concepts/tasks-and-workflows).