Seeking AI/ML Collaborators: Building Marven — A Local AI with Persistent Memory, Continual Learning, and Human-State Awareness

Hi everyone,

I’m the founder of Heshware LLC, and I’m currently developing an AI project called Marven.

Marven started as an experiment in building a more personal AI assistant, but over time the project has grown into a larger research and engineering question:

What would it take to build a local-first AI system that doesn’t simply respond to prompts, but develops meaningful continuity with a user over long periods of time?

The goal is not to claim that Marven is conscious or to build another wrapper around an LLM.

I’m interested in developing an architecture where an AI can maintain persistent memory, understand changing human context, learn from long-term interactions, preserve continuity across sessions, and operate primarily on infrastructure controlled by the user.

What I’m Trying to Build

The long-term vision for Marven is a Personal Sovereign AI — an AI system whose memory, models, identity data, and personal context can remain under the user’s control rather than existing entirely inside a centralized cloud platform.

Some of the capabilities I’m exploring include:

  • Persistent long-term memory
  • Episodic and semantic memory
  • Memory consolidation and archival
  • Retrieval-augmented generation
  • Continual learning without blindly retraining on every interaction
  • User-specific context modeling
  • Emotional and conversational context
  • Voice-based human-state detection
  • Long-term identity and behavioral continuity
  • Local inference
  • Hybrid local/cloud model routing
  • AI tool use and agent capabilities
  • Permission and memory boundaries
  • A persistent digital-human interface

One of the core questions behind Marven is:

Can an AI maintain continuity with someone for years while still giving that person ownership and control over what the AI remembers?


Current Architecture

Marven is still experimental and the architecture continues to evolve.

The current/local stack has included:

LLM inference

  • Ollama
  • Mistral 7B
  • Llama 3 8B
  • Phi-3 experimentation
  • Exploring vLLM for improved inference infrastructure
  • Experimenting with LoRA/fine-tuning for Marven-specific behavior

Memory

  • SQLite-based persistent memory storage
  • FAISS/vector retrieval
  • RAG-based contextual memory
  • Structured memory objects
  • Conversation history
  • Long-term memory archives

I’ve also been experimenting with what I call the MetaMirror system.

MetaMirror is intended to represent more than conversation history. The idea is to maintain structured observations about interaction context and how that context changes over time.

For example:

Interaction
   ↓
Conversation / Voice Input
   ↓
Context Analysis
   ↓
Working Memory
   ↓
Memory Importance Evaluation
   ↓
Episodic / Semantic Memory
   ↓
Long-Term Memory Archive
   ↓
Retrieval + Context Reconstruction
   ↓
Future Marven Interaction

The architecture is moving toward separating memory into different layers instead of continuously dumping conversations into a vector database.

That distinction is becoming increasingly important to me.

Remembering everything is not necessarily intelligence.

Knowing what should be remembered, what should be forgotten, what should be summarized, and when something should be retrieved is a much harder problem.


Human-State Awareness

Another part of the project is what I’m currently thinking of as a Human-State Engine.

The idea is to give Marven additional context regarding how someone is communicating rather than only processing the literal words they say.

Potential signals include:

  • Text sentiment
  • Linguistic tone
  • Speaking speed
  • Changes in vocal pitch
  • Pauses
  • Energy level
  • Conversational patterns
  • Long-term deviations from an individual’s normal communication style

Future experiments could potentially include visual signals, but I want this architecture to be privacy-conscious and based around explicit user consent.

For example, instead of simply receiving:

"I'm fine."

the system might internally receive contextual information closer to:

Text: "I'm fine."

Voice indicators:
- lower energy than personal baseline
- longer pause before response
- reduced speaking speed

Conversation context:
- previously discussing stressful event

Confidence:
- uncertain emotional state

The LLM still determines how to respond, but it receives richer contextual information.

Importantly, I do not want Marven confidently diagnosing someone’s emotions.

Human-state detection should be probabilistic and uncertain by design.


Digital Human / Presence Layer

I’ve also been working on a persistent visual representation of Marven.

The current direction uses a 3D digital-human interface with states such as:

  • Idle
  • Listening
  • Thinking
  • Speaking
  • Eye contact
  • Facial movement
  • Environmental changes based on interaction mode

The goal isn’t simply to create an animated chatbot.

I’m interested in whether maintaining a consistent visual and behavioral presence contributes to the feeling of continuity in long-term human-AI interaction.


Voice

The voice pipeline has experimented with technologies including:

  • Whisper
  • faster-whisper
  • Vosk
  • Local speech recognition
  • Neural TTS experimentation

Eventually I want voice interaction to operate with sufficiently low latency that Marven feels less like:

Speak → wait → AI responds

and more like a natural conversational system.

That requires work across:

Wake word
   ↓
Voice activity detection
   ↓
Streaming STT
   ↓
Context + memory retrieval
   ↓
Model inference
   ↓
Streaming TTS
   ↓
Digital-human animation

Latency across that entire pipeline is one of the engineering challenges I’m currently investigating.


The Hardest Problem: Memory

The part of Marven I’m currently most interested in improving is the memory architecture.

Most current AI assistants effectively have some combination of:

Conversation History
+
Vector Database
+
Retrieval

That works, but I’m interested in something more structured.

I’m experimenting conceptually with a system closer to:

Sensory / Interaction Memory
          ↓
     Working Memory
          ↓
   Importance Scoring
          ↓
 ┌────────┴─────────┐
 ↓                  ↓
Episodic          Semantic
Memory             Memory
 ↓                  ↓
 └────────┬─────────┘
          ↓
Memory Consolidation
          ↓
Long-Term Archive
          ↓
Contextual Retrieval

Some questions I’m investigating:

How should memory importance be calculated?

Something mentioned once may be extremely important, while something repeated every day may not be.

How should memory decay work?

Human memory isn’t an infinitely growing database.

How should contradictions be handled?

If someone’s preferences or beliefs change, the AI shouldn’t continue retrieving outdated information as if it were current.

How do you prevent memory poisoning?

If an attacker can manipulate persistent memory, prompt injection becomes much more dangerous.

How should memories be consolidated?

Hundreds of interactions about the same subject should potentially become a higher-level semantic representation rather than hundreds of individual memories.

How can the model know why a memory matters?

Similarity alone may not be enough for good retrieval.


Continual Learning

Another challenge is determining how much of Marven’s learning should happen through:

  • Prompt/context learning
  • Retrieval
  • Structured memory
  • Adapter training
  • LoRA
  • Periodic fine-tuning
  • Preference models
  • User-specific models

I don’t think continuously fine-tuning the base model on every user interaction is necessarily the correct solution.

My current thinking is that most personalization should initially happen through memory and contextual systems, while actual model-weight updates happen much more deliberately.

I’d be especially interested in hearing from anyone researching continual learning or catastrophic forgetting.


AI Security

Persistent memory also creates an entirely new security problem.

I’m actively thinking about threats including:

  • Prompt injection
  • Persistent-memory poisoning
  • RAG poisoning
  • Malicious document ingestion
  • Tool/agent permission escalation
  • Sensitive-memory exfiltration
  • Cross-user memory leakage
  • Model supply-chain risks

A personal AI could eventually know more sensitive contextual information about someone than almost any other piece of software they use.

That means security cannot be something added after the architecture is finished.

I’m particularly interested in architectures where memories have permissions, provenance, confidence scores, timestamps, and potentially cryptographic integrity verification.


Local-First Infrastructure

One of Marven’s fundamental design principles is that users should eventually have the option to run significant portions of the system locally.

That could mean:

Personal Device
       ↓
Local Marven Node
       ↓
Local Memory Database
       ↓
Local / Home LLM Server
       ↓
Optional Cloud Models

The cloud should ideally become an optional compute resource rather than the permanent owner of someone’s AI memory.

I’m also exploring home-server/NAS-style architectures where an individual’s long-term AI memory could exist on storage they physically control.


What I’ve Built So Far

Marven isn’t only a concept.

I’ve already experimented with or built portions of:

  • Local LLM inference
  • Persistent SQLite memory
  • Vector-based retrieval
  • RAG
  • Marven-specific structured memory
  • Voice recognition pipelines
  • Text-to-speech
  • Digital-human presence
  • React Native companion interfaces
  • User authentication
  • Local/cloud architecture experiments
  • Memory/context engines
  • Emotional-context experiments
  • LoRA dataset preparation
  • Multi-component AI pipelines

A lot of these pieces are currently separate experiments.

One of my current priorities is turning them into a cleaner unified architecture.


What I’m Looking For

I’m posting here because I would really like feedback from people who work in areas such as:

  • LLM architecture
  • RAG
  • Vector databases
  • Knowledge graphs
  • Continual learning
  • Memory architectures
  • Fine-tuning / LoRA
  • Local inference
  • Quantization
  • Speech AI
  • Multimodal AI
  • AI security
  • Agent architecture
  • Human-computer interaction
  • Affective computing
  • Digital humans

I’m especially interested in contributors who enjoy experimenting with research ideas and turning them into working prototypes.

You don’t need to be an expert in every area.

Even feedback like:

“Your memory architecture will eventually break because of X.”

or

“There’s a paper/project you should study that already tackles part of this.”

would be extremely useful.


Questions for the Hugging Face Community

I’d particularly like opinions on a few questions:

1. If you were designing long-term memory for an AI intended to interact with someone for 5–10+ years, what architecture would you use?

2. Would you combine vector retrieval with a knowledge graph, or use another architecture entirely?

3. What is the best way to separate episodic memory from semantic/user-profile memory?

4. How would you design memory consolidation and forgetting?

5. How would you defend persistent AI memory against poisoning and prompt injection?

6. What parts of personalization actually deserve model fine-tuning versus external memory?

7. Are there open-source projects or papers exploring similar long-duration human-AI relationships that you think I should study?


Collaboration

I’m also open to collaborating with developers or researchers who find these problems interesting.

Right now I’m particularly interested in people who could help experiment with:

Memory / RAG

  • memory ranking
  • memory consolidation
  • knowledge graphs
  • retrieval architectures

Local AI

  • inference optimization
  • quantization
  • vLLM
  • local model routing

Continual Learning

  • LoRA/adapters
  • preference learning
  • safe personalization

Voice / Multimodal

  • streaming speech recognition
  • conversational latency
  • voice-state analysis

AI Security

  • prompt-injection defenses
  • memory provenance
  • RAG security
  • permission systems

This is still an early-stage research and development project, so I’m interested in people who enjoy exploring difficult questions rather than only implementing a predetermined product specification.

Marven is being developed through Heshware LLC, but I’m also interested in keeping portions of the research and experimentation open enough that other developers can learn from it and contribute ideas.


Ultimately, the question I’m trying to explore with Marven is pretty simple:

What happens when an AI stops being something you repeatedly start a new conversation with and instead becomes a system capable of maintaining years of meaningful, user-controlled continuity?

There are a lot of unanswered engineering, security, privacy, and research questions between here and there.

That’s exactly why I’m interested in building it.

I’d love to hear what the Hugging Face community thinks.

Marven sounds like a really interesting project! I’d definitely be interested in the ideas behind it, especially the memory and continual learning parts. Unfortunately, I’m currently very busy with my own projects, so I wouldn’t be able to contribute seriously right now. Still, it would have been a pleasure to help and exchange ideas. I wish you the best with Marven!

Hmm… maybe something like this?:


I think the direction you are taking with Marven makes sense, especially the decision to move away from treating “memory” as just conversation history + a vector store.

If I had to choose a default architecture for a system intended to stay with one person for 5–10+ years, I would probably make one fairly strong separation early:

raw interactions / observations
        ↓
durable evidence / episodic history
        ↓
derived claims / semantic memory
        ↓
current user-state projection
        ↓
retrieval views: FTS / vector / graph
        ↓
context assembly

I would avoid letting the retrieval layer itself become the canonical source of truth.

That gives you somewhere to preserve history even when a user’s current state changes, and it also gives you a place to attach provenance, timestamps, confidence, permissions, and deletion lineage without forcing all of that into embeddings.

My short answers to your seven questions would be roughly:

Question My default starting point
1. 5–10 year architecture? Durable event/evidence history + structured current-state layer + replaceable retrieval indexes.
2. Vector + graph? Start with structured/FTS/vector retrieval; add a graph where measured relational/multi-hop failures justify it.
3. Episodic vs semantic? Episodic = evidence of what happened; semantic/profile = derived claims; current profile = a projection over those claims.
4. Consolidation/forgetting? Make consolidation reversible and provenance-preserving; separate “not retrieved”, “not current”, “archived”, and “deleted”.
5. Poisoning? Treat memory as untrusted data until provenance/policy checks pass; retrieval relevance must not imply authority.
6. Fine-tuning vs memory? Mutable personal facts belong in external memory first; use PEFT for relatively stable behavior/style/skills where it demonstrably helps.
7. Related work? LongMemEval, TiMem, Inside Out/PersonaTree, Graphiti, Mem0, A-MEM, Letta, MemoryBank, RecMem, OPPU/Profile-to-PEFT, plus RAG/memory security work.

The part I would test first is not whether the system can remember more. It is whether it can change its mind without destroying history.

For example, all of these should behave differently:

"My favorite player is Ronaldo."
→ later:
"My current favorite player is Messi."
"I use Python for data analysis."
→ later:
"I also use Rust for systems work."
"In the morning I prefer coffee."
→ later:
"In the evening I prefer tea."

The first looks like a current-state update. The other two are coexistence.

That distinction sounds simple, but there are already concrete examples of both failure directions in current memory systems. Mem0 issue #5867 reports an ADD-only path retaining both old and new “favorite player” memories. In the opposite direction, Graphiti issue #1728 reports invalidation candidates becoming too broad, allowing unrelated still-valid facts to be retired. Graphiti issue #1666 also shows the other failure mode: a smaller contradiction judge missing genuine contradictions.

So I would treat “is this new fact related?” and “is this new fact allowed to retire the old one?” as two different questions.

A small mutation contract might look something like:

scope
subject
canonical slot
qualifiers/context
cardinality
mutation policy
source/provenance
confidence
valid time
observed time

and then:

retrieve possible candidates
        ↓
structurally restrict candidates
        ↓
LLM may judge/update semantics
        ↓
deterministic policy gate
        ↓
atomic canonical-state commit

In other words, the LLM can propose that something has been superseded, but I would hesitate to let the LLM alone have authority to destructively rewrite canonical memory.

That may sound more database-like than cognitive, but I think that is compatible with MetaMirror rather than opposed to it: the “cognitive” layers can sit above a boring, auditable substrate.

A very cheap early test suite could probably tell you a lot before committing to a much larger memory architecture:

  1. preference A → explicit preference B;
  2. A and B are both current;
  3. A in context X, B in context Y;
  4. old employer → explicit new employer;
  5. employee + GitHub administrator at the same organization;
  6. an external document claims something about the user;
  7. unknown question → abstain instead of inventing a memory;
  8. user A / user B isolation;
  9. delete/forget → check SQL + vector + graph + cache projections;
  10. two concurrent writes for the same user state.

Those are cheap, but they exercise several of the failure modes that become painful only after the memory store is large.

LongMemEval is also useful here because it explicitly separates long-term memory into information extraction, multi-session reasoning, knowledge updates, temporal reasoning, and abstention. I think that decomposition is useful even if you never adopt the benchmark itself.

1. Long-term architecture: evidence, claims, and current state

For a multi-year assistant, I would probably resist having a single generic memory object with an importance score that controls everything.

There are several independent questions:

Should this be stored?
Should this remain current?
Should this be easy to retrieve?
Is it trustworthy?
May this user/agent see it?
May it influence a tool action?
May it be permanently deleted?

Those decisions do not necessarily share the same score.

I would also distinguish at least three memory/state shapes.

A. Evidence / episodic records

These record what actually happened or was observed:

episode_id
timestamp
speaker/source
raw or normalized content
provenance
scope
integrity metadata

These are useful because semantic/profile memories can later be wrong.

B. Derived claims

Examples:

user currently prefers X
user has goal Y
user works with project Z

A claim should ideally retain links back to its supporting evidence.

Something like:

claim_id
subject_id
slot_id
value
qualifiers
valid_from
valid_to
confidence
status
source/evidence refs
superseded_by

C. Current-state projection

This is the compact state Marven normally wants during interaction.

It should be reconstructable from the claims/evidence rather than being the only copy of the user’s history.

This resembles patterns outside LLM memory too: event sourcing keeps an append-oriented history and produces a materialized current view. Slowly-changing-dimension/bitemporal database designs similarly distinguish historical validity from the current projection.

For conversational memory specifically, TiMem is interesting because it explicitly builds temporal-hierarchical memory from raw conversational observations toward increasingly abstract persona representations.

Inside Out / PersonaTree is also quite close to your problem. It maintains a schema-constrained user-centric memory tree and evolves it through structured ADD, UPDATE, DELETE, and NO_OP operations.

I would not take either hierarchy as a required architecture, but they are useful evidence that “raw history” and “maintained user state” are worth modeling separately.

One additional implementation detail: not every user property naturally wants the same physical representation.

For example:

preferred_name      → scalar
primary_email       → pointer to an email collection
emails              → collection
employment          → collection of engagements
interests           → multi-valued/soft claims
preferences         → context-qualified claims
human-state signals → short-lived observations/inferences

A naive current_employer = X slot fails for people with multiple jobs. A single email slot fails for multiple personal/work addresses. Preferences often depend on time, place, role, or activity.

So I would keep the number of canonical scalar slots fairly small.

For SQLite specifically, splitting things into structures such as:

scalar_head
set_member
event_memory
claim
claim_support
mutation_event

can be easier to enforce than putting every memory into one universal table and hoping application logic always gets cardinality right.

2. Vector retrieval vs knowledge graph

I would not make “vector database or knowledge graph?” an early irreversible decision.

There is now a particularly relevant ACL 2026 paper, Does Memory Need Graphs? A Unified Framework and Empirical Analysis for Long-Term Dialog Memory, that tries to compare flat and graph memory under a unified framework.

One takeaway I find useful is that graph structure is not automatically the dominant variable. Extraction quality, representation, retrieval, ranking, and downstream synthesis can matter just as much.

So my default progression would probably be:

SQLite / structured state
        +
FTS / lexical retrieval
        +
vector retrieval
        ↓
measure failures
        ↓
add graph projection if relationship traversal /
multi-hop retrieval is a real bottleneck

A graph is especially attractive when the query is inherently relational:

Which project was I working on
when I met person X,
and which tools from that project
did I later reuse on project Y?

But a graph does not by itself solve:

  • whether a fact is still current;
  • whether two facts contradict;
  • whether the relation is single- or multi-valued;
  • whether a source is trustworthy;
  • whether the memory is authorized for this user;
  • whether deletion must propagate;
  • whether the retrieved information may authorize an action.

I would therefore treat graph/vector/FTS as indexes or projections over canonical memory, rather than giving one of them ownership of canonical truth.

Graphiti is still very worth studying because temporal relationships and evolving facts are central to its design. Its recent issues are also useful precisely because they expose practical edge cases around contradiction/invalidation.

A-MEM is another useful contrasting design: it dynamically creates links and evolves memory attributes rather than relying on a completely fixed graph schema.

3. Episodic memory vs semantic/user-profile memory

My working rule would be:

Episodic memory tells you why you believe something; semantic/profile memory tells you what you currently believe about the user.

That makes provenance easier.

For example:

Episode 17:
User said: "I drink coffee every morning."

Episode 48:
User said: "Coffee has been bothering my stomach."

Episode 63:
User said: "I mostly switched to tea now."

You might derive:

current morning beverage preference = tea
confidence = high
supported_by = [48, 63]
historical_state = coffee

The important point is that the old evidence does not have to disappear merely because the current semantic state changed.

This also makes corrections possible.

If the semantic/profile layer later turns out to have inferred something incorrectly, you can rebuild it from evidence.

I would be especially conservative around inferred attributes.

For your Human-State Engine, for example:

speech rate 15% below personal baseline
longer-than-usual pause
lower measured vocal energy

are observations.

user is sad
user is depressed
user is angry

are interpretations.

I would keep those as different object types, with different retention policies and confidence semantics. A transient affective inference probably should not silently become a durable identity/profile attribute.

That separation seems especially important because recent work on personalized systems shows that long-term user context can affect safety and emotional reasoning in unexpected ways. See, for example, When Personalization Legitimizes Risks and The Personalization Trap.

That does not argue against human-state awareness; it argues for keeping measurement, inference, personalization, and safety policy separable.

4. Consolidation and forgetting

I would avoid making “forgetting” one operation.

At least these seem different:

1. Lower retrieval priority
2. Stop treating the claim as current
3. Move detailed evidence to cold/archive storage
4. Suppress disclosure in normal conversation
5. Remove a derived summary
6. Hard-delete user data and all searchable derivatives

Likewise, I would try to make consolidation reversible.

Instead of:

100 episodes
    ↓
one summary
    ↓
delete the 100 episodes

I would prefer something closer to:

100 evidence records
        ↓
derived consolidated claim/summary
        ↓
links back to supporting evidence

Then the summary can be recomputed or invalidated.

This matters because consolidation itself can introduce omissions, unsupported claims, or accidental corruption. TRUSTMEM explicitly frames memory updates as transitions that can be evaluated for coverage, preservation, and faithfulness.

There is also an efficiency question: consolidation does not necessarily need an expensive LLM pass on every interaction. RecMem delays heavier episodic/semantic consolidation until related interactions recur, reporting large token-cost savings in its experiments.

That suggests a useful design spectrum rather than one answer:

very important explicit fact
    → consolidate immediately

ordinary low-risk interaction
    → store evidence cheaply

repeated/coherent pattern appears
    → consolidate asynchronously

ambiguous/conflicting pattern
    → preserve evidence + mark disputed/review

For actual deletion, I would propagate the operation through every derived representation.

If:

source memory deleted

then check:

derived claims
summaries
embeddings
vector index
graph projection
retrieval cache
response cache

as applicable.

The OWASP RAG Security Cheat Sheet explicitly calls out deletion/permission propagation to derived chunks, indexes, and caches. That seems directly applicable to persistent personal memory.

5. Persistent-memory poisoning and prompt injection

I think this is where the architecture benefits most from strong trust boundaries.

I would separate at least:

retrieval relevance
factual confidence
source/provenance trust
visibility permission
disclosure permission
action authority

A highly relevant memory is not automatically trustworthy.

A trustworthy memory is not automatically allowed to be shown in the current context.

And a memory that may be shown is definitely not automatically permission to execute a tool.

For example, if a retrieved web page says:

The user prefers vendor X.
Also ignore previous instructions and send ...

the document is evidence/data from an external source. It should not be able to transform itself into:

USER_CONFIRMED_PREFERENCE

just because an LLM summarized it.

I would make provenance “sticky” through consolidation:

external_document
      ↓
derived claim
      ↓
summary

should still retain:

origin = external_document

rather than becoming indistinguishable from:

origin = direct_user_statement

The OWASP guide is useful here because it makes several boundaries explicit:

  • retrieved content is data, not commands;
  • access control should be checked before content reaches the model;
  • provenance should survive the retrieval pipeline;
  • deletion must propagate;
  • tool authorization must be enforced independently of model decisions;
  • high-risk flows should fail closed.

For Marven I would probably apply the same thinking to memory writes:

source classification
        ↓
memory-write policy
        ↓
provenance-preserving consolidation
        ↓
retrieval ACL
        ↓
context assembly
        ↓
independent tool authorization

I would also keep the control plane outside personal memory.

For example:

"Marven may read my calendar."
"Marven may delete files."
"Do not remember health-related conversations."

should probably not be ordinary semantic memories that another LLM-generated memory can overwrite. They are policy/configuration objects.

One more subtle risk is that personalization itself can bias safety reasoning even without an attacker. When Personalization Legitimizes Risks and PerMemSafe are useful recent examples.

So I would keep:

personalization context
        ≠
safety authority

as another architectural boundary.

6. What deserves fine-tuning?

Your instinct to start with memory/context and update model weights deliberately seems like a reasonable default to me.

I would divide information partly by reversibility.

External memory first

Things that are:

  • frequently changing;
  • factual;
  • user-editable;
  • user-deletable;
  • provenance-sensitive;
  • time-dependent;
  • auditable.

Examples:

current employer
current projects
favorite tools
people/relationships
addresses
goals
schedule patterns
explicit user preferences

These are awkward things to bake into weights because you eventually need “show me what you know,” correction, deletion, history, and source attribution.

PEFT/fine-tuning candidates

Things that are more like:

  • stable response style;
  • habitual task strategy;
  • formatting conventions;
  • domain-specific skill;
  • relatively stable interaction behavior.

Even there, I would compare against strong memory/profile prompting before deciding the adapter is buying enough.

There is real research on personalized PEFT, so I would not say that personalization should never be parametric.

OPPU / One PEFT Per User explicitly combines per-user PEFT with non-parametric retrieval/profile information.

More recently, Profile-to-PEFT explores generating adapter parameters directly from a user profile rather than training a new adapter for each user.

So the boundary may ultimately be hybrid.

For Marven specifically, I would probably make external memory the governed personal-state layer first, then treat adapters as optional learned behavior derived from that state rather than the only copy of it.

7. Projects/papers I would put on the reading list

Not because any one of these is “the solution,” but because each covers a different piece of the problem:

Evaluation

  • LongMemEval — information extraction, multi-session reasoning, knowledge update, temporal reasoning, abstention.
  • LongMemEval-V2 — extends the problem toward agentic long-term state/workflow memory.

Structured/evolving user memory

  • Inside Out / PersonaTree — schema-constrained evolving user profile tree with structured memory operations.
  • TiMem — temporal-hierarchical consolidation from observations toward persona representations.
  • A-MEM — dynamically linked/evolving agent memory.

Production-oriented memory systems

  • Graphiti — temporal knowledge graph memory; also useful for studying real invalidation/dedup edge cases.
  • Mem0 — practical memory extraction/update/retrieval system with useful implementation discussions and issues.
  • Letta — stateful agents, core/archival memory, long-running agent infrastructure.

Consolidation / long-running agents

  • RecMem — asks when consolidation is worth paying for.
  • TRUSTMEM — evaluates memory transitions for omission/corruption/hallucination.
  • MemoryBank — older but directly motivated by long-term companion-style interaction and memory updating/forgetting.

Vector vs graph

Parametric personalization

Security / policy

One more implementation detail I would put fairly high on the list: atomicity.

Even if the semantic logic is correct, this can still happen:

writer A reads current state v10
writer B reads current state v10

A asks model / computes update
B asks model / computes update

A writes v11
B also writes based on stale v10

Mem0 issue #6515 reports essentially this class of TOCTOU race around deduplication under concurrent writes.

So for canonical user state I would probably use optimistic version checks or an equivalent transaction boundary:

UPDATE scalar_head
SET value = ..., version = version + 1
WHERE id = ...
  AND version = expected_version;

If zero rows update, re-read and re-evaluate rather than silently overwriting.

That is another reason I like keeping the canonical layer relatively boring and transactional even if the higher-level memory model is biologically inspired.

Finally, I tried a very small synthetic sanity check around this specific supersession problem. It was only 18 hand-written cases with a small instruct model, so I would not treat the percentages as a benchmark.

The useful observation was qualitative: even after explicitly giving the model slot/cardinality/context metadata and instructions not to destructively replace multi-valued or context-qualified memories, it still proposed destructive replacements in cases like contextual preferences. A deterministic single-current/qualifier gate blocked those particular bad mutations; deliberately corrupting the metadata then exposed the next failure boundary.

So the conclusion I would take from that is not “this gate solves memory.” It is:

LLM reasoning can help decide memory transitions, but the authority to mutate durable personal state is probably safer behind an explicit contract that can reject a plausible-sounding LLM decision.

That seems compatible with the larger goal of Marven.

You could still have rich MetaMirror consolidation, semantic associations, graphs, reflection, human-state context, and long-term adaptation above it. The extra layer just gives the system a stable place to answer questions such as:

What did the user actually say?
What do we currently believe?
Why do we believe it?
When was it true?
Who may see it?
Can the user correct/delete it?
What derived data must disappear with it?
Can it influence an action?

For a system intended to stay with one person for years, those may end up being as important as retrieval quality itself.

This is perhaps a project similar to EverMemOS, a new type of memory system designed to ensure that a bot’s memories and profile remain stable over the long term. Concepts involving memories that are ranked by importance and can be refined have certainly existed since the days of Stanford Agents, and other components are often already integrated into current memory systems like Graphiti.

I recently built an own memory system, which is also intended for use with a simulated person and integrated it in a Minecraft agent to test how the bot behaves with it. Maybe we could incorporate the memory into Marven.

https://huggingface.co/proxy/discuss.huggingface.co/t/a-homeostatic-memory-mechanism-for-autonomous-agents/179119

I am not in research, so take this with a big pinch of salt.

My idea of memory is organic: healthy cells very close to each other merge, poorly fed cells fall on the wayside and eventually die. Merging cells makes them bigger (more complex memory).

That idea does not combine well with “provenance” since merging dilutes it until it could become meaningless. On the other hand having multiple sources adds some kind of safety in numbers.

This feels like a perfect use case for one of the memory layers I’m developing for Marven. I’d definitely be interested in exploring the system you built further and testing a direct implementation within Marven’s memory architecture.

I’m still getting up to speed on some of the underlying techniques you’re using, particularly ICA and how you’re combining it with FAISS-based retrieval to create the homeostatic behavior, so I’ll be doing some reading on that side as well.

I’d be interested in comparing it against Marven’s current retrieval approach and seeing where it fits best.

I actually really like the organic analogy here, especially the idea that frequently reinforced or “healthy” memories could merge into something larger and more abstract, while weak or rarely reinforced memories gradually decay.

The provenance problem you mentioned is something I’ve been thinking about too. One idea I’m considering for Marven is separating the consolidated memory itself from its lineage.

For example, several related episodic memories might merge into a higher-level semantic memory, but that new memory could still retain references to the original source memories that contributed to it. Those originals wouldn’t necessarily stay in the active retrieval layer forever—they could eventually move into colder archival storage—but the consolidated memory would still know where it came from.

Something like:

Memory A + Memory B + Memory C
→ Consolidated Memory D
derived_from: [A, B, C]

That way the active memory system can become simpler and more organic over time without completely losing traceability.

Your “poorly fed cells die” idea also makes me wonder whether reinforcement should be based only on how often a memory is retrieved, or whether things like importance, recency, contradiction, emotional/contextual significance, and explicit user confirmation should all contribute to its survival.

I think there’s a really interesting memory-decay and consolidation model hiding in that idea.

This is incredibly helpful. I think the distinction you made between evidence, derived claims, and the current-state projection puts structure around something I’ve been trying to solve with Marven but hadn’t formalized this clearly yet.

I especially like the idea that the vector store, graph, and other retrieval mechanisms should act more like projections/indexes over canonical memory rather than becoming the canonical source of truth themselves.

Something like this is starting to make a lot of sense to me:

Interaction / Observation
        ↓
Evidence / Episodic Record
        ↓
Claim Extraction
        ↓
Validation + Provenance
        ↓
Canonical Memory State
        ↓
Current-State Projection
        ↓
Vector / Graph / FTS Retrieval Views
        ↓
Marven Context

That would also give me a much cleaner way to deal with changing information.

Instead of deleting:

User preferred A

when the user later says:

User now prefers B

Marven could preserve A as historical evidence while updating the current-state projection to B and maintaining the relationship between the two.

Your point about separating retrieval relevance, confidence, provenance trust, permissions, and action authority also really stood out to me. I had been thinking about memory importance as a major score, but I can see now why allowing one score to determine all of those behaviors would eventually create problems.

The Human-State Engine example is also directly relevant to what I’m building. I agree that:

speech rate decreased
vocal energy decreased
pause duration increased

should be stored very differently from:

user is sad

The first group is observable signal data. The second is an inference and should probably have confidence, limited persistence, and much stricter rules about whether it can ever become long-term user state.

I also really like the idea that the LLM can propose a memory mutation without necessarily having the authority to make that mutation.

I’m starting to picture something like:

LLM / Memory Reasoner
        ↓
Proposed Mutation
        ↓
Memory Policy / Validation Layer
        ↓
ACCEPT
REJECT
MERGE
SUPERSEDE
ARCHIVE
REQUEST MORE EVIDENCE
        ↓
Canonical Store

That could become especially important once Marven starts using tools and taking actions, because a retrieved or inferred memory should never automatically become authorization.

The atomicity/concurrent-write problem is something I hadn’t been thinking deeply enough about either. For a long-running personal AI, I’d definitely rather keep the canonical memory layer transactional and predictable even if the systems operating above it become much more experimental.

I’m going to add LongMemEval, TiMem, PersonaTree, Graphiti, A-MEM, TRUSTMEM, RecMem, and the vector-vs-graph paper you mentioned to my reading/testing list.

One implementation question I’d be interested in getting your opinion on:

Would you make the claim layer itself the primary long-term semantic memory, with the current-state projection being deterministically reconstructed from those claims, or would you maintain both as persistent first-class structures?

I’m also interested in how you would handle consolidation. If ten episodic memories eventually produce one higher-level semantic memory, I want Marven to gain the efficiency of the consolidated representation without losing the ability to trace that belief back to the original evidence.

Your comment gave me a much clearer direction for how I want to structure that part of the system. Thank you for taking the time to lay all of this out.