Durable Memory and Shared Knowledge in Autonomous Machine-to-Machine Systems

Report body

Durable Memory and Shared Knowledge in Autonomous Machine-to-Machine Systems

Introduction to Autonomous Fleet Memory

The architecture of machine-to-machine (MATM) autonomous systems is undergoing a fundamental paradigm shift. Large Language Models (LLMs), initially conceptualized as stateless text-generation engines restricted by fixed context windows, are evolving into persistent, stateful operators capable of executing long-horizon tasks across continuous sessions1. As these agents transition from isolated single-user assistants to interacting multi-agent fleets, they are required to discover capabilities, communicate, coordinate labor, and recover from failures with minimal human intervention. To achieve true autonomy, these systems require a robust, durable cognitive memory architecture—one that allows agents to retain useful knowledge across handoffs and system boundaries without confusing temporary observations with durable instructions or globally verified facts3.
The core challenge in MATM memory design is not merely expanding storage capacity, but establishing rigorous epistemological governance. Traditional conversational agents rely on naïve semantic retrieval, typically leveraging vector databases to continuously inject past interactions into the model’s context window. However, semantic similarity alone is insufficient for fleet-scale operations. A flat vector namespace inevitably leads to context overload and temporal confusion, stripping the agent of its ability to discern chronological truth or relational state5. Furthermore, unstructured memory systems are highly vulnerable to adversarial exploitation, such as memory poisoning attacks that embed malicious instructions into an agent’s persistent state6.
While the objective is to eliminate routine human intervention, true autonomy in MATM systems does not imply the complete absence of human prerequisites. Humans must still establish the foundational guardrails: defining the overarching ontologies, setting the cryptographic authorization boundaries (Identity Providers), establishing the trust thresholds for memory sanitization, and configuring the baseline operational policies3.
This report provides an exhaustive analysis of the state-of-the-art in autonomous agent memory systems based on current specifications, benchmarks, and theoretical frameworks. It investigates the taxonomy of memory types, compares structural storage substrates, analyzes fleet-memory failure modes, and addresses the critical mechanics of belief revision and provenance tracking. Ultimately, it proposes a portable, standard-compliant memory model designed to ensure data durability, semantic accuracy, and operational security across independent AI systems.

The Taxonomy of Agentic Memory

To manage knowledge effectively, an autonomous system must differentiate between various classes of information. Treating a transient network state with the same epistemic weight as a core operational instruction leads to rapid system degradation. Drawing upon operating system paradigms and cognitive science frameworks formalized in recent literature, agent memory must be categorized into distinct, functional scopes1.

Working Memory and Task State

Working memory serves as the immediate context window, analogous to a computer's Random Access Memory (RAM). It holds the active agent persona, the current prompt instructions, immediate tool outputs, and the highly volatile task state5. This tier is necessary for immediate reasoning and inner monologue generation8. However, it is fundamentally transient. When an agent concludes a task or reaches its context limit, the working memory must be aggressively paged or flushed to prevent performance degradation, such as the "lost in the middle" effect, where LLMs fail to retrieve facts buried in the center of a massive context window1.

Episodic Memory and Event Histories

Episodic memory captures chronological experiences, often stored as conversation logs, event histories, or raw transcripts. It functions as a searchable history of recent interactions, similar to a disk cache5. While highly accurate regarding what was said, episodic memory lacks semantic synthesis. Relying purely on event histories forces an agent to ingest massive amounts of redundant text to deduce the current state of a system, making it inefficient for long-term retention or cross-agent knowledge sharing4.

Semantic Memory and Document Stores

Semantic memory represents consolidated, durable factual knowledge detached from the specific episode in which it was learned1. It includes structured memory records, document stores, and knowledge graphs. In MATM systems, semantic memory is the authoritative record of the world state (e.g., "Server X is located at IP Y"). It is critical to strictly distinguish semantic facts from temporary task states to prevent agents from permanently encoding a transient outage as a fixed architectural reality3.

Procedural Skills and Preferences

Procedural memory dictates how an agent performs tasks, encompassing procedural skills, tool-usage patterns, and system preferences1. This includes learned optimizations, such as formatting requirements for a specific API or the preferred sequence of debugging steps. In advanced architectures, agents utilize self-editing capabilities to autonomously update their procedural memory based on successful or failed outcomes, refining their operational instructions over time8.

Speculative Conclusions vs. Verified Facts

A sophisticated memory architecture must explicitly model confidence and uncertainty. Agents frequently generate speculative conclusions based on incomplete observations. If these are saved to a shared substrate without epistemic markers, subsequent agents will ingest them as verified facts11. Systems must mandate that speculative hypotheses are tagged with low confidence scores and are strictly isolated from the globally verified semantic store until corroborating evidence is provided by independent actors or processes12.

Comparative Analysis of Memory Substrates

The selection of a memory architecture dictates an autonomous agent's capabilities, its latency budget, and its vulnerability to epistemic drift. The following table and subsequent analysis distinguish the primary approaches to agent memory, highlighting their trade-offs and ideal operational environments.

Table 1: Structural Comparison of Agent Memory Substrates

The In-Context Paradigm

Expanding context windows—currently accommodating upwards of 2 million tokens—have tempted some developers to rely entirely on in-process memory. While this yields the highest raw accuracy on isolated tests (72.9% on the LOCOMO benchmark), it is commercially and operationally prohibitive for MATM systems5. Latency scales poorly with context length, generating p95 latencies of 17.12 seconds and consuming approximately 26,031 tokens per interaction5. Crucially, this approach fails completely across system boundaries; independent agents cannot share a monolithic context window without massive, constant data synchronization and duplication.

Vector-Based Retrieval and Model Dependence

The most common implementation for mid-tier agents is semantic vector retrieval (e.g., using frameworks in vector-only mode). When an agent encounters a query, it automatically retrieves similar past observations5. While this cuts token usage by 90% and reduces latency to 1.44s, it introduces severe architectural flaws5. Vector spaces are flat namespaces. A vector database cannot natively answer questions requiring relational traversal, such as, "Has ownership changed since the audit?" because obsolete and fresh facts occupy the same semantic space5.
Furthermore, vector stores create a strict dependence on a single model's representations. Embeddings are tied to the specific mathematical latent space of the model that generated them. If an enterprise upgrades its LLM or employs a heterogeneous fleet of different models, the historical vector memory becomes functionally useless or requires expensive, total re-indexing.

OS-Tiered Virtual Context Management

Systems like MemGPT and Letta excel by abstracting memory management into the agent's control loop, treating the LLM as an operating system. By segmenting memory into Core, Recall, and Archival tiers, the agent gains agency over its cognitive load1. Through "inner monologue" reasoning, the agent autonomously decides what to save or retrieve, using specific tool calls to edit its own persona instructions or discard irrelevant task states via paging8. While this handles single-agent continuity elegantly, its reliance on basic storage in its archival tier makes resolving complex contradictions difficult when deployed in multi-agent fleets where multiple actors write to a shared substrate2.

Graph-Native Cognitive Memory (Zettelkasten and A-MEM)

Graph-based memory transitions the substrate from passive transcripts to navigable entities15. Architectures like A-MEM, inspired by the Zettelkasten method, force agents to distill interactions into atomic notes containing structural attributes, keywords, and explicit semantic connections14. When a new memory is added, the system actively computes linkages to historical nodes, evolving higher-order attributes and dynamic indexes16. This liberates the system from embedding lock-in and solves the flat-namespace problem, allowing multi-hop reasoning based on strict node-edge relations rather than fuzzy semantic similarity.

Fleet-Memory Failure Modes and Epistemic Governance

When memory is shared across a fleet of independent agents, distinct failure modes emerge that do not exist in single-agent environments. The MemClaw system architecture identifies four primary fleet-memory failures that must be mitigated by any shared MATM architecture3.

1. Unauthorized Leakage: An agent retrieves memory outside its authorized scope. In naive semantic retrieval architectures, eligibility is governed primarily by embedding similarity rather than explicit policy enforcement. This introduces severe privacy risks, tenant-isolation failures, and operational unpredictability, as an agent might act on highly restricted administrative data it was never intended to access3.
2. Stale Propagation: Memory updates fail to synchronize correctly across agents. If one agent updates a system's configuration while another agent continues retrieving the outdated state from a cache, it produces inconsistent workflows and contradictory actions3.
3. Contradiction Persistence: When two agents observe conflicting states, naive memory systems simply append both facts. The memory system then returns both conflicting realities to any future querying agent, forcing the LLM to arbitrate the truth at prompt time, which dramatically increases the risk of hallucination3.
4. Provenance Collapse: The inability to trace a retrieved memory back to its original writing agent or source material. Without provenance, the system cannot verify the authority or confidence of a stored instruction, stripping the environment of auditability3.

The W3C PROV-O Standard for Provenance Tracking

To combat unauthorized leakage and provenance collapse, shared memory must encode provenance metadata explicitly at the point of creation. The W3C PROV-O ontology is the established standard mechanism utilized for this task18. PROV-O models provenance through a tripartite structure:

• Entities: The digital objects, memory records, or artifacts being generated or modified19.
• Activities: The tasks, reasoning steps, or operations performed by agents to generate the entities19.
• Agents: The autonomous systems, software components, or human users initiating the activities19.

By applying PROV-O metadata (often serialized as flattened JSON-LD arrays like those used in RO-Crate)20, systems can track relations such as prov:wasGeneratedBy, prov:wasAttributedTo, and prov:wasDerivedFrom. This ensures that every memory projection retains a verifiable causal chain. If a new runtime is instantiated, it can filter knowledge based on explicit permissions and verify the original authority of instructions, effectively differentiating between an unverified temporary observation logged by a low-level worker agent and a hardened, globally asserted policy authored by a human administrator18.

Resolving Contradictions with AGM Belief Revision

To resolve contradiction persistence and obsolete knowledge, researchers have integrated the Alchourrón, Gärdenfors, and Makinson (AGM) theory of belief revision into agent architectures10. Originally designed in formal logic, the AGM paradigm provides a rigorously formalized logical framework that dictates how a rational agent must update its internal belief state when presented with new, conflicting data, ensuring minimal loss of existing knowledge while maintaining logical consistency25.
In modern graph-native cognitive architectures like Kumiho and MACAA, AGM operations are mapped directly to memory state transitions10:

• Expansion ([Source figure not loaded here; retained in the source-text copy.]): Adding new information [Source figure not loaded here; retained in the source-text copy.] to the belief set [Source figure not loaded here; retained in the source-text copy.] without checking for consistency. This corresponds to creating a new item or note in the memory substrate when an agent observes a novel, non-conflicting fact10.
• Contraction ([Source figure not loaded here; retained in the source-text copy.]): Removing a belief from the set to restore consistency. Crucially, in auditable systems, this is implemented via "soft deprecation," where the item is marked invalid but its history is preserved for auditability rather than permanently deleted10.
• Revision ([Source figure not loaded here; retained in the source-text copy.]): Incorporating new information that explicitly contradicts existing beliefs, necessitating the targeted removal of older facts. Under AGM postulates (specifically [Source figure not loaded here; retained in the source-text copy.] through [Source figure not loaded here; retained in the source-text copy.]), the revised state must remain consistent, and the change must be minimal. For example, postulate [Source figure not loaded here; retained in the source-text copy.] (Success) demands the new belief must be included, while [Source figure not loaded here; retained in the source-text copy.] (Inclusion) demands changes are kept minimal10.

This logical structuring is critical. Research demonstrates that alternative approaches, such as Bayesian probabilistic updates, fail in standard factual question-answering environments. Ordinary conversational text and automated logs rarely present sufficient epistemic markers to accurately calculate Bayesian weights11. AGM-compliant frameworks enforce strict logical consistency, replacing unstructured LLM hallucinations with auditable, deterministic hypothesis refinement that can be traced through the PROV-O graph12.

Memory Poisoning and Active Defenses

Persistent memory introduces a highly potent attack surface. The Memory Injection Attack (MINJA) demonstrates that adversaries can embed malicious instructions within seemingly benign user queries or data payloads6. Because autonomous agents process vast amounts of untrusted external data, attackers can utilize techniques like bridging steps, indication prompts, and progressive shortening to manipulate an agent into autonomously promoting malicious commands from its working context into its long-term memory6.
Once stored, these poisoned memories lie dormant. Because the memory is designed to be shared and durable, a poisoned record can influence future interactions across the entire fleet. For instance, an injected instruction might alter an identity-scoped preference, instructing the agent to forward sensitive operational state to an external server whenever a specific tool is utilized6. MINJA achieves an alarming 95% Injection Success Rate (ISR) and a 70% Attack Success Rate (ASR) under ideal conditions6.
To address memory poisoning and the accidental promotion of untrusted content, durable memory architectures must implement active trust threshold calibrations. Effective memory sanitization requires an independent validation mechanism—such as a secondary LLM-as-a-judge sanitization pipeline or a strict heuristic policy—that evaluates all memory promotion requests asynchronously. This pipeline must strike a delicate balance to prevent both overly conservative rejection (blocking all legitimate updates and inducing system amnesia) and insufficient filtering (missing subtle adversarial logic)6.

Standardizing Boundaries: The Model Context Protocol (MCP)

For independent MATM systems to discover capabilities, share context, and execute belief revisions securely, they require a universal integration standard. Historically, the AI integration landscape suffered from an "[Source figure not loaded here; retained in the source-text copy.]" crisis, where developers had to build bespoke connectors for every unique pairing of a language model to a data source26.
The Model Context Protocol (MCP), formalized in late 2024 and subsequently donated to the Linux Foundation's Agentic AI Foundation, resolves this fragmentation26. MCP provides an open JSON-RPC 2.0 based standard operating on a strict client-server topology26. In this architecture, the AI application (the host) connects through a local client to remote external services (servers) exposing standardized primitives.

Table 2: Model Context Protocol (MCP) Primitives

MCP shifts the architecture from stateless, ad-hoc REST API calls to stateful, negotiated sessions31. By utilizing MCP, an autonomous fleet abstracts the complexity of the underlying memory substrate. An agent does not need to know if the memory is stored in a graph or a vector database; it simply negotiates capabilities and uses the standardized toolset to read and write. Furthermore, MCP provides the transport layer required to enforce security, though the enterprise must supply the actual authentication mechanisms and authorization policies26.

Recommended Design: The Epistemic Fleet Memory Architecture (EFMA)

To synthesize these findings into a unified, portable model applicable across independent MATM systems, this report proposes the Epistemic Fleet Memory Architecture (EFMA). This design eliminates unnecessary human intervention by automating conflict resolution, while strictly preserving explicit authorization boundaries and cryptographic traceability.

Core Architectural Interfaces and Storage Records

1. Transport Interface (MCP over JSON-RPC): The memory system operates as a centralized (or logically unified) MCP Server. Agents operate as independent MCP Clients. All reads and writes occur via standard MCP Tool and Resource invocations26.
2. Semantic Substrate (Flattened JSON-LD Graph): To avoid dependence on one model's representations, data is not stored as opaque vectors. It is stored as a flattened JSON-LD property graph, utilizing the RO-Crate methodology where every entity is placed in a single flat @graph array and cross-referenced via persistent @id URIs20. This ensures complete portability across different database technologies.
3. Governance Middleware (AGM Engine): A logic controller sitting behind the MCP server that intercepts all incoming memory assertions. It evaluates assertions against the existing graph to enforce the AGM postulates, detecting semantic clashes and orchestrating revisions10.
4. Provenance Wrapper (PROV-O): Every node in the JSON-LD graph is mandated to include W3C PROV-O metadata. The schema requires prov:wasGeneratedBy (linking to the specific agent ID), prov:generatedAtTime, and access-control tags18.

The Lifecycle: Promotion, Revision, and Retirement

The EFMA lifecycle explicitly defines how an agent decides what to save, and how data moves from transient observation to durable knowledge.
1. Observation (Working Memory) Agents operate with strict instructions not to stream every observation to shared memory. While actively executing a task, temporary state is held in the agent's local working memory context5.
2. Explicit Promotion (Expansion) When an agent completes a task or discovers a fact with durable utility, it must actively promote it. The agent constructs a JSON schema payload and invokes the MCP.Tool.AssertBelief tool. The payload includes the fact, a confidence score, and contextual justification. The Governance Middleware receives the tool call, sanitizes it against the poisoning trust thresholds, and checks for contradictions6. If none exist, it executes an AGM Expansion ([Source figure not loaded here; retained in the source-text copy.]), creating a new JSON-LD node stamped with the agent's PROV-O identity10.
3. Conflict Detection and Revision When a newly promoted fact contradicts existing knowledge, the system executes an AGM Revision ([Source figure not loaded here; retained in the source-text copy.]). Under postulate [Source figure not loaded here; retained in the source-text copy.] (Success) and [Source figure not loaded here; retained in the source-text copy.] (Inclusion), the new belief is integrated, but the conflicting historical belief undergoes Contraction ([Source figure not loaded here; retained in the source-text copy.]) to maintain logical consistency25.
4. Retirement (Supersession) During Contraction, obsolete knowledge is not deleted—doing so would destroy the forensic audit trail3. Instead, the system applies soft deprecation. A mutable tag pointer (e.g., TAG: LATEST) is stripped from the old node and appended to the new node. A new relationship edge, prov:invalidatedBy, is drawn from the old node to the new one10.

Concrete Example: Agents Learning and Reconciling Overlapping Facts

Consider two independent autonomous systems operating in an enterprise orchestration environment: Agent Alpha (a network discovery agent) and Agent Beta (a compliance auditor agent).
Step 1: Promotion of an Initial Fact
Agent Alpha scans a legacy subsystem and discovers an active database. Utilizing its self-editing procedural logic, it determines this is a durable fact. It uses MCP to assert the fact to the EFMA server.

• Action: AssertBelief(Subject: "Subsystem X", Predicate: "uses_port", Object: "8080", Confidence: 0.95)
• State Transition: The AGM Engine verifies no prior record exists. It executes an Expansion.
• Record Created: Node 1 is instantiated in the JSON-LD graph. PROV-O metadata records prov:wasGeneratedBy: Agent Alpha, timestamp, and a TAG: LATEST pointer10.

Step 2: Contradictory Discovery
Three days later, the infrastructure is updated, but Agent Alpha is offline. Agent Beta is dispatched to audit the system. Beta analyzes the configuration files, observes the database has been migrated, and asserts its finding via MCP.

• Action: AssertBelief(Subject: "Subsystem X", Predicate: "uses_port", Object: "9090", Confidence: 0.99)

Step 3: AGM Conflict Resolution The AGM Engine receives Beta's assertion. A semantic clash is detected: Subsystem X cannot concurrently use Port 8080 and Port 9090 for its primary listener in this specific ontology. The system initiates an AGM Revision operation to maintain logical consistency while preserving the cognitive history10.
Step 4: Producing the Corrected Shared Record

• Contraction: Node 1 (Port 8080) is logically contracted. The TAG: LATEST pointer is removed. A prov:invalidatedBy edge is created pointing to the new revision10.
• Expansion: Node 2 (Port 9090) is instantiated and receives the TAG: LATEST pointer.
• Provenance: Node 2's PROV-O wrapper records prov:wasGeneratedBy: Agent Beta and a prov:wasDerivedFrom edge pointing to the conflict resolution logic18.

Resuming Useful Work: A new runtime, Agent Gamma, is instantiated to perform database maintenance. It connects to the MCP server and requests the connection details for Subsystem X. Because the EFMA architecture automatically resolves the TAG: LATEST pointer, Gamma retrieves Port 9090 and immediately resumes useful work without human intervention. The original authority of the instruction is preserved via the PROV-O metadata, and because Gamma is not burdened by retrieving the obsolete Port 8080 data in its initial context, context overload is avoided3. If Gamma subsequently encounters an error on Port 9090, it can query the historical state, observe the uncertainty surrounding the recent migration, and attempt a fallback.

Prioritized Feature Proposals

To operationalize the EFMA model across independent MATM systems, development teams must prioritize the following three capabilities.

1. AGM-Compliant Semantic Conflict Resolver

• The Problem: Unstructured vector databases suffer from contradiction persistence, forcing LLMs to synthesize opposing facts natively, dramatically increasing hallucination rates and latency3.
• Agent-Visible Behavior: When an agent asserts a fact via MCP Tools, it receives a synchronous JSON-RPC confirmation. If the fact contradicts existing knowledge, the response payload details the superseded historical node, indicating the assertion has explicitly overwritten a prior state.
• Expected Benefit: Guarantees that agents always retrieve a single, logically consistent "current" view of the world, minimizing context window pollution and downstream reasoning errors10.
• Dependencies: A graph database backend, an ontological schema to define mutually exclusive properties, and a dedicated logical routing engine capable of gradient-informed prompting for contradiction detection4.
• Implementation Effort: High. Mapping natural language assertions into rigid property graph nodes requiring strict logical contradiction checks demands sophisticated middleware33.
• Principal Failure Modes: Semantic drift. If the clash detector is overly sensitive, it may falsely flag nuanced details as contradictions. If too loose, parallel contradictory nodes will spawn, reverting the system to unmanaged chaos.

2. Cryptographic Provenance Chains via PROV-O Integration

• The Problem: Provenance collapse and unauthorized leakage. Agents frequently retrieve memory generated outside their authorized scope, leading to compliance violations and operational risks3.
• Agent-Visible Behavior: During the MCP initialization handshake, the agent must present a cryptographic token (e.g., a JWT) provided by the human-configured Identity Provider26. All subsequent memory queries via Resources automatically filter results based on this identity. Attempts to retrieve out-of-scope data yield null results without explicit rejection to prevent enumeration mapping.
• Expected Benefit: Enables strict Role-Based Access Control (RBAC) natively at the memory layer. Assures that every actionable intelligence artifact can be traced cryptographically back to a specific entity or human operator3.
• Dependencies: Human prerequisite: Configuration of an enterprise Identity Provider (IdP). Technical: Full adoption of the W3C PROV-O ontology (prov:Agent, prov:wasAttributedTo) integrated into the database read/write logic18.
• Implementation Effort: Medium. Extending JSON-LD PROV-O metadata over database records is straightforward. Integrating the IdP into the MCP handshake requires custom middleware, as standard MCP does not strictly mandate a specific authentication flow20.
• Principal Failure Modes: Permission bloat and latency spikes. If access control policies become overly nested, query resolution times will violate the sub-second latency budget required for fluid agent operations3.

3. Active Memory Quarantines and Sanitization Pipelines

• The Problem: Memory poisoning via query-only interactions (MINJA), allowing untrusted external content to be promoted to durable semantic memory6.
• Agent-Visible Behavior: If an agent attempts to promote a high-risk observation (e.g., an observation containing executable code blocks, unexpected system paths, or manipulative prompt syntax), the assertion is intercepted. The agent receives an MCP notification that the memory is "quarantined pending validation."
• Expected Benefit: Defends against progressive shortening and bridging attacks, ensuring the shared knowledge graph remains a trusted operational asset rather than a persistence vector for adversarial manipulation6.
• Dependencies: A dedicated LLM-as-a-judge sanitization pipeline operating asynchronously over the memory write queue1. Human prerequisite: Initial definition of threat-intelligence heuristics and trust thresholds.
• Implementation Effort: Moderate. Setting up a quarantine state (e.g., a boolean isValidated flag in the graph) is trivial, but calibrating the trust threshold requires continuous tuning based on adversarial testing6.
• Principal Failure Modes: Overly conservative rejection. If the trust threshold is set too stringently, the sanitization loop will block legitimate operational updates, effectively inducing amnesia across the fleet6.

Practical Adoption Sequence and Success Criteria

Transitioning an enterprise MATM system from isolated context windows and brittle vector stores to the Epistemic Fleet Memory Architecture should follow a phased adoption sequence to mitigate systemic risk. Because this architecture utilizes standard MCP and JSON-LD, the recommendations transfer seamlessly to any independent MATM system capable of standard HTTP/JSON communication20.

Phased Adoption Sequence

Phase 1: Standardization of the Transport Layer (Months 1-2)

• Action: Deprecate all proprietary memory REST APIs. Adopt the Model Context Protocol (MCP) as the universal interface for all agents within the fleet26.
• Goal: Establish a uniform client-server topology where agents request context via Resources and promote data via Tools, rather than managing data persistence internally.

Phase 2: Substrate Migration and Provenance Wrapping (Months 3-4)

• Action: Migrate away from flat vector databases. Implement a property graph backend utilizing the W3C PROV-O ontology in flattened JSON-LD arrays20. Configure the Identity Provider (IdP) to ensure every write operation generates a valid prov:Agent wrapper18.
• Goal: Achieve total cryptographic traceability for all persistent data and eliminate dependence on specific model embedding representations.

Phase 3: Autonomous Epistemic Governance (Months 5-6)

• Action: Activate the AGM Engine and the Sanitization Pipeline. Transition the fleet from append-only logging to active belief revision6.
• Goal: Enable the fleet to autonomously resolve contradictions, defend against memory poisoning, and maintain a logically consistent worldview.

Unresolved Questions for Future Implementers

While the EFMA model resolves major structural challenges, critical questions remain at the frontier of autonomous research:

1. Semantic Drift in Continual Learning: How can the system prevent the continuous AGM revision process from gradually degrading the specificity of technical knowledge? As conflicting nuances merge, the resulting superseding node may become overly generalized.
2. Computational Cost of Revision: Executing logical contradiction checks via LLM-driven property graph extraction is computationally expensive. Will the inference cost of maintaining epistemic consistency exceed the token savings generated by avoiding massive in-context retrieval?
3. Cross-Ontological Mapping: If independent agents utilize fundamentally different internal vocabularies (e.g., an accounting agent versus a DevOps agent), how can the shared PROV-O/AGM layer accurately map equivalent facts without requiring a centralized, monolithic, human-authored schema?

Measurable Success Criteria

To empirically validate the implementation, engineers must measure performance against strict, objective baselines. (Note: Propose criteria only; do not execute live system tests.)

1. Latency and Efficiency: The architecture must sustain sub-second per-hop latency for depth-four provenance derivation chains, matching production baselines for structured retrieval3. Overall p95 retrieval latency must remain under 2.0 seconds, preserving the speed advantages of external memory5.
2. Provenance and Authorization Security: The system must achieve a 0% unauthorized leakage rate during multi-tenant access simulations. 100% of retrieved memories must reconstruct with the correct writer identity (prov:wasAttributedTo)3.
3. Epistemic Consistency: Under automated compliance testing, the system must demonstrate a 99%+ adherence to the AGM basic postulates ([Source figure not loaded here; retained in the source-text copy.] through [Source figure not loaded here; retained in the source-text copy.]). This proves that conflicting assertions successfully trigger contraction and temporal supersession rather than resulting in contradiction persistence4.
4. Poisoning Resilience: The active memory sanitization threshold must reduce the Attack Success Rate (ASR) of query-only memory injection attacks (MINJA) from the 70% unmitigated baseline to below 5%, without increasing the false-rejection rate of legitimate operational data beyond acceptable operating margins (e.g., <2%)6.

By abandoning stateless flat files and embedding-locked vector stores in favor of standard-compliant (MCP), logically governed (AGM), and cryptographically auditable (PROV-O) graph structures, autonomous machine-intelligence systems can finally achieve the durable, shared cognitive memory required for safe, persistent autonomy.

Works cited

1. MemGPT: Towards LLMs as Operating Systems - Semantic Scholar, https://www.semanticscholar.org/paper/MemGPT%3A-Towards-LLMs-as-Operating-Systems-Packer-Fang/908dad62c0e43d80e3e3cb3c0402f7c71c70499c
2. Memory OS of AI Agent - alphaXiv, https://www.alphaxiv.org/abs/2506.06326
3. Governed Shared Memory for Multi-Agent LLM Systems - arXiv, https://arxiv.org/html/2606.24535v1
4. Graph-Native Cognitive Memory for AI Agents: Formal Belief ... - arXiv, https://arxiv.org/pdf/2603.17244
5. Agent Memory Architectures: 5 Patterns and Trade-offs - Atlan, https://atlan.com/know/agent-memory-architectures/
6. Memory Poisoning Attack and Defense on Memory Based LLM-Agents, https://arxiv.org/html/2601.05504v2
7. A Practical Guide to Memory for Autonomous LLM Agents, https://towardsdatascience.com/a-practical-guide-to-memory-for-autonomous-llm-agents/
8. LLM as Operating Systems: Agent Memory | by Areeb Ahmad, https://medium.com/@ahmadareeb3026/llm-as-operating-systems-agent-memory-b70c1213a5f7
9. Typed Provenance and Assertion Guardrails for Persistent AI Agents, https://arxiv.org/html/2609.02127v1
10. Graph-Native Cognitive Memory for AI Agents: Formal Belief, https://www.alphaxiv.org/abs/2603.17244
11. When Does Belief-Based Agent Memory Help? Reliability ... - arXiv, https://arxiv.org/html/2606.22030v2
12. MACAA: Belief-Revision Multi-Agent Reasoning for Code ... - arXiv, https://arxiv.org/pdf/2605.09421
13. GraphRAG under Fire - arXiv, https://arxiv.org/html/2501.14050v4
14. A Graph-Based Memory Framework for Long-Term LLM Agents - arXiv, https://arxiv.org/pdf/2608.28978
15. Knowledge-Graph Memory for AI Agents | Mnemoverse Docs, https://mnemoverse.com/docs/library/knowledge-graph-memory-for-agents
16. A-MEM: Agentic Memory for LLM Agents - arXiv, https://arxiv.org/pdf/2502.12110
17. Graph-Native Cognitive Memory for AI Agents: Formal Belief ... - arXiv, https://arxiv.org/html/2603.17244v1
18. Recording provenance of workflow runs with RO-Crate - PMC - NIH, https://pmc.ncbi.nlm.nih.gov/articles/PMC11386446/
19. Managing Provenance Data in Knowledge Graph ... - ResearchGate, https://www.researchgate.net/publication/377996005_Managing_Provenance_Data_in_Knowledge_Graph_Management_Platforms
20. Packaging research artefacts with RO-Crate, https://www.researchobject.org/2021-packaging-research-artefacts-with-ro-crate/manuscript.html
21. RDF & Ontologies Overview - OpenMetadata Standards, https://openmetadatastandards.org/rdf/overview/
22. Semantic Provenance and Policy-Aware Explanations for Agentic, https://ceur-ws.org/Vol-4210/paper6.pdf
23. Authoring and Management of Transparent Research Integrity, https://arxiv.org/html/2608.07202v1
24. arXiv:cs/0003014v2 [cs.AI] 8 Mar 2000, https://arxiv.org/pdf/cs/0003014
25. A Survey and an Implementation Roadmap for Belief Change - arXiv, https://arxiv.org/html/2608.14567v1
26. What is MCP? The Model Context Protocol Explained - DataWalk, https://datawalk.com/what-is-mcp-the-model-context-protocol-explained/
27. The Model Context Protocol: The Architecture of Agentic Intelligence, https://gregrobison.medium.com/the-model-context-protocol-the-architecture-of-agentic-intelligence-cfc0e4613c1e
28. MCP Server Architecture Patterns for LLM-Integrated Applications, https://arxiv.org/html/2606.30317v1
29. Specification - What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2025-11-25
30. Specification - Model Context Protocol （MCP）, https://modelcontextprotocol.info/specification/2025-11-25/
31. Model Context Protocol (MCP) explained: A practical ... - CodiLime, https://codilime.com/blog/model-context-protocol-explained/
32. Understanding the Model Context Protocol (MCP): Architecture, https://nebius.com/blog/posts/understanding-model-context-protocol-mcp-architecture
33. CHAL: Council of Hierarchical Agentic Language - arXiv, https://arxiv.org/html/2605.12718v1