What wasmCloud Provides
wasmCloud's design centers on three commitments: WebAssembly as the unit of code, NATS as the unit of communication, and a lattice as the unit of deployment. Application logic is compiled to a Wasm component, signed, and pushed to an OCI registry. A wasmCloud host running on any node, whether laptop, datacenter, or edge gateway, can pull the component, instantiate it inside its sandbox, and join it to the lattice. Capability providers such as HTTP server, key-value store, and messaging broker plug into the same lattice and broker resource access on the component's behalf. The lattice is fundamentally a NATS overlay: components and providers find each other through NATS subjects, and work is distributed across hosts as the topology changes.
The advantages this stack genuinely delivers are portability, sandbox isolation, hot-swappable deployment, and the ability to compose distributed applications without writing infrastructure plumbing. It is a serious piece of secure distributed-computing engineering, and the open-source community around it is real. The distinction drawn here is not a criticism of the actor model or of wasmCloud's engineering. It is a characterization of the execution model itself: what triggers computation, and how the state that computation leaves behind is governed.
Message-Driven, Not Self-Executing
A wasmCloud component activates when it receives a message on a NATS subject it subscribes to. It processes the message, optionally invokes capability providers, optionally mutates external state through a provider-mediated key-value store, and returns a response. Between messages, the component is dormant, and the runtime need not even keep an instance resident, since components can be cold-started on demand. This is the actor model functioning as designed. It is event-driven by deliberate architectural choice, and the scaling and portability properties that make wasmCloud attractive depend on it.
Self-executing computation is a different shape. A persistent executable object that executes from its own state does not subscribe to a subject and wait. As disclosed in 19/538,221, the object carries an intent field, a context block, and a memory field, and each time a hosting execution node gives it an evaluation cycle it parses that intent, evaluates the context block against locally applicable policy, reads its own prior execution records from the memory field, and selects an action from execution, mutation, delegation, dormancy, reentry, or termination. There is no inbound message that triggers the action; the object's own resident state, evaluated locally, is the trigger. A skilled implementer could host such an object on a Wasm sandbox, and the sandbox is well suited to it, but the actor model itself does not describe this self-triggered behavior.
Capability-Based Security Without Governance Memory
wasmCloud's capability model controls what a component can reach from the outside: which HTTP endpoints, which messaging subjects, which key-value namespaces. Link definitions bind a specific component to a specific capability provider configuration, and the host enforces that binding at runtime. This is strong access governance for the boundary between a component and its environment.
This is a different layer from governance over a computational object's own state. In the memory-resident model disclosed in 19/538,221, a mutation event is a controlled modification of execution-relevant attributes that is constrained by the structural schema of the object and by policy references it carries, and every such mutation is appended to an append-only memory field so the chain that produced the current value can be replayed and audited. Capability-based security and this schema-constrained, lineage-recording mutation address different questions. The first asks what this code is allowed to reach. The second asks, given that a computational object's state changed, whether the change was admissible under the object's declared schema and whether the chain that produced the current value can be reconstructed from records carried in the object itself. wasmCloud, by design, answers the first. Memory-resident execution is built around the second.
What Memory-Resident Execution Provides
A memory-resident execution object, as disclosed in 19/538,221, is a persistent executable object built from three parts: an intent field encoding a machine-readable execution descriptor, a context block encoding identity and trust-scoped metadata, and a memory field storing an append-only execution history. Every mutation is constrained by the object's structural schema and its embedded policy references, and every mutation is recorded so lineage is preserved. Every execution cycle proceeds by local evaluation at whatever node holds the object, without a central scheduler or server to dispatch it. The object is its own execution authority, gated by its schema and its policy references rather than by an inbound message. The specification describes deployment across stateless, memory-aware, federated, edge-oriented, and agent-based environments, so a skilled implementer has a broad range of substrates on which to build it, of which a Wasm host is one.
On a wasmCloud lattice, this composition is natural. The Wasm sandbox provides the isolation, the lattice provides the host topology, and the capability model continues to gate outbound access. What the memory-resident layer adds is the object schema, the schema-constrained and lineage-recording mutation surface, and the self-triggered evaluation loop that advances the object forward without depending on the NATS message bus to wake it. The actor model is not displaced, and message-reactive components continue to make sense for many workloads. Memory-resident objects extend the picture to cover workloads where the trigger is internal state rather than external traffic.
Where wasmCloud Deployment Is Heading
As Wasm-component deployment moves into edge fleets, autonomous-system pipelines, and on-device agent workloads, the workloads that are easiest to express as message-reactive components are not the only ones operators need. Edge nodes that must keep making decisions when their uplink is intermittent, robotics and vehicle workloads where the trigger is an internal sensor-fusion state rather than an inbound RPC, and agent runtimes whose objects must self-evaluate over long horizons all push toward state-driven execution. There is a second axis alongside the trigger question: crossing trust domains. The specification describes federated execution in which a persistent executable object propagates across multiple administrative or trust domains, and execution outcomes generated in one domain are preserved in the object's memory field and can be evaluated by nodes in another domain without synchronized control or shared authorization infrastructure. A NATS lattice coordinates within an operator's own topology; carrying governed execution state and replayable lineage inside the object itself is the mechanism the memory-resident model provides for spanning domains that do not share a controller. wasmCloud's lightweight host is a strong runtime for these workloads, and what it would gain is the object schema and self-triggered evaluation loop layered above the component.
Closing
wasmCloud is a strong host for sandboxed, portable, distributed Wasm code. The actor model it implements is event-driven by design, and that design is the right one for the workloads it has historically targeted. Memory-resident execution does not contradict the actor model. It adds a sibling category of object, schema-constrained, self-triggered, and free of a required central controller, that could run on the same sandbox, the same lattice, and the same capability gating, while answering a different structural question: what triggers computation, how state mutation is governed and made replayable, and how execution continuity survives movement across trust domains.
Disclosure Scope
The invention described here, memory-resident execution of persistent executable objects, is disclosed in United States Patent Application 19/538,221. The technical claims in this article about the invention, including the intent field, context block, and append-only memory field, schema-constrained mutation with recorded lineage, local policy-bound action selection among execution, mutation, delegation, dormancy, reentry, and termination, and federated execution across trust domains without synchronized control or shared authorization infrastructure, trace to that filing and its specification. This article is a dated public disclosure tied to that application. It describes an approach in sufficient detail that a skilled implementer could build it, and it enumerates deployment variations, including stateless, memory-aware, federated, edge-oriented, and agent-based environments, rather than a single embodiment.
References to wasmCloud, WebAssembly, NATS, and the actor model are provided as external context to situate the invention against a real, well-engineered platform. Those references describe products and architectures owned and maintained by their respective projects and organizations, are believed accurate at the time of writing, and are not claims of the filing. Nothing here asserts a defect in wasmCloud; the comparison is scoped to a specific architectural axis, namely how computation is triggered and how governed execution state travels across administrative and trust domains.
