Long-horizon memory in leading AI agent frameworks.

An agent that needs to behave consistently over weeks or months needs at least four distinct memory layers: session memory, durable application memory, durable external artifacts, and an operational system of record that survives retries, schema changes, and human corrections. LangGraph, OpenAI Assistants, Claude Agent SDK, and AutoGPT Platform distribute those responsibilities in four genuinely different ways — and the differences matter a lot once you're planning for month-scale consistency instead of a single session.

LangGraph — the most explicit architecture

LangGraph separates checkpointers (thread-scoped state snapshots — conversation continuity, human-in-the-loop, time travel) from stores (arbitrary key-value data that persists across threads — user preferences, facts, shared knowledge). That split is unusually deliberate, and it comes with real production controls: TTL configuration for both checkpoints and store items, delete-vs-keep-latest sweep strategies, and encryption at rest in Agent Server deployments. Checkpoints are created at every super-step, so you get full replay and branching — a real operational advantage when an agent has to stay explainable over months.

The risk isn't that LangGraph memory disappears. It's that it becomes too easy to keep everything, producing bloat, stale facts, and branch divergence if you don't apply TTLs and treat the store as curated durable facts rather than a dumping ground.

OpenAI Assistants — the most managed, and the most opaque

Assistants persists threads, not a dedicated long-term memory subsystem. Threads store message history and truncate it automatically once a conversation exceeds context length — convenient, but it means commitments can silently slide out of the active prompt even though they technically still exist somewhere. Vector stores (the retrieval substrate for file_search) do support expiration policies and chunking controls, but there's no first-class user-profile abstraction, no version history, and no per-memory ACLs. For anything that has to be remembered "forever" — a user preference, a standing commitment — a thread is the wrong primitive, because it's scoped to a conversation and gets truncated by design.

Claude Agent SDK — strong at transcripts, not semantic memory

The Agent SDK persists session transcripts to disk automatically — full support for continue, resume, fork, and an optional SessionStore that mirrors transcripts to S3, Redis, or Postgres. Critically, sessions persist the conversation, not the filesystem — working-directory artifacts and CLAUDE.md memory files don't survive a restart unless you persist them separately. Mirror writes are also best-effort: after retries fail, the SDK emits mirror_error and keeps going, meaning the local transcript stays authoritative while a shared store can silently fall behind.

Anthropic's separate Managed Agents product now has a considerably richer native memory system — workspace-scoped stores, immutable versions, optimistic concurrency, 30-day retained history, explicit read-only vs. read-write access. That's one of the best turnkey long-term memory offerings on the market today, but it's adjacent to the Agent SDK, not part of it.

AutoGPT Platform — real persistence, no canonical memory model

Today's AutoGPT Platform persists a lot: workflow definitions, execution history, user workspaces, schedules, and embeddings, all in Postgres/pgvector with Redis and RabbitMQ as supporting services. That's solid durable application persistence — but it's not opinionated about long-horizon autobiographical memory the way LangGraph is. The classic branch's memory layer has historically been pluggable and unstable, with vector-memory backends documented in places and removed elsewhere during rework. You get real infrastructure pieces, but you have to define the canonical memory schema yourself.

The design conclusion that travels across all four

Don't let a framework's built-in "memory" become your source of truth. Store authoritative facts, preferences, commitments, and side-effect history in a database you govern; treat thread or session memory as working memory; treat semantic retrieval as recall assistance, not ground truth. A robust agent loop needs an explicit extraction and reconciliation stage between transient interaction history and durable memory — none of these frameworks force that discipline on you by default.

The same three failure modes show up everywhere: scope confusion (treating session history as durable memory), silent incompleteness (checkpoint bloat, thread truncation, or workflow state drifting out of sync with files and embeddings), and memory poisoning (a writable store getting corrupted by prompt injection from untrusted input — Anthropic is the only vendor here that names this threat explicitly in its docs, with the fix being to keep shared/reference stores read-only).