Synapse AI Memory Graph (SMG v2)

1. Executive Summary & Problem Formulation

Modern Large Language Model deployments face a fundamental limitation: context saturation. As conversational agents interact with users over weeks, months, or years, accumulated dialogue history can exceed the model's practical context budget. Two common strategies introduce important trade-offs:

• Brute-Force Context Stuffing: replaying raw multi-turn histories scales with retained tokens — increasing inference expense while degrading retrieval quality when many unrelated details compete for attention.
• Lossy Summarization: compressing historical interactions into high-level prose reduces token load but destroys atomic facts and exact episodic details required for granular recall.

SMG v2 Solution. A dual-tier execution architecture decouples conversation persistence from active generation. A strictly bounded sliding window handles immediate dialogue, while a pointer-virtualized storage vault preserves historical events. Evicted interactions are indexed using atomic keywords and unique IDs; the full payload remains outside the active prompt and is demand-paged only when needed.

2. Core Architecture & Structural Memory Model

SMG v2 is organized around three foundational pillars: the L1 Active Buffer, the L2 Keyword Box, and the L2 Chat Store. Together they separate short-term generation state from durable episodic memory.

Pillar 1 — L1 Active Buffer (The Sliding Window)

The Active Buffer resides directly in the LLM's volatile context window. It is strictly capped at a 4-turn interaction window, where each turn consists of an input/output pair. When a fifth interaction begins, the oldest interaction is evicted from the active prompt. This bounds the amount of historical text processed during ordinary generation.

Pillar 2 — L2 Keyword Box (The Semantic Index)

When an interaction is evicted, an asynchronous process extracts approximately 3–7 atomic keywords plus compact semantic metadata. The resulting Keyword Bundle receives a unique ID (for example, SGO100002345). The semantic representation can be persisted in a vector index, while a low-latency key-value or graph layer accelerates pointer resolution.

Pillar 3 — L2 Chat Store (The Virtualized Vault)

The complete input/output payload is stored separately from the semantic index. The same unique ID is attached to the raw payload, creating a strict pointer-mapping relationship: the Keyword Box identifies what an event is about; the Chat Store contains what actually happened.

3. Runtime Execution Lifecycle

Phase 1 — Ingestion & Async Tagging (Turns 1–4)

During active conversation, the latest turns remain in volatile context. In parallel, background workers extract canonical tags, micro-context, and metadata without blocking the generation path. Each interaction receives a stable ID that can reference both its semantic record and raw payload.

Phase 2 — Eviction & Bifurcated Storage (Turn 5 Onward)

When Turn 5 begins, Turn 1 leaves the active prompt. Its raw input/output is persisted in the Chat Store, while its Keyword Bundle is persisted in the semantic index. Both records retain the same identifier — for example, SGO100002345. The cycle repeats indefinitely.

Phase 3 — Demand Paging Retrieval (Memory Recall)

1. Query Analysis: The model interprets the new request and derives semantic retrieval intent.
2. Tool Calling: A memory connector is invoked with relevant terms or an embedding-based query.
3. Pointer Resolution: The semantic index returns one or more candidate IDs.
4. Targeted Fetch: The selected IDs are resolved against the Chat Store to retrieve exact historical payloads.
5. Micro-Context Injection: Only the minimal historical evidence required for the current response is inserted into the dynamic prompt.
6. Transient Cleanup: After generation, injected historical context is discarded from the active working set.

4. Data Schema — Master Node & Pointer Record

Each interaction is represented by a structured master record. The schema below separates retrieval metadata from the durable raw payload reference.

Field Semantics

• turn_id — stable identifier shared by semantic and raw records.
• timestamp — event time used for temporal filtering and chronology.
• domain / sub_domain — hierarchical routing metadata for memory partitioning.
• atomic_tags — compact semantic retrieval anchors.
• micro_context — short evidence summary suitable for bounded prompt injection.
• access_frequency — historical access signal that can influence retrieval policy.
• decay_weight — optional recency/importance weighting signal.
• raw_payload_ref — pointer to the durable full conversation payload.

5. Technical Implementation Framework

A practical implementation can be assembled as a modular retrieval service. The exact products are interchangeable; the architectural requirement is the separation of orchestration, semantic indexing, pointer resolution, and durable payload storage.

Layer	Candidate Technologies	Primary Responsibility
Orchestration	Python · FastAPI / Django · Celery / Async IO	API lifecycle, background tagging, retrieval orchestration
Semantic Index	ChromaDB · Pinecone · comparable vector store	Semantic matching and candidate memory discovery
Pointer / Cache	Redis	Fast ID lookup, routing, caching, pointer resolution
Chat Store	PostgreSQL · MongoDB · cold storage	Durable encrypted storage of raw interaction payloads

Operational Requirements

• Stable IDs — identifiers must remain unique and resolvable across storage migrations.
• Asynchronous indexing — semantic tagging should not unnecessarily extend the critical generation path.
• Bounded injection — retrieval should enforce a strict evidence/token budget rather than returning unrestricted history.
• Access controls — memory records should be isolated by user, tenant, agent, and permission domain.
• Auditability — retrieval events should be observable so incorrect memories can be traced and corrected.
• Encryption — raw conversational payloads should be protected at rest and in transit.

6. Architectural Comparison & Competitive Characteristics

The comparison below describes the intended architectural behavior of each approach. It is a design-level comparison, not a benchmark result; actual performance depends on model, database, retrieval policy, workload, and implementation.

Dimension	Brute-Force Context	Naive RAG	SMG v2 Specification
Token Cost / Turn	Grows with retained history	Typically depends on retrieved chunks	Target: bounded micro-context payload
Lookup Traversal	Broad context processing	Approximate top-k retrieval	Pointer resolution after semantic candidate discovery
Memory Isolation	Large active prompt surface	Fragmented retrieved chunks	Sandboxed pointer domains
Historical Recall	Can degrade as history grows	Chunk-dependent recall	Exact episodic event anchors via stable IDs

7. Conclusion & Future Scope — SMG v3

The Synapse AI Memory Graph (SMG v2) proposes a memory architecture in which long-term conversational persistence is decoupled from the LLM's active context window. The key mechanism is pointer virtualization: semantic records remain lightweight and searchable, while exact historical payloads remain external and are fetched only when required.

Under the specification, this design can support long-horizon episodic memory without continuously replaying years of dialogue into every generation request. The strongest architectural property is therefore bounded active context with demand-paged historical evidence.

SMG v3 — Lateral Memory Graph

The next iteration can introduce graph-based relationships between memory pointers. A Graph Neural Network, graph database, or learned relation layer could connect semantically or temporally related memories — for example, linking a historical shoulder pain event to a later gym routine change. This would enable controlled multi-hop reasoning across years of episodic data.

• Pointer Virtualization
• Episodic Memory
• Infinite Context
• LLM Memory Optimization
• Context Saturation
• Systems Architecture