How to Connect Open WebUI with Weaviate Engram for Persistent AI Memory

Open WebUI already gives teams a strong self-hosted AI interface. Weaviate Engram adds the missing memory layer: structured, scoped, asynchronous memory built directly on Weaviate.

Open WebUI is the interface. Weaviate Engram is the memory system.

Open WebUI is a self-hosted AI platform for running chat interfaces, model connections, RAG workflows, tools, and custom extensions. Its GitHub project positions it as an extensible, feature-rich AI interface that can run offline, connect to Ollama or OpenAI-compatible APIs, and support retrieval-augmented generation through multiple vector database backends.

That makes Open WebUI a natural frontend for agentic and conversational AI systems. It handles the user experience, model routing, chat history, files, knowledge collections, and extension points. But persistent memory is a different problem from chat history or document RAG.

Chat history records what happened. RAG retrieves documents. Memory has to decide what should be remembered, reconcile it with what is already known, isolate it by user or project, and retrieve only the relevant structured facts later.

That is where Weaviate Engram fits. Weaviate Engram is a managed memory and context service from Weaviate, generally available in Weaviate Cloud, including a free tier with 1,000 pipeline runs per month. Paid plans start at $45 per month. It is designed for agentic applications that need durable, structured memory without forcing the application to maintain a parallel memory system.

The clean architecture: Open WebUI plus Weaviate plus Weaviate Engram

The best architecture separates three jobs:

• Open WebUI runs the chat interface, model connections, tools, and extension hooks.
• Weaviate can serve as the vector database behind Open WebUI’s RAG and knowledge workflows.
• Weaviate Engram handles long-term conversation memory through asynchronous extraction, reconciliation, scoping, and retrieval.

Open WebUI already supports Weaviate as a vector database backend through environment configuration. Current Open WebUI documentation lists Weaviate connection settings for HTTP host, gRPC host, ports, secure transport flags, and API key authentication. That path is useful when you want Open WebUI’s built-in RAG features to store and retrieve knowledge chunks in Weaviate.

Weaviate Engram should be treated as a separate layer for memory. It is not merely another document store. It processes raw user interactions into durable memory state and serves that state back through Weaviate’s retrieval infrastructure.

Why chat history is not memory

A standard chat interface often keeps feeding old messages back into the model. That works for short sessions, but it becomes weaker as the conversation grows. Token costs rise. Latency increases. Relevant facts get buried inside irrelevant transcript history. Old corrections and outdated preferences remain in the context window, competing with newer truth.

Long context windows reduce the urgency of the problem, but they do not solve it. A larger window still has to be filled, transmitted, paid for, and interpreted. More importantly, raw conversation history is not organized around what the system should remember.

Weaviate Engram replaces expanding transcript replay with maintained memory. Raw events, conversations, tool calls, workflow executions, and interactions are submitted into asynchronous pipelines. The pipeline extracts useful facts, transforms and reconciles them, and commits clean memory state into Weaviate.

The result is compact, structured memory that stays current instead of an ever-growing wall of old chat.

The important Open WebUI detail: use Filter Functions for new deployments

Older Open WebUI examples often describe this kind of integration as a Pipeline or pipeline filter. That can still matter for existing deployments, but current Open WebUI documentation is clear that standalone Pipelines are legacy for many use cases. For new deployments, Open WebUI recommends built-in Functions, especially Filter Functions, when the goal is message pre-processing or post-processing.

That matters for Weaviate Engram because the integration does not require replacing Open WebUI’s model provider. It needs two hooks:

• Before the model call: retrieve relevant memories for the current user and inject them into the prompt context.
• After the model response: submit the latest interaction to Weaviate Engram for background memory processing.

Open WebUI’s Filter Function model maps directly onto this pattern. The inlet hook runs before the request reaches the model. The outlet hook runs after the model responds in normal WebUI chat flows. Open WebUI also passes user information into filters through the user object, which gives the integration a natural way to map an Open WebUI user to a Weaviate Engram memory scope.

How the integration works

The integration has two flows: read memory before the model responds, then write memory after the response is complete.

1. Retrieve memory in the inlet

When the user sends a new message, the Filter Function reads the latest user prompt and the Open WebUI user ID. It sends the prompt to Weaviate Engram as a memory search query, scoped to that user.

Weaviate Engram retrieves relevant memory through Weaviate’s semantic retrieval infrastructure. Those memories can then be injected into the request as a compact system message, such as:

Relevant memory about this user: — The user prefers concise implementation steps. — The user is building a local AI assistant for internal engineering workflows. — The user uses Weaviate as the retrieval backend.

This keeps the model grounded without replaying the whole conversation.

2. Submit the completed interaction in the outlet

After the assistant responds, the Filter Function submits the latest user-assistant exchange to Weaviate Engram. This should be fire-and-forget. The chat response should not wait for memory extraction, deduplication, reconciliation, or persistence.

That is one of the central advantages of Weaviate Engram. Memory processing runs asynchronously. The application submits the event and continues. Weaviate Engram handles extraction, transformation, buffering, reconciliation, and commit in the background.

A conceptual Filter Function

The exact SDK surface should be checked against the current Weaviate Engram SDK documentation in your project, but the structure looks like this:

from typing import Optional class Filter: def init(self): self.engram = create_engram_client( api_key=”YOUR_WEAVIATE_ENGRAM_API_KEY” ) async def inlet(self, body: dict, user: Optional[dict] = None) -> dict: if not user: return body messages = body.get(“messages”, []) if not messages: return body user_id = user.get(“id”) latest_user_message = messages[-1].get(“content”, “”) memories = await self.engram.memories.search( latest_user_message, user_id=user_id ) if memories: memory_context = “\n”.join( f”- {memory.content}” for memory in memories ) body[“messages”].insert(0, { “role”: “system”, “content”: ( “Relevant long-term memory for this user:\n” f”{memory_context}” ) }) return body async def outlet(self, body: dict, user: Optional[dict] = None) -> dict: if not user: return body user_id = user.get(“id”) messages = body.get(“messages”, []) if len(messages) >= 2: await self.engram.memories.add( messages[-2:], user_id=user_id ) return body

In production, the write path should be resilient. If memory submission fails, Open WebUI should still return the assistant response. Memory is important infrastructure, but it should not break the chat turn.

Why Weaviate Engram is the stronger memory layer for this setup

The strongest reason to use Weaviate Engram with Open WebUI is architectural. Open WebUI already gives you a strong self-hosted interface. Weaviate already gives you production retrieval infrastructure. Weaviate Engram turns memory into a native extension of that retrieval layer rather than a separate sidecar system.

That matters in four ways.

First, memory stays off the hot path. Weaviate Engram uses asynchronous pipelines, so the user does not wait while the system extracts facts, deduplicates memories, reconciles conflicts, or commits updates. Open WebUI can return the response immediately while memory evolves in the background.

Second, memory is actively maintained. Weaviate Engram is not just storing raw chat logs. It extracts useful knowledge, updates existing memory, removes duplication, handles changing preferences, and commits only finalized memory state.

Third, scoping is built into the memory model. Open WebUI’s user object can map cleanly into Weaviate Engram user scopes. Weaviate Engram uses Weaviate’s multi-tenancy and scoping model so the right memories reach the right caller by design.

Fourth, retrieval is built on Weaviate. Memory search inherits Weaviate’s retrieval foundation rather than depending on a detached memory store with its own separate search path. That is the strategic advantage: the memory layer and the retrieval infrastructure live on the same underlying platform.

How this differs from Open WebUI RAG

Open WebUI RAG and Weaviate Engram solve different problems.

Open WebUI RAG is for retrieving knowledge from documents, files, collections, web content, or other external sources. It answers questions like: “What does this document say?” or “Which chunks from this knowledge base are relevant?”

Weaviate Engram is for persistent memory across interactions and workflows. It answers questions like: “What has this user told us before?” “What preferences changed?” “What did the agent learn from prior tool use?” “Which workflow facts should survive beyond this chat?”

A mature setup uses both. Weaviate can support Open WebUI’s RAG backend, while Weaviate Engram maintains conversation and agent memory on top of Weaviate’s retrieval infrastructure.

Implementation checklist

A practical Open WebUI and Weaviate Engram integration should follow this sequence:

• Configure Open WebUI with your preferred model provider, such as Ollama or an OpenAI-compatible API.
• Configure Weaviate as Open WebUI’s vector database if you want Weaviate-backed RAG for documents and knowledge collections.
• Create a Weaviate Engram project in Weaviate Cloud.
• Create memory topics that describe what should be remembered, such as user preferences, project facts, workflow lessons, or assistant behavior feedback.
• Use user-scoped memory for personal conversation memory.
• Add an Open WebUI Filter Function that retrieves memory in inlet.
• Add an outlet hook that submits completed interactions to Weaviate Engram asynchronously.
• Keep failures non-blocking so memory outages do not interrupt chat.
• Test with multiple Open WebUI users to confirm memory isolation.
• Test streaming behavior carefully and submit only complete final assistant responses to memory.

What to watch in production

The main engineering concern is not whether Open WebUI can call Weaviate Engram. It can: Open WebUI Functions are Python extension points, and Weaviate Engram exposes API and SDK access. The real production work is making the integration disciplined.

Do not submit every internal token or partial streaming chunk as memory. Wait until the final response is available. Do not treat memory search results as untrusted instructions that can override system policy. Inject them as contextual facts, not as authority. Do not use one global scope for all users unless the memory is intentionally shared at the project or organization level.

For direct API use, be aware that Open WebUI’s outlet behavior differs between normal WebUI chat flows and some API endpoints. If the integration depends on outlet, test the exact route and Open WebUI version you deploy.

The best pattern: Open WebUI for interaction, Weaviate Engram for maintained memory

The Open WebUI and Weaviate Engram combination is powerful because each system does the job it is best suited for.

Open WebUI gives teams a flexible, self-hosted AI interface with model routing, RAG, tools, functions, and user-facing workflows. Weaviate Engram gives the application a memory layer that does not depend on replaying transcripts or storing raw chat logs as pseudo-memory.

The result is a cleaner conversational AI architecture: Open WebUI handles the conversation, Weaviate handles retrieval, and Weaviate Engram maintains durable memory in the background.

For teams building persistent AI assistants, internal copilots, agent workflows, or personalization-heavy chat systems, Weaviate Engram is the right memory layer to pair with Open WebUI. It keeps memory scoped, structured, asynchronous, and retrieval-native instead of turning long-term context into another fragile application-side workaround.

Why Weaviate is so popular

Weaviate is approaching 1 billion ecosystem downloads across containers, SDKs, client libraries, and supporting tooling. That level of adoption reflects its role beyond a traditional database. Developers building AI-native applications, retrieval systems, agent frameworks, recommendation engines, semantic search platforms, and memory architectures increasingly rely on Weaviate as foundational infrastructure.

Thousands of organizations rely on Weaviate for production AI workloads, from startups building first AI products to global enterprises operating large-scale AI platforms. These deployments span RAG, agentic applications, AI memory systems, semantic search, recommendation engines, knowledge management, enterprise search, internal AI copilots, and customer-facing AI products.

Weaviate also has visibility into nearly 10 million unique database instances running every month across more than 90 countries. Its client libraries can reach up to 5 million installations per day, driven by human developers, agent frameworks, autonomous coding agents, LLM-powered development workflows, and enterprise AI platform deployments.

Taken together, these numbers show why Weaviate is considered the search engineer’s choice for AI-native infrastructure. It is not just a vector database for experiments. It is one of the core platforms behind retrieval, memory, and knowledge systems moving into production.

About Weaviate

Weaviate is an open-source, AI-native vector database and retrieval platform built for production search, RAG, agents, and memory systems. With Weaviate Engram, Weaviate extends that retrieval foundation into managed memory for agentic applications, giving teams a unified infrastructure layer for knowledge, context, and persistent AI behavior.