Multi-Turn Memory Isolation

Mechanism

Each time a skill is invoked, the cognitive architecture allocates a fresh memory region bound to that specific invocation. The region holds the skill's working state for the duration of its execution, including its prompt buffers, tool-call traces, intermediate scratch values, and any structured outputs that have not yet been committed to the agent's canonical fields. The region is typed by the skill's manifest, which declares the expected shape of its working state, and is sized according to the skill's declared maximum footprint.

Address resolution within the region is performed through a region-local handle table rather than through global pointers. A handle issued inside region R cannot be dereferenced outside R, because the dereference operation requires the caller to present R's region key, and that key is held only by the skill instance whose invocation R was allocated for. This is the structural property the patent specification calls handle locality: a leak path can exist only if a region key escapes, and the architecture's type system prevents region keys from being copied into any field whose type is not itself region-scoped.

When the skill instance terminates, whether by normal completion, by error, or by external cancellation, the region is released through a deterministic teardown sequence. The teardown unbinds every handle issued from the region, zeroes the underlying storage, and returns the storage to the allocator. There is no reachability analysis, no mark-and-sweep, no asynchronous finalizer queue. The teardown completes synchronously before the skill's terminating event is recorded in lineage, which means the lineage record itself is the proof that cleanup occurred.

Cross-region communication, when intentional, is mediated through the agent's canonical fields. A skill that wishes to publish a result writes it into a typed canonical slot via the mutation engine, which performs validation and arbitration before any other skill or any subsequent invocation can read it. The canonical slot is not a memory region; it is part of the agent's persistent state and lives outside the per-invocation regions. A skill that wishes to consume a prior result reads it from the canonical slot at entry, copying the value into its own region. There is no mechanism, and no need, for one region to read another's storage directly.

The structural impossibility of cross-skill leakage follows from three properties operating in combination: regions are allocated per invocation rather than per skill class, region keys are type-scoped and unforgeable, and teardown is synchronous with the invocation's terminating event. Defeating any one property would require a corresponding violation of the cognitive architecture's type system, which is itself the artifact protected by the patent.

Operating Parameters

The first parameter is the per-skill region budget. The policy reference declares, for each registered skill, a maximum memory footprint that the region allocator will honor. Skills that exceed their budget are terminated with an out-of-region fault, which is a recoverable lineage event rather than a process crash. The budget enables capacity planning at the policy level: an operator can compute the worst-case memory pressure of a given skill mix without examining the implementation of any individual skill.

The second parameter is the region-key scoping rule. By default, region keys are scoped to the invocation, meaning they cannot escape the skill instance even into its caller's frame. The policy may relax this to invocation-tree scoping, in which a parent skill's region key is visible to any sub-skill it spawns, enabling the sub-skill to write directly into the parent's region for performance-sensitive cases. Relaxation is per-skill and is recorded in the skill's manifest, so any change in scoping rule is visible in lineage and reviewable in audit.

The third parameter is the teardown discipline. The default is zero-on-release, in which the underlying storage is overwritten before being returned to the allocator. The policy may select a stronger discipline, multi-pass overwrite, for skills handling sensitive material, or a weaker discipline, no-overwrite, for trusted skills where the performance cost of zeroing is unacceptable. The discipline is per-skill and, like region budget, is part of the manifest.

The fourth parameter is the cancellation latency target. When an external signal cancels a running skill, the teardown sequence must complete within a declared bound. The bound is enforced by the architecture, not by the skill, and is achievable because teardown does not depend on the skill's cooperation: the region allocator can always reclaim a region by tearing down its handle table independently of whether the skill's code is still running. Skills that hold external resources are required by their manifest to register release callbacks, which are invoked synchronously as part of teardown.

The fifth parameter is the lineage detail level. By default, region allocation and release are recorded in lineage as discrete events, with timestamps, sizes, and skill identifiers. The policy may elevate this to include per-handle traces for forensic analysis or reduce it to aggregate statistics for high-throughput deployments. The detail level affects only what is recorded, not what occurs; the structural guarantees are independent of how thoroughly they are observed.

Alternative Embodiments

In a single-process embodiment, regions are implemented as arenas within the agent's address space, with handle tables backed by sparse arrays and region keys backed by capability tokens enforced by a runtime check. This is the lightest-weight implementation and is appropriate for embedded agents and edge deployments where process isolation overhead is unacceptable.

In a process-per-region embodiment, each skill invocation runs in its own operating-system process, with the region implemented as the process's heap and teardown implemented as process termination. This embodiment provides the strongest isolation, since handle dereferences across regions become inter-process operations that the operating system itself refuses, but at the cost of process-creation latency on every invocation.

In a container-per-region embodiment, regions are containerized environments with strict resource limits and ephemeral filesystems. This embodiment is appropriate when skills invoke external tools whose side effects must be scoped to the invocation: any file written by the skill exists only within its container and is destroyed at teardown. The cognition patent contemplates hybrid configurations in which most skills run in arenas and high-risk skills run in containers, with the choice declared per-skill in the manifest.

In a distributed embodiment, regions can be allocated on remote hosts, with the handle table implemented as a distributed capability table and teardown coordinated through a two-phase protocol. This embodiment is used when the agent's compute and memory budget exceed what any single host can provide, and the structural guarantees of region isolation are preserved across the distribution by ensuring that region keys never appear in network payloads, only their handles.

A further embodiment binds the region not to a single skill invocation but to a multi-turn dialogue session, with each turn allocating a sub-region within the session's parent region. Turn-level sub-regions are torn down at end-of-turn while the session-level region persists until session end, enabling deliberate carry-over of dialogue state without permitting accidental carry-over of intermediate computation.

Composition With Other Mechanisms

Memory isolation composes with the embodied skill gating mechanism by ensuring that capability evidence consulted during a gate evaluation is scoped to the invocation that consults it. A body-side proof read by skill A's gate cannot be cached in skill B's region, because the read produces a value typed to skill A's region; transmission to skill B requires republication through a canonical field, which is observable in lineage.

Memory isolation composes with the agent's lineage recorder by giving every region a unique identifier that becomes part of the lineage entry for every event that occurred within it. Forensic reconstruction of an agent's behavior can therefore proceed at region granularity, distinguishing events of one invocation from events of another even when they involve the same skill class.

Memory isolation composes with the multi-LLM arbitration mechanism by ensuring that competing proposals from different LLMs are evaluated in disjoint regions. There is no shared scratch space in which one LLM's intermediate reasoning could influence another's, which is the structural counterpart to the arbitration engine's logical guarantee that proposals are evaluated independently.

Prior-Art Distinction

Conventional LLM agent frameworks share a single working-memory buffer across turns and across skill invocations within a turn, relying on prompt-engineering conventions and post-hoc summarization to manage contamination. Under that arrangement, residual context from a prior invocation routinely affects the next, and the only available remedies are heuristic: clear the buffer, rewrite the prompt, or hope that the next invocation's context dominates. The disclosed mechanism replaces the heuristic with a structural guarantee: the next invocation begins in a region that is allocated empty, and the prior invocation's storage has been zeroed before reuse.

Garbage-collected language runtimes provide a form of automatic cleanup but do not provide isolation. A handle to one invocation's working state remains valid as long as any reference to it exists, and the very flexibility of the runtime makes leak paths difficult to rule out. The disclosed mechanism's region-keyed handle table makes leak paths a type error rather than a runtime contingency.

Operating-system process isolation, taken on its own, addresses cross-process leakage but does not address cross-invocation leakage within a single agent process, which is the dominant configuration for latency-sensitive deployments. The disclosed mechanism provides isolation at invocation granularity regardless of whether invocations share a process, a container, or a host, because the isolation property derives from the type system that holds the region keys rather than from the operating-system boundary that contains them. Conversely, where process isolation is desired, the architecture admits it as the process-per-region embodiment without changing the abstract guarantee.

Vector-database session memory and retrieval-augmented generation systems sometimes claim isolation by purging conversational context at session boundaries, but the purge is a behavioral convention rather than a structural property: nothing in the architecture prevents residual embeddings, cached completions, or prompt-cache entries from persisting beyond their notional lifetime, and the burden of proving non-persistence falls on testing rather than on inspection. The disclosed mechanism inverts this: persistence is structurally impossible across the region boundary, and the burden of proof is discharged by examining the region allocator's signature.

Disclosure Scope

The disclosed mechanism covers any agent architecture in which skill invocations execute in per-invocation memory regions, cross-region access is mediated by an unforgeable region-key system, and teardown is deterministic and synchronous with the invocation's terminating event. The scope encompasses single-process, multi-process, container, and distributed implementations, and applies whether the skill is driven by an LLM, a classical procedure, or a hybrid.

Because the absence of leak paths is provable from the region allocator's type signature rather than from behavioral testing, the mechanism supports compliance regimes that require evidentiary cleanup of sensitive material between invocations. This is the principal commercial property the disclosure protects.