Memory for long-horizon agents — episodic, semantic, versioned

Abstract

An agent that runs your wet-lab for a month has memory requirements that a chat session does not. We describe how the Apex agent runtime ^[1] represents memory for long-horizon agents: a two-store architecture (episodic + semantic), hash-linked provenance on every write, hybrid retrieval that mixes vector similarity with symbolic graph traversal and temporal scan, storage-layer enforcement of right-to-delete, and version-pinned exports for audit. The architecture is what makes the rest of the runtime's safety story ^{[3, 4]} practically enforceable; this paper documents the mechanism.

1. Why memory matters for long-horizon agents

A chat session lasts minutes; a model invocation completes in seconds. Memory for that mode of operation is effectively the context window. For a long-horizon agent — one that runs your wet-lab for a month, one that drives a chip-design flow over a tape-out cycle, one that does on-call review across a quarter — the context window is wildly inadequate. The agent has to remember things from yesterday, last week, last campaign. None of that fits in 1M tokens, and even if it did, putting all of it in context every call is the wrong architecture.

We separate the concepts carefully. The model's parameter weights are one kind of memory — they encode what the model learned during pretraining. The context window is another — it encodes what the model is being asked about right now. Neither of these is what we mean here. We mean a persistent, queryable, audit-grade store of events and concepts that the agent has accumulated across all the times it has been running, owned by the customer, governed by their policies, and refreshable only through documented mechanisms.

Most agent frameworks treat this as an afterthought — a vector store bolted on, accessed through generic retrieval-augmented-generation patterns. That works for prototypes. It does not work for an agent that holds keys to a liquid handler, or for an agent whose recommendations have to be defensible under regulatory audit.

2. Two stores

Memory in the runtime is split into two stores. They are co-resident, they share a transactional substrate, and they are queried together — but they have different shapes.

Episodic memory is event-keyed. Every tool call, every decision, every observation has a hash-linked record. The record contains the inputs, the outputs, the policy that was active at the time, and a pointer to the parent event (the prior step in the agent's reasoning, or the previous tool call that produced this call's input). The chain is append-only; events cannot be edited after the fact without invalidating downstream records.

Semantic memory is concept-keyed. Facts about the campaign, the chemistry, the customer's preferences — stored as a graph with edges typed by their evidence. Each edge in the graph carries a reference to the episodic record (or records) that justifies it. A semantic fact without episodic evidence cannot exist in the graph; we enforce this at write time.

3. Provenance

Every memory write is attributed to the decision that produced it, the tool call that observed it, and the policy that allowed it. This is not a logging concern; provenance is part of the data model. A query that returns a memory record also returns its provenance, and an agent that uses the record is responsible for handling it consistent with the policy at the time of the write.

"The model just forgot" is not a thing that can happen in this runtime — forgetting requires explicit revocation, and revocation is itself versioned. If a customer's compliance review requires deletion of a specific class of records, the deletion is performed by an explicit revocation operation, which appears in the audit trail as its own event. The records are not silently lost; they are explicitly tombstoned with a reference to the revocation event.

This is what makes the runtime defensible under audit. When a regulator asks "why did the agent recommend X," we can produce the exact memory state that was visible to the agent at the time of the recommendation, the policy that was active, and the chain of episodic records that supported the underlying semantic facts.

4. Hybrid retrieval

Retrieval is hybrid by design. Different queries want different policies.

• Vector similarity for concept-level recall — "find memories that are similar to this idea." The semantic-memory graph is indexed by an embedding model fine-tuned on customer-domain concepts.
• Symbolic graph traversal for relational queries — "what plates were derived from reagent lot 47B and assayed against target X." The episodic and semantic stores share a join key on entity references.
• Temporal scan for time-window queries — "what did the agent do yesterday between 2pm and 4pm." Episodic records are indexed by their event timestamp; the index supports both range and point queries.
• Capability-gated retrieval — "return only memories that the calling principal is authorised to see." Authorisation is checked at retrieval, not at storage; tombstoned and access-restricted records are filtered before they reach the agent.

The runtime picks the policy per query based on the surface form and the calling agent's declared intent. The agent does not specify which index to hit; it asks for memory satisfying some criterion, and the runtime decides which combination of vector, symbolic and temporal retrieval will answer the criterion most efficiently. This indirection is deliberate — it lets us evolve the underlying retrieval strategy without changing every agent that uses it.

5. Right-to-delete

GDPR and customer-policy deletion is enforced by the storage layer, not by a post-hoc cleanup job. A delete request rewrites the affected records to a tombstone, propagates the deletion through any derived semantic edges, and produces an explicit revocation event. The propagation is transactional — either all of the affected records are tombstoned together, or none of them are. There is no race condition in which an agent can read a record that has been logically deleted.

The audit trail of the deletion itself is retained. We always know — and can prove to an auditor — was X deleted, when, on whose request, under what policy, and with what scope. The contents of the deleted record are gone; the fact of the deletion is preserved.

Customer-defined retention policies are first-class. A customer can specify that all records of type T older than 90 days should be automatically tombstoned; the storage layer performs the tombstoning as a background operation and records each one as a revocation event. We do not silently truncate.

6. Why this matters for safety

Capability gates ^[3] and refusal policies ^[4] use memory. A request to repeat an unsafe operation is refused with reference to the previous refusal — and the reference is auditable. Memory-attested provenance is also how the runtime enforces separation-of-duties controls in regulated environments: an action authorised by principal A is recorded with A's identity, and a subsequent action that depends on the first cannot be authorised by A alone because the policy checks the dependency chain.

Without memory provenance, the safety architecture works only in the short-term. The refusal corpus catches the request in front of the model right now; the capability gate enforces the policy at the moment of the tool call. Without memory, both of these are local checks, and a sufficiently patient attacker can compose individually-passable actions into an unsafe campaign over a long horizon. With memory, the runtime can detect the composition because it has the full event chain.

7. Storage substrate

The underlying storage is append-only. Episodic events are written to a hash-linked log; semantic edges reference event hashes rather than mutable identifiers. Compaction is supported but logically equivalent to a deletion + re-creation under a new policy; nothing in the active store is silently modified.

Replication, durability and recovery follow standard practice for high-availability storage. Per-tenant compute pools have per-tenant data planes; cross-tenant queries are denied at the storage layer rather than by application code. Backups are encrypted with customer-held keys; restoration requires the customer's key plus our administrative key, with both presences logged.

Capacity planning is straightforward. The episodic store is bounded by event throughput times retention period; a busy production agent generates roughly 10⁴ events per day, and a typical regulated retention period is 7 years. The dominant cost is not storage volume but indexing — vector and symbolic indices are roughly 4× the raw-data footprint, and they have to be rebuilt periodically.

8. Export and audit

Memory contents are exportable to the customer at any time. The export format is JSONL with the hash-link structure preserved; the customer can verify integrity without trusting our infrastructure. Per-tenant exports include the full episodic chain plus the semantic graph plus the policy that was active during each write.

Audit access is read-only and append-trailed. An auditor's query against memory is itself recorded as an episodic event in the auditor's own audit space, distinct from the customer's. We can prove to the customer which records the auditor examined; the customer's substantive memory is not modified by the audit.

9. What this is not

This is not the model's pretraining memory. Aether ^[1] does not learn from customer interactions during production. Customer memory accumulates in the per-tenant store described above; it is used at inference time but it does not modify the model's weights.

It is also not a magic bullet. Memory provenance makes audit possible; it does not by itself make every audit pass. The customer's policy, the policy's correctness, the agents' adherence to their declared capabilities — all of these still matter. Memory is the substrate; the rest of the safety story sits on top.

10. Conclusion

Long-horizon agents need long-horizon memory, and the right shape for that memory is dictated by the requirements of production and of audit. The Apex runtime implements a two-store architecture — episodic events and semantic concepts — both append-only, both hash-linked, both versioned with provenance. Hybrid retrieval policies make the stores useful in practice; storage-layer right-to-delete makes them defensible under regulation. The architecture is what makes capability gating ^[3] and refusal-corpus extension ^[4] practically enforceable in long-running deployments.