rushdb
ProductSolutionsDevelopersPricingResourcesCompanyGitHub
Sign InStart building

Understand

Context layer

Why shared operational context needs its own infrastructure layer.

Product overview

Create, inspect, retrieve, use, and operate connected context.

Architecture

See the data model, query surfaces, and deployment boundaries.

Build

Ingestion and live schema

Turn evolving payloads into typed, inspectable structure.

Graph and relationships

Preserve known links and review suggested patterns.

Semantic retrieval

Combine similarity, exact filters, and connected records.

Smart Search

Generate inspectable SearchQuery from natural language.

Operate

Query and analytics

Use one query shape across records, schema, and metrics.

Deployment options

Use managed cloud, an External Database, or self-hosted infrastructure.

Security

Review privacy, controls, and deployment posture.

Explore the product →

Primary workflows

Agent context and memory

Durable state, decisions, tool output, and semantic recall.

GraphRAG

Retrieve connected evidence, not only similar chunks.

Applications

Build operational software on connected context.

Operational analytics

Analyze current values, relationships, and change.

Solution patterns

Customer intelligence

Connect customer, product, support, and event data.

Search and discovery

Power semantic, faceted, and connected discovery.

Evidence and compliance

Keep operational evidence connected and inspectable.

Blueprints

Agent systemsConnected applicationsAnalytical systemsAll blueprints
Explore all solutions and blueprints →

Documentation

Concepts, tutorials, deployment, and API guides.

Quickstart

Create a project and run your first query.

TypeScript SDK

Type-safe access for browser and Node.js applications.

Python SDK

Sync and async access for services and data workflows.

MCP server

Expose RushDB operations to MCP-compatible clients.

Agent skills

Install task guidance for memory, querying, and modelling.

Open documentation →

Guides

Evergreen explanations and implementation paths.

Comparisons

Evaluate RushDB against graph, vector, and memory tools.

Blog

Product updates and technical articles.

Architecture

Understand the data path and current boundaries.

Changelog

Follow product and platform releases.

LMPG research

Separate the property-centric implementation from research direction.

Explore resources →

Contact

Discuss product, architecture, or enterprise requirements.

Security

Security, privacy, and responsible disclosure.

Open source

Review the source, open issues, and contribute.

Contact RushDB →
rushdb

Open-source context infrastructure for agents, applications, and analytics, with connected records, live schema, semantic retrieval, and operational queries through one API.

GitHubDiscord

Product

Context layerProduct overviewArchitecturePricingSecurityDeployment

Solutions

Agent contextGraphRAGApplicationsOperational analyticsBlueprint library

Developers

DocsQuick startAPI referenceTypeScript SDKPython SDKMCP serverAgent skills

Resources

GuidesComparisonsBlogChangelogOpen sourceContactSelf-hosting

© 2026 Collect Software Inc.

PrivacyTermsCookies
Engineering10 min read18th August 2026

Persistent Agent Memory for OpenClaw and Hermes with RushDB

RushDB brings scoped, durable, lifecycle-aware memory to OpenClaw and Hermes Agent through native connectors and one shared event contract.

By RushDB
AI agentsagent memorypersistent memoryopenclawhermes agentknowledge graph
On this page
  1. Why native memory needs lifecycle hooks
  2. What shipped
  3. OpenClaw: additive memory without replacing local storage
  4. Hermes Agent: a native MemoryProvider
  5. One contract across both runtimes
  6. Durability without adding latency to every answer
  7. Native memory and MCP solve different problems
  8. How to verify the integration
  9. A shared memory layer, not a shared transcript
  10. Sources

On this page

  1. Why native memory needs lifecycle hooks
  2. What shipped
  3. OpenClaw: additive memory without replacing local storage
  4. Hermes Agent: a native MemoryProvider
  5. One contract across both runtimes
  6. Durability without adding latency to every answer
  7. Native memory and MCP solve different problems
  8. How to verify the integration
  9. A shared memory layer, not a shared transcript
  10. Sources

RushDB

Give your agent a memory.

Push any JSON. Get graph relationships and vector search instantly — no schema, no pipeline, no setup.

Start building free →

FAQ

Related reading

vector searchgraph databasehybrid retrieval

Vector Search Doesn't Understand Data Structure

Embeddings rank similarity but ignore joins, cardinality, and constraints. Learn how RushDB combines semantic retrieval with explicit graph relationships and live schema discovery.

15 min readRead →
data-pipelinesai-architecturegraph-database

Why Every AI Stack Grows Into Five Data Pipelines

LLM applications naturally fragment into ETL, embedding, graph sync, search indexing, and metadata pipelines. Learn why this happens and how a single ingestion layer can replace.

20 min readRead →
ai-agentsschema-discoverygraph-database

Stop Teaching Agents Your Schema

Every new agent needs a prompt explaining your tables and fields. RushDB lets agents fetch a structured snapshot of the live graph at runtime.

24 min readRead →

RushDB now has native memory connectors for OpenClaw and Hermes Agent. Both integrations recall relevant history before inference, persist completed turns through a durable local outbox, and keep remote database failures away from the conversation path. They share one provider-neutral event contract, so memory written by different runtimes has the same identity, scope, trust, and retrieval semantics.

The connectors are available today as @rushdb/openclaw-memory on npm and rushdb-hermes-memory on PyPI.

Why native memory needs lifecycle hooks

An MCP server gives an agent tools. The model can decide to search, create, update, or traverse records, which is exactly what you want for explicit work such as storing a decision or connecting a task to an artifact.

Automatic memory has a different job. It must run at moments the model does not control:

  • recall before the prompt is finalized;
  • capture only after a turn completes successfully;
  • preserve the last bounded episode before compression;
  • rotate or clear state when sessions change;
  • flush pending writes during session end and shutdown.

A tool call cannot guarantee those transitions. A native connector can, because it participates directly in the host runtime lifecycle. The new RushDB connectors make that lifecycle plane automatic while leaving MCP available as the knowledge plane.

What shipped

PackageRuntimeRole
@rushdb/openclaw-memoryOpenClawAdditive plugin for automatic recall and completed-turn capture
rushdb-hermes-memoryHermes AgentNative MemoryProvider with recall, turn sync, compression, and session hooks
@rushdb/agent-memory-contractTypeScript and custom runtimesShared AgentMemoryEvent v1 types, identity helpers, scoped client, schema, and fixture

At a high level, both native connectors follow the same path:

Text
Before inference
  host metadata -> authorized scope -> RushDB semantic recall -> untrusted context

After a successful turn
  latest user/assistant pair -> local outbox -> idempotent RushDB upsert -> EPISODE

During degraded operation
  short timeout -> continue the host turn -> replay pending writes later

This is memory designed around agent execution rather than a generic transcript archive.

OpenClaw: additive memory without replacing local storage

The OpenClaw connector supplements the runtime's existing Markdown and SQLite memory. It does not claim an exclusive memory slot or disable local behavior. The plugin searches RushDB before prompt construction and projects the latest successful user/assistant pair to an EPISODE after agent_end.

Install the published package and expose a RushDB project key to the gateway:

Shell
openclaw plugins install @rushdb/openclaw-memory
export RUSHDB_API_KEY="your-project-api-key"

Automatic recall and capture are enabled by default. A minimal explicit configuration looks like this:

JSON
{
  "plugins": {
    "entries": {
      "rushdb-memory": {
        "enabled": true,
        "config": {
          "profileId": "default",
          "autoRecall": true,
          "autoCapture": true,
          "recallTimeoutMs": 300
        }
      }
    }
  }
}

Only eligible private or local conversations receive automatic RushDB memory. Sandboxed, shared-group, automation, heartbeat, hook, and subagent contexts fail closed. The plugin also ignores system messages, full transcripts, tool calls, command output, secrets, and local paths during automatic capture.

Completed events first enter a mode-0600 outbox under ~/.openclaw/rushdb-memory/outbox. If RushDB is temporarily unavailable, OpenClaw still replies, its local memory remains active, and the pending event can replay after restart. The OpenClaw connector guide documents the full configuration and verification flow.

OpenClaw currently maps completed turns to EPISODE. Its existing local memory path remains the right owner for explicit “remember this” behavior; use RushDB MCP when the model needs to create intentional graph records.

Hermes Agent: a native MemoryProvider

The Hermes connector implements the runtime's native MemoryProvider interface. It prefetches scoped memory, synchronizes successful primary-agent turns, captures the latest eligible episode before compression, reacts to session switches, and performs bounded flushes at session end and shutdown.

Install the provider into the same Python environment as Hermes:

Shell
pip install rushdb-hermes-memory
export RUSHDB_API_KEY="your-project-api-key"
hermes memory setup

Hermes discovers the rushdb provider through its Python entry-point system. Once selected, the provider owns automatic lifecycle recall and persistence without requiring the model to call a database tool.

Hermes also exposes a trusted native memory-write surface. Supported add and replace events become active MEMORY_FACT records, so an explicit preference or rule can be recalled independently from conversational episodes.

The local outbox lives under $HERMES_HOME/rushdb-memory/outbox, preserving profile isolation. Subagents and other non-primary contexts do not write automatic memory. See the Hermes provider guide for lifecycle details and environment options.

One contract across both runtimes

The connectors share AgentMemoryEvent v1 instead of inventing an OpenClaw schema and a separate Hermes schema. The contract defines two canonical record types:

LabelSemantic propertyMeaning
EPISODEsummaryOne bounded completed turn or lifecycle observation
MEMORY_FACTtextA curated preference, rule, or fact with active/version state

Every canonical record carries the same authorization scope:

Text
agentId
profileId
privacyScope
participantScopeHash
sandboxEligible

These fields are structured prefilters, not similarity hints. The connector applies all five before vector ranking. Participant identifiers are salted and hashed instead of being stored as raw platform IDs, and a runtime that cannot derive a trusted scope does not broaden the query.

AgentMemoryEvent v1 also standardizes provenance, visibility, trust classification, timestamps, and deterministic SHA-256 identities. Retries therefore use the same eventId or factId, allowing idempotent upserts instead of duplicate memories. The event contract documentation includes the canonical graph, supersession rules, and trust boundaries.

For custom TypeScript harnesses, the contract package exposes the same primitives directly:

Shell
pnpm add @rushdb/agent-memory-contract

Its published JSON Schema and conformance fixture provide a language-neutral boundary for other runtimes.

Durability without adding latency to every answer

Memory persistence is a separate committed action from the model response. Neither connector keeps a database transaction open across inference or waits indefinitely for a remote write.

The reliability model has four parts:

  1. Fail-open recall. A short timeout returns no remote memory instead of failing the host turn.
  2. Durable enqueue. Completed episodes reach a local outbox before background delivery is acknowledged.
  3. Idempotent replay. Deterministic IDs make retry and restart replay safe.
  4. Recent-write fallback. A bounded local cache makes fresh episodes recallable while managed embeddings become visible.

This keeps the conversation responsive while still giving acknowledged memory writes a durable path to RushDB.

Native memory and MCP solve different problems

Installing a native connector does not make RushDB MCP redundant. The two layers are complementary:

LayerBest owner for
Native connectorPre-inference recall, completed-turn episodes, compression/session handling, retry, shutdown
RushDB MCPExplicit DECISION, TASK, ENTITY, ARTIFACT, and other domain records; graph traversal; administration

The important rule is to assign each operation one owner. Do not mirror every completed turn through MCP when the native connector already captures it. Use MCP when the write adds intentional structure beyond the episode—for example, turning a conversation outcome into a DECISION connected to a TASK and an ARTIFACT.

For application-controlled runtimes, use the shared contract and a RushDB SDK to build the same lifecycle explicitly. For hosts without native hooks, MCP-only memory remains useful, but recall and persistence are model-directed rather than guaranteed lifecycle operations.

How to verify the integration

After installing either connector:

  1. Tell the primary agent a stable project decision in an eligible private session.
  2. Complete the turn and end or switch the session.
  3. Start another authorized session with the same profile and participant scope.
  4. Ask about the decision without instructing the model to call RushDB.
  5. Confirm that one canonical EPISODE exists for the deterministic event ID.
  6. Temporarily make RushDB unavailable and confirm that the conversation still completes.
  7. Restore connectivity and verify that the outbox replays the pending event.

For Hermes, also test an explicit native memory add and confirm that it creates an active MEMORY_FACT. For OpenClaw, confirm that local Markdown and SQLite memory remain available alongside the RushDB supplement.

A shared memory layer, not a shared transcript

The goal is not to upload everything an agent sees. It is to retain the smallest useful, authorized memory unit and make it available at the right lifecycle moment.

OpenClaw and Hermes now reach that goal through their own native interfaces while producing compatible RushDB records. The result is automatic recall where it belongs, durable capture without response-path network waits, explicit boundaries for privacy and trust, and a graph layer ready for more deliberate knowledge operations.

Create a project at app.rushdb.com, install the connector for your runtime, and let the next session start with the context the previous one earned.

Sources

  • OpenClaw Native Memory documentation
  • Hermes Native Memory Provider documentation
  • Agent Memory Event Contract documentation
  • @rushdb/openclaw-memory on npm
  • rushdb-hermes-memory on PyPI
  • @rushdb/agent-memory-contract on npm