System Design

System Design #3: Vector DB & Memory Patterns — So Your AI Agent Doesn't Forget

Thoroughly discussing vector database and memory patterns for AI Agents: from pgvector to knowledge graph, from basic RAG to hybrid memory. So your agent remembers, not just chats.

Muhammad Amien·Jul 1, 2026·13 min read

System Design #3: Vector DB & Memory Patterns — So Your AI Agent Doesn't Forget

Minggu ketiga setelah gue deploy AI Agent buat customer support. Semua lancar — response time di bawah 3 detik, customer puas, Slack channel sepi dari komplain. Sampai suatu pagi client WA: "Bro, agent lo kayaknya lupa semua conversation kemarin. Dia nanya nama customer yang udah 4x chat minggu ini."

Gue cek log. Ternyata conversation history udah overload context window model. Begitu conversation kepotong, informasi kustomer lama hilang. Agent balik jadi chatbot amnesia — nyapa semua orang kayak baru pertama ketemu.

Itu hari gue sadar: AI Agent tanpa memori itu cuma ChatGPT pake kostum bisnis. Dan bikin memori yang bener itu bukan cuma soal pilih database — tapi soal arsitektur. Artikel ini breakdown semua yang gue pelajari tentang vector database dan memory patterns buat AI Agent yang bisa lo terapin besok.

Kenapa Agent Lo Perlu Memori yang Bener — Bukan Sekadar Chat History

Kebanyakan developer mikir memori agent = simpan chat history di array. Teknisnya bener — tapi mindset-nya salah.

Coba bayangin: lo lagi ngerjain task complex yang butuh 14 langkah. Lo ngumpulin data dari 5 sumber, analisis, bikin draft, kirim ke 2 orang buat review. Di langkah ke-8, lo lupa apa yang lo lakuin di langkah ke-3. Gimana? Gak mungkin kan.

Tapi itu yang terjadi ke agent lo kalo memorinya cuma chat buffer. Setiap kali context window penuh, informasi lama ilang. Agent mulai ngulang pertanyaan. Nanya hal yang udah dijawab 3 turn lalu. Atau lebih parah: hallucinate fakta karena konteksnya udah gak lengkap.

AI Agent butuh tiga jenis memori, dan ini bukan metafora — ini arsitektur yang beda-beda cara kerjanya:

Short-term: Percakapan dalam satu sesi. Disimpen di buffer. Cepat, murah, tapi terbatas context window.
Long-term: Pengetahuan yang bertahan antar sesi. Ini tempat lo butuh vector DB. Mahal dikit, tapi ini yang bikin agent lo "ingat".
Working memory: State sementara — apa yang lagi dikerjain sekarang. Kayak sticky notes di meja. Biasanya JSON object yang di-update tiap langkah.

Contoh konkret working memory state — JSON yang di-update tiap langkah:

Diagram 1: Arsitektur 3-Tier Memori AI Agent

Vector DB Showdown 2026 — Mana yang Cocok Buat Lo?

Ini pertanyaan yang gue dapet paling sering: "Vector DB apa yang harus gue pake?" Jawaban singkatnya: tergantung skala dan budget lo.

Tapi sebelum lo scroll ke tabel perbandingan, satu hal penting: kebanyakan developer overestimate kebutuhan mereka. Kecuali lo bangun agent buat jutaan user, kemungkinan besar PostgreSQL + pgvector udah cukup.

The Lightweight Tier — Buat Solo Dev & Prototyping

PostgreSQL + pgvector (⭐ 22K). Lo udah pake Postgres? Install extension-nya, bikin table dengan kolom vector, beres. Lo bisa query semantic similarity dengan SQL biasa. Support IVFFlat dan HNSW indexing. Cukup buat jutaan vector. Gak perlu infrastructure tambahan.

Setup dasarnya simpel banget — cuma butuh 3 langkah:

Gue pake ini buat production agent gue sendiri. Reason? Satu database buat semua — business data, user auth, sama vector memory — simplify everything. Debugging juga lebih gampang karena semuanya di satu tempat.

Chroma (⭐ 28.6K). Open-source, Python-native, jalan embedded dalam aplikasi lo. Gak perlu server terpisah. Perfect buat prototyping dan proyek kecil-menengah. Banyak tutorial dan komunitas aktif karena integrasi erat dengan LangChain.

LanceDB (⭐ 10.7K). Developer-friendly, serverless, jalan di-disk tanpa server terpisah. Support multimodal (text, image, video). Cocok buat agent yang perlu handle berbagai tipe data — misal agent yang bisa ingat gambar, PDF, dan teks sekaligus.

The Production Tier — Buat Skala Besar

Qdrant (⭐ 32.6K). Performance-oriented, written in Rust. Support filtering kompleks, payload indexing, quantization. Recommended buat agent yang perlu query kompleks — misal "cari conversation mirip topik X dari user yang pernah komplain bulan lalu".

Milvus (⭐ 45K). Yang paling mature, cloud-native. Dibangun buat skala miliaran vector. Digunakan sama perusahaan besar: Walmart, eBay, Tencent. Tapi ops-nya berat — lo butuh dedicated DevOps, minimal 4 node Kubernetes. Jangan pake ini buat side project.

Weaviate (⭐ 16.4K). Hybrid search (vector + keyword) built-in. Support GraphQL out of the box. Bagus buat agent yang perlu combine semantic search dengan filtering terstruktur — misal agent legal yang perlu cari dokumen dengan keyword spesifik + konteks semantik.

Pinecone Managed service. Lo gak mikirin infrastructure. Mahal (mulai $70/bulan), tapi reliable. Startup-funded teams biasanya pilih ini karena gak mau hire DevOps khusus vector DB.

Decision Framework — Kapan Pake Apa

Gue simplify jadi tiga skenario:

Skenario 1 — Solo Dev / Indie Hacker: Start with pgvector. Lo udah pake Postgres, gak perlu belajar tool baru. Kalo butuh performa lebih, Chroma embedded. Kalo butuh multimodal, LanceDB.

Skenario 2 — Startup Early Stage: pgvector masih oke. Tapi kalo team lo 3+ engineer dan mulai ngeliat perf issue — Qdrant self-hosted. Performa bagus, ops manageable.

Skenario 3 — Scale-up / Enterprise: Pinecone (managed, zero ops) atau Milvus (self-hosted, full control). Pilih berdasarkan budget vs control yang lo mau.

Diagram 2: Decision Framework — Memilih Vector Database

Empat Pola Memori — Lebih dari Sekadar Simpan dan Cari

Setelah lo pilih database-nya, pertanyaan selanjutnya: gimana cara makenya? Memory pattern menentukan seberapa efektif agent lo memanfaatkan informasi yang disimpan.

Pola 1: RAG as Memory — Paling Sederhana

Simpan setiap interaksi sebagai document di vector DB. Sebelum agent nge-response, retrieve top-K dokumen paling relevan via semantic search. Inject hasilnya ke context.

Implementasi dasarnya di Go cuma 30 baris:

Kelebihan: Simpel. Lo cuma butuh vector DB + embedding model. Bisa jalan dalam 1 jam.

Kekurangan: Static retrieval. Agent gak bisa decide kapan dia perlu retrieve atau apa yang perlu di-retrieve. Semua retrieval terjadi setiap turn — boros token. Dan gak ada mekanisme untuk update, merge, atau delete memory yang udah stale.

Pola 2: MemGPT / Letta — Virtual Context Management

Ini yang paling mature secara akademis. Konsepnya: memperlakukan context window LLM kayak RAM, dan vector database kayak disk. Agent secara otomatis memindahkan data dari "disk" ke "RAM" saat dibutuhkan — mirip hierarchical memory di OS.

Letta (dulu MemGPT) punya tiga tier:

Recall memory: Archival storage — vector search untuk historical interactions.
Core memory: Key-value untuk persona, user info, preferences — selalu di-inject ke context.
Conversation memory: Chat history dalam context window. Short-term, terus di-flush.

Cocok untuk: agent yang perlu long-running conversations — customer support, personal assistant, therapist AI.

Pola 3: Temporal Knowledge Graph — Fakta yang Berubah Seiring Waktu

Ini approach yang dipake Zep. Vector DB bagus buat similarity search, tapi jelek buat tracking fakta yang berubah. Contoh: user lo pindah dari Jakarta ke Bandung. Vector search masih bisa return informasi lama tentang Jakarta — agent lo nyasar.

Zep pake knowledge graph dengan temporal awareness. Setiap fakta punya timestamp. Saat user update lokasi ke Bandung, fakta lama tentang Jakarta gak dihapus — ditandai sebagai historical. Ini penting buat agent yang perlu reasoning tentang perubahan seiring waktu.

Cocok untuk: CRM agent, health tracking agent, financial advisor agent — semua yang melibatkan fakta user yang berubah seiring waktu.

Pola 4: Hybrid — Gabungan Vector + Graph + Rules

Ini tren 2026. Paper terbaru dari Juni 2026 ("Are We Ready For An Agent-Native Memory System?") ngetes 12 sistem memori berbeda — dan kesimpulannya jelas: gak ada arsitektur tunggal yang dominan di semua skenario.

Hybrid approach menggabungkan:

Vector DB untuk semantic retrieval konteks tidak terstruktur
Knowledge Graph untuk fakta terstruktur dan relasi kompleks
Deterministic rules untuk pruning, scoring, dan maintenance tanpa biaya LLM

Paper DMF (Juni 2026) nunjukin sesuatu yang mengejutkan: pendekatan deterministic — pake classical NLP + mathematical scoring — bisa menyamai akurasi Mem0 (LLM-based) tapi dengan 0 token untuk memory management. 5x sampai 242x lebih hemat token sepanjang percakapan.

Diagram 3: Hybrid Memory Pattern — Vector DB + Knowledge Graph + Rules

Production Checklist — Dari Prototype ke Production

Berikut checklist yang gue pake sendiri setelah beberapa kali gagal deployment:

1. Mulai dengan pgvector. Selalu.

Jangan overengineer dari awal. Lo belum tau pola query lo kayak apa, berapa banyak data yang bakal numpuk, atau bottleneck di mana. pgvector kasih lo fleksibilitas untuk eksperimen tanpa lock-in ke vendor tertentu.

2. Budget Memory Lo — Jangan Biarin Membengkak

Memory store yang gak di-manage bakal tumbuh tanpa batas. Setiap interaksi baru ditambahin, gak ada yang dihapus. Hasilnya: storage cost bengkak, retrieval makin lambat, kualitas hasil turun karena terlalu banyak noise.

Paper MemRefine (Juni 2026) propose solusi simpel: tetapkan hard budget untuk jumlah entries. LLM judge (atau deterministic scoring) memutuskan setiap entry baru: simpan, merge dengan entry existing, atau delete.

3. Jangan Inject Seluruh History ke Context

Godaan terbesar: "Ah, context window model sekarang 128K token, inject aja semua memory." Jangan. Selain boros biaya, kualitas reasoning LLM menurun pas context makin panjang (lost-in-the-middle problem). Retrieve top 5-10 items paling relevan aja.

4. Monitor Retrieval Quality — Bukan Cuma Uptime

Kebanyakan monitoring cuma ngecek: agent online gak? Response time berapa? Itu gak cukup. Lo perlu monitor: berapa persen retrieval yang bener-bener relevan? Ada fakta yang dijawab bener di satu query tapi salah di query lain? Paper MemTrace (Juni 2026) nunjukin bahwa evaluasi tradisional menyesatkan — fakta yang sama bisa bener dalam satu kondisi dan salah di kondisi lain.

5. Siapkan Fallback When Retrieval Fails

Gak semua query bisa dijawab dari memory. Agent lo harus tau kapan bilang "gue gak tau" daripada hallucinate. Implementasi gampang: kasih threshold similarity score. Kalo semua hasil retrieval di bawah threshold, trigger clarification question ke user.

Yang Belum Lo Tau: Masalah yang Belum Ada Solusinya

Jujur aja: memory untuk AI Agent masih nascent. Ada beberapa masalah yang belum ada solusi elegan-nya:

Cross-agent memory sharing: Gimana caranya 3 agent berbeda share memori tanpa conflict? Belum ada standar.
Memory privacy: Paper MRMMIA (Mei 2026) pertama kali nunjukin serangan privasi terhadap agent memory. Agent bisa dieksploitasi untuk leak data user.
Forgetting mechanisms: Manusia lupa itu fitur, bukan bug — kita lupa hal yang gak penting. Agent belum bisa selective forgetting dengan baik.

Closing: Start Simple, Grow When Needed

Gue tutup dengan prinsip yang sama dari artikel sebelumnya: arsitektur AI Agent itu soal fondasi, bukan fitur. Lo gak perlu vector DB canggih di hari pertama. Lo perlu memori yang konsisten — walau simpel.

Start dengan pgvector. Implement RAG basic. Monitor. Kalo lo liat retrieval quality menurun atau latency mulai naik — baru pertimbangin dedicated vector DB. Kalo lo mulai perlu tracking fakta yang berubah seiring waktu — baru tambahin knowledge graph.

Agent yang bisa ingat itu beda kelas dengan chatbot. Dan di 2026, perbedaan itu bukan lagi nice-to-have — itu ekspektasi minimum.

Artikel berikutnya: gue bakal bahas AI Agent Production Deployment — monitoring, cost optimization, dan gimana caranya agent lo gak bangkrutin lo di production. Stay tuned.