Drop-in memory provider for Hermes Agent. Multi-tenant Postgres backend. Auto-compression, audit log, cross-agent federation. Open-source. Free to install. Built for the pains 99 Hermes user stories already documented.
We read 99 user stories from the Hermes ecosystem. Five of seven biggest documented gaps are solved natively by what Sibyl Memory already does. The plugin productizes that.
| Gap they documented | How the plugin solves it |
|---|---|
| "73% of every API call is fixed overhead. Long conversations were making the agent slow and forgetful."token-overhead pain | HOT / WARM / COLD / REFERENCE / ARCHIVE tier auto-compression. Old conversations summarize into structured cards. Retrieval scoped by tier. |
| "I want per-group specialization. Per-session same personality, system prompt, CLAUDE.md, working directory." Users hack this with Telegram topics today.partitioning pain | Multi-tenant by tenant_id namespace. One parameter at construction. Each role / project / channel gets isolated memory enforced at the DB layer. |
| "112 of 129 audited sessions violated approval protocol. For multi-user servers, kid-facing bots, compliance — I want a human-in-the-loop gate."compliance pain | Tamper-proof audit log on every memory write. Cascade-delete for GDPR. Self-host path for air-gapped requirements. EU AI Act export ready. |
| "Users want agents to adapt style and preferences but the current system only recalls."persona pain | Schema accepts persistent personality scaffolding (identity, voice, soul, diary). Cross-session retention validated at #2 on LongMemEval Oracle. |
| "Built a memory provider plugin connecting agentmemory to Hermes. Covers cross-agent memory."federation pain | Polymorphic SDK. Same Postgres schema usable from Hermes, Claude Code, Cursor, anywhere with database access. Federation by design, not by hack. |
"I built my own stack independently and we converged on the same architecture — background self-improvement, persistent memory, CLAUDE.md project context, reusable skills." Hermes user · public story
EXAMPLE INTERFACE. NOT YET SHIPPABLE.
Everything below shows the planned install and integration interface. The package is not yet published. pip install sibyl-memory-hermes will fail today; PyPI does not yet host this name. The commands and code on this page reflect the design we're building toward, published here so prospective users and Hermes power users can review the shape of the plugin before we ship. For early access to the actual implementation when it lands, contact [email protected].
Once shipped, the plugin will be open-source under MIT. Activation provisions an account at sibyllabs.org and initializes a
local Postgres-in-WASM database at ~/.sibyl-memory/memory.db. All memory operations execute
locally. No data leaves your machine on the free tier.
$ pip install sibyl-memory-hermes Successfully installed sibyl-memory-hermes-0.1.0 (bundles pglite ~3MB) $ python -m sibyl_memory_hermes init Welcome to Sibyl Memory for Hermes Agent. To activate, open this link in your browser: https://sibyllabs.org/plugin/activate?session=8f3a2c1e9b Waiting for activation... (10 min timeout) [ ⠋ polling ... ] ✓ Activation complete. Account: acc-9f3e2c · tier: free Local DB: ~/.sibyl-memory/memory.db (pglite, schema applied) Free cap: ~X MB local · uncapped via Sibyl Stake / Sibyl Cloud / Lifetime Credentials: ~/.sibyl-memory/credentials.json Wire it into your Hermes agent: from sibyl_memory_hermes import SibylMemoryProvider agent.memory = SibylMemoryProvider()
Headless servers and containers without a browser pass --api-key directly. Activation can complete from any machine and bind the same tenant.
The plugin generates a session token locally, prints an activation URL, and polls for binding. The browser handles auth. The plugin picks up the result. Nothing exotic. Seven steps end-to-end.
On first run of python -m sibyl_memory_hermes init, the plugin generates a UUIDv4 session token, saves it to local state, and begins polling sibyllabs.org/api/plugin/check?session=... every 3 seconds with a 10-minute timeout.
Plugin prints https://sibyllabs.org/plugin/activate?session=.... User opens it in any browser on any machine. Page reads the session token from the URL query parameter, stores it in browser state.
Page presents two paths: Sign-In With Ethereum (SIWE) for crypto-native users, or email + verification link for everyone else. Both flows produce a verified user record.
A new row is inserted into sibyl_memory.tenants with the user's wallet or email. An API key is generated. The binding (session_token → api_key + tenant_id) is written to plugin_sessions.
The next /api/plugin/check response includes the API key and tenant ID. Plugin writes ~/.sibyl-memory/credentials.json with mode 0600. Session token is invalidated server-side.
A webhook fires to the growth team's Discord channel with the new-lead notification: email, wallet (if SIWE), activation timestamp, source platform. JY's concierge cadence begins.
Wire the provider into your Hermes agent in two lines. From this point on, every memory read and write routes through the plugin to the Sibyl Memory Postgres schema. Audit log captures every operation. Cache layer keeps reads fast.
Standard Python package layout. Hosted on PyPI as sibyl-memory-hermes. Mirrored on GitHub.
Roughly 2,000 lines of code including tests. The provider implements Hermes' v0.10.0 memory contract.
├── pyproject.toml # package metadata, dependencies ├── README.md # getting-started ├── LICENSE # MIT ├── CHANGELOG.md # version history ├── sibyl_memory_hermes/ │ ├── __init__.py # public exports │ ├── provider.py # Hermes v0.10.0 memory provider implementation │ ├── client.py # Sibyl Memory SDK wrapper (polymorphic constructor) │ ├── activation.py # device-flow activation + credentials persistence │ ├── compression.py # auto-compression policy hooks │ ├── tenant.py # multi-tenant namespace routing │ ├── audit.py # tamper-proof audit log helpers │ ├── config.py # env loading, runtime config │ ├── telemetry.py # anonymized usage signal (capacity, retention, OS) │ ├── exceptions.py # custom exceptions │ └── cli/ │ ├── __init__.py │ ├── init.py # python -m sibyl_memory_hermes init │ ├── status.py # python -m sibyl_memory_hermes status │ ├── upgrade.py # python -m sibyl_memory_hermes upgrade │ └── reset.py # python -m sibyl_memory_hermes reset ├── examples/ │ └── reference_hermes_agent.py # smoke-tested reference example └── tests/ ├── test_provider.py ├── test_activation.py ├── test_compression.py └── test_tenant.py
Embedded pglite (Postgres-in-WASM) holds your memory. Permissions 0700 on the directory,
0600 on the credentials file. Your existing Hermes memory files are not modified.
├── memory.db # embedded pglite database · canonical memory store ├── memory.db-wal # write-ahead log ├── credentials.json # account_id, tenant_id, api_key, wallet/email, tier ├── config.json # user preferences (compression policy, audit level, telemetry opt-in) ├── cache/ # in-memory query result cache (rebuilt on launch) └── logs/ └── plugin.log # local operations log, rotates at 10MB
Your Hermes agent's existing memory files (MEMORY.md, USER.md, SQLite FTS5 db) are
not modified. The plugin replaces the SQLite FTS5 backend at the provider layer. Optional one-time migration
command available: python -m sibyl_memory_hermes migrate.
The plugin auto-loads credentials from ~/.sibyl-memory/credentials.json. No env vars required.
No config files. Sane defaults. The provider implements Hermes' v0.10.0 memory contract end-to-end.
from sibyl_memory_hermes import SibylMemoryProvider from hermes_agent import Agent agent = Agent(memory=SibylMemoryProvider())
Each turn, the plugin injects a structured memory context block into the agent's system prompt. Compressed, tenant-scoped, audit-logged. Replaces the FTS5 dump that Hermes ships by default.
[BEGIN MEMORY CONTEXT - Sibyl Memory v0.1.0] Tenant: t-abc123 (local pglite) Tier active: HOT Memory size: 2,847 entities · 12,431 journal entries · 47 active rules · 184MB # Recent entities (top 5 by recency) - project/atlas status=active last_modified=2h ago - person/jane role=collaborator context=working on Atlas project - product/atlas-v1.2 status=staging gate=jane signoff before prod - decision/error-budget threshold=2% last_referenced=4h ago - relationship/jane trust_level=high interaction_count=47 # Recent journal (top 5) - 2026-05-08T10:23 deployed atlas v1.2 to staging - 2026-05-08T08:51 jane requested rollback if errors >2% - 2026-05-07T19:14 shipped retry logic for queue worker - 2026-05-07T15:02 pair-debugged with jane on atlas batch processor - 2026-05-07T11:30 daily standup notes captured # Active rules (top 3 by relevance) - never deploy to production without jane's signoff - escalate any error rate >5% to operator - session bridging: end every session with a forward list [END MEMORY CONTEXT]
Free users never touch our cloud for memory operations. The plugin embeds Postgres-in-WASM and runs every read, write, and retrieval against the local database. Our cloud is in the path only for activation and Sibyl Cloud paid features (cross-device sync, team federation, enterprise audit export).
Enterprise self-host: SDK in databaseUrl mode opens a pooled pg connection directly
against the customer's own Postgres (RDS, Aurora, self-managed). Same SQL schema as the embedded pglite version.
Schema migrations bundled. Customer fully owns the data; Sibyl Labs licenses + supports.
Free tier runs locally with a soft size cap. When you approach the cap, three upgrade paths open — pick the one that matches how you buy. Cloud-tier services are branded as Sibyl Cloud.
Conversion logic by user type: crypto-native users see Sibyl Stake as the natural option (wallet already connected at activation). Mainstream developers pick Sibyl Cloud if they need sync or team features. Subscription-averse devs pick Sibyl Local Lifetime — pay once, own it. Compliance-driven orgs go through sales for Enterprise self-host. One product surface, four upgrade doors matched to how each segment actually buys.
Sibyl Memory parity test (priority #4 in the lab's public roadmap) is the gating prerequisite. When the result publishes, the plugin enters public beta. If you run a Hermes Agent in production, we want you in the early-access cohort. Reply with your use case and we will reach out when the beta opens.