I Was Tired of AI Agents Forgetting Everything, So I Built a Zero-Config Persistent Memory Sidecar

I Was Tired of AI Agents Forgetting Everything, So I Built a Zero-Config Persistent Memory Sidecar

I was tired of AI agents forgetting everything.

So I built a zero-configuration persistent memory sidecar for Hermes/OpenClaw that works on both Windows and Linux using PostgreSQL.

AI agents are getting smarter, but their memory model is still fragile.
They can reason well in-session, but across days and weeks, they lose context, preferences, and project history unless you keep feeding them expensive prompts.

I wanted something practical:

Self-hosted
Easy to install
Durable memory
Fast retrieval
Minimal operational overhead
That became HermesClawZero-ConfigSidecar.

The Problem
Most agent workflows break down over time for three reasons:

Session memory is temporary.
Long prompts are costly and still lossy.
Teams need memory that persists beyond one chat window.
I wanted memory to behave like infrastructure, not like a fragile prompt trick.

What I Built
HermesClawZero-ConfigSidecar is a sidecar service that stores and retrieves memory for Hermes/OpenClaw using PostgreSQL + pgvector.

At a high level:

Capture events and notes.
Store embeddings and metadata.
Retrieve by semantic + lexical relevance.
Manage memory health with a dashboard and optimizer tools.
Setup Experience
One design goal was first-run simplicity.

🤖 AI-Agent Installation (Auto-Setup)
You can install this project automatically using an AI agent (like OpenClaw or Hermes). Simply paste this URL to your agent and say: “Install this project from GitHub”: https://github.com/SunMe1977/HermesClawZero-ConfigSidecar

You can run setup scripts on Windows or Linux/macOS, generate configuration, and launch Docker services quickly. The setup flow also supports provider keys and updater defaults.

Dashboard and Operations
I added a dashboard to make memory management operationally clear:

search and review memories
maintenance and optimizer actions
update/version visibility
safer admin flows

Data Layer
Under the hood, memory is persisted in PostgreSQL with pgvector and indexed for practical retrieval workflows.

Security and Reliability Improvements Before Release
Before calling this v1.0-ready, I focused on release hardening instead of feature creep:

added health checks and restart policies
improved auth behavior and endpoint protection
fixed production-facing bugs (rerank crash, delete form binding, transcribe safety)
improved docs, troubleshooting, and release notes
This was important: I wanted the repo to feel like a mature open-source project, not just a prototype.

Performance (Local Snapshot)
Local measurements (example values from my setup):

Hybrid retrieval: ~18 ms
PostgreSQL lexical search: ~12 ms
API startup (warm): ~0.8 s
Idle API memory: ~70 MB
Docker stack startup: ~4 s
Your numbers will vary by machine and provider configuration.

Why This Approach
There are stronger enterprise-grade memory platforms out there, but my goal here was different:

easy self-hosting
low setup friction
straightforward architecture
practical long-term agent memory
Not “the best system in the world.”
A reliable one you can actually run today.

What’s Next
For the next iterations, I plan to improve:

observability and logs
backup/restore workflows
policy controls for memory lifecycle
more deployment templates
Final Thoughts
Persistent memory should be a standard primitive for agents.

If your assistant forgets everything between sessions, you are rebuilding context from scratch every day.
That is expensive, fragile, and avoidable.

This project is my practical answer: a zero-config memory sidecar for Hermes/OpenClaw that works on Windows and Linux with PostgreSQL and Docker.

If you want to try it, I would love your feedback after first install and first real-world usage.