What You Are Building

You are building agents that can pick up on a second server exactly where they left off on a first one, with their working memory, their permissions, and their history intact. This is the problem behind the search that brought you here: a long-running agent needs to move from a centralized server to a federated node, or out to an edge device, and today that move loses something. Either the agent restarts cold, or you bolt on an external session store and a re-authorization step and hope the two servers agree on what the agent was allowed to do.

The people who hit this are teams running agents that outlive a single request: multi-step research agents, agents that hand work to other agents, agents that need to keep running when a device goes offline and reconnect later. What you want is not a faster copy of a session blob. You want the agent to remain the same agent across the move, provably, and to remain inside its permitted behavior the whole way.

The architecture in this guide gets there by inverting where state lives. Instead of the server owning the agent's state, the agent object owns it, and the server is just a place the agent happens to be running right now.

Why the Obvious Approaches Fall Short

The usual approaches are reasonable and widely used. They just leave a structural gap for this specific problem.

The first approach is an external session store. The agent's memory sits in a database or cache keyed by a session id, and any server can load it. This works for stateless request handlers. The gap is that the store becomes a centralized dependency and a single point of coordination, and the agent's permissions and history live somewhere other than the thing being moved. When the agent arrives on a new server, that server still has to independently decide what the agent is allowed to do, usually by re-reading policy from yet another system.

The second approach is static credentials. The agent carries a key or token, and servers trust the key. Public-key infrastructure is a mature, well-understood way to do this and it works well for many systems. The gap for a migrating, mutating agent is that a static key says nothing about whether this is the same agent that ran a hundred mutations ago on another server, or a replayed copy. The key is stable precisely when the agent is not, so it cannot by itself express behavioral continuity across the move.

The third approach is centralized orchestration: a controller that knows where every agent is and shuffles state around. This gives you a clean global view, but it makes the controller a bottleneck and a trust anchor, and it does not degrade gracefully to federated, mesh, or edge substrates where no single controller is reachable.

The common thread is that state, permission, and identity are held by infrastructure around the agent rather than by the agent. Every server boundary then becomes a place where those three things have to be re-fetched and re-agreed. The architecture below removes the boundary problem by moving those three things inside the agent.

The Architecture

The disclosed approach makes each agent a memory-bearing object with a fixed internal schema, and makes the substrate it runs on validate that object rather than depend on external session state. Everything below traces to United States Patent Application 19/230,933.

The agent is a structured object with six fields. Per the disclosure, each semantic agent carries an intent field, a context block, a memory field, a policy reference field, a mutation descriptor field, and a lineage field. Intent is the agent's semantic objective. Context describes its current environment, including which trust zone and originating substrate it belongs to. Memory is a mutable internal ledger of execution events, policy decisions, mutation results, and delegation records. The policy reference field holds one or more cryptographically signed links to policy contracts that define what the agent may do. The mutation descriptor defines the conditions under which the agent may transform itself. Lineage records ancestry: hash references to parent agents, prior mutation states, and propagation paths. Because all six travel together, the agent is self-describing: it carries everything needed to decide how it should behave and where it may go.

State moves because the object moves. The disclosure describes propagation across centralized servers, federated clusters, decentralized mesh networks, and edge substrates, with the same field structure preserved regardless of where the agent executes. Moving state between servers is therefore not a separate copy operation. It is the agent object arriving at a new substrate carrying its own memory and lineage. The transitions between substrates are described as semantic routing decisions, not physical network links: propagation eligibility is decided by evaluating the agent's own fields against the receiving substrate, not by an address lookup.

Arrival is validated, not trusted. When an agent arrives, the disclosed middleware runs it through an ordered pipeline: a semantic router reads the context field to pick a governing trust zone, a structural validator checks that the required fields are present, a policy enforcement engine evaluates the policy reference field against the active zone before any mutation or propagation, a mutation queue applies only permitted transformations and records them in memory, and a propagation interface decides eligibility to leave. Critically, the policy reference is evaluated at runtime prior to any mutation, delegation, or propagation, and the action is deterministically permitted or denied without centralized authorization or post-execution filtering. So the receiving server does not re-authorize the agent out of band. It reads the permission scope the agent brought with it and enforces it in place.

Identity is continuity, not a static key. Instead of a persistent credential, the disclosure derives a Dynamic Agent Hash (DAH) from the agent's memory field, mutation history, context, and policy references, and a Dynamic Device Hash (DDH) from the host substrate's local entropy conditions. Each time the agent mutates, the new DAH includes a reference to the host DDH at that moment, and this coupling is recorded in the agent's memory trace. This is called trust slope entanglement. When the agent lands on a new server, that server retrieves the prior DAH and DDH checkpoints from the agent's lineage and confirms that the sequence of identity states follows an acceptable trajectory. If the DAH trajectory has diverged, for example from an unauthorized mutation, or the entanglement references are missing, the agent is quarantined, rolled back, or rejected. This is how the architecture tells the same migrated agent apart from a tampered or replayed copy without any long-lived key.

Partial arrivals are recoverable. The disclosure anticipates that an agent may arrive structurally incomplete, for example after crossing a bandwidth-constrained or edge boundary. A partial agent is routed to a fallback engine that reconstructs missing fields through three stages described in the spec: contextual policy resolution infers the trust zone from remaining fields, an environmental scaffold layer supplies templates from local substrate memory, and lineage inference retrieves missing intent or mutation descriptors from parent records. The rehydrated agent is then slope-validated before it is allowed to execute, and its memory records which fields were reconstructed and how. This is what lets an agent survive a lossy move rather than being discarded.

Memory is the audit trail. Every mutation, policy decision, delegation, and zone transition is appended to the agent's own memory field as a tamper-evident, cryptographically linked record, each entry referencing a prior state, the mutation descriptor invoked, and the governing policy. The move between servers is therefore itself recorded inside the thing that moved, which is what makes the whole trajectory reconstructable after the fact.

How to Approach the Build

You are implementing this yourself. The steps below are the order the disclosed architecture implies; the sketches are illustrative and faithful to the spec, not drop-in code.

Step 1: Define the agent object schema first. Fix the six fields before anything else, because the rest of the system reads them. An illustrative shape:

Agent {
  intent            // semantic objective
  context           // zone, originating substrate, role
  memory            // append-only ledger of events + prior hashes
  policyReference   // signed links to policy contracts
  mutationDescriptor// conditions under which self-transformation is allowed
  lineage           // parent hashes, prior states, propagation path
}

Treat memory and lineage as append-only. Their integrity is what later makes identity and audit work.

Step 2: Make policy a first-class, signed object, not code. Per the disclosure, policy references are cryptographically signed contracts that the substrate evaluates deterministically at runtime. Build a policy contract format that a validator can parse and check a signature on, and that expresses mutation permissions, propagation boundaries, and override conditions. Include meta-policy contracts for the special case where an agent tries to change its own limits.

Step 3: Build the arrival pipeline on the receiving substrate. Implement the ordered stages: route by context, validate structure, enforce policy before mutation, apply permitted mutations to memory, then decide propagation. The load-bearing rule is that policy is evaluated before any mutation, delegation, or propagation, and the decision is local and deterministic. Do not add a post-hoc filter that lets an action run and then judges it; the design denies up front.

Step 4: Implement identity as a slope, not a key. Compute a DAH from the agent's memory, mutation history, context, and policy references. Compute a DDH from host-local entropy on each substrate. On every mutation, fold the current host DDH into the new DAH and record the pair in memory. On arrival, validate the DAH/DDH sequence from lineage against an acceptable trajectory before authorizing execution. Decide your acceptance bounds explicitly, since the spec makes trajectory acceptability a policy-, zone-, or prior-state-defined threshold rather than a fixed constant.

Step 5: Implement fallback rehydration for lossy moves. Before rejecting a structurally incomplete arrival, run the three recovery stages: infer the zone from context and lineage, scaffold missing fields from local templates, and pull missing fields from parent records via lineage. Slope-validate the reconstructed agent before it executes, and write back which fields were reconstructed.

Step 6: Choose your trust zone boundaries. Zones in the disclosure are logical governance domains, not physical partitions, defined by semantic class, organizational context, or regulatory scope. Decide where your policy boundaries lie and instantiate zones there. For contested mutations, the spec provides for validator quorum and escalation to a meta-policy layer; implement quorum only where you actually need multi-party agreement, since single-substrate enforcement is the common path.

Step 7: Make routing semantic. Move agents by evaluating their fields against the destination substrate's governance profile, memory capacity, and slope continuity, rather than by address. A move succeeds only when policy is compatible and slope continuity holds; otherwise the agent is retained for rehydration or reconciliation.

What This Does Not Give You

This is an architecture, not a package. There is no SDK to install and nothing here "just works" out of the box. You implement the schema, the pipeline, the identity derivation, and the policy format yourself, and the design choices left open in the disclosure, such as slope acceptance thresholds, entropy sources for the DDH, quorum sizes, and the concrete policy contract format, are yours to make and get right.

It is a disclosed architecture, not a benchmarked or productized system. The filing describes how the mechanisms are structured and why; it does not supply performance numbers, and this guide does not claim throughput, latency, or scale figures. Do not treat any part of this as production-proven simply because it is described here.

It also does not replace your transport or storage. Agents still run on real servers with real networks and real memory; the architecture governs how state, permission, and identity travel with the agent, not how bytes physically cross the wire. And it is aimed at stateful, mutating, long-lived agents that cross trust or substrate boundaries. If your agents are short-lived, single-server request handlers, a conventional session store is simpler and this machinery is more than you need.

The security properties depend entirely on your implementation. Slope validation, signed policy contracts, and tamper-evident memory are only as strong as the entropy sources, signature verification, and append-only guarantees you actually build. The architecture describes the structure; it does not certify your instance of it.

Disclosure Scope

The architecture described in this guide is disclosed in United States Patent Application 19/230,933. This guide is educational. It explains how the disclosed approach is structured so that a developer can understand and build toward it, and every mechanism described above is grounded in that filing. It is not a warranty, a specification of a shipping product, or an offer of software, and nothing here should be read as a guarantee of performance, security, or fitness for any purpose. You are responsible for your own implementation and its behavior.