PGMem: Why Your AI Agent Forgets What It Knows About Users

Your AI agent knows that Sarah prefers Python over JavaScript. But when asked why, it cannot tell you. Was it from her GitHub activity? A conversation three months ago? A project she mentioned once?

This is the memory-persona validity gap: personas stored as flat profiles detached from the events that justify them. The result: persona drift, unexplainable preferences, and retrieval that misses the evidence.

PGMem (Persona-Memory Graph) closes this gap by connecting event and persona nodes through typed provenance and evidence edges. Every persona signal is traceable to the events that support or revise it.

The Two Gaps That Break Personalisation

Existing memory systems suffer from two related but distinct problems:

1. The Memory-Persona Validity Gap

Problem: Personas are stored as flat summaries, disconnected from the events that created them.

# Current approach (flat profile)
persona = {
    "preferred_language": "Python",
    "experience_level": "senior",
    "interests": ["ML", "graph databases"]
}

# Where did this come from? Unknown.
# Is it still valid? Unknown.
# What events support it? Unknown.

Consequence: When new evidence contradicts the persona, the system cannot reconcile the conflict. The persona drifts.

2. The Persona-Aware Retrieval Gap

Problem: Memory retrieval ignores persona context. Queries retrieve events, but don't prioritise persona-relevant signals.

# User query: "What projects should I recommend?"
# Current retrieval: Fetch recent events
# Missing: Filter by user's known interests (Python, ML, graphs)

Consequence: Recommendations are generic, not personalised. The system "forgets" what it knows about the user.

PGMem's Solution: Heterogeneous Persona-Memory Graph

PGMem structures memory as a heterogeneous graph with three node types and four edge types:

                    ┌─────────────────┐
                    │   Event Node    │
                    │  (timestamped)  │
                    └────────┬────────┘
                             │
            ┌────────────────┼────────────────┐
            │                │                │
            ▼                ▼                ▼
    ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
    │ Evidence     │  │ Provenance   │  │ Revision     │
    │ Edge         │  │ Edge         │  │ Edge         │
    └──────────────┘  └──────────────┘  └──────────────┘
            │                │                │
            ▼                ▼                ▼
    ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
    │  Persona     │  │  Persona     │  │  Persona     │
    │  Signal A    │  │  Signal B    │  │  Signal C    │
    └──────────────┘  └──────────────┘  └──────────────┘

Node types:

• Event nodes: Timestamped user interactions (conversations, actions, preferences)
• Persona signal nodes: Inferred traits (preferred_language = Python)
• Evidence nodes: Supporting data points (GitHub repo, conversation excerpt)

Edge types:

• Evidence edges: Event → Persona Signal (this event supports this trait)
• Provenance edges: Persona Signal → Evidence (this trait comes from this source)
• Revision edges: Event → Persona Signal (this event revises/contradicts this trait)
• Temporal edges: Event → Event (chronological ordering)

How Retrieval Works

At query time, PGMem performs evidence-based expansion:

def retrieve_personalised(query, user_id):
    # Step 1: Identify query-relevant persona seeds
    seeds = query_match_persona(query)  # e.g., "Python" → preferred_language
    
    # Step 2: Expand along evidence edges
    evidence = graph.expand(seeds, edge_type="evidence")
    
    # Step 3: Rank by evidential validity
    ranked = rank_by_validity(evidence)  # Stronger evidence = higher rank
    
    # Step 4: Filter out revision-contradicted signals
    valid = filter_revisions(ranked)  # Remove signals with revision edges
    
    return valid

The key: retrieval is persona-aware. It doesn't just fetch events — it fetches events weighted by persona relevance and evidential strength.

What the Benchmarks Say

PGMem was evaluated across three benchmarks with small language model backbones (7B-13B parameter class):

Benchmark	Task	Baseline	PGMem Improvement
PersonaChat	Dialogue personalisation	0.62 F1	+18.4%
MemBench	Memory retrieval accuracy	0.71 EM	+22.7%
LongMem	Long-context memory (100+ turns)	0.58 EM	+31.2%

Key findings:

• Performance improves as context grows — unlike flat memory which degrades
• Outperforms summary-based, persona-aware, graph-structured, and agentic memory baselines
• Ablation shows provenance edges contribute 40% of the improvement

Production Considerations

Graph Storage

PGMem can run on:

• Neo4j: Native graph, Cypher queries for expansion
• NetworkX + vector store: For smaller deployments
• Cloud graph services: AWS Neptune, Azure Cosmos DB

Recommended schema (Neo4j):

// Create event node
CREATE (e:Event {
    id: $event_id,
    timestamp: $timestamp,
    content: $content,
    user_id: $user_id
})

// Create persona signal
CREATE (p:PersonaSignal {
    id: $signal_id,
    trait: $trait,
    value: $value,
    confidence: $confidence
})

// Link with evidence edge
CREATE (e)-[:SUPPORTS {strength: $strength}]->(p)

// Add provenance
CREATE (p)-[:FROM_SOURCE {source_type: $source}]->(e)

Query Patterns

Common queries:

// Get all evidence for a persona trait
MATCH (p:PersonaSignal {trait: "preferred_language"})<-[:SUPPORTS]-(e:Event)
RETURN e.content, e.timestamp
ORDER BY e.timestamp DESC

// Find revision conflicts
MATCH (p:PersonaSignal)<-[:SUPPORTS]-(e1:Event)
MATCH (p)-[:REVISION]->(e2:Event)
RETURN p, e1, e2

// Rank evidence by validity score
MATCH (p:PersonaSignal)<-[s:SUPPORTS]-(e:Event)
RETURN p.trait, p.value, s.strength AS validity
ORDER BY validity DESC

Cost Implications

PGMem adds graph traversal overhead but reduces LLM token waste:

• Graph queries: Sub-millisecond for 10K events
• Token reduction: Persona-aware retrieval fetches 30-50% fewer irrelevant events
• Storage: ~50 bytes per event node, ~100 bytes per persona signal

For 100K events: ~15 MB graph storage, 100ms query latency

Implementation Pattern

Here's the minimal architecture:

class PGMem:
    def __init__(self, graph_store, extractor, ranker):
        self.graph = graph_store  # Neo4j client
        self.extractor = extractor  # LLM for persona extraction
        self.ranker = ranker  # Scoring model for evidence
    
    def ingest_event(self, event):
        # Step 1: Store event
        event_id = self.graph.create_event(event)
        
        # Step 2: Extract persona signals
        signals = self.extractor.extract(event.content)
        
        # Step 3: Link with evidence edges
        for signal in signals:
            self.graph.link_evidence(event_id, signal)
            
            # Step 4: Check for revisions
            existing = self.graph.find_conflicting_signals(signal)
            for existing_signal in existing:
                self.graph.add_revision(event_id, existing_signal)
    
    def retrieve(self, query, user_id):
        # Step 1: Find persona seeds
        seeds = self.graph.query_persona_seeds(query, user_id)
        
        # Step 2: Expand along evidence
        evidence = self.graph.expand_evidence(seeds)
        
        # Step 3: Rank by validity
        ranked = self.ranker.score(evidence)
        
        # Step 4: Filter revisions
        valid = self.graph.filter_revisions(ranked)
        
        return valid

Where the Field Is Heading

PGMem reveals three trends:

1. Traceable Memory as Standard

Flat memory summaries are dead. Future systems will require provenance tracking for every persona signal.

2. Graph-Native Agent Memory

Vector stores alone cannot capture structured relationships between events and traits. Graph-native memory will become standard for personalisation.

3. Revision-Aware Systems

Personas evolve. Systems that track revisions and resolve conflicts will outperform static profile systems.

The Bottom Line

PGMem solves the memory-persona validity gap by:

• Connecting personas to events via typed edges
• Tracking evidence and revisions explicitly
• Retrieving with persona-aware expansion

For personalisation systems, the implication is clear: your memory must be traceable. Flat profiles drift. Graph-connected memory persists.

---

Further Reading

• PGMem paper: arXiv:2608.01708
• AgentMemory (.NET): Knowledge graph agent memory implementation
• ACE-GraphRAG: Context engineering for GraphRAG arXiv:2608.01269
• DocNavRAG: Document navigation pattern arXiv:2608.01565