The comparison in one line
Fly Machines is one of the fastest publicly available VM substrates in production, and it is orchestrated: the Fly.io control plane holds a Machine's lifecycle and scheduling, and the Fly Proxy routes requests to it, including waking a suspended or stopped Machine on demand. Memory-resident execution, disclosed in United States Patent Application 19/538,221, moves the parts that decide whether and how a unit of work runs out of an external control plane and into the executable object itself. This is not a claim that Fly Machines is deficient. It is a comparison on a single architectural axis: where execution continuity, eligibility, and governance physically reside.
What Fly Machines is, described fairly
Fly Machines is the execution primitive behind Fly.io's Apps v2 platform. Described at the architecture level:
- Each Machine is a Firecracker-based micro-VM, giving hardware-level isolation rather than shared-kernel container isolation.
- Machines are created, started, stopped, suspended, and destroyed through the Machines API and the Fly.io control plane, which schedules them onto worker hosts across regions.
- The Fly Proxy is an anycast edge layer that routes incoming traffic and can start a stopped or suspended Machine when a request arrives, enabling scale-to-zero and fast resume.
- Persistent state is attached through Fly Volumes (NVMe-backed) or external data services; a Machine's local disk is tied to the host it runs on.
- Startup is fast for a VM: cold starts and resume-from-suspend are typically in the hundreds of milliseconds rather than the multiple seconds a full OS boot would take.
These are real strengths. For running standard server workloads with strong isolation and near-container startup, Fly Machines is an excellent fit, and much of what follows is not a criticism of it for that job. The point is only that the Machine is an orchestrated container of a workload; it is not itself a self-governing unit of work whose continuity rules travel with it.
The axis the patent application draws
The 19/538,221 disclosure describes a persistent executable object: a memory-resident object carrying three fields (per the specification):
- an intent field encoding a machine-readable execution descriptor,
- a context block encoding identity, trust-scope, and execution-relevant metadata, and
- a memory field storing an append-only execution history of traces, mutations, delegations, and policy outcomes.
The object propagates among execution nodes. At each node that receives it, an execution evaluation cycle parses the intent, evaluates the context block against locally applicable policy "without reliance on centralized coordination," reads the memory field for prior records, and selects one action from a fixed set: execution, mutation, delegation, dormancy, reentry, or termination. The outcome is appended to the memory field. Continuity across lifecycles is preserved by that field, not by any node or scheduler.
Three consequences of that design mark the axis against an orchestrated micro-VM model:
Where the lifecycle lives. A Fly Machine's start/stop/suspend/resume transitions are decided by the control plane and Proxy. In the disclosed model, transitions including dormancy and reentry are selected by the object from its own state under locally applied policy. Dormancy in the specification is "a first-class execution state," a deliberate execution decision distinct from failure or termination, with reentry conditions the object carries.
Cross-domain continuity without a shared controller. The specification's federated-execution embodiment states that a semantic object can propagate across "multiple administrative or trust domains," where each domain evaluates it under local policy and outcomes generated in one domain are preserved in the memory field and readable by nodes in another "without requiring synchronized control or shared authorization infrastructure." A Machine, by contrast, is bound to one operator's control plane; continuity across a trust boundary is an integration problem solved outside the workload.
Governance carried in the object. Policy references travel inside the object and are evaluated by a local policy evaluator at each node "without reliance on centralized authorization servers, shared registries, or global trust authorities" (per the specification). The same object can therefore be authorized differently at different nodes, and each decision is recorded as an auditable trace. The disclosure also separates cognition (advisory reasoning), authority (policy evaluation), and execution (state transformation) so that a reasoning component cannot unilaterally authorize or mutate execution state.
None of these is a feature the Machines primitive is trying to provide. A micro-VM is deliberately a neutral compute box; the orchestration lives above it. The disclosed invention relocates the orchestration into the unit of work.
Where the two compose rather than compete
The comparison is an architecture-of-control comparison, not a substitution claim. The specification is explicit that its execution semantics are deployment-agnostic and run across "stateless," "memory-aware," "federated," "edge-oriented," and "agent-based" environments without changing. A persistent executable object needs somewhere to actually run its evaluation cycle. A Firecracker micro-VM is a perfectly reasonable execution node for that: strong isolation, fast resume, regional placement. In such a deployment Fly Machines supplies isolated, fast-resuming compute, and the memory-resident object supplies the continuity, cross-domain lineage, and object-carried governance that the compute substrate does not model. The invention is defined by where execution state and authority live, not by any particular host.
Why this is worth stating precisely
For teams whose workloads must resume across operators, edge sites, or trust boundaries, and must carry their own audit trail and policy envelope, the relevant question is not "how fast does the VM start" but "does continuity survive when the orchestrator changes." An externally orchestrated micro-VM answers the first question extremely well. Memory-resident execution is aimed at the second: the object remains "valid, addressable, and evaluable" across asynchronous intervals and heterogeneous nodes because its history and eligibility are intrinsic to it.
Disclosure scope
The technical approach described here, namely a persistent executable object carrying an intent field, a context block, and an append-only memory field, evaluated locally at each execution node to select among execution, mutation, delegation, dormancy, reentry, and termination without centralized coordination, is disclosed in United States Patent Application 19/538,221 ("Memory-Resident Execution of Persistent Executable Objects in Distributed Computing Systems"). Enumerated embodiments include stateless, memory-aware, federated, edge-oriented, and agent-based deployments; deterministic rule-based and probabilistic-inference execution nodes; single-object and multi-object (delegation, lineage, swarm) configurations; and object-resident or node-computed reentry conditions, among others. A skilled implementer can build the approach from the specification: define the object schema, serialize it for propagation, and implement per-node parsing, local policy evaluation, action selection, and append-only outcome recording.
All statements about Fly Machines, Fly.io, the Fly Proxy, and Fly Volumes are external context describing a third party's publicly documented architecture, provided for comparison only. They are not claims of United States Patent Application 19/538,221, are not endorsed by or affiliated with Fly.io, and reflect that platform's general architecture at the level described; they may change as that product evolves. Nothing here asserts a defect in Fly Machines, which is a capable micro-VM platform for the workloads it targets.
