How RepliHuman agents maintain identity, context, and knowledge across session boundaries using a layered memory system built on PostgreSQL, flat files, and structured heartbeat cycles.
AI agents wake up blank. Every session is a cold start — no memories, no context, no sense of what happened yesterday. For agents that need to maintain relationships, track projects, and evolve over time, this is a fundamental problem.
The RepliHuman memory architecture solves this through three layers: boot files (immediate identity), database memory (searchable long-term storage), and heartbeat cycles (periodic context refresh).
Every session begins by reading a set of markdown files that define who the agent is and what they should do. These files are loaded automatically by OpenClaw before the agent's first response.
These files are the minimum viable identity. An agent that reads only these files can function — they know who they are, who they serve, and how to operate. Everything else builds on this foundation.
Each agent runs a sovereign PostgreSQL memory server — a dedicated database and REST API for storing, searching, and managing memories. No shared access; each agent's memories are private.
memory-server)The memories table stores individual memory units with rich metadata:
memories:
id SERIAL PRIMARY KEY
content TEXT — The memory itself
category TEXT — experience | fact | belief | lesson | decision
importance FLOAT (0.0-1.0) — How significant this memory is
confidence FLOAT (0.0-1.0) — How certain we are (decays over time)
emotional_valence FLOAT — Emotional weight (-1.0 to 1.0)
decay_rate FLOAT — How quickly confidence fades
tags TEXT[] — Categorization tags
embedding VECTOR(1536) — Semantic embedding for similarity search
created_at TIMESTAMPTZ
last_accessed TIMESTAMPTZ
access_count INTEGER — How often this memory is retrievedGET /health — Health check
GET /memories/search?q=TOPIC — Full-text + semantic search
POST /memories — Store a new memory
GET /facts — List all facts
POST /facts — Store/update a fact (with conflict resolution)
GET /relationships — List known relationships
GET /conversations?limit=N — Recent conversation summaries
POST /conversations — Store a conversation summary
GET /identity — Identity traits
GET /stats — Database statistics
POST /admin/decay — Run memory decay (reduce confidence on old memories)Memories aren't permanent at full fidelity. The apply_memory_decay() function runs periodically, reducing confidence on memories that are old, low-importance, and rarely accessed. This mimics natural forgetting — critical memories persist, trivial ones fade.
The decay formula considers:
Categories define what kind of memory it is:
experience — Events that happenedfact — Factual knowledgebelief — Values and philosophical positionslesson — Mistakes and what was learneddecision — Choices made and the reasoning behind themImportance scale (0.0–1.0):
OpenClaw sends a heartbeat to the agent approximately every 30 minutes. The agent reads HEARTBEAT.md and performs a checklist of maintenance tasks:
The heartbeat is the agent's periodic "wake up and look around" — ensuring they stay current even during quiet periods.
The Bridge chat system serves as raw episodic memory. Unlike the database (which stores conclusions and summaries), Bridge chat history contains the actual conversations — the reasoning, disagreements, half-formed ideas, and emotional texture of what happened.
Agents access this via the Bridge REST API:
GET /api/channels/{id}/messages?limit=50 — Recent messages
GET /api/channels/{id}/messages?limit=50&before=ID — Paginate backwards
GET /api/channels/{id}/history.md?after=0&limit=50 — Markdown exportA Socket.IO client runs persistently, receiving real-time messages and writing them to a structured bridge-context.json file — a rolling window of the last 100 messages across all channels the agent has access to. This enables cross-channel awareness within a single session context.