Vendor and Product Reality
Dapr originated at Microsoft, was donated to the CNCF, and has reached graduated status. Its architecture attaches a sidecar process to each application instance and exposes a uniform HTTP/gRPC API for cross-cutting concerns: pub/sub messaging across pluggable brokers, state management across pluggable stores, service invocation with mTLS and retries, input/output bindings to external systems, virtual actors with single-threaded turn-based execution, secrets retrieval, and a workflow engine for durable orchestrations. Components are configured through Kubernetes CRDs (or YAML in self-hosted mode); the sidecar reads the configuration and exposes the configured backends behind the uniform API.
The value proposition is real. Application code calls a single API for state regardless of whether the underlying store is Redis, Cosmos DB, or Postgres. Pub/sub topics decouple producers from brokers. The actor model gives developers a familiar single-instance-per-id execution semantic without forcing them to manage placement or persistence. The sidecar pattern keeps language-specific SDKs thin and portability genuine. For teams building polyglot microservices on Kubernetes, Dapr removes a category of plumbing.
The architectural question this article addresses is not whether the sidecar pattern works. It does. The question is where the rules that govern a given piece of state live, and what travels with the state when it moves between sidecars, between clusters, or between organizations.
Architectural Gap: Rules and Policy Are Server-Side
In Dapr, a piece of state is a value associated with a key under a configured store. The rules that govern that value, which services may read it, which may write it, what consistency model applies, what TTL applies, what retry policy applies, which subscribers receive notifications when it changes, are encoded in the component CRD, in resiliency policies, in access-control policies, and in the sidecar's configuration. The sidecar consults its configuration and applies those rules. The state does not carry the rules. The runtime carries them.
The same pattern holds for pub/sub: subscriptions, topic-level access control, and retry behavior are configured at the sidecar; the messages do not carry their own subscription policy. It holds for actors: placement, reminders, and concurrency are runtime concerns. It holds for workflow: the durable orchestration logic is code deployed to the runtime, and the data the workflow manipulates flows through the orchestrator without carrying its own evaluation.
For application development this is a sensible split. For governance it produces the same gap that broker-side workflow engines produce: the audit and authority story is a property of the runtime's configuration, not a property of the state. When state moves between Dapr instances, across clusters, across tenants, across organizations, it does not carry the policy under which it was written. Whatever sidecar receives it next applies whatever rules its own configuration encodes. Continuity of governance depends on operational discipline at every receiving runtime.
A second consequence is that Dapr services are request-driven. The state sits in its store. The actor sits idle until a message activates it. The workflow advances when an event arrives. None of these execution models include a self-evaluation cycle in which the state itself decides whether conditions warrant action. The execution model is "wait to be told." For microservice request/response work this is correct. For state that should evaluate itself, that should detect that a condition has been met and act on it, there is no native primitive in Dapr that performs that evaluation as a property of the state object rather than as a property of code running elsewhere.
What Memory-Resident Execution Provides
Memory-Resident Execution, as disclosed in United States Patent Application 19/538,221, treats the state object as a persistent executable object rather than a passive value. The object is structured around three embedded fields: an intent field encoding a machine-readable execution descriptor, a context block encoding identity, trust-scope, and execution-relevant metadata used for localized policy evaluation, and an append-only memory field recording execution traces, mutation records, delegation references, and policy outcomes. At each execution node that receives the object, an execution evaluation cycle parses the intent field, evaluates the context block against locally applicable policy without reliance on centralized coordination, reads the prior execution records from the memory field, and selects an execution action from a defined set: execution, mutation, delegation, dormancy, reentry, or termination. The outcome is appended to the memory field. The runtime hosts the object and supplies scheduling, persistence, and messaging, but does not own the rules that determine what the object does. The rules ship with the state.
A skilled implementer could build this on top of a runtime such as Dapr. The persistent executable object is a serializable structure (JSON, protobuf, or an equivalent schema) with the three fields above; the evaluation cycle is a deterministic or rule-based state machine, and the spec is explicit that no probabilistic model or language model is required to achieve execution continuity, though an inference engine may participate as an advisory execution node whose recommendation is recorded as an outcome without itself authorizing execution. Policy references are evaluated by a local policy evaluator at each node; memory entries carry a trace identifier, timestamp, origin node identifier, policy reference, outcome descriptor, and a cryptographic signature. The spec enumerates deployment modalities including stateless, memory-aware, federated, edge-oriented, and agent-based execution environments, and execution behaviors including semantic mutation of intent, recursive delegation into a distributed execution graph, dormancy with policy-governed reentry, autonomous polling with semantic backoff, and self-termination on a terminal condition. These variations are disclosed as embodiments, not as the only implementation.
Two consequences follow. First, governance is portable. When the object moves, to a different sidecar, a different cluster, a different organization, the policy moves with it. The receiving runtime cannot widen the object's authority by virtue of having a more permissive configuration; the object admits its own actions against its own credentialed policy regardless of host. Lineage of state transitions is recorded against the same policy, producing an audit trail that is intrinsic rather than configuration-dependent.
Second, execution is intrinsic rather than triggered. The object self-evaluates. It does not require an external event to decide to act. A condition embedded in its policy fires when its data satisfies the condition; the resulting action is itself admitted against the policy and recorded against the lineage. Request-driven invocations remain available, the object can still respond to messages and HTTP requests, but they are not the only path by which the object acts.
Composition Pathway With Dapr
The composition with Dapr is layered. Dapr's state stores remain the persistence substrate; memory-resident objects use Dapr's state API to persist themselves between cycles. Dapr's pub/sub remains the messaging substrate; objects emit policy-admitted events through the configured broker. Dapr's actor model provides a natural placement substrate for memory-resident objects, with the addition that the actor's behavior is not a code class deployed to the runtime but a policy structure carried by the object itself. The actor framework hosts the object; the object decides what to do.
The execution cycle is supplied by an evaluator that runs alongside the Dapr sidecar, either as an additional sidecar or as a Dapr extension, and that periodically (or event-triggered) wakes each hosted object, hands it its state and its policy, and admits any actions the object proposes. Admitted actions flow back through Dapr's API surface: state writes through the state API, messages through pub/sub, external calls through bindings and service invocation. The infrastructure value Dapr provides is preserved. The authority over what each object does becomes a property of the object.
Dapr's workflow building block becomes a special case. Where today the orchestration logic is deployed code, in the composed architecture the orchestration is a memory-resident object whose policy encodes the workflow. The workflow's authority travels with the workflow; the runtime executes it without owning it.
Commercial and Licensing Posture
Dapr is open source under CNCF stewardship; commercial momentum sits with vendors who package, distribute, and support Dapr distributions, Diagrid being the most prominent, and with platform teams at large enterprises that have standardized on Dapr for polyglot microservice fabrics. The commercial story is portability and developer productivity. The exposure is the same exposure visible across the runtime category: as governance obligations migrate from "what the system did" to "under what authority each unit of state acted," configuration-side authority becomes structurally insufficient, and the runtimes that ship rules with state will be the runtimes that meet the obligation natively.
Adopting Memory-Resident Execution as the layer above Dapr's building blocks converts the exposure into a position. Dapr's portability story is preserved and extended: not only does the application code travel across stores and brokers, the governance of each piece of state travels with it. The composition pathway preserves the investment that platform teams have already made in Dapr as the runtime substrate for distributed applications. Existing CRDs, existing component manifests, existing pub/sub topologies, and existing actor placements continue to function; the addition is that the state hosted on top of those substrates carries its own governing rules and its own evaluation cycle, so that the question "under what authority did this state change" has a structural answer rather than a configuration-dependent one.
Disclosure Scope
The inventive step described here, Memory-Resident Execution of persistent executable objects, is disclosed in United States Patent Application 19/538,221. The claims of that filing govern its scope. This article is a dated public disclosure of the approach: a persistent executable object carrying an intent field, a context block, and an append-only memory field, evaluated locally by each execution node through parse, policy evaluation, memory read, action selection from the set of execution, mutation, delegation, dormancy, reentry, and termination, and outcome recording, without centralized coordination or shared authorization infrastructure. The embodiments and variations enumerated above, including stateless, memory-aware, federated, edge-oriented, and agent-based deployment modalities, are disclosed to enable a skilled implementer to build the approach.
All statements about Dapr, its architecture, the Distributed Application Runtime, its sidecar model, its building blocks, its CNCF status, and its commercial ecosystem including Diagrid, are provided as external context describing a real, independently developed system, drawn from Dapr's public documentation and architecture. They describe what Dapr is and does well and scope the comparison to a single architectural axis: where the rules that govern a unit of state reside. Nothing in this article is a claim of the referenced filing about Dapr, an assertion of a defect in Dapr, or a statement made on behalf of Dapr, Microsoft, the CNCF, or Diagrid. Dapr is used here under its own name solely for accurate identification and comparison.
