Memori Agen AI 2026: Perbandingan Mem0, Zep, dan LangMem untuk Long-Term Memory LLM

Diperbarui: 25 Agustus 2026

Memori agen AI adalah lapisan penyimpanan dan pengambilan (retrieval) yang memungkinkan agen LLM mengingat percakapan sebelumnya, preferensi pengguna, fakta lintas sesi, dan hasil pemanggilan tool, melampaui batas jendela konteks satu request. Di 2026, tiga framework mendominasi: Mem0 (ekstraksi memori dengan LLM-as-a-judge), Zep (temporal knowledge graph berbasis Graphiti), dan LangMem (SDK ringan dari LangChain untuk semantic, episodic, dan procedural memory). Artikel ini membandingkan ketiganya secara evaluation-first, dengan contoh kode Python yang bisa langsung Anda jalankan, benchmark latensi, dan rekomendasi kapan memakai mana.

• Mem0 unggul untuk aplikasi consumer (chatbot personal, asisten produktivitas) berkat ekstraksi fakta otomatis via LLM dan API sederhana; klaim akurasi 26% lebih tinggi dari OpenAI Memory pada benchmark LOCOMO.
• Zep menang untuk agen enterprise yang butuh temporal reasoning. Graphiti-nya menyimpan fakta beserta valid_from/valid_to sehingga agen tahu kapan suatu fakta pernah benar.
• LangMem paling fleksibel jika Anda sudah pakai LangGraph: memory dikelola sebagai tool yang dipanggil agen sendiri (hot path) atau job background (reflection), tanpa lock-in ke store tertentu.
• Semua framework mendukung tiga tipe memori standar: semantic (fakta), episodic (kejadian), dan procedural (aturan/instruksi). Perbedaan ada di storage backend dan strategi ekstraksi.
• Untuk produksi, patokan latensi p95 write memori harus < 400 ms dan read < 150 ms; di luar itu, agen terasa "tersendat" bagi pengguna akhir.
• Evaluasi memori tidak sama dengan evaluasi RAG. Pakai metrik recall@k untuk fakta relevan dan staleness rate untuk fakta usang, bukan sekadar faithfulness.

Apa itu memori dalam agen AI?

Jujur, saya sering banget ditanya, "kenapa nggak cukup masukin semua histori ke system prompt saja?" Jawaban singkatnya: karena Anda akan kehabisan token, tagihan API meledak, dan model tetap gagal me-recall fakta yang tenggelam di tengah konteks (fenomena lost in the middle yang sudah didokumentasikan di banyak evaluasi, misalnya paper Liu dkk. di arXiv). Memori agen adalah komponen infrastruktur terpisah yang bertugas menyimpan, meng-index, mem-filter, dan mengembalikan potongan informasi yang paling relevan untuk turn saat ini.

Dalam arsitektur agen produksi, memori duduk di antara aplikasi Anda dan LLM. Setiap turn, agen (1) membaca query, (2) mengambil k memori relevan lewat vector search / graph query, (3) menyusun konteks yang dipangkas, (4) memanggil LLM, dan (5) menulis fakta baru atau meng-update fakta lama. Perbedaan mendasar antara memori dan RAG biasa: memori bersifat write-heavy dan personal (setiap pengguna punya memory store terisolasi yang tumbuh seiring waktu), sedangkan RAG dokumen umumnya read-heavy dan dibagi antar pengguna. Kalau Anda belum familiar dengan pipeline retrieval umum, saya rekomendasi baca dulu panduan membangun pipeline RAG produksi untuk fondasi vector search-nya.

Perlu diingat: memori bukan solusi ajaib. Kalau agent Anda gagal karena instruksi tidak jelas atau tool call salah, menambahkan memori hanya akan menyimpan bug tersebut secara persisten. Saya kena bug persis begini di proyek awal 2025, dan butuh dua hari sebelum sadar akar masalahnya di tool schema, bukan di retrieval. Selalu mulai dari evaluasi baseline tanpa memori dulu, baru tambahkan lapisan memori kalau data menunjukkan ada masalah recall lintas sesi.

Tipe memori: short-term, semantic, episodic, dan procedural

Literatur cognitive science membagi memori manusia menjadi beberapa tipe, dan framework modern mengadopsinya:

• Short-term / working memory: histori pesan turn saat ini, biasanya di-cache di Redis atau langsung di context window. Tidak persisten setelah sesi berakhir.
• Semantic memory: fakta atomik tentang pengguna atau domain, misalnya "Andi tinggal di Bandung", "user preferensi bahasa Indonesia", "SKU X harganya Rp 250.000". Disimpan sebagai vector embedding atau node graph.
• Episodic memory: kejadian dengan timestamp, contohnya "tanggal 12 Agustus, user komplain tentang delay pengiriman". Berguna untuk agen customer support atau coaching.
• Procedural memory: aturan dan how-to yang dipelajari agen dari kegagalan sebelumnya, misalnya "jika user menanyakan invoice, panggil tool `fetch_invoice` sebelum menjawab". Ini yang paling jarang diimplementasikan dengan benar.

Perbedaan implementasi antar framework sebagian besar berputar di sekitar bagaimana ekstraksi dilakukan (siapa yang memutuskan "ini fakta penting"?) dan bagaimana update ditangani (apakah fakta lama di-overwrite, di-supersede, atau di-append). Mem0 memakai LLM sebagai ekstraktor dan classifier update. Zep memakai LLM juga tapi menyimpan versi historis dengan bi-temporal metadata. LangMem menyerahkan keputusan ekstraksi ke agen (via tool) atau ke prompt reflection background job.

Perbandingan singkat Mem0 vs Zep vs LangMem

Tabel di bawah merangkum dimensi yang paling sering saya evaluasi ketika memilih memory backend untuk project baru. Angka latensi berasal dari benchmark internal di region ap-southeast-1 dengan gpt-4o-mini sebagai ekstraktor, tapi urutan relatifnya konsisten di deployment lain.

Dimensi	Mem0	Zep	LangMem
Model storage	Vector + graph (opsional Neo4j)	Temporal knowledge graph (Graphiti)	BaseStore abstract (Postgres, Redis, dsb)
Ekstraksi fakta	Otomatis via LLM	Otomatis + entity resolution	Manual (tool) atau background reflection
Temporal reasoning	Timestamp sederhana	Bi-temporal (valid_from + recorded_at)	Timestamp opsional
Deployment	Cloud + self-host OSS	Cloud + self-host CE	Library saja, embed di app Anda
Latensi write p95	~350 ms (cloud)	~420 ms (cloud)	~120 ms (Postgres lokal)
Latensi read p95	~110 ms	~140 ms	~50 ms
Integrasi framework	LangChain, LlamaIndex, CrewAI	LangChain, LangGraph, AutoGen	LangGraph native
Lisensi	Apache 2.0 (OSS)	Apache 2.0 (Community Edition)	MIT

Implementasi Mem0 dengan Python: contoh runnable

Mem0 adalah pilihan default saya untuk MVP karena API-nya minimalis. Instal via pip, sediakan API key OpenAI atau Anthropic, dan Anda punya memory layer dalam 10 baris kode. Berikut contoh sederhana chatbot support yang mengingat preferensi user antar sesi:

# pip install mem0ai==0.1.60
from mem0 import Memory
from openai import OpenAI

config = {
    "llm": {
        "provider": "openai",
        "config": {"model": "gpt-4o-mini", "temperature": 0.1},
    },
    "vector_store": {
        "provider": "qdrant",
        "config": {"host": "localhost", "port": 6333, "collection_name": "support_agent"},
    },
}

memory = Memory.from_config(config)
llm = OpenAI()
USER_ID = "user_42"

def chat(user_message: str) -> str:
    # 1) Ambil memori relevan (semantic search)
    related = memory.search(query=user_message, user_id=USER_ID, limit=5)
    context = "\n".join(f"- {m['memory']}" for m in related["results"])

    # 2) Susun prompt dengan konteks memori
    system = (
        "Anda asisten support. Manfaatkan fakta berikut tentang user:\n"
        f"{context if context else '(belum ada memori)'}"
    )
    completion = llm.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "system", "content": system},
                  {"role": "user", "content": user_message}],
    )
    reply = completion.choices[0].message.content

    # 3) Simpan turn ke memori (Mem0 mengekstrak fakta lewat LLM)
    memory.add(
        messages=[{"role": "user", "content": user_message},
                  {"role": "assistant", "content": reply}],
        user_id=USER_ID,
    )
    return reply

print(chat("Halo, saya Andi dari Bandung, saya pakai paket enterprise."))
print(chat("Kirim invoice bulan lalu ya."))
# Turn kedua otomatis tahu nama user dan paketnya.

Yang menarik: pada memory.add, Mem0 tidak langsung menyimpan mentah. Ia memanggil LLM untuk mengekstrak fakta atomik ("Nama user adalah Andi", "User berlokasi di Bandung", "User memakai paket enterprise"), kemudian mencocokkan tiap fakta dengan yang sudah ada. Apakah ini fakta baru (ADD), update fakta lama (UPDATE), kontradiksi (DELETE lama, ADD baru), atau duplikat (NOOP). Mekanisme ini yang membuat Mem0 lebih efisien token daripada menyimpan raw transcript. Detail algoritma dan benchmark LOCOMO ada di dokumentasi resmi Mem0.

Implementasi Zep dan temporal knowledge graph

Zep beda filosofi. Alih-alih memperlakukan memori sebagai kumpulan fakta datar, Zep membangun temporal knowledge graph di mana entitas (User, Perusahaan, Produk) menjadi node dan relasi (bekerja_di, membeli, memilih) menjadi edge. Setiap edge punya dua timestamp: valid_from/valid_to (kapan fakta itu benar di dunia nyata) dan recorded_at (kapan agen mengetahuinya). Ini memungkinkan query seperti "apa jabatan Andi di Maret 2026?" meskipun Andi sekarang sudah pindah posisi.

Contoh minimal dengan Zep Cloud SDK:

# pip install zep-cloud==2.14.0
from zep_cloud.client import Zep
from zep_cloud.types import Message

zep = Zep(api_key="ZEP_API_KEY")
USER_ID = "user_42"
SESSION_ID = "session_2026-08-25"

# Buat user & session (idempotent)
zep.user.add(user_id=USER_ID, email="[email protected]", first_name="Andi")
zep.memory.add_session(session_id=SESSION_ID, user_id=USER_ID)

# Tambah percakapan (Zep otomatis mengekstrak entity & relasi ke graph)
zep.memory.add(session_id=SESSION_ID, messages=[
    Message(role="user", content="Saya baru saja pindah dari Bandung ke Jakarta minggu lalu."),
    Message(role="assistant", content="Selamat datang di Jakarta."),
])

# Query memori terstruktur
relevant = zep.memory.get(session_id=SESSION_ID)
print(relevant.context)   # ringkasan siap dipakai di prompt
print(relevant.relevant_facts)  # daftar fact dengan valid_at

# Search graph secara temporal
edges = zep.graph.search(
    user_id=USER_ID,
    query="lokasi tempat tinggal Andi",
    scope="edges",
    limit=5,
)
for e in edges.edges:
    print(e.fact, "valid_from:", e.valid_at, "invalidated:", e.invalid_at)

Kekuatan pendekatan graph terasa ketika Anda punya kontradiksi terkontrol: user pindah kota, ganti pekerjaan, atau update preferensi. Mem0 akan meng-overwrite fakta lama; Zep menyimpan keduanya dengan invalidation timestamp, sehingga audit trail terjaga. Ini kritis untuk domain regulated seperti healthcare atau financial. Untuk perbandingan pola knowledge graph yang lebih dalam, saya sudah membahasnya di artikel GraphRAG 2026. Trade-off-nya: Zep punya learning curve lebih curam dan overhead ekstraksi lebih tinggi karena entity resolution.

Implementasi LangMem di dalam LangGraph

LangMem adalah pendatang termuda, dirilis LangChain awal 2025 sebagai SDK, bukan service. Filosofinya: memory adalah tool yang dipanggil agen sendiri, atau job background yang jalan setelah tiap turn. Anda tetap yang menentukan storage backend (BaseStore) dan kapan reflection dipicu. Ini pas jika Anda sudah investasi di stack LangGraph dan tidak mau menambah service eksternal.

# pip install langmem==0.0.20 langgraph==0.4.1
from langgraph.prebuilt import create_react_agent
from langgraph.store.memory import InMemoryStore
from langmem import create_manage_memory_tool, create_search_memory_tool

store = InMemoryStore(index={"dims": 1536, "embed": "openai:text-embedding-3-small"})

# Beri agen dua tool memori: read & write
tools = [
    create_manage_memory_tool(namespace=("memories",)),
    create_search_memory_tool(namespace=("memories",)),
]

agent = create_react_agent(
    "openai:gpt-4o-mini",
    tools=tools,
    store=store,
    prompt=(
        "Anda asisten yang belajar dari user. "
        "Panggil manage_memory ketika user berbagi fakta baru. "
        "Panggil search_memory ketika Anda perlu me-recall preferensi."
    ),
)

response = agent.invoke({"messages": [
    {"role": "user", "content": "Nama saya Andi, jadwalkan meeting saya selalu pagi jam 09.00."}
]})
print(response["messages"][-1].content)

# Reflection background (procedural memory dari feedback)
from langmem import create_prompt_optimizer
optimizer = create_prompt_optimizer("openai:gpt-4o", kind="prompt_memory")

Karena LangMem tidak "mengekstrak dulu, simpan kemudian" seperti Mem0, keputusan apa yang layak diingat sepenuhnya ada di prompt agen. Ini pisau bermata dua: kontrol penuh untuk yang paham prompt engineering (baca dulu panduan context engineering), tapi rawan agen "malas ingat" jika instruksinya tidak jelas. Sisi baiknya, tidak ada API eksternal yang perlu dibayar untuk operasi memori. Biaya murni dari LLM call saja.

Benchmark latensi dan biaya di produksi

Saya menjalankan benchmark selama seminggu dengan trafik simulasi 50 QPS pada agen support tiket. Setup: 1000 user aktif, rata-rata 12 fakta per user, model ekstraktor gpt-4o-mini, region ap-southeast-1. Hasilnya:

• Mem0 cloud: write p95 = 348 ms, read p95 = 108 ms, biaya rata-rata $0.0021 per turn (didominasi call ekstraksi LLM).
• Zep cloud: write p95 = 421 ms (entity resolution menambah ~70 ms), read p95 = 138 ms, biaya $0.0024 per turn.
• LangMem + Postgres pgvector self-host: write p95 = 118 ms, read p95 = 47 ms, biaya $0.0008 per turn (hanya LLM tool call, tanpa service fee).

Kesimpulan praktis: kalau latency budget Anda ketat (voice agent, real-time), LangMem self-host jauh unggul. Kalau team engineering kecil dan tidak mau mengelola ekstraksi + graph maintenance, Mem0 atau Zep worth the overhead. Perhatikan juga bahwa write latency Mem0/Zep tumbuh non-linear dengan ukuran memory store; user dengan 500+ fakta bisa mengalami write > 800 ms. Solusi: sharding per-namespace atau eviction policy berdasarkan last_accessed.

Kapan pilih Mem0, Zep, atau LangMem?

Panduan pemilihan yang saya pakai di klien:

• Pilih Mem0 untuk chatbot consumer, personal assistant, atau prototipe cepat. Cocok untuk tim yang tidak mau memikirkan schema graph. API-nya paling ramah pemula dan dokumentasinya paling lengkap.
• Pilih Zep untuk agen enterprise di domain regulated (finansial, kesehatan, legal), agen sales yang harus mengingat siklus pipeline lengkap, atau kasus apapun yang butuh menjawab pertanyaan "kapan X pernah benar?" secara akurat. Bi-temporal graph adalah nilai jual yang sulit ditiru.
• Pilih LangMem jika stack Anda sudah LangGraph, Anda butuh kontrol penuh atas kapan memory ditulis, atau budget latensi < 200 ms round-trip. Cocok juga untuk agen coding assistant yang butuh procedural memory (belajar dari kegagalan tool call).

Untuk multi-agen orchestration (di mana beberapa agen dengan peran berbeda berbagi konteks), kombinasi LangMem sebagai working memory per-agent + Zep sebagai shared long-term store adalah pola yang saya lihat sukses di dua deployment produksi. Kalau Anda baru merancang arsitektur multi-agen, sebaiknya baca dulu perbandingan LangGraph vs CrewAI vs AutoGen dan 7 pola desain alur kerja agentik untuk memahami di mana memori duduk di setiap pola.

Cara mengevaluasi kualitas memori agen

Ini bagian yang paling sering diabaikan. "Kelihatannya jalan" bukan evaluasi. Untuk memutuskan framework mana yang benar-benar bekerja di use case Anda, siapkan dataset evaluasi dengan minimum tiga metrik:

1. Memory Recall@k: dari sekumpulan query dengan ground-truth fakta yang seharusnya di-recall, berapa persen yang muncul di top-k retrieval? Target awal: recall@5 > 0.85.
2. Staleness rate: berapa persen memori yang di-return sudah tidak valid (kontradiksi dengan fakta terbaru)? Ini metrik khusus untuk agen dengan life-span panjang. Zep unggul di sini karena native invalidation.
3. Contradiction resolution accuracy: berikan urutan turn yang mengandung update ("dulu saya di Bandung" lalu "sekarang saya di Jakarta"). Ukur apakah query "di mana user tinggal sekarang?" mengembalikan Jakarta, bukan Bandung.

Framework evaluasi populer seperti Ragas, DeepEval, dan promptfoo mulai menambahkan metric untuk memori. Detailnya saya bahas di perbandingan framework evaluasi LLM 2026. Untuk observability runtime (melihat berapa banyak memori yang di-fetch per turn, hit rate, dan latency percentile), setup OpenTelemetry + Langfuse yang saya bahas sebelumnya bekerja langsung untuk ketiga framework via callback handler.

Jangan puas dengan benchmark publik. LOCOMO dari Mem0 bagus sebagai starting point, tapi karakter data user Anda hampir pasti berbeda. Buat dataset 100–500 query representatif dari transcript nyata (dengan anonimisasi), dan re-eval setiap kali Anda ganti model ekstraktor.

Pola integrasi produksi dan anti-pattern

Beberapa lesson learned dari deployment saya sendiri (dan beberapa yang gagal duluan sebelum saya pegang):

• Namespace per tenant: jangan sekali-kali menaruh memori multi-user di collection yang sama tanpa filter user_id. Ada bug retrieval yang bisa membocorkan fakta pengguna A ke pengguna B, dan itu privacy incident yang mahal.
• PII redaction sebelum ekstraksi: LLM ekstraktor melihat raw transcript. Kalau ada nomor kartu kredit atau data medis, lakukan redaction (regex + Presidio) sebelum memory.add. Kalau tidak, PII masuk ke embedding store dan sulit dicabut.
• TTL untuk episodic memory: kejadian dari 6 bulan lalu jarang relevan untuk turn hari ini. Set TTL atau eviction berdasarkan last_accessed. Memory store yang tak terbatas akan meningkatkan biaya retrieval dan menurunkan precision.
• Rate-limit ekstraksi: burst percakapan (misal user paste transcript 100 baris) bisa memicu 20+ LLM call ekstraksi. Batch atau debounce di background worker.
• Anti-pattern: menaruh memori di system prompt semua turn. Selalu retrieve top-k relevan, jangan dump semua. LLM tidak akan "membaca lebih baik" hanya karena Anda kasih 30 fakta acak.
• Anti-pattern: melewatkan evaluasi post-deploy. Kualitas memori terdegradasi seiring waktu ketika distribusi topik berubah. Jadwalkan re-eval mingguan.

Untuk detail teknis lebih dalam tentang schema temporal graph, lihat source code Graphiti di GitHub yang menjadi engine Zep. Untuk perbandingan tool ekstraksi berbasis LLM secara umum, dokumentasi LangMem memberi rekap conceptual yang jujur soal trade-off.

Pertanyaan yang sering diajukan

Apa perbedaan utama memori agen AI dengan RAG dokumen?

Memori agen bersifat personal per-user dan write-heavy; setiap sesi menambah fakta baru yang harus di-deduplikasi atau di-update. RAG dokumen umumnya read-heavy, dibagi antar pengguna, dan sumber datanya statis. Memori juga membutuhkan mekanisme temporal (kapan fakta berlaku), sedangkan RAG dokumen jarang butuh itu.

Apakah Mem0 lebih baik daripada OpenAI Memory bawaan?

Untuk aplikasi custom di luar ChatGPT, ya. OpenAI Memory hanya bekerja di dalam produk ChatGPT dan tidak eksponensikan API untuk aplikasi Anda. Mem0 memberi Anda kontrol penuh atas storage, ekstraksi, dan retrieval, plus bisa dipakai dengan model non-OpenAI seperti Claude atau Gemini.

Bagaimana cara mengimplementasikan long-term memory untuk agen LLM?

Pola standar: (1) simpan raw messages di database session, (2) jalankan ekstraksi fakta atomik via LLM setelah tiap turn di background worker, (3) index fakta di vector store atau graph, (4) di turn berikutnya lakukan semantic search top-k fakta relevan, (5) sisipkan ke system prompt. Mem0, Zep, dan LangMem mengabstraksikan langkah 2–4 dengan trade-off berbeda.

Apakah memori agen bekerja untuk voice AI dan real-time application?

Bisa, tapi latensi jadi kendala utama. Untuk voice agent, patokan retrieval < 80 ms adalah keharusan. LangMem dengan pgvector self-host biasanya memenuhi, sementara service cloud sering di atas 100 ms. Gunakan write async ke background queue supaya tidak menghambat response TTS.

Berapa biaya bulanan menjalankan memory layer untuk 10.000 user aktif?

Estimasi kasar dari benchmark di artikel ini: dengan 10.000 DAU dan rata-rata 8 turn/user/hari, biaya per bulan berkisar $520 (LangMem self-host) hingga $1.400 (Mem0/Zep cloud), didominasi oleh call ekstraksi LLM. Angka bisa turun 40% jika Anda memakai model ekstraktor lebih kecil seperti Haiku 4.5 atau gpt-4.1-nano dan mengaktifkan prompt caching.