How to Fix 'memory not persisting' in AutoGen (TypeScript)

When AutoGen says memory is not persisting in TypeScript, it usually means your agent can see state during one run, but that state is gone on the next turn, next request, or process restart. In practice, this shows up when you expect Memory or a store-backed component to retain conversation context, but you’ve only wired in ephemeral in-memory objects.

The usual failure mode is simple: the agent is recreated per request, or the memory object is not connected to a persistent store. You’ll often see behavior like memory.get() returning empty on the next run, or the agent acting like it has no prior context even though you “saved” it.

The Most Common Cause

The #1 cause is using an in-memory instance that gets rebuilt every time your app handles a request.

In AutoGen TypeScript, this typically happens when you create the agent and memory inside a route handler, serverless function, or job worker. The code runs fine once, but the data disappears as soon as the process ends.

Broken vs fixed pattern

// BROKEN: recreated on every request
import { AssistantAgent } from "@autogen/agent";
import { InMemoryStore } from "@autogen/memory";

export async function POST(req: Request) {
  const memory = new InMemoryStore();
  const agent = new AssistantAgent({
    name: "support-agent",
    modelClient,
    memory,
  });

  await memory.add({
    key: "customer_notes",
    value: "VIP customer prefers email",
  });

  const result = await agent.run("What do we know about this customer?");
  return Response.json({ result });
}

// FIXED: stable memory/store outside the handler
import { AssistantAgent } from "@autogen/agent";
import { FileMemoryStore } from "@autogen/memory";

const memory = new FileMemoryStore({
  path: "./data/autogen-memory.json",
});

const agent = new AssistantAgent({
  name: "support-agent",
  modelClient,
  memory,
});

export async function POST(req: Request) {
  await memory.add({
    key: "customer_notes",
    value: "VIP customer prefers email",
  });

  const result = await agent.run("What do we know about this customer?");
  return Response.json({ result });
}

If you’re running in serverless, file-based persistence may still be wrong if the filesystem is ephemeral. In that case, use a real backing store like Redis, Postgres, or whatever persistence layer your deployment actually guarantees.

Other Possible Causes

1) You attached memory to the wrong object

Some AutoGen setups separate the chat participant from the orchestration layer. If you attach memory to a helper object that never gets used by the actual AssistantAgent, nothing persists in practice.

// Wrong
const memory = new FileMemoryStore({ path: "./memory.json" });
const runtime = { memory }; // not used by agent

const agent = new AssistantAgent({
  name: "assistant",
  modelClient,
});

// Right
const memory = new FileMemoryStore({ path: "./memory.json" });

const agent = new AssistantAgent({
  name: "assistant",
  modelClient,
  memory,
});

2) Your store writes are never flushed or awaited

If your storage adapter is async and you don’t await writes, you can get intermittent loss. This shows up especially when your process exits right after adding memory.

// Broken
memory.add({ key: "case_id", value: "A-12345" });
process.exit(0);

// Fixed
await memory.add({ key: "case_id", value: "A-12345" });
// let the event loop finish naturally

3) You are expecting conversation history to be persisted automatically

AutoGen chat history and long-term memory are not always the same thing. A stored message transcript does not mean semantic memory was written to your configured store.

// This keeps runtime chat state only if you don't persist it yourself
const result = await agent.run("Summarize my last issue");

If you need persistence across sessions, explicitly write relevant facts into your Memory implementation or use a backed conversation store.

4) Your environment resets between runs

This one hits local dev and containerized deployments hard. If your Docker container restarts or your serverless function cold-starts with empty local disk, FileMemoryStore will look broken even though it’s doing exactly what you asked.

# Example bad deployment assumption
volumes:
  - ./data:/app/data   # works locally, may not survive redeploys in prod

Use durable storage:

const memory = new RedisMemoryStore({
  url: process.env.REDIS_URL!,
});

How to Debug It

1. •

   Check whether you’re recreating objects per request
   Log object creation for both the agent and memory store.

   console.log("creating memory/store");
   console.log("creating assistant agent");
   

2. •

   Verify reads and writes directly on the store
   Don’t test through the agent first.

   await memory.add({ key: "foo", value: "bar" });
   console.log(await memory.get("foo"));
   

3. •

   Inspect whether your backing store is actually persistent
   If you’re using InMemoryStore, stop there. That class is expected to lose data on restart.

4. •

   Confirm your deployment survives restarts
   Restart the app and query for previously written state.

   • •If it disappears after restart, your storage layer is ephemeral.
   • •If it exists but the agent can’t see it, wiring is wrong.

Prevention

• •Create agents and stores at application scope when possible, not inside request handlers.
• •Use a real persistent backend for anything that must survive restarts.
• •Write a small integration test that:
  • •stores a fact,
  • •restarts the process,
  • •verifies retrieval still works.

The shortest version of this bug report is usually: you used ephemeral storage or recreated everything per request. Fix that first before debugging prompt logic or model behavior.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.