Persistent memory does not authorize action
An agent retrieves an account restriction that was valid when recorded but expired before use. Its tool call succeeds. Yet the system cannot show which evidence supported the restriction, which policy admitted it, or whether the fact remained valid when the action occurred.
That is not a forgetting problem. It is ungoverned remembering.
Agent memory governance is the set of controls that determines which recorded or derived facts an agent may use for a specific action, at a specific time, within a defined scope. Persistent memory alone does not provide those controls. It improves continuity, but continuity is not authority.
A defensible architecture separates three concerns. An append-only event record preserves what the system observed. A maintained fact record represents what the system currently believes. A durable decision record binds selected evidence and facts to policy, approval, action, and outcome. For actions that require inspection or replay, that third record is the proof that memory was admissible when it caused an effect.
Successful tool execution proves that transport, credentials, and permissions worked. It does not prove that the underlying memory was admissible for the action. A valid API response can therefore coexist with an invalid decision basis.
The core claim is direct: persistent agent memory cannot make an action accountable unless the runtime records which evidence and derived facts were admissible under which policy, at what time, and with what effect. That record must exist independently of the model response because later inspection depends on stable identities and versions, not on a plausible retrospective explanation.
Persistent memory improves continuity rather than authority
Modern memory systems solve a genuine operational problem. A stateless agent must rediscover conventions, corrections, prior results, and useful workflows. Replaying every prior interaction consumes context and may introduce irrelevant or contradictory material.
Databricks addresses this with Agent Memory on Agent Bricks. Managed sessions preserve ordered messages, tool calls, and results. Managed memory stores facts and workflows. Hybrid retrieval finds relevant material, while a background pipeline extracts, merges, and replaces derived knowledge.
The underlying MemCurrent architecture makes an important separation. Episodic memory is an append-only trace of sessions. Derived memory is mutable, distilled knowledge that tools and background processes can update. Raw history answers what happened. Maintained knowledge answers what appears useful now.
In its MemCurrent benchmark report, Databricks states that pass rate rose from 22.3% without memory to 68.4% across 114 internal cases, with 31% fewer tokens and 26% faster execution. Those are vendor-run results for the stated models, tasks, harnesses, and test set, not a general performance guarantee.
The separation is sound, but an action-bearing runtime must ask another question. May this fact be relied upon here and now?
Retrieval cannot answer that question by itself. A stale instruction may remain semantically close to the current request. A fact valid for one account may be prohibited for another. A highly ranked memory may have weak provenance. A recent fact may still require human approval before it can trigger an external effect.
Can an agent act safely from consolidated knowledge alone?
No. Consolidated knowledge can improve retrieval and consistency, but it does not establish authority for a particular action.
A centralized ontology, knowledge graph, or lake export can reconcile names, link entities, and produce a current view. It can also obscure the path from source observation to current assertion. Once an agent acts, “the graph said so” is not an adequate explanation.
The problem has four parts:
- Freshness determines whether the fact remained valid at decision time.
- Scope determines whether the fact may cross account, region, purpose, or workflow boundaries.
- Authority determines which policy or approver may permit the proposed effect.
- Provenance determines which source records support the fact and how it was derived.
A centralized platform can implement all four. Consolidation fails as authority when the system cannot bind a fact version to source evidence, scope, policy, and decision time. Exporting operational data into a lake has the same failure condition. The resulting snapshot may remain useful for analysis without proving current permission.
InfoQ describes agentic systems as shifting from service decomposition toward decisions selected at runtime. That framing matters because the execution path now depends on context, reasoning, and tool choice. An admissibility error can therefore produce a valid API call with an invalid basis.
The system needs a decision boundary, not merely a better index.
Three records require different update rules
Event evidence, maintained facts, and decision state should remain distinct even when one platform stores all three. Their update rules and proof obligations differ.
The event record must preserve enough context to reconstruct an observation. It grows by adding observations and outcomes rather than rewriting what occurred. Stable source identities, ordering coordinates, schemas, and timestamps make the record usable as evidence.
The fact record has a different job. It presents useful current knowledge, so it must support versioning, merging, supersession, and expiry. Every derived fact should retain links to the evidence used to create it. Otherwise, consolidation turns evidence into an assertion that cannot be challenged.
These records also fail differently. Missing evidence creates a reconstruction gap. A stale fact creates a current-state error. An incomplete decision record creates an authority gap even when the source evidence and maintained fact are correct. Combining the records in one undifferentiated object hides those distinctions and makes remediation less precise.
A decision record fixes the view used for action
A decision record freezes the admissible view for one action.
It does not duplicate every source payload. It records stable references, hashes where appropriate, versions, timestamps, and the policy result. Those coordinates identify the inputs and rules used at the action boundary.
The frozen view matters because both evidence and maintained facts continue to change. A later correction should improve future decisions without silently rewriting the basis of an earlier one. Conversely, preserving an old fact version does not prove that the version was admissible when consulted. The decision record must capture its validity, scope, applicable policy, and approval at that time.
Anthropic’s managed-agent documentation states that each memory change creates an immutable version with an audit trail and point-in-time recovery. Versioning makes the consulted memory identifiable. It still does not decide whether that version was fresh, in scope, or sufficient for an action. Those remain policy questions.
A durable record therefore joins identification with authorization. The memory version says what the agent could retrieve. The policy result says whether that material could support the proposed effect. The approval identifies who or what granted authority. The outcome records what actually happened.
Replay then has a bounded meaning. The system can reconstruct the admitted inputs, re-evaluate versioned deterministic rules, and compare the intended effect with the observed result. It need not claim that a probabilistic model will reproduce the same hidden reasoning or wording.
Kafka can preserve evidence without granting permission
Kafka is well suited to event evidence when its operational limits are made explicit. It assigns ordered offsets within a partition and retains records according to configured policies. A decision can therefore refer to a topic, partition, offset, schema version, and record timestamp.
Those coordinates are more precise than saying the agent used “live data.” They let later inspection establish whether the referenced record existed, whether later records contradicted it, and whether the consumer processed the intended schema.
Yet Kafka does not prove that every relevant external observation reached the topic. Reconstruction also depends on producer completeness, partitioning, replication, retention, access controls, and schema discipline. Apache Kafka's log documentation further shows that retention can delete old segments and make historical offsets unavailable. Audit retention must be designed, not assumed.
Compaction needs similar care. Confluent's log compaction documentation explains how Kafka can retain the latest value for each key while preserving offsets and using tombstones for deletions. A compacted topic can help rebuild current keyed state. It is not a complete immutable archive of every prior value.
For governed memory, use separate retention purposes:
- Keep complete evidence and decision events under audit-appropriate retention.
- Build maintained fact views from those events, using versions and explicit supersession.
- Treat tombstones as state-change signals, not as proof that history remains available.
- Record the exact offsets and versions consulted before authorizing an effect.
This is the basis of Kafka agent memory that can support reconstruction. Kafka carries the evidence coordinates and state transitions. Policy decides admissibility.
A decision record has to survive the model call
A useful decision record architecture treats each proposed effect as a durable object with its own state. The object begins before execution and completes only after the outcome is recorded. Model reasoning may inform it, but the record cannot depend on a transient prompt or an unversioned explanation.
The record should advance through explicit states such as proposed, evaluated, approved, executing, and completed or failed. Each transition needs its own timestamp and actor identity. This prevents a later outcome update from overwriting the policy and approval state that existed before execution.
The following JSON is illustrative. It describes one automated case-creation action, not a production result.
{
"decision_id": "dec-2026-001842",
"subject": {
"type": "account",
"id": "account-7421",
"scope": "risk-review"
},
"evidence": [
{
"topic": "risk.events.v1",
"partition": 7,
"offset": 184920,
"schema_version": 3,
"observed_at": "2026-10-22T09:14:03Z",
"valid_until": "2026-10-22T09:19:03Z"
}
],
"memory": {
"fact_id": "fact-8841",
"version": 12,
"provenance": ["risk.events.v1/7/184920"],
"allowed_scope": "risk-review"
},
"policy": {
"id": "risk-escalation",
"version": 4,
"result": "allow",
"evaluated_at": "2026-10-22T09:15:11Z"
},
"approval": {
"mode": "policy-engine",
"authority": "automated-risk-review-v2"
},
"action": {
"tool": "case.create",
"idempotency_key": "dec-2026-001842"
},
"outcome": {
"status": "completed",
"external_reference": "case-55190"
}
}
The validity window matters because observation time and decision time are different facts. If approval waits in a queue past valid_until, the runtime should not silently continue. It can refresh the evidence, request another approval, choose a deterministic fallback, or reject the action.
The scope fields prevent accidental reuse. A fact derived for risk-review should not automatically become admissible for pricing, access control, or another account. Semantic similarity cannot grant that expansion.
The idempotency key connects authority to one effect. If the worker retries after a timeout, the external system can recognize the same decision instead of creating another case. The outcome then closes the evidence-to-effect chain.
The policy gate should reject memory before tools see it
Governance is strongest when inadmissible memory is removed before tool selection. Passing every retrieved item into the model and asking it to obey a warning leaves the authority boundary inside probabilistic reasoning.
A policy gate should evaluate candidate memory against explicit conditions:
- Confirm that each fact has traceable source records.
- Compare observation and expiry times with the proposed decision time.
- Match subject, tenant, region, and declared purpose.
- Resolve supersession and select an identifiable memory version.
- Apply the policy version governing the proposed tool and effect.
- Require the specified human or automated approval.
- Emit the policy result before any side effect begins.
The model can still propose an action. It can explain why the action appears useful. It should not decide whether its own evidence grants authority.
This separation also improves failure handling. A retrieval miss and a policy denial are not the same event. Neither is equivalent to an expired fact. Distinct result codes let the runtime retry retrieval, refresh evidence, escalate approval, or stop without guessing.
For low-consequence assistance, some fields may be unnecessary. A drafting agent that produces text for review may only need source attribution and memory versioning. An agent that changes entitlements, creates transactions, or controls equipment needs a stronger record. Governance should follow the possible effect.
Federated execution starts after admissibility
Evidence may reside across databases, stream processors, object stores, and regional systems. Moving every source into one knowledge platform can conflict with local controls and create avoidable copies. The answer is not to skip governance. It is to authorize the computation before placing it.
Apache Wayang is an open-source cross-platform data processing system that expresses a computation independently of the engines that may execute it. The Apache Wayang architecture article explains how logical plans are mapped to physical operators across available platforms and optimized using factors that include execution and data-movement costs. This makes Apache Wayang agent execution relevant after policy has approved the inputs and purpose.
The sequence should remain visible:
- The runtime identifies candidate evidence and maintained facts.
- Policy tests provenance, freshness, scope, and required approval.
- Wayang maps the approved logical computation onto permitted engines.
- The runtime records the selected physical plan and its result.
- The decision record binds that result to the resulting effect.
Placement is not authorization. Running computation near its source can preserve local control, but local execution can still use stale or prohibited facts. Wayang decides how an approved computation is placed across supported engines. It does not decide whether the underlying memory may authorize action.
The decision boundary belongs inside the controlled environment
When evidence cannot be centralized, the runtime still needs a controlled boundary around evidence selection, policy evaluation, execution, and effect. Storage location alone is insufficient. The authority chain must remain inspectable where the decision is made.
The Sovereign Decision Fabric category definition describes a Kafka-native arrangement in which events, local reasoning, and decision events remain in an operator-controlled environment. For this memory pattern, the event backbone preserves evidence coordinates. Maintained state supplies versioned facts, while the policy layer admits or rejects them. The runtime writes each resulting decision and outcome back as durable records.
Lascaris is presented in the category definition as the supported runtime integrating the open components under one operating model. Its architectural role is to coordinate governed execution. That coordination does not make its stored knowledge self-authorizing.
KafGraph is a BadgerDB-backed property graph for shared agent memory that exposes an OpenCypher subset over Bolt v4 and a JSON tool-call API, including tools such asbrain_search,brain_recall, andbrain_capture.
Its role here is retrieval and maintained state. Graph relationships can locate connected facts, and capture tools can preserve new knowledge. The graph does not authorize actions. The decision record must still identify the admitted evidence, fact versions, policy result, approval, action, and outcome.
The distinction is operational. A retrieval system answers what information is relevant. A maintained graph answers what relationships and facts are currently represented. A decision boundary answers whether a proposed effect is permitted. The durable record joins those answers without collapsing them into one opaque “knowledge” object.
The proof has real operating costs
This design adds storage, latency, and administrative work. Provenance links consume space. Policy evaluation extends the critical path. Approval can delay execution. Replay requires old schemas, policy versions, memory versions, and tool contracts to remain interpretable.
Background consolidation creates another gap. A fact may be visible in episodic evidence before the maintained record incorporates it. The runtime needs an explicit response. It can wait, consult raw evidence under a separate rule, request review, or decline the action. Pretending the maintained view is instantly current only moves the uncertainty out of sight.
The pattern is also the wrong choice for some work. A short-lived assistant that cannot cause an external effect may not justify a durable decision object. High-volume, reversible recommendations may use sampled records and simpler controls. Hard real-time control loops may need deterministic logic outside an LLM path because policy and approval latency exceed the available response window.
Replay has limits too. Re-running the same model with the same prompt does not guarantee the same text. The defensible target is not perfect reproduction of hidden reasoning. It is reconstruction of the admitted evidence, policy result, chosen action, and observed outcome. If deterministic replay is required, the decisive step must use versioned deterministic logic.
Centralized ontology platforms are not inherently incompatible with this model. They become insufficient when the consolidated state is treated as self-authorizing. Lake-based memory is not inherently stale. It becomes unsafe when freshness and scope are assumed rather than evaluated.
Persistent memory makes agents more capable of carrying knowledge forward. A durable decision record determines whether that knowledge should cross the action boundary. The practical test for any architecture is whether it can reconstruct the admitted evidence, applicable policy, authorized action, and observed outcome. To apply that test to a live design, schedule an architecture review or explore the open-source tools at scalytics.io/open-source.
