The Problem: The Agent Memory Bloatware Crisis
If you have built an autonomous AI agent recently (using frameworks like LangChain, Mem0, or Letta), you have probably noticed a glaring absurdity:
To give an agent long-term memory across sessions, you are often forced to run three separate database engines:
- A vector database (Qdrant, Pinecone, Chroma) for dense semantic search.
- A keyword/full-text engine (Elasticsearch, BM25) to catch exact tokens, port numbers, or UUIDs.
- A graph database (Neo4j, FalkorDB) to track relationships and dependencies between entities.
The result? Docker container fatigue, runaway cloud bills, massive Python virtual environments, and query latencies exceeding 200 ms simply to recall what the user said 10 minutes ago.
We asked a straightforward question: Why can't agent memory live in a single, compact binary file that boots in 1 ms, runs completely offline, and queries in under 100 microseconds?
What SQLite did for relational data and Git did for version control, we set out to build for agent memory.
Meet Pyintel Mem (.pmem).
The Architecture: Single-File Binary Wire Layout (0x50 0x4D)
pyintel-mem compiles to a 536.5 KB standalone binary with 0 external runtime crate dependencies (no tokio, no serde, no rocksdb, no sqlite, no ndarray).
All data structures—vectors, HNSW graph layers, BM25 hash postings, and CSR temporal edges—live inside a single binary .pmem file with a 64-byte wire header:
Zero-Copy OS Memory Mapping (mmap)
When a process executes pmem recall "query", the file is not parsed or copied into heap memory. Instead, it utilizes native operating system memory mapping (MapViewOfFile on Windows, mmap on POSIX). Pages are faulted in directly by CPU cache lines on-demand.
The 4-Signal Hybrid Retrieval Engine
Instead of running separate queries across three distinct databases and reranking them with a slow LLM pass, pyintel-mem evaluates a unified 4-Signal Hybrid Search in a single memory-mapped pass:
\[\text{Score} = \Big(\alpha \cdot S_{\text{vector}} + \beta \cdot S_{\text{bm25}} + \gamma \cdot S_{\text{graph}}\Big) \cdot e^{-\lambda \cdot \Delta t} \cdot \text{Importance}\]
1. Vector Quantization: SQ8 + BQ1 Hardware POPCNT
- Symmetric int8 (SQ8): Compresses 32-bit floats 4x with 16-way loop-unrolled SIMD dot-product accumulation.
- 1-bit Binary Signatures (BQ1): Compresses vectors 32x into
u64 bitmasks. A single-cycle hardware POPCNT instruction calculates Hamming distance to instantly discard 90% of non-matching candidates before running dot products.
2. Zero-Allocation Hash-Keyed Okapi BM25+
- Tokenizes text into
u64 FNV-1a hash postings with CamelCase and digit boundary splitting (AutoVLA -> auto, vla).
- Built-in Damerau-Levenshtein <= 1 typo recovery: queries like
"what is the autoVLA ADE scre?" automatically recover "score".
3. CSR-Encoded 2-Hop Temporal Knowledge Graph
- Nodes are linked by directed weighted edges:
RELATES_TO, CAUSES, SUPERSEDES, PART_OF, DEPENDS_ON.
- Traversals use Compressed Sparse Row (CSR) layout with spreading activation.
- Superseding Logic: When fact B replaces fact A, linking them with
SUPERSEDES suppresses the outdated fact during recall while preserving historical lineage.
4. Ebbinghaus Spaced Repetition & O(1) Tombstoning
- Unaccessed memories decay exponentially based on elapsed time ($\Delta t$).
- Recalling a memory automatically reinforces its
access_count and refreshes its timestamp.
- Critical rules can be
--pinned to never decay.
- Outdated facts can be soft-deleted in O(1) time via the
TOMBSTONE flag.
Solving "Filtered Recall Collapse" with the Adaptive Router
A known limitation of standard HNSW vector search is that when you filter by metadata (e.g., namespace or tag where only 5% of nodes match), greedy graph traversals hit dead ends, causing recall to collapse to near 0%.
pyintel-mem includes an Adaptive Selectivity Router:
- High Selectivity (>15% match): Routes through the logarithmic HNSW graph.
- Low Selectivity (<15% match): Dynamically bypasses the graph and runs a pre-filtered SIMD SQ8 scan over candidate bitsets.
- Result: 100% recall retention across all filter densities in under 350 microseconds.
Empirical Benchmark
Measured on an AMD Ryzen / NVMe setup (x86_64-pc-windows-gnu, release build with LTO + strip):
| Metric | Result |
|---|
| Standalone Binary Size | 536.5 KB (0 external crates) |
| Indexed Nodes & Edges | 2,500 nodes (128-D) + 833 edges |
| .pmem File Size | 1,088 KB (~445 bytes / node) |
| Single-Store Query | 31.9 µs (sub-millisecond) |
| Federated Global Query (3 stores) | 84.0 µs (1.00 ms total mmap) |
| Selective 5% Filtered Query | 332.2 µs p50 (100% recall) |
Quickstart
1. Install via Cargo
cargo install --git https://github.com/Pyintel/pyintel-mem.git
2. Shorthand CLI
# Store facts with namespace and tags
pmem store "Apex Studio UDP listener migrated to port 4141" --ns apex --tags network,udp --importance 2.0
# Sub-millisecond recall (typo tolerant)
pmem recall "what is the apex udp port?"
# Link causal / superseding relationships
pmem link --src 2 --dst 1 --kind SUPERSEDES --weight 1.0
# Delete / forget outdated memories by ID or query
pmem forget "port 3000"
# Federated cross-store search across EVERY .pmem file on disk in <100 µs
pmem global "what is the apex udp port?"
3. Connect as an MCP Server (Cursor / Claude Code / Antigravity)
Add this to your MCP settings (mcp_config.json):
{
"mcpServers": {
"pyintel-mem": {
"command": "pmem",
"args": ["mcp", "workspace.pmem"]
}
}
}
Exposes mem_store, mem_recall, mem_forget, mem_link, and mem_stats over stdio JSON-RPC 2.0.
One-Click Chat Memory Harvester
Have an ongoing Cursor, Claude, or ChatGPT conversation that you want to preserve into .pmem without dumping a giant wall of text?
Grab our autonomous Memory Harvester prompt:
PowerShell:
irm https://pyintel.cc/pmem-harvest.prompt | claude -p
Bash / macOS / Linux:
curl -fsSL https://pyintel.cc/pmem-harvest.prompt | claude -p
It instructs the agent to deconstruct the session into atomic 1–2 sentence facts (20–50 words), categorize them into namespaces, pin core rules, and link causal relationships automatically.
Summary & Open Source
Pyintel Mem is completely open-source under the MIT license. We provide Authenticode-signed pre-built binaries for Windows (x86_64 & ARM64), macOS Universal (Apple Silicon & Intel), and Linux (x86_64 & ARM64).
