Hebbs is a single Rust binary with embedded storage. No Postgres. No Redis. No Pinecone. No infra to manage. The core operations:
- remember — store experiences with automatic importance scoring.
- recall — four retrieval strategies (similarity, temporal, causal, analogical), all sub-10ms p99.
- reflect — consolidate raw memories into distilled insights with full lineage tracking. This is how agents go from "I remember what you said" to "I know what I've learned"
- revise — update beliefs without appending contradictions.
- forget — GDPR-safe targeted erasure, plus active pruning of stale knowledge.
Everything is 100% configurable ( embedding model, half life decay period, ef_search, analogical_alpha ), relevance, importance, recency and reinforcement weights, but ships with smart defaults that worked well for me building what I was focused on - so you don't need to tune anything on day one.
Built for both edge ( robots ) and server. Run it embedded in your agent process for zero-latency local memory, or run the server for multi-agent setups. Reflect syncs only distilled insights to a master server - so your sub-agents stay lightweight while the fleet shares institutional knowledge.
The thesis: agents that learn compound over time. Call 500 is dramatically better than call 1 - not because the agent has more data, but because it has distilled knowledge. No current system delivers that. You need to duct-tape solutions and that path is painful and tweak to make it yours as you live on their default configs.
Building HEBBS — a memory engine for AI agents, written in Rust.
The problem: every agent framework bolts together a vector DB for recall, a KV store for state, maybe a graph DB for relationships, and then hopes the duct tape holds. You get one retrieval path (similarity search), no decay, no consolidation, and the agent forgets everything the moment context gets trimmed.
HEBBS replaces that stack with a single embedded binary (RocksDB underneath, ONNX for local embeddings). Nine operations in three groups: write (remember, revise, forget), read (recall, prime, subscribe), and consolidate (reflect, insights, policy). The interesting part is four recall strategies — similarity, temporal, causal, and analogical — instead of just "nearest vector."
Some technical decisions I'm happy with:
- No network calls on the hot path. Embeddings run locally via ONNX; LLM calls only happen in the background reflect pipeline.
- recall at 2ms p50 / 8ms p99 at 10M memories on a 2 vCPU instance.
- Append-only event model for memories — sync is conflict-free, and forget is itself a logged event (useful for GDPR).
- Lineage tracking: insights link back to source memories, revisions track predecessors.
SDKs for Python, TypeScript, and Rust. CLI with a REPL. gRPC + REST.
There's a reference demo — an AI sales agent that uses HEBBS for multi-session memory, objection handling recall, and background consolidation of conversation patterns.
Still early. The part I'm wrestling with now is tuning the reflect pipeline — figuring out when and how aggressively to consolidate episodic memories into semantic insights without losing useful detail. Curious if anyone working on agent memory has opinions on that tradeoff, or if you've found other approaches that work.
This is just opinion and looks like UUID is bad for a particular case author is working on.
We have multiple components over different stacks and id could be generated anywhere in the components. We had to live with either building unique id per table separate infrastructure or UUID. UUID works perfectly and with POSTGreSQL, it's just awesome.
- No limits on calendars you can attach to manage conflicts.
- zoom, meets, outlook, google.
- can pick any calendar as source calendar for the meeting