Stash - Lapisan memori persisten untuk agen AI

• Lapisan memori persisten yang mempertahankan konteks percakapan dan pekerjaan meskipun sesi berganti, dengan menyimpan observasi mentah sebagai episodes lalu mengakumulasikannya menjadi pengetahuan terstruktur
• Menggunakan arsitektur yang independen dari model, sehingga Claude, GPT, LLM lokal, hingga agen kustom dapat terhubung ke lapisan memori yang sama, dengan penyimpanan berbasis PostgreSQL dan pgvector
• Memiliki peran yang berbeda dari RAG: tidak berhenti pada pencarian dokumen, tetapi juga mengakumulasi fakta, relasi, tujuan, kegagalan, dan hipotesis baru dari percakapan, serta dapat digunakan bersama RAG
• Memisahkan pengetahuan pengguna, proyek, dan pengetahuan diri agen dengan namespace dan jalur hierarkis, lalu terus menyintesis facts, relationships, causal links, patterns, dan contradictions melalui pipeline konsolidasi
• Mencakup integrasi native MCP, model diri berbasis /self, hingga loop riset berulang untuk mengubah agen berbasis sesi yang tak punya memori menjadi pelaku kerja dengan kontinuitas jangka panjang

---

Ikhtisar Stash

• Sebuah lapisan memori persisten yang berada di antara agen AI dan dunia luar, sehingga konteks sebelumnya tetap berlanjut walau sesi berganti
• Menyimpan observasi mentah sebagai episodes, lalu mengakumulasikannya menjadi pengetahuan terstruktur seperti facts, relationships, patterns, goals, failures, dan hypotheses
• Dirancang bukan untuk menggantikan model itu sendiri, melainkan memperkuat kontinuitas, dan dapat dipasang ke agen apa pun seperti Claude, GPT, maupun model lokal
• Menggunakan PostgreSQL + pgvector sebagai basis penyimpanan
• GitHub

Cara memori disusun

• Memori dipisahkan dengan namespace seperti pengguna, proyek, dan pengetahuan diri agen
• Setiap namespace terdiri dari jalur hierarkis; ketika membaca /projects, subjalur seperti /projects/stash dan /projects/cartona juga ikut disertakan
• Penulisan hanya dicatat ke satu namespace yang tepat untuk mencegah kontaminasi memori
• Memori terkait pengguna, memori proyek, dan pengetahuan diri di bawah /self dijaga agar tidak tercampur satu sama lain
• Contoh strukturnya mencakup /users/alice, /projects/restaurant-saas, /projects/mobile-app, /self/capabilities, /self/limits, /self/preferences

Perbedaan dengan RAG

• RAG lebih dekat ke lapisan pencarian yang mengambil konten relevan dari dokumen, dan tidak mengingat atau belajar dari percakapan itu sendiri
• RAG hanya bisa menangani hal-hal yang sudah ada di dalam dokumen, dan tidak dapat menciptakan pengetahuan baru dari percakapan
• Pelacakan tujuan, pemahaman niat, deteksi kontradiksi seiring waktu, dan penalaran sebab-akibat diposisikan di luar cakupan RAG
• Stash secara otomatis belajar dari percakapan, keputusan, keberhasilan, dan kegagalan sambil membangun grafik pengetahuan
• Karena pencarian dokumen dan memori pengalaman menangani masalah yang berbeda, RAG dan Stash dapat digunakan bersama

Yang membedakan dari memori AI yang ada

• Claude.ai dan ChatGPT juga memiliki memori, tetapi fitur itu terikat pada platform dan model mereka sendiri
• Stash bekerja secara independen dari model, sehingga dapat dipasang juga ke model lokal dan privat
• Kepemilikan data tetap berada di pihak pengguna, dan tersedia sebagai open source
• Mencakup item seperti konsolidasi background, pelacakan goals dan intent, pembelajaran dari failures, causal reasoning, dan self-model agen
• Berdasarkan tabel perbandingan, ChatGPT Memory dan Claude.ai Memory digolongkan sebagai “notepad”, sedangkan Stash sebagai “mind”

Masalah yang ingin diselesaikan

• Model AI saat ini pandai bernalar, tetapi tidak memiliki memori antar-sesi, sehingga pengguna harus menjelaskan ulang diri mereka dan latar belakang proyek setiap kali
• Pendekatan memasukkan riwayat percakapan panjang ke prompt setiap saat itu lambat dan mahal, serta tetap dibatasi oleh context window
• Masih kurang mekanisme pewarisan pelajaran yang bisa mencegah percobaan gagal terulang lagi di sesi berikutnya
• Fitur memori hanya disediakan sebagai fitur eksklusif di sebagian platform, sehingga agen kustom atau LLM lokal memulai dari nol tanpa konteks

Pipeline integrasi

• Proses background terus menyintesis pengalaman untuk mengubah memori mentah menjadi pengetahuan terstruktur
• Pada tahap Episodes, observasi disimpan secara append-only
• Pada tahap Facts, kumpulan episode disintesis dengan LLM
• Pada tahap Relationships, relasi entitas antar-fakta diekstrak
• Pada tahap Causal Links, pasangan sebab-akibat antar-fakta dihubungkan
• Pada tahap Patterns, diturunkan pola abstrak tingkat lebih tinggi
• Pada tahap Contradictions, dilakukan koreksi diri dan confidence decay
• Dengan Goal Inference, fakta terkait tujuan aktif dilacak secara otomatis dan kemajuan maupun konflik ditampilkan
• Dengan Failure Patterns, kesalahan berulang dideteksi lalu diekstrak sebagai fakta baru untuk mengurangi pengulangan kegagalan yang sama
• Dengan Hypothesis Scan, bukti baru dapat mengonfirmasi atau membantah hipotesis terbuka tanpa intervensi manual

Integrasi MCP

• Berjalan secara native MCP dan dapat dipasang ke Claude Desktop, Cursor, OpenCode, agen kustom, LLM lokal, serta klien MCP lainnya
• Dapat terhubung tanpa SDK, dan memungkinkan penggunaan lapisan memori yang sama di mana pun tanpa vendor lock-in
• Menyediakan total 28 alat, mencakup remember, recall, forget, init, hingga causal links, contradictions, dan hypotheses
• ./stash mcp execute --with-consolidation dapat menjalankan server MCP stdio bersama konsolidasi
• ./stash mcp serve --port 8080 --with-consolidation dapat menjalankan server SSE untuk agen jarak jauh

Model diri agen

• Saat memanggil init, dibuat kerangka namespace /self untuk mulai membangun model diri
• Di /self/capabilities, agen mengingat hal-hal yang dikuasainya dan memanfaatkannya dalam perencanaan kerja
• Di /self/limits, catatan kegagalan dan kelemahan disimpan untuk mencegah pengulangan kesalahan yang sama
• Di /self/preferences, dipelajari cara kerja yang paling efektif sehingga membentuk gaya kerja jangka panjang

Loop pembelajaran otonom

• Dengan menjalankan research loop setiap 5 menit, agen mengambil konteks saat ini dari memori masa lalu, memilih topik untuk diteliti sendiri, membuat koneksi baru, mengintegrasikannya lagi, lalu berhenti
• Pada tahap Orient, konteks masa lalu, tujuan aktif, hipotesis terbuka, dan kegagalan sebelumnya dipanggil kembali
• Pada tahap Research, agen melakukan pencarian web pada topik yang dipilihnya sendiri
• Pada tahap Think, ketegangan, kekosongan, dan kontradiksi dalam pengetahuan saat ini diungkap
• Pada tahap Invent, dihasilkan keluaran baru seperti hipotesis, pola, dan temuan
• Pada tahap Consolidate, pipeline dijalankan untuk menyintesis episode mentah menjadi pengetahuan terstruktur
• Pada tahap Reflect + Sleep, ringkasan sesi ditinggalkan dan konteks untuk eksekusi berikutnya disiapkan sebelum berhenti
• Lihat prompt loop

Kompatibilitas model dan infrastruktur

• Mengasumsikan satu konfigurasi provider yang menggunakan API kompatibel OpenAI untuk embedding maupun reasoning
• Mendukung konfigurasi cloud, lokal, dan self-hosted, serta menyatakan tidak ada vendor lock-in
• Disebutkan bahwa OpenRouter digunakan secara lokal, sehingga ratusan model dapat diakses dengan satu API key
• Juga bekerja langsung dengan Ollama, memungkinkan konfigurasi memori offline menggunakan model lokal seperti Qwen, Llama, dan Mistral
• Backend yang menggunakan format OpenAI API seperti vLLM, LM Studio, llama.cpp server, Together AI, dan Groq juga disebut didukung
• Model embedding default adalah openai/text-embedding-3-small, dan dalam kombinasi itu digunakan STASH_VECTOR_DIM=1536
• STASH_VECTOR_DIM hanya dapat diatur sebelum eksekusi pertama; jika diubah setelah inisialisasi, seluruh database harus direset

Informasi deployment dan penggunaan

• Menyediakan konfigurasi Docker Compose untuk menjalankan Postgres, pgvector, dan Stash bersama-sama
• Prosedur eksekusi dijelaskan dalam 3 langkah: clone repositori, salin .env.example menjadi .env, lalu atur API key dan model sebelum menjalankan docker compose up
• Setelah eksekusi awal, yang diharapkan adalah postgres + pgvector siap, migration diterapkan, server MCP menunggu, dan konsolidasi background berjalan
• Proyek ini dirilis dengan lisensi Apache 2.0
• GitHub Repository
• alash3al.com

[GN⁺]

Komentar Hacker News

• Saya mengira ini akhirnya membuat sesuatu seperti sistem memori Claude.ai menjadi portabel, jadi saya klik, tapi ternyata sama sekali bukan itu
  Yang ada di sini cuma pendekatan store/remember, dan yang menurut saya lebih baik adalah model latar belakang yang merangkum riwayat chat untuk membuat memori
  Di sana model tidak perlu menulis memorinya sendiri, jadi hasilnya jauh lebih baik, dan karena itu memperkenalkan ini seolah setara dengan Claude.ai terasa agak misleading
  Saya juga terus mencari sistem memori dengan pendekatan serupa karena ingin pindah ke sesuatu seperti LibreChat, tapi belum menemukannya, dan saat ini itu hampir satu-satunya alasan saya masih bertahan di Claude.ai
  Sebagai catatan, sistem itu hanya ada di Claude.ai dan tidak ada di Claude Code

  • Menurut kebocoran Claude Code terbaru, ada sesuatu bernama autoDream, dan di sana dijelaskan sebagai background memory consolidation engine: https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it
  • Saya benar-benar ingin mencoba pendekatan itu
    Pengalaman saya justru kebalikannya; saya membuat https://github.com/flippyhead/ai-brain terutama untuk diri saya sendiri, dan beberapa teman juga memakainya
    Sejauh ini, lewat CLAUDE.md, pendekatan yang menyuruh AI mencari memori yang relevan dan memikirkan kapan serta bagaimana menyimpannya bekerja cukup baik
    Pendekatan ini bisa membangun struktur berdasarkan prioritas dan juga meninggalkan catatan untuk masa depan, jadi terasa cukup berbeda dari sekadar merangkum semuanya
  • Saya lebih suka recall otomatis berjalan tanpa terlihat oleh agen
    Pembuatan memori lewat tool call juga cukup bagus, dan membuat memori otomatis saat kompresi konteks juga menurut saya oke
    Hanya saja, kalau pembuatannya otomatis, perlu consolidation asinkron, dan menyebutnya dreaming terasa agak berlebihan
    Implementasi saya ada di Elroy.bot, dan berbagai pendekatan saya rangkum di sini: https://tombedor.dev/approaches-to-agent-memory/
  • Saya penasaran bagaimana mereka membenchmark itu
    Kalau memori diekstrak di background, masalahnya jadi sulit diselaraskan dengan prefix cache
    Bahkan hanya dengan LOG.md dua tahap yang sederhana (log detail pekerjaan dan pelajaran) + MEMORY.md (mencatat item yang dipromosikan saat log dipotong) + stop hook yang dijalankan di akhir giliran, hasilnya sudah bisa cukup jauh
  • Konsep ini cukup menarik
    Rasanya seperti ada staf pendukung di belakang agen yang berbicara dengan pengguna, diam-diam menyimak percakapan lalu mencatat fakta penting, atau mencari fakta terkait di DB lalu menyela dengan memori X ini tampaknya relevan
    Kalau token gratis, ini terlihat mudah, tapi membuatnya efisien adalah masalah yang cukup menarik

• Proyek yang menjanjikan sesuatu tanpa hampir sama sekali menjelaskan cara implementasinya selalu terlihat sebagai red flag besar
  Kalau digali lebih jauh, pada dasarnya ini struktur pg_vector dengan mcp serta dua fungsi recall/remember
  Pada akhirnya lebih dekat ke RAG, dan meskipun bisa saja diklaim struktur datanya penting, hampir semua sistem memori seperti ini sejauh ini bekerja dengan cara yang mirip
  Sampai sekarang saya belum melihat bukti bahwa pencariannya lebih baik daripada vector DB search dasar

  • Situsnya keren, ada tulisan memory, dan LLM-nya buruk tapi produk ini ditampilkan seolah menyelesaikannya dengan ajaib
    Kalau itu benar-benar berhasil, pada akhirnya ini juga tidak jauh dari vectordb yang dikemas dengan rapi

• Sudah ada ulasannya: https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/
  Banyak LLM memory systems lain juga dikumpulkan di sini: https://zby.github.io/commonplace/agent-memory-systems/
  Dan di sini juga ada rangkuman hal-hal yang diharapkan dari sistem seperti ini: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/

• Agent memory systems seperti ini terasa overengineered sekaligus underdesigned, dan tampak seperti jalan buntu
  Sulit membayangkan realitas di mana ia tidak cepat melenceng dari kebutuhan model terbaru lalu membusuk
  Misalnya, hanya karena pernah sekali membuat fitur pembayaran, memori seperti don't use stripe bisa membuat banyak sesi berikutnya terus condong ke arah pembayaran

  • Yang lebih buruk, hampir tidak terlihat tanda bahwa penulisnya sendiri benar-benar pernah memakainya
    Ini sepenuhnya memory layer yang belum terbukti, dan terasa seperti hanya menaruh klaim berlebihan di situs marketing yang mewah tanpa tangkapan layar penggunaan nyata
  • Saya melihat ini sebagai masalah informasi, dan membuat utilitas kecil yang sengaja tidak menyimpan sebagian besar hal: https://github.com/skorokithakis/gnosis
    Premisnya sederhana. Hal yang sudah diketahui LLM akan tetap diketahui, jadi saya tidak menyimpan apa yang dikatakan LLM, dan hal terkait kode bisa ditinggalkan di kode serta komentar
    Sebaliknya, ada hal-hal yang bukan keduanya tapi tetap tidak pernah tertangkap
    Saat membuat sesuatu, sering kali yang lebih penting daripada apa yang benar-benar dilakukan adalah apa yang diputuskan untuk tidak dilakukan, dan utilitas ini menangkap alternatif yang ditolak serta alasannya di akhir sesi lalu menyimpannya sebagai system knowledge
    Pada akhirnya saya ingin menyimpan informasi yang tidak bisa ditemukan hanya dengan grep pada kode, yaitu hal-hal yang cuma ada di kepala rekan kerja, dan sejauh ini ini bekerja cukup baik meski masih awal
  • Saya memakai sistem memori khusus buatan sendiri, dan menghindari masalah ini dengan menjadikan semua memori sebagai ruang pencarian per konteks
    Memori seperti don't use stripe hanya masuk ke konteks ketika model diberi prompt untuk mengerjakan sesuatu yang terkait payment processing

• Saya sudah lama mencari hal seperti ini, dan senang melihat akunnya menunjukkan bahwa mereka telah merilis software sejak sebelum boom LLM
  Tapi saya berharap setiap proyek menyertakan semacam riwayat penggunaan LLM
  Akan bagus kalau ada informasi apakah dibuat dengan LLM, kalau ya seberapa besar, dipakai pada tahap apa, seberapa teliti output-nya ditinjau, dan apakah kualitasnya terasa setidaknya sama atau lebih baik dibanding jika dibuat sendirian
  Bukan untuk mencurigai orang tertentu, tapi saya ingin itu jadi hal umum di semua proyek, dan saya juga berniat melakukannya

  • Jujur saja ini terdengar agak entitled
    Tidak ada yang memaksa orang memakai proyek ini, dan Anda bisa membaca serta meninjau kodenya sendiri lalu memutuskan akan dipakai atau tidak
  • Pertanyaannya sendiri valid, tapi menurut saya tidak bisa dibiarkan dijawab hanya lewat self-reporting dari pihak yang bersangkutan
    Saya rasa tidak banyak orang yang akan jujur mengakui bahwa mereka hampir tidak mendesain atau menguji apa pun dan kualitas kodenya buruk
    Malah mungkin dibutuhkan sistem pihak ketiga untuk menjawab pertanyaan seperti ini, walaupun tentu saja kalau itu juga berbasis LLM, hasilnya bisa sangat subjektif
  • Ada sangat banyak cara membuat software dengan LLM
    Akhir-akhir ini saya menjalankan sebagian besar proyek dengan berpusat pada beberapa file Markdown, menggunakan AI untuk riset awal, perencanaan, dan pelacakan progres implementasi
    Implementasinya dilakukan bertahap sesuai rencana dan tiap tahap juga terus ditinjau
    Kalau saya diminta mendokumentasikan workflow saya, file-file itu sendiri sudah menjadi dokumentasinya
    99% kode memang dihasilkan, tapi saya berusaha keras agar dihasilkan dengan cara yang memuaskan bagi saya, dan hasilnya juga sering terasa lebih baik daripada kalau saya membuatnya sendirian
  • Saya tidak terlalu paham kenapa itu penting
    Software yang bagus dan software yang buruk bisa dibuat tanpa LLM maupun dengan LLM
    Kita tidak bertanya ke tukang kayu apakah dia memakai palu atau nail gun, atau mana yang dipakai untuk atap dan dek
    Kalau tidak ada dasar kepercayaan, pada akhirnya Anda harus memverifikasi kualitasnya sendiri atau membuatnya sendiri dari nol, selain itu ya lebih mendekati harapan bercampur optimisme

• Saya masih belum menemukan memory yang benar-benar berguna
  Ada yang cuma meninggalkan ringkasan tingkat tinggi seperti agents.md, sehingga tidak banyak membantu untuk detail konkret, misalnya kalau elemen ini diubah maka elemen itu harus ditandai sebagai draft
  Sebaliknya, pendekatan yang terlalu rinci justru kebanyakan detail sehingga diabaikan, atau detail dari satu area fitur malah mencemari perubahan di area lain
  Pada akhirnya, sejauh ini yang paling efektif justru tanpa memori, dengan memilih secara manual hanya konteks yang penting untuk sesi/prompt tersebut

  • Saya cukup tertarik pada memori, tapi setidaknya untuk alat coding, saya tidak melihatnya terlalu berguna
    Source of truth tentang apa yang dilakukan repo dan apa yang seharusnya dilakukan pada akhirnya tetaplah repo itu sendiri
    Yang Anda jelaskan barusan lebih mirip pedoman code review, dan hal seperti itu bisa dimasukkan secara eksplisit ke konteks pada saat perubahan dilakukan
    Dibanding itu, sistem memori terlalu kompleks dan akurasinya juga lebih rendah
  • Wishlist untuk sistem seperti ini ada di sini: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
  • Saya juga merasakan hal yang mirip
    Saya penasaran apakah suatu hari model-model ini akan punya continual learning
    Mereka sudah cukup pintar, tapi terasa merepotkan karena tidak punya memori sungguhan
  • Memori yang dibuat Claude hampir semuanya tipe remember-to-not-forget, jadi pada akhirnya saya mematikan fitur itu

• Bagi saya ada beberapa hal sederhana yang bekerja cukup baik, alatnya berbasis Codex

  1. functional specification yang detail dan selalu terbaru
  2. codebase yang terstruktur menjadi beberapa proyek
  3. kode dengan penamaan dan dokumentasi yang baik. Nama kelas, variabel, dan fungsi harus jelas tujuannya, meskipun panjang dan terlihat lucu, dan aturan seperti ini saya masukkan ke panduan coding di Agent.md
     Functional spec saya berperan sebagai Project.md bagi agen
     Lalu sebelum setiap agentic code review, saya membuat pohon direktori proyek, menggabungkannya dengan codebase menjadi satu file, lalu menambahkan timestamp pada nama file
     Ini ternyata cukup penting karena mengurangi kemungkinan LLM merujuk ke versi lama, dan juga memudahkan melihat diff dengan cepat tanpa harus mengirim git
     Sejauh ini workflow sederhana ini bekerja cukup baik bahkan pada codebase besar yang kompleks
     Efisiensi token-nya memang buruk, tapi ya memang berfungsi
     Tidak perlu selalu menggabungkan seluruh codebase; proyek yang sudah selesai, sudah diuji, atau tidak relevan dengan pekerjaan saat ini bisa dikeluarkan
     Tapi tetap saya masukkan ke printed directory tree, supaya agen setidaknya tahu itu ada dan bisa meminta file tertentu jika perlu
  • Pendekatan yang menarik
    Saya penasaran bagaimana pekerjaan penggabungan itu dilakukan
    Apakah manual, hanya menggabungkan file yang berubah, atau campuran keduanya?

• LLM memory secara teori terdengar bagus, tapi dalam praktiknya makin besar justru jadi sama berantakannya dengan bekerja tanpa memori
  Seperti contoh di layar awal, meski Anda bilang lanjutkan proyek saya, dalam kenyataannya jarang orang hanya mengerjakan satu proyek
  Bisa ada 5 atau 10 hal di dalam memori, dan masing-masing pasti punya makna saat disimpan
  Pada akhirnya Anda tetap harus menyebutkan lagi secara spesifik seperti lanjutkan proyek sass, dan sebagai gantinya Anda hanya mendapat sedikit konteks detail sambil mengisi LLM context dan membayar biaya tambahan MCP calls

  • Benar juga, tapi ini implementasi yang terlalu naive
    Kalau dibuat dengan benar, implementasinya mungkin bisa melampaui keterbatasan itu
  • Pada akhirnya, begitu Anda mulai menentukan secara spesifik apa yang harus diingat, itu nyaris tidak berbeda dari menyuruh AI melakukan write/read ke file

• Ini jadi terasa seperti hanya untuk vibecoder yang bekerja sendirian
  Dalam proyek nyata dengan orang sungguhan, sistem ini tidak mungkin punya seluruh memori proyek, dan saya sendiri juga tidak punya keseluruhan memori itu
  Begitu PR lain di-merge, ingatan yang saya punya langsung usang, dan yang saya pedulikan hanyalah tiket saya sendiri
  Jadi saya makin merasa hal seperti ini mungkin memang bukan alat untuk kerja kolaboratif semacam itu

• Sekarang biaya membuat software pada dasarnya sudah nyaris nol, tapi tetap saja mengejutkan melihat sesuatu seperti ini dijual lewat situs marketing vibe-coded
  Siapa yang punya waktu untuk mencoba hal seperti ini lalu menunggu berminggu-minggu atau berbulan-bulan untuk memastikan apakah benar-benar bekerja?
  Di situsnya tidak ada bukti bahwa ini lebih baik daripada RAG, atau bahkan lebih baik daripada sekadar folder file memori plus grep
  Meski begitu, isinya penuh klaim fantastis, dan scrolling-nya pun tersendat di 14fps
  Ini terlihat seperti sesuatu yang dikoding 24 jam lalu, dan sejujurnya terasa terlalu malas