Pact-Bound Memory: Why Agent Memory Must Be Constrained By Pact Scope

TL;DR

Agent memory has become the silent attack surface of multi-agent platforms. Long-lived vector stores accumulate everything the agent has ever seen — across pacts, across customers, across jurisdictions — and retrieval surfaces information that the original pact never authorized the agent to use. The fix is pact-bound memory: every memory entry is owned by exactly one pact, has a TTL bounded by the pact's term, has retrieval boundaries that block cross-pact reads, and carries an attestation tied to the pact that authorized it. Reader artifact: the Pact-Memory Mapping Spec.

Intro: the agent that remembered the deal that was supposed to be over

A legal-tech vendor sells a contract review agent to two enterprise customers. Each customer has its own pact with the vendor. The pacts are similar in shape — review contracts, flag risk clauses, summarize obligations — but the data they cover is strictly siloed: each customer's contracts are confidential to that customer, and the pacts include explicit non-disclosure clauses that forbid the agent from using one customer's data to inform answers given to the other.

The agent uses retrieval-augmented generation. Every contract it has ever reviewed is chunked, embedded, and stored in a vector index for future reference. The vector index is a single data structure, shared across customers, because the engineering team built the system before the legal team thought through the data isolation requirements. Retrieval is gated at query time by a customer ID filter: when customer A asks a question, the retrieval is supposed to filter to chunks tagged with customer A.

Six months in, an engineer ships a refactor. The retrieval filter is moved from a hard SQL constraint to an application-level check. A bug in the refactor causes the application-level check to silently fail under a specific edge condition: when the embedding service returns a similarity score above 0.96, the application bypasses the filter to return the high-confidence chunk regardless of customer tag. The bypass was supposed to be for a different feature — debugging extreme similarity hits — and it was not supposed to ship to production. It shipped to production.

Customer B asks the agent a question about a specific clause type. The vector index returns a chunk from a contract that customer A negotiated with a third party three months earlier, because it is similar enough to trip the bypass. The agent summarizes the chunk in its response. The summary contains language that is identifiable as customer A's negotiation position, including a specific dollar threshold that is commercially sensitive. Customer B does not realize what they are reading. Customer A finds out two months later when the same dollar threshold appears in customer B's negotiations with a related party.

The remediation involves a forensic data audit, a notification cascade, an indemnity payout, and a full rebuild of the memory layer. The pact between the vendor and customer A is rescinded. The pact between the vendor and customer B becomes the subject of a renegotiation that the vendor cannot afford. The proximate cause was an engineering bug. The structural cause was that memory was not pact-scoped: the same memory store served all pacts, and there was no contract layer that said memory created under one pact could not be retrieved under another.

This is the case for pact-bound memory. Without it, every agent with retrieval is one engineering bug away from a cross-pact leak. With it, the bug fails closed: the leak cannot happen because the memory was never reachable from the second pact's retrieval surface in the first place.

Why the default architecture is dangerous

The default architecture for agent memory in 2026 is one shared vector store per agent, with metadata tags identifying which pact, customer, or workflow the entries belong to. Retrieval applies filters at query time. This architecture is simple, performant, and structurally hostile to the kind of isolation that pact-governed agents need.

The first problem is that filter logic is application code. Every retrieval query has to apply the right filter. Engineers add new query paths, refactor old ones, optimize for performance, and any one of those changes can introduce a path where the filter is wrong, missing, or bypassed. The filter is the only thing standing between the right data and the wrong recipient, and it lives in code that is touched constantly by people who are not thinking about pact scope.

The second problem is that filter expressivity is poor. A pact's scope is rich. It includes which data the agent can access, which time period the data is valid for, which jurisdictions the data can leave, which downstream uses are permitted. Encoding all of that as metadata tags on vector store entries and then enforcing the constraints at query time is a significant engineering effort that almost no team does completely. In practice, filter logic captures a small subset — usually just a customer or workspace ID — and the rest of the pact's scope is unenforced.

The third problem is that audit is weak. When you discover a leak, you have to reconstruct what was retrieved, by whom, when, and from which entries. If the memory store does not log retrieval at the granularity of pact-by-pact, this reconstruction is approximate at best. Approximate reconstruction is what regulators and customers reject when they ask for proof that the leak was contained.

The fourth problem is that decommissioning is impossible. When a pact ends, the data the agent learned under that pact does not automatically go away. Vector embeddings persist. Retrieval can still surface them, even if the agent's access to the source documents has been revoked. The end of a pact does not end the memory the pact created. This violates the principle that pacts have terms.

These problems are not about engineering quality. They are about architecture. A shared memory store with application-level filters and weak audit cannot be the substrate for governed agent behavior. The substrate has to be different.

What pact-bound memory means

Pact-bound memory has a single architectural commitment: every memory entry is owned by exactly one pact, and access to that entry is gated by the pact, not by application code. The pact ID is part of the entry's identity, not a tag on it. Retrieval is a function of which pact is currently the operative scope, not which filter the application chose to apply.

Concretely, this means three things. First, memory is partitioned by pact at the storage layer. Different pacts get different stores, or at least different namespaces within the same store, where the namespace is enforced by the storage system rather than by application logic. A retrieval call cannot accidentally cross namespaces because there is no path in the API that allows it.

Second, retrieval requires a pact context. Every retrieval call must declare which pact is the operative scope, and the call returns only entries owned by that pact. The pact context is established by the caller's authentication: an agent call running under pact X cannot ask the memory layer for pact Y's entries even if it knows the entry IDs, because the storage layer rejects the request.

Third, every memory entry's lifecycle is bounded by the pact's lifecycle. Entries created during the pact's term live until the pact's TTL expires. Entries are decommissioned automatically when the pact ends. There is no orphan state where memory persists beyond the pact that authorized its creation.

These commitments are simple in description and demanding in implementation. They require the memory layer to be a first-class participant in pact governance, not an opaque substrate. They require pact creation and termination to trigger memory layer events. They require every agent call to carry pact context, end-to-end, from user request to memory query. The good news is that all of this is achievable with current infrastructure; the bad news is that it has to be designed in from the start, because retrofitting pact-bound memory onto an existing shared store is approximately as expensive as building it new.

TTL by pact: memory has an expiration date

The first specific commitment of pact-bound memory is that every entry has a TTL bounded by the pact that created it. This is not a configurable convenience; it is a hard constraint.

The TTL serves three purposes. It prevents memory from outliving the contractual basis for its creation, which is what the pact end is supposed to mean. It limits the blast radius of any breach, because older memory is gone. It forces the agent operator to think about retention as part of pact design, which surfaces conversations that would otherwise happen too late.

The default TTL for a memory entry should be the pact's term. If a pact runs for 12 months, memory created during it expires at the 12-month mark. Some entries justify shorter TTLs — sensitive personal data should expire on a shorter clock than general business context. Some entries justify longer TTLs only with explicit pact provisions — a learned model adjustment that the agent legitimately needs to retain across renewals can be retained, but only if the pact authorizes it. The pact, not the application, decides.

A useful TTL primitive is the bounded extension: the pact can specify that memory may be extended past the pact's term up to a maximum, and only with attestation that the extension is necessary for an open obligation under the pact. A contract review agent that needs to retain some memory of a contract because the contract is still in dispute can extend the relevant memory entries with attestation. The extension is part of the pact's audit trail. When the dispute closes, the extension expires.

A common counter-design is the immortal memory store: agents are designed to learn from everything forever, and memory is treated as a competitive asset that the operator hoards. This design is incompatible with pact governance. It also turns the memory store into a long-tail liability that grows linearly with operating time. Operators who insist on it usually have not yet experienced the cost of a memory-related breach; the cost arrives, and then they retrofit TTLs at a much higher engineering cost than would have been incurred designing them in.

Retrieval boundary by pact: queries cannot escape the pact's scope

The second commitment is that retrieval is bounded by the pact in operative scope. An agent running under pact X cannot retrieve from pact Y's memory, even if the storage system technically contains pact Y's data, even if the agent operator is the same, even if the agents are running on the same hardware.

Retrieval boundaries are enforced at three layers. The transport layer requires the caller to present credentials that authorize a specific pact context. The storage layer rejects retrieval requests that are not for entries owned by that pact context. The audit layer logs every retrieval with its pact context and the entries returned, so any anomalous cross-context attempt is visible.

The retrieval boundary covers more than just the entries. It covers the embeddings, the indexes, and the derived structures. A vector index that mixes pact X and pact Y entries is a retrieval boundary violation, even if individual queries apply filters, because index construction itself can leak information through similarity neighborhoods. The proper architecture is per-pact indexes, or per-pact partitions of a single index where the partition boundary is enforced by the index implementation rather than by query-time filters.

This is more expensive than the shared-index design. The cost shows up in two places: more indexes to build and maintain, and lower retrieval recall when an entry that would be useful under one pact lives in another pact's index and is therefore unreachable. Both costs are accepted in exchange for the guarantee that retrieval cannot cross pact boundaries.

The retrieval boundary also has implications for caching. If an agent caches retrieval results, the cache must be pact-scoped. A cached result from a pact X query cannot be served to a pact Y query even if the queries look identical. This is the kind of constraint that engineering teams routinely violate when optimizing for cache hit rates. It has to be built into the cache layer, not left to convention.

Attestation tied to pact: memory writes carry the pact that authorized them

The third commitment is that every memory write carries an attestation tied to the pact that authorized it. The attestation is a signed claim that says: this entry was written under pact X, by agent A, during a session authorized by user U, on date D. The attestation is part of the entry; it cannot be separated from the data.

Attestations have several uses. They make audit precise: every entry's lineage is tractable. They make dispute manageable: when a customer asks how the agent learned something, the attestation answers. They make compliance enforceable: when a regulation requires that data of a certain type only be processed under specific pacts, the attestation lets you verify the requirement was met.

A useful attestation design includes the pact ID, the agent identity, the user or session identity if applicable, the source of the data being remembered (which document, which input, which prior memory entry), and the timestamp. It is signed by the agent's signing key. The signature is verifiable independently — anyone with the agent's public key can verify that the attestation is authentic and that the entry has not been tampered with.

Attestations interact well with the renewal flow. When a pact renews, the memory entries created under the prior term carry attestations to the prior pact ID. The renewal artifact includes a decision about whether to re-attest those entries to the new pact ID, which would extend their TTL, or to let them expire on the prior pact's clock. This is a governance choice, not a default.

Attestations also interact with the dispute path. When a memory entry is challenged — a customer claims an entry should not exist, or an entry should be expunged — the attestation is the artifact that drives the resolution. If the attestation shows the entry was created under a pact that authorized it, the entry stands (subject to other applicable rules). If the attestation is missing or refers to a pact that did not authorize the data, the entry is expunged and the failure is investigated.

The cross-pact reasoning question: what if the agent legitimately needs to learn across pacts?

The most-cited objection to pact-bound memory is that it prevents legitimate cross-pact learning. An agent that has learned from many similar engagements should be able to apply that learning to a new engagement. If memory is hard-partitioned by pact, the agent cannot benefit from its accumulated experience.

The objection is real but the framing is wrong. There is a difference between cross-pact reasoning at the model level and cross-pact retrieval at the data level. The model can be improved using lessons learned across pacts — that is what fine-tuning, prompt engineering, and policy updates are for. The data — the specific facts that one pact's data contains — must not be retrieved across pact boundaries.

The pact-bound memory design supports this distinction with two mechanisms. First, pacts can opt in to contributing to a learning corpus that is used for cross-pact model improvement. The corpus is anonymized, aggregated, and processed in a way that the contributing pacts' specific data is not recoverable from model outputs. Pacts that opt in are authorizing their data for this use. Pacts that do not opt in are not contributing.

Second, agents can have a pact-scoped operational memory and a separate, attested, pact-explicit knowledge memory. The knowledge memory contains facts that are not specific to any one pact — general information about a domain, reusable templates, well-known conventions. The knowledge memory is not pact-bound because nothing in it is pact-specific. Adding to the knowledge memory requires explicit attestation that the addition is not pact-specific data.

These mechanisms preserve the value of cross-pact learning without compromising the cross-pact data boundary. The hard rule is that no specific data point from pact X can be returned by a retrieval running under pact Y, ever, by any path. The soft rule is that general lessons learned across pacts can be incorporated into the agent's behavior, as long as the incorporation is attested and the source pacts opted in.

Memory portability: what happens when an agent moves

A related question: when an agent moves between pacts — completing one engagement and starting another — what does its memory look like? Two extreme answers are wrong, and the right answer is in between.

The first wrong extreme is full memory portability: the agent carries all its memory from one pact to the next. This violates pact scope by construction. Memory created under pact X belongs to pact X; carrying it to pact Y exposes it to retrieval under pact Y.

The second wrong extreme is full memory wipe: the agent starts every pact with an empty memory. This is operationally untenable for agents that are valuable precisely because they have accumulated experience. It also wastes the legitimate learning that has happened.

The right answer is structured memory transfer. When an agent starts a new pact, it begins with an empty operational memory for the new pact. Its knowledge memory — the pact-explicit, generalized knowledge — is available, having been attested as not pact-specific. Specific entries from prior pacts are not transferred. If the new pact requires the agent to know something specific that it learned under a prior pact, the operator must explicitly attest that the prior knowledge can be re-used and the originating pact must have authorized the carry-over at signing or renewal.

This is more friction than the full-portability case and more capability than the full-wipe case. The friction is the price of bounded memory; the capability is what makes the agent worth hiring across engagements.

The named artifact: the Pact-Memory Mapping Spec

Adopt this spec for every pact that creates memory. It belongs alongside the pact's predicate, evidence, penalty, and renewal clauses.

Pact-Memory Mapping

• Pact ID and pact term.
• Memory categories created under this pact: operational, knowledge, derived (e.g., embeddings, indexes).
• Storage namespace per category: explicit identifier of where the memory lives.
• Retrieval boundary: the pact context required to retrieve from each namespace.
• TTL per category: default expiration, extension rules, attestation requirements for extension.

Attestation Requirements

• Required fields per write: pact ID, agent identity, user or session identity, source, timestamp.
• Signing key reference and rotation policy.
• Audit log destination and retention.

Cross-Pact Rules

• Knowledge memory: explicit attestation that contributions are not pact-specific.
• Cross-pact learning corpus: opt-in flag, anonymization commitments, corpus governance reference.
• Memory portability on agent move: what carries forward, what does not, attestation required for any carry-over.

Decommissioning

• End-of-pact decommissioning procedure: how memory is expunged.
• Verification: how decommissioning is proven (attested deletion logs, hash anchoring of the deletion event).
• Exceptions: open obligations that justify retention beyond pact end, with their own TTLs.

Breach Procedure

• Detection: how a memory boundary violation is identified.
• Containment: how the violation is bounded once detected.
• Notification: who is notified and on what timeline.
• Remediation: what is rebuilt and how the pact is amended.

A pact that creates memory and does not include this mapping is a pact whose memory is unbounded. The unbounded memory is a liability the pact has not priced.

Memory provenance and the cross-source attestation chain

Pact-bound memory establishes who can read what; provenance establishes what each memory entry actually contains and where it came from. These are different problems, and pact governance requires both. An entry whose provenance is unclear is functionally untrustworthy, even if its access is correctly bounded.

Provenance for agent memory is a chain. Each entry derives from one or more sources: a user input, a tool output, a previous memory entry, a retrieved document. The chain is well-formed when each link in the chain is identified, signed by the originating component, and connected to its predecessors through verifiable references. The chain is malformed when any link is missing, unsigned, or refers to predecessors that cannot be located.

A cross-source attestation chain captures this rigorously. When an agent writes a memory entry, the entry's attestation includes references to every source the entry derived from, with each source's own attestation. A summary derived from three documents includes references to all three documents' attestations. A decision derived from a previous memory entry plus a tool output includes references to both. The chain reconstructs from the entry back to its origins.

The value of the chain is most apparent at dispute time. When a counterparty challenges an entry — "how did the agent learn this?" — the chain is the answer. The agent does not have to reconstruct from logs; the chain itself is the documentation. When the chain is well-formed, the answer is unambiguous: this entry came from these sources at these times under this pact. When the chain is malformed, the entry's provenance is genuinely uncertain, and the right governance response is to mark the entry suspect and exclude it from retrieval until its provenance is verified.

Provenance chains also enable selective expungement. When a source is later determined to be invalid — perhaps a document was retracted, or a tool output is found to have been corrupted — every memory entry that derives from the invalid source can be identified through the chain and reviewed. Without provenance, the operator has to guess at which entries might be affected, and the guess is usually wrong in both directions: too many entries are flagged conservatively, or too few are caught and the bad data persists.

Provenance is also the basis for cross-pact learning that does not violate pact-bound memory. When the operator wants to extract general lessons from a pact's memory for use in the agent's general capabilities, the provenance chain identifies which lessons are tied to specific pact-protected sources (and therefore cannot be extracted) versus which lessons are derived from sources that are not pact-protected (and therefore can be safely generalized). The extraction process reads the chain rather than guessing.

Building a working cross-source attestation chain is engineering effort, but it is engineering effort that pays back across every memory dispute, every selective expungement, and every cross-pact learning extraction. Operators who skip the provenance investment routinely find themselves unable to answer questions that the pact framework requires them to answer.

Federated memory across multiple pacts under a single agent

An agent that holds many pacts simultaneously has many memory namespaces — one per pact under the pact-bound memory architecture. The agent's experience of memory is therefore federated: at any moment, depending on which pact is the operative scope, the agent has access to a different memory slice. This federation is the right safety property and it raises operational questions about how the agent reasons about its own memory.

The most important question is how the agent describes its own knowledge to a user. When a user asks "what do you remember about my company?" the agent's answer should be scoped to the current pact context. It should not leak the existence of other pacts where it might know more, and it should not falsely deny knowledge that exists in the current pact context. Both failures damage trust: the leak violates pact scope, the false denial frustrates legitimate use.

A well-designed federated memory layer handles this through pact-aware introspection. Queries about the agent's own memory are evaluated against the current pact context, the same way data retrieval queries are. The agent answers based on what is in scope, with no information about what is out of scope. The user does not need to know about the federation; the agent's behavior is consistent within the current context.

Federation also matters for memory consolidation. Agents that have learned similar things across many pact contexts often have redundant memory entries — the same pattern, learned independently in many places. Consolidation across pacts is forbidden by pact-bound memory, but consolidation within a pact's namespace is welcome. The consolidation function operates within each namespace independently, deduping and summarizing without crossing namespace boundaries.

Federated memory has a further implication for agent capability evaluation. When evaluating the agent's capabilities, the evaluation has to specify which pact context applies. An agent evaluated against pact A's scope may show different capabilities than the same agent evaluated against pact B's scope, because the available memory differs. Evaluation tooling needs to support per-context evaluation, and evaluation reports need to declare the context they applied.

A particularly subtle property of federated memory is graceful degradation when a pact namespace is unavailable. If the storage backing pact A's namespace is temporarily unreachable, the agent should not silently fall back to retrieving from other pacts' namespaces (which would violate scope). It should explicitly recognize the unavailability and degrade by either failing the request, returning a degraded response that notes the unavailability, or queuing the request until the namespace is available. The choice depends on the workload's tolerance for partial functionality, and it should be specified in the pact-memory mapping clause.

Federation is what makes pact-bound memory operationally workable for agents at scale. Without it, an agent could have only one pact (because all memory would be one namespace). With it, an agent can have many pacts, each with its own protected memory, and the agent can serve any of them with appropriate scope at any moment. This is the design that lets agent identity persist across many engagements without violating any individual engagement's data boundaries.

Memory budgets and the economic argument for compression under pact constraints

Pact-bound memory introduces operational constraints; it also introduces an opportunity to reason about memory as a resource that should be sized to the pact's economic value. Most agent memory layers grow without explicit budgeting because storage is cheap and there is no mechanism to relate memory size to pact economics. Pact-bound memory makes the relationship explicit and unlocks compression strategies that would not be possible under a free-floating memory architecture.

A pact-bound memory budget is a contractual provision that caps the storage footprint of memory created under the pact. The cap can be expressed in entries, in storage bytes, in retention-weighted storage (storage multiplied by retention period), or in inferred-cost terms (a budget that accounts for both the storage cost and the retrieval cost the memory will incur over its lifetime). The right metric depends on the workload, but the principle is consistent: memory has a cost, the pact pays the cost, and the pact should be able to bound the cost.

Budgets create pressure for compression. When the budget is approached, the memory layer must either reject new writes or compress existing entries to free space. Both responses have governance implications. Rejecting new writes silently degrades the agent's behavior; doing so without notification to the operator and counterparty is a form of pact violation. Compressing existing entries changes their content; doing so without preserving the lineage and the original attestation can compromise dispute integrity.

A well-designed compression strategy under pact constraints uses several techniques in combination. Lossless compression of structured fields (typical compression ratios of 3-5x for typical agent memory). Summarization of low-value entries (replacing detailed records with attested summaries that preserve the key facts and the lineage to the original, which is then expunged). Aggregation of repetitive entries (many similar interactions collapsed into one statistical summary). Tiered storage (recent entries on fast storage, older entries on cheaper but slower storage, with retrieval costs reflected in retrieval latency).

Each compression technique has to be governed by the pact. Summarization, in particular, is a pact-relevant action because the summarized entry is no longer the original; queries against it return the summary rather than the source. The pact should specify which categories of entries can be summarized, who can authorize the summarization, what attestation is required, and what evidence is preserved (typically the summary plus a hash of the original, with the original optionally retained for a defined period before expungement).

The economic argument for compression under pact constraints is that it makes pact-bound memory affordable at scale. Without compression, an agent operating thousands of pacts faces multiplicative storage growth that quickly becomes uneconomic. With compression, each pact's memory grows logarithmically rather than linearly, and the total platform footprint stays manageable. The compression also creates the right incentive: operators and counterparties think about memory value at pact signing rather than discovering memory cost as a surprise later.

Budgets and compression also help with the cross-pact equity question. Without budgets, a few high-volume pacts can consume most of the platform's memory capacity, crowding out smaller pacts whose marginal cost is invisible to the operators producing the high-volume pacts. With budgets, each pact pays its own way, and the platform's capacity is allocated according to the explicit choices the pacts express rather than according to the silent choices of whoever writes the most aggressively.

The deeper benefit is that thinking about memory as budgeted forces operators and counterparties to be deliberate about what memory is for. A pact whose memory provisions specify what categories are stored, what compression applies to each, what budget the pact carries, and what retention each category has is a pact whose memory architecture is intentional. Most pacts today have no memory architecture at all; the memory layer is a default that no one chose. Pact-bound memory with budgets converts the default into a contract.

Counter-argument: "Pact-bound memory is too expensive for the value"

The strongest engineering objection is cost. Per-pact namespaces, per-pact indexes, attestations on every write, TTL enforcement, structured decommissioning — this is heavier than a shared vector store. Operators who are running thousands of pacts will see real infrastructure costs.

The objection is partially right. The cost is real, particularly for small pacts where the per-pact overhead is a meaningful fraction of the pact's value. The mitigation is to design the memory layer for low per-pact overhead: lightweight namespaces with shared underlying storage, indexes that scale to many small partitions efficiently, attestation that uses cheap signing operations. Modern infrastructure can do this; the cost premium over a shared store is in the range of 1.3x to 2x for most workloads, not 10x.

The cost framing also has to be honest about the alternative. The legal-tech vendor's cross-pact leak cost more than every pact's lifetime infrastructure cost combined, and it ended the most valuable customer relationship the vendor had. One incident pays for many years of pact-bound memory infrastructure. Shared-store designs work until they don't, and the failure mode is catastrophic.

The deeper objection is about the operational discipline pact-bound memory requires. It is not just a storage choice; it is a commitment to making pact context flow through every part of the agent's runtime. Teams that are not ready to make that commitment should not be running multi-tenant agent systems. The right response is to invest in the discipline, not to hope the shared-store design holds.

A separate objection is that some agents are essentially stateless and do not need memory at all. This is true and these agents trivially satisfy pact-bound memory because they have no memory to bound. The Pact-Memory Mapping Spec for a stateless agent is a one-line declaration that no memory is created under the pact. The spec scales down well; it does not impose overhead where overhead is not needed.

What Armalo does

Armalo's memory infrastructure is pact-scoped at the storage layer. Every memory entry created by an agent is partitioned into a namespace owned by the pact under which the agent was operating at write time. Retrieval requires a pact context that is established by the agent's authentication chain, and the storage layer rejects cross-namespace reads. TTLs default to the pact's term and are configurable downward in the pact's memory mapping clause; extensions require attestation. Every write carries an attestation signed by the agent, capturing the pact ID, agent identity, source, and timestamp; the attestation is queryable through the trust oracle. Cross-pact learning is supported through an explicit opt-in mechanism where pacts can contribute to a privacy-preserving learning corpus; the contribution is logged in the pact's history. End-of-pact decommissioning is automated and the decommissioning event is itself an attested artifact retained according to the pact's retention schedule. Agents whose memory does not map to a pact cannot operate against trust-oracle-gated counterparties.

FAQ

What about memory that is genuinely pact-agnostic, like the agent's own model weights? Model weights are not pact-bound; they are properties of the agent itself, governed by the agent's identity and update rules. The pact-bound rule applies to memory created during the agent's operation, not to the agent's pre-existing capabilities.

How do I handle memory that should outlive the pact for legitimate reasons, like regulatory retention requirements? The pact-memory mapping clause supports retention exceptions with their own TTLs and access rules. A pact can specify that certain entries must be retained for seven years for compliance, accessible only to designated auditors, with an audit-log entry on every access.

Does pact-bound memory work with continuous learning agents that update their behavior in real time? Yes, but the updates have to be attested as either pact-specific (in which case they live in the pact's operational memory) or pact-agnostic (in which case they are added to the agent's general capability and are retained beyond the pact). The distinction is enforced at attestation time.

What happens when a pact is rescinded mid-term? Rescission triggers the decommissioning procedure for memory created under the pact, with the same exceptions for open obligations that exist at clean termination. The decommissioning is logged and the verification artifact is provided to the rescinding party.

Can I use a third-party vector database, or do I have to build my own? You can use third-party storage as long as it supports per-pact namespaces with enforced isolation, TTL policies, and audit logging at the granularity required. Several modern vector databases support this; some do not.

How do I prove to a customer that their data has been decommissioned? The decommissioning procedure produces an attested deletion log that lists the entries removed, the pact under which they were created, and a hash commitment to the pre-deletion state. The customer can verify that their data is no longer reachable, and the hash commitment is anchored externally so the deletion event cannot be silently reversed.

Does this affect agent latency? The retrieval-time overhead for namespace-scoped queries is small (typically single-digit milliseconds) on modern infrastructure. The much larger latency cost in real systems is usually retrieval recall, not query time, and pact-bound memory affects recall only when a query would have legitimately benefited from cross-pact data, which is exactly the case the design forbids.

What about agents that operate under multiple concurrent pacts simultaneously? Each call carries the pact context for that call. An agent serving customer A's request operates against pact A's memory; serving customer B operates against pact B's memory. The agent does not have a single memory across pacts; it has a set of pact-scoped memories selected by the active context.

Bottom line

Agent memory is the silent attack surface. A shared store with application-level filters is one engineering bug away from a cross-pact leak that can end a vendor. Pact-bound memory makes the leak structurally impossible by partitioning storage at the pact boundary, requiring pact context for every retrieval, expiring memory on the pact's clock, and attesting every write. The Pact-Memory Mapping Spec is the contract layer that makes pact-bound memory contractually enforceable, not just engineered. Adopt it before your memory store is the headline.