Fly Machines are fast-launching VMs with direct REST and flyctl control over lifecycle, resources, and region placement. Fly documents start and stop behavior at subsecond speeds and exposes create, update, start, stop, suspend, delete, lease, and metadata operations through the Machines API.12 AgentVM deliberately sits one level higher, treating the machine as a bounded resource acquired for an agent job.3
Both products can result in a real VM. The difference is how much infrastructure policy you want to build yourself around that VM.
Fly Machines gives you the primitive
Fly Machines is designed for developers who want low-level control. A Machine belongs to a Fly App, and the platform exposes lifecycle, resources, and regional placement through both an API and flyctl.12
That is a strong foundation when your team wants to build its own scheduler, app platform, worker system, or regional orchestration logic and values direct VM control as the base primitive.
AgentVM gives you an agent-oriented policy layer
AgentVM wraps machine creation in choices and boundaries intended for agents: published plans, a maximum runtime, SSH public-key handling, managed provider credentials, machine state, expiry, and optional managed endpoint behavior.3
Instead of asking every agent integration to reconstruct those controls around a raw VM API, AgentVM makes them part of the provisioning contract.
Provider choice is handled differently
Fly Machines runs on Fly.io's platform and gives precise control within that environment.1 AgentVM is a gateway over multiple provider integrations, with Hetzner, AWS, and OVH paths represented in its compute control plane.3
That abstraction can be useful when provider selection is a policy decision or catalog choice rather than something each agent should encode directly. The tradeoff is less direct access to every provider-specific knob.
Machine payments change the provisioning handshake
AgentVM's MPP surface lets an autonomous client discover a bounded resource and handle payment as part of the HTTP exchange.4 This is aimed at workloads where infrastructure purchasing itself needs to be delegated safely.
Fly's public Machines documentation is centered on authenticated API and CLI lifecycle control.12 If your organization already owns the Fly account and orchestration layer, that may be exactly what you want.
Build on Fly, or delegate through AgentVM
Choose Fly Machines when you want a very capable VM primitive and are comfortable building the agent-specific budget, payment, identity, expiry, and policy layers around it.
Choose AgentVM when those agent-specific controls are the product requirement. The value is not merely launching a VM; it is constraining who can launch it, for how long, with which SSH identity, through which provider path, and under which payment boundary.