Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

11 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

ZestMem

CI Security Release MIT License Discord

Coding agents lose useful decisions when a session ends. ZestMem gives a team one durable, searchable memory service without storing their transcripts or handing their operational knowledge to a hosted platform.

ZestMem survives a service restart

Agents use two core MCP tools:

agent-a → remember("Production deploys require signed images")
                         ↓
              PostgreSQL + vector search
                         ↓
agent-b → recall("What constrains production deploys?")
          "Production deploys require signed images"

ZestMem is self-hosted, authenticated, and designed for persistent teams using Codex, Claude Code, OpenCode, or any Streamable HTTP MCP client.

Why ZestMem?

Alternative Good at What ZestMem adds
Markdown and JSON files Simple local notes Ranked recall, concurrent agents, ownership, and revision history
Redis or NATS Fast coordination and queues Durable knowledge with provenance and semantic retrieval
A vector database Similarity search MCP semantics, access control, lifecycle, attribution, and auditability
Hosted agent memory Fast onboarding Self-hosting and control over credentials, retention, and data location

ZestMem is not a transcript recorder or a replacement for AgentBus. AgentBus moves durable messages between agents; ZestMem preserves knowledge they should reuse later.

Five-minute start

ZestMem is deliberately production-shaped: PostgreSQL 17 with pgvector, a local embedding service, and OIDC authentication. There is no auth-off production mode.

Requirements:

  • Docker Compose or Podman
  • An OIDC issuer and audience
  • Ports 8080 and 15432 available on localhost
git clone https://github.com/jahwag/zestmem.git
cd zestmem
cp .env.example .env
chmod 600 .env

Edit .env and set at least:

POSTGRES_PASSWORD=replace-with-a-long-random-value
OIDC_ISSUER=https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0
OIDC_AUDIENCE=YOUR_MEMORY_API_APP_ID
OIDC_SUBJECT_CLAIM=oid
OIDC_REQUIRED_ROLE=ZestMem.Agent

Entra v2 access tokens put the resource application's bare client-ID GUID in aud; api://YOUR_MEMORY_API_APP_ID/.default is the scope used when requesting the token.

Then start the stack:

docker compose up -d
curl --fail http://127.0.0.1:8080/readyz

The MCP endpoint is http://127.0.0.1:8080/mcp. The memory browser is at http://127.0.0.1:8080/console/.

Prebuilt binaries, checksums, signatures, provenance, and SBOMs are available from GitHub Releases.

Authentication

OIDC workload tokens and individually revocable native API keys both work on the MCP endpoint. OIDC identities resolve through the exact configured (issuer, sub) or (issuer, oid) binding to a local Principal; ZestMem's Space grants remain the authorization boundary. Give every stable agent its own identity and credential.

The browser console exchanges its entry credential for an opaque, HttpOnly product session. It supports three portable entry modes:

  • native Reader API-key exchange;
  • standard Authorization Code + PKCE through CONSOLE_OIDC_*; or
  • a trusted-edge JWT assertion through CONSOLE_ASSERTION_*.

The trusted-edge assertion authenticates only the human browser surface. MCP clients authenticate directly to the MCP resource. See .env.example and client setup for the complete settings.

What agents see

Once an operator has created a principal and space, an authenticated MCP client can store a focused memory:

{
  "name": "remember",
  "arguments": {
    "target_space_id": "team-space-id",
    "title": "Production image policy",
    "body": "Production deploys require signed container images.",
    "use_when": "Planning or reviewing a production deployment",
    "kind": "decision",
    "topics": ["deployment", "security"],
    "idempotency_key": "deploy-image-policy-v1"
  }
}

Another agent can retrieve it without knowing the title or exact wording:

{
  "name": "recall",
  "arguments": {
    "query": "What constrains production deploys?",
    "space_ids": ["team-space-id"],
    "limit": 5
  }
}

Recall returns ranked candidates and compact metadata. Full bodies are fetched only when the client explicitly reads a selected memory.

Architecture

 Codex / Claude Code / OpenCode
               │
      Streamable HTTP MCP
               │
        ┌──────▼──────┐
 OIDC ─►│   memoryd   │◄─ memoryctl (operator)
        └───┬─────┬───┘
            │     │
   PostgreSQL     local embeddings
   + pgvector     (TEI)
  • PostgreSQL is the source of truth.
  • Embeddings provide candidate retrieval; lexical evidence and metadata remain visible to clients.
  • Memories are revisioned, attributable, and scoped to spaces.
  • Workspace claims can constrain which agents may access a space.
  • Mutation responses do not echo stored memory bodies.

Operating it

Run the public endpoints behind TLS and keep PostgreSQL, embedding, health, and metrics ports private. The included Caddy configuration serves the MCP endpoint over HTTPS when MEMORY_DOMAIN is configured.

For a remote deployment, tunnel the console rather than exposing it:

ssh -N -L 18080:127.0.0.1:8080 user@memory-host

Then open http://127.0.0.1:18080/console/.

Operational references:

Health endpoints (/healthz, /readyz, and /metrics) are operational surfaces, not public product APIs.

Project status

ZestMem is actively developed and already publishes signed multi-platform binaries and container images. Interfaces may continue to sharpen as more agent teams exercise the model.

Licensed under the MIT License.

About

Distributed, context-bounded memory for autonomous agent teams

Resources

Code of conduct

Contributing

Security policy

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Used by

Contributors

Languages