Memind: a Java-native memory engine for AI agents that keeps users and agents apart

What Memind actually solves, and for whom

Most agent frameworks treat memory as one bucket of retrieved text. Memind's README draws a different line: it separates USER memory from AGENT memory. User memory holds profiles, preferences and life context. Agent memory holds directives, tool experience, playbooks and knowledge from resolved tasks. The same engine serves both, but they are distinct stores.

That split is the interesting design decision. A coding agent that remembers "this repository uses Maven and the tests are slow" is storing something different from a chatbot that remembers "this person prefers short answers." Collapsing them into one vector index means a query about a user's preference can return an agent's internal playbook, and vice versa. Memind's answer is to keep the two apart and retrieve across both layers at query time.

The intended audience is Java shops. The README claims Memind is "the first Java-native SOTA memory and context engine for AI agents," and the badge list names Java 21. The repository is a multi-module Maven build with memind-core, memind-server, memind-clients, memind-plugins, memind-integrations, memind-ui and memind-evaluation as top-level entries, plus a .claude-plugin directory. If your stack is Python, nothing here stops you from calling the REST API, but the SDKs and runtime APIs described in the README are aimed at JVM applications and Spring AI.

How the pipeline turns raw context into an Insight Tree

The README describes the flow in one sentence: Memind captures raw context from conversations, documents, images, audio, tool calls, agent timelines and resolved tasks, then turns it into structured user memory, reusable agent experience, evolving insights, connected memory graphs and task-aware memory threads.

Three structures carry the weight. The Insight Tree distills raw memories into Leaf, Branch and Root insights, so a handful of low-level facts can roll up into a pattern. The Memory Graph materializes entities, mentions, semantic links, temporal links, causal links, aliases and co-occurrence signals, then uses graph expansion at retrieval time to recover related context that similarity search alone would miss. Memory Thread groups related items into durable threads with timeline events, memberships, lifecycle state and enrichment, so an unfinished task survives across sessions.

Retrieval is multi-layer by design. The README lists Insight Trees, Memory Items, raw source data, Memory Graphs, Memory Threads, vector search, BM25 keyword search and temporal signals, with an optional Deep Retrieval path that adds query expansion, sufficiency checking and reranking. That is a lot of moving parts, and the honest reading is that each layer is a tuning surface. The README does not document how the layers are weighted or how to disable one that is hurting precision, so expect to read docs.openmemind.com before you can reason about a bad result.

Installing Memind with Docker Compose and running a first ingest

The README lists four usage paths and names Docker Compose as the recommended one: it starts memind-server and the admin UI together. The repository ships a docker-compose.yml at the top level, and the .env.example file says to copy it to .env for Docker Compose.

Start by copying the example environment file. The default placeholder is enough to boot the service, but the file is explicit that real memory extraction, retrieval and embedding calls require valid provider credentials.

cp .env.example .env

Then edit .env. The defaults point at an OpenAI-compatible endpoint through OpenRouter, with openai/gpt-4o-mini as the chat model and openai/text-embedding-3-small as the embedding model. Set OPENAI_API_KEY to a working key before you expect anything to be extracted.

OPENAI_API_KEY=your-api-key
OPENAI_BASE_URL=https://openrouter.ai/api
OPENAI_CHAT_MODEL=openai/gpt-4o-mini
OPENAI_EMBEDDING_MODEL=openai/text-embedding-3-small

Bring the stack up. The compose file exposes the server on port 8366 through SERVER_PORT, and persists state to /app/data inside the container: a SQLite database at /app/data/memind-server.db and a vector store at /app/data/vector-store.json.

docker compose up -d

If you leave MEMIND_RERANK_API_KEY blank, the README and .env.example both state that the default no-op reranker stays in place, so Deep Retrieval will not rerank. That is a reasonable first run: you get extraction and retrieval without a second provider dependency, and you can add the reranker later by setting MEMIND_RERANK_API_KEY and MEMIND_RERANK_MODEL (the example value is jina-reranker-v3).

The README does not print a curl example for the REST API, so the concrete first call is not something this article can show without inventing it. The documented entry points are REST, HTTP MCP tools, SDKs, Java runtime APIs and first-party agent integrations; docs.openmemind.com is where the README sends you for the request shapes.

Where Memind will frustrate you

The compose file makes the dependency structure plain. Memory extraction, embedding and reranking all leave your network. There is no documented local-model path, so an air-gapped deployment is not something the README supports. If your constraint is that conversation content cannot reach a third-party endpoint, this is the wrong tool.

The persistence layer is also worth pausing on. The default datasource is jdbc:sqlite:/app/data/memind-server.db and the vector store is a JSON file at /app/data/vector-store.json. Those are fine for a single node and a modest corpus. The README does not describe a clustered deployment, a migration path off SQLite, or how the JSON vector store behaves under concurrent writes. A team planning multi-instance serving is planning something the documentation does not cover.

Finally, the deletion story is missing. The README describes ingestion of conversations, documents, images and audio, and it describes retrieval, but it does not document how a memory item is deleted, expired or rolled back once written. For a system that stores user profiles and life events, that is the gap to resolve before production, not after. The README is silent on it; docs.openmemind.com may not be, but nothing here confirms it.

Memind against a plain vector store

The README states directly that Memind "is not a vector-store wrapper." The comparison that matters is against the common alternative: pgvector, or any vector database plus your own chunking and prompt assembly.

A vector store answers one question well. Given a query embedding, return the nearest chunks. Everything above that, deciding what to store, when to merge two facts, how to expire a stale preference, how to connect a task to the conversation that started it, is left to you. Memind's Insight Tree, Memory Graph and Memory Thread are attempts to answer those questions in the engine rather than in application code.

The trade is real in both directions. A vector store is a component you already know how to operate, back up and delete from. Memind is a server with a model dependency, an extraction pipeline and several retrieval layers whose interaction the README does not fully specify. You are buying structure and paying in operational surface. The benchmark badges claim rank #1 among listed baselines on LoCoMo, LongMemEval and PersonaMem under aligned MemOS / EverMemOS-style evaluation, but benchmark placement is not the same as fitness for your corpus, and no numbers for latency or cost per ingest are given.

Licence, maintenance and what an upgrade costs

Memind is licensed Apache-2.0, and the docker-compose.yml and .env.example both carry the Apache header. For most teams that is a permissive licence with a patent grant and no copyleft obligation on your own code. It says nothing about the model providers you configure: your OpenAI-compatible or DeepSeek or GLM or Anthropic or Gemini or SiliconFlow usage is governed by those vendors' terms, and the compose file lets you set keys for all of them. That is a commercial question, not a licensing one, and it is the one to take to whoever owns your vendor contracts.

The repository is not archived. Its last push was on 2026-08-13, and release 0.2.0 was tagged the same day. That is a single data point, not a track record, and no earlier releases are listed, so there is no cadence to extrapolate from. Version 0.2.0 also means the API surface is young; the README does not promise stability, and the presence of a memind-evaluation module alongside memind-core suggests the retrieval internals are still being measured and changed. Budget for reading release notes between minor versions rather than assuming drop-in upgrades.

Editorial conclusion

Memind fits Java and Spring AI teams that already have an OpenAI-compatible endpoint and need long-term memory split between user profiles and agent experience. It does not fit teams that want a managed service, a single flat vector index, or a deployment with no external model calls, because the default compose file still points at a provider. Before adopting, verify two things the README does not document: how stored memories are deleted or rolled back, and whether the SQLite datasource at MEMIND_DATASOURCE_URL is acceptable for your write volume.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openmemind/memind on GitHub
3. Project website
4. README
5. Releases