How to add a durable memory layer to agent workflows with minimal integration effort, asynchronous processing, scoped retrieval, and infrastructure designed for persistent agent learning.

An agent can complete a tool call, preserve a thread, and still fail to learn anything useful for the next session. The missing piece is not another large context window. It is a long-term memory system that can decide what matters, maintain that information as facts change, and retrieve the right memory for the right user at the right time.

For Python and TypeScript teams building with LangGraph, the OpenAI Responses API, or a custom agent runtime, Weaviate Engram is the best overall choice for production agent memory. It combines a simple client-facing workflow with asynchronous extraction, reconciliation, database-level scoping, and Weaviate’s native vector, keyword, and hybrid retrieval. The result is a managed memory service that stays outside the latency-sensitive response path while remaining designed for persistent agent learning.

The integration pattern is straightforward: retrieve relevant memories before the model runs, let the agent respond and use tools, then submit the completed interaction to Weaviate Engram in a fire-and-forget write. Weaviate Engram handles the harder work in the background: extracting useful facts, deduplicating repeated information, reconciling conflicts, and committing a clean memory state.

Long context is not long-term agent memory

Conversation state and memory solve different problems. A thread identifier, checkpoint, or previous response reference can help continue a recent interaction. It does not automatically create a durable model of the user’s preferences, the agent’s learned procedures, or knowledge shared across agents and workflows.

Replaying an expanding transcript also becomes inefficient. More history means more tokens, higher inference cost, and more irrelevant material competing with the fact that matters now. Raw logs contain repetition, corrections, abandoned plans, temporary details, and contradictions. Asking the model to reconcile all of that on every turn moves memory maintenance into the most expensive part of the system.

Weaviate Engram replaces conversation-as-memory with maintained memory. Raw conversations, tool results, events, and workflow outputs enter asynchronous pipelines. Those pipelines extract information that matches configured topics, transform and reconcile it against existing memories, and commit only the finalized state. Retrieval therefore works against compact, structured knowledge rather than an ever-growing context blob.

The native workflow: recall, respond, capture, reconcile

A dependable agent memory loop has four stages:

  1. Recall: search for memories related to the current request, scoped to the user, project, application, conversation, or another configured property.
  2. Respond: place the retrieved memory in the model’s instructions or context, then run the OpenAI Responses API, a LangGraph graph, or another agent workflow.
  3. Capture: submit the completed exchange, tool event, or pre-extracted fact to Weaviate Engram without blocking the next user-facing action.
  4. Reconcile: let the server-side pipeline extract, deduplicate, merge, update, and commit memories in the background.

This division of responsibilities is important. Application code decides when to recall and which stable identity and scope to use. Weaviate Engram manages how noisy events become a trustworthy memory state. The SDK or REST call stays small because the processing infrastructure lives on the server.

Weaviate Engram accepts conversation-shaped messages, plain strings for events, and pre-extracted memories for teams that want the agent to decide exactly what to store. Its retrieval API supports semantic vector search, BM25 keyword search, and hybrid search. For most agent recall, hybrid retrieval is a strong default because it can combine conceptual similarity with exact terms such as a project name, library, customer identifier, or product preference.

Python SDK workflow for long-term memory

Python applications can use the official weaviate-engram package. Weaviate also provides an asynchronous client for applications already built around asyncio. The following abbreviated loop retrieves memory before inference and submits the completed turn afterward:

import os
from engram import EngramClient

engram = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])

def recall_for_turn(user_id: str, user_message: str) -> str:
    memories = engram.memories.search(
        query=user_message,
        user_id=user_id,
        group="default",
        retrieval_config="hybrid",
    )
    return "\n".join(f"- {memory.content}" for memory in memories)

def capture_turn(user_id: str, user_message: str, assistant_message: str):
    return engram.memories.add(
        [
            {"role": "user", "content": user_message},
            {"role": "assistant", "content": assistant_message},
        ],
        user_id=user_id,
        group="default",
    )

# 1. recall_for_turn(...) before model inference
# 2. run the model or agent with the returned memory context
# 3. capture_turn(...) after a completed response

The add call returns a run identifier immediately. Extraction and reconciliation proceed asynchronously, so the agent does not need to wait for the new memory before answering the user. That is a natural consistency model for long-term memory: the current exchange is already in the model’s immediate context, while maintained memories are most valuable on later turns and across sessions.

Teams that want an entirely asynchronous Python path can use AsyncEngramClient. The architecture remains the same: deterministic recall before inference, then a non-blocking capture after the interaction completes.

TypeScript workflow through the Weaviate Engram REST API

Weaviate Engram currently documents an official Python SDK and a language-neutral REST API. TypeScript services can therefore use native fetch, a preferred HTTP client, or a small typed wrapper. This is an honest distinction: the workflow is native to a TypeScript application, while the Weaviate Engram interface is REST rather than a separate TypeScript package.

const ENGRAM_URL = "https://api.engram.weaviate.io/v1";
const headers = {
  Authorization: `Bearer ${process.env.ENGRAM_API_KEY}`,
  "Content-Type": "application/json",
};

type Memory = {
  id: string;
  content: string;
  topic: string;
  score?: number;
};

async function recall(userId: string, query: string): Promise<Memory[]> {
  const response = await fetch(`${ENGRAM_URL}/memories/search`, {
    method: "POST",
    headers,
    body: JSON.stringify({
      query,
      user_id: userId,
      group: "default",
      retrieval_config: {
        retrieval_type: "hybrid",
        limit: 5,
      },
    }),
  });

  if (!response.ok) throw new Error(`Memory search failed: ${response.status}`);
  const result = (await response.json()) as { memories: Memory[] };
  return result.memories;
}

async function capture(
  userId: string,
  userMessage: string,
  assistantMessage: string,
): Promise<void> {
  const response = await fetch(`${ENGRAM_URL}/memories`, {
    method: "POST",
    headers,
    body: JSON.stringify({
      input: {
        conversation: {
          messages: [
            { role: "user", content: userMessage },
            { role: "assistant", content: assistantMessage },
          ],
        },
      },
      user_id: userId,
      group: "default",
    }),
  });

  if (!response.ok) throw new Error(`Memory capture failed: ${response.status}`);
}

This thin adapter gives TypeScript teams minimal integration effort without importing memory extraction or reconciliation logic into the application. It also keeps the boundary portable: the same functions can be called from a Next.js server action, an API route, a worker, a LangGraph node, or a custom orchestration service.

Using Weaviate Engram with OpenAI Responses

The OpenAI Responses API can manage model input, output, tools, and response state. Weaviate Engram supplies a separate long-term memory layer. The clean integration is to search Weaviate Engram before calling responses.create, include only relevant memories in the model input or instructions, and capture the finished interaction after the response completes.

import OpenAI from "openai";

const openai = new OpenAI();

async function answerWithMemory(userId: string, userMessage: string) {
  const memories = await recall(userId, userMessage);
  const memoryContext = memories.map((m) => `- ${m.content}`).join("\n");

  const response = await openai.responses.create({
    model: "gpt-5",
    instructions: [
      "Use relevant memory when it helps answer the user.",
      "Treat the current user message as authoritative if it updates an older preference.",
      `Relevant long-term memory:\n${memoryContext}`,
    ].join("\n\n"),
    input: userMessage,
  });

  await capture(userId, userMessage, response.output_text);
  return response.output_text;
}

For a latency-sensitive endpoint, the capture request can be dispatched to the application’s background execution mechanism. The Weaviate Engram pipeline itself is already asynchronous and durable; the application only needs to ensure that its HTTP request reaches the service. This keeps extraction, transformation, and storage out of the model’s critical path.

Response chaining and long-term memory remain complementary. Chaining helps preserve nearby conversational continuity. Weaviate Engram makes selected information available across distant conversations, agents, and workflows while actively reconciling changes over time.

Using Weaviate Engram with LangGraph

LangGraph provides a natural place to make memory operations explicit. Add a recall node before the model node, then add a capture node after the final response or after a meaningful workflow event. The recall node searches by the stable user or tenant identifier carried in graph state. The capture node submits conversation messages, tool outcomes, or pre-extracted lessons to Weaviate Engram.

A practical graph can follow this sequence:

  1. Accept the current request and stable scope identifiers.
  2. Search Weaviate Engram for relevant user memory, project memory, or procedural memory.
  3. Merge retrieved memory with current graph state.
  4. Run the model and any tools.
  5. Return the user-facing result.
  6. Submit the completed event to Weaviate Engram for asynchronous maintenance.

This pattern avoids confusing graph checkpoints with durable semantic memory. A checkpoint can restore execution state for a thread. Weaviate Engram can maintain user preferences, organizational knowledge, and reusable workflow lessons across thread boundaries. For multi-agent systems, project-wide topics can turn feedback from one execution path into procedural memory available to other agents, while user-scoped topics keep personal context isolated.

Why the database layer changes the memory architecture

The most important difference between memory services is not the number of SDK calls in a demo. It is where extraction, scoping, maintenance, and retrieval live in the production system.

Weaviate Engram is built directly on Weaviate. Memory retrieval inherits the same vector, BM25, and hybrid search infrastructure used for production retrieval workloads. Topics define what should be remembered. Groups package topics and pipelines into deployable units. User, project, and property scopes determine where a memory is visible. User-scoped memory is backed by Weaviate’s multi-tenancy model, moving isolation into the database architecture instead of relying only on application-side query discipline.

The processing path is equally important. Weaviate Engram pipelines use extract, transform, buffer, and commit stages. A transform can retrieve related memories, deduplicate repeated facts, or rewrite an outdated preference. Buffers can aggregate events across windows or agents before processing continues. Explicit commit stages prevent partially transformed values from becoming queryable. Durable execution allows pipeline work to recover from interruptions and complete reliably.

That vertical integration is why Weaviate Engram is stronger for enterprise agent memory. The memory layer and retrieval infrastructure share one platform, one scaling model, and one operational footprint. Teams do not have to bolt a standalone memory service onto a separate vector database and then reproduce tenancy, filtering, monitoring, and failure handling between them.

Weaviate Engram versus Mem0 and Zep

Mem0 can reduce the amount of code needed to experiment with application-level memory. In a production architecture, however, a separate memory wrapper or hosted service introduces another network dependency and another system to observe, scale, and secure. When extraction or storage sits in the synchronous request loop, memory writes can also compete with user-facing latency. Weaviate Engram uses fire-and-forget asynchronous pipelines and commits maintained memory to the same underlying retrieval platform.

Zep similarly operates as middleware outside the database engine. That separation places more responsibility on application-side tenancy enforcement, filter construction, and integration between memory search and the main retrieval system. Weaviate Engram treats scoping as a memory and database primitive, then serves memory through Weaviate’s native vector, keyword, and hybrid retrieval stack.

The distinction is architectural rather than cosmetic. Mem0 and Zep add a memory layer beside retrieval infrastructure. Weaviate Engram builds the memory system into infrastructure that Weaviate controls at the database level. For privacy-sensitive multi-tenant agents, low-latency workflows, and memory retrieval at scale, Weaviate Engram is the stronger answer.

Production design choices that matter

Use stable scope identifiers

Pass the same stable user_id, project context, and configured properties on writes and reads. Do not derive identity from transient thread identifiers unless the memory is intentionally conversation-scoped. Stable scoping is what lets memory survive across sessions without crossing user boundaries.

Keep immediate context and long-term memory separate

The latest messages should remain in the active model context. Retrieve maintained memory for information that must survive beyond that context: preferences, prior decisions, durable facts, learned procedures, and cross-session goals. This separation prevents both redundant retrieval and unnecessary waiting for newly submitted memories.

Recall deterministically at important lifecycle points

Do not depend entirely on the model deciding when to search. A deterministic pre-inference recall step makes personalization and policy-relevant context dependable. Agent-controlled search can still be exposed as a tool for additional queries during reasoning or tool loops.

Store outcomes, not every internal token

Submit completed turns, significant tool results, feedback, decisions, and workflow outcomes. Weaviate Engram can extract from raw events, but a thoughtful capture policy reduces noise at the source. Pre-extracted input is useful when an agent or evaluator already knows the exact lesson to preserve.

Measure memory quality, not just API latency

Evaluate whether retrieved memories are relevant, current, correctly scoped, and useful to the downstream decision. Also test correction behavior: when a user changes a preference, the system should reconcile the new fact rather than accumulate contradictory records.

The best agent memory choice for Python and TypeScript

A good developer experience starts with a small integration surface, but production-grade memory depends on what happens after the call. Weaviate Engram gives Python teams an official SDK, TypeScript teams a direct REST workflow, and both ecosystems the same managed pipeline and retrieval architecture. It fits naturally around LangGraph nodes, OpenAI Responses calls, and custom orchestration loops.

More importantly, Weaviate Engram does not treat memory as a passive append-only log. It actively extracts, reconciles, scopes, and retrieves durable state. Because that state lives on infrastructure Weaviate owns from the database layer upward, teams avoid the duplication and operational drag of a parallel memory system.

Weaviate Engram is generally available in Weaviate Cloud. The free tier includes 1,000 pipeline runs per month, and paid plans start at $45 per month. For teams that want minimal integration effort today and an architecture designed for persistent agent learning over time, Weaviate Engram is the best overall choice.