Septem: Arsitektur Memori Terpadu untuk AI Agent yang Belajar

Obsidian sebagai Knowledge Base

Obsidian dipilih sebagai persistent storage karena kemampuannya dalam mengelola dokumen markdown yang saling berhubungan. Setiap entry di Obsidian bisa memiliki tag, metadata, dan link ke entry lain, sehingga membentuk knowledge graph yang kaya. Untuk AI agent, ini berarti pengetahuan tidak hanya tersimpan tetapi juga terhubung secara kontekstual.

# Contoh: Menyimpan pengetahuan permanent
python3 obsidian-memory.py save "Artikel Septem published di vyuapp.my.id" \
  --tags "article,septem,publication" \
  --importance permanent \
  --agent "project-manager"

Knowledge vault saat ini berisi 144 file dengan 29 entry yang diklasifikasikan sebagai permanent. Entry permanent mencakup arsitektur sistem, keputusan desain, dan lesson learned yang relevan untuk jangka panjang. Entry temporary (dengan TTL) mencakup progress task, session context, dan data transient lainnya.

Redis Hash untuk Session Context

Hash structure adalah struktur data yang paling banyak digunakan dalam Septem. Setiap agent memiliki hash sendiri dengan namespace yang unik, misalnya agent:artoria:recent_context atau agent:scout:research_cache. Field dalam hash merepresentasikan berbagai aspek konteks session — topik yang sedang dikerjakan, status terakhir, keputusan yang sudah diambil, dan langkah selanjutnya.

Penggunaan Hash alih-alih multiple key-value pairs memberikan beberapa keuntungan. Pertama, semua data konteks agent tersimpan dalam satu struktur data sehingga operasi read/write lebih atomic. Kedua, Hash structure mendukung operasi field-level sehingga agent bisa memperbarui satu field tanpa mempengaruhi field lainnya. Ketiga, ukuran memori yang digunakan lebih efisien dibandingkan multiple keys.

Sorted Set untuk Tracking Prioritas

Sorted Set digunakan untuk tracking yang membutuhkan berdasarkan timestamp atau skor. Dalam arsitektur ini, Sorted Set digunakan untuk dua keperluan utama: tracking kapan terakhir kali sebuah memori diakses (untuk menentukan TTL dinamis), dan tracking urutan event dalam event bus (untuk memastikan event diproses secara ordered).

# Contoh: Tracking last access time
redis.zadd("memory:access_log", {"agent:artoria:context": 1784333631})
# Query: memory mana yang paling lama tidak diakses
redis.zrangebyscore("memory:access_log", 0, timestamp_30hari_lalu)

Dengan Sorted Set, Sistem bisa dengan mudah melakukan cleanup memory yang sudah tidak aktif tanpa perlu scan seluruh database. Operasi range query pada Sorted Set memiliki kompleksitas O(log(N) + M) di mana N adalah jumlah element dan M adalah jumlah element yang dikembalikan, sehingga sangat efisien untuk dataset besar.

Redis Shared Context untuk Koordinasi Agent

Salah satu fitur paling powerful dari Septem adalah shared context yang memungkinkan agent berkoordinasi tanpa komunikasi langsung. Ketika Artoria (PM) menyelesaikan task dan ingin menyerahkan hasilnya ke Scribe untuk penulisan, Artoria menyimpan hasil riset di Redis dengan key yang bisa diakses oleh Scribe. Scribe kemudian mengambil context tersebut dan melanjutkan pekerjaan tanpa perlu Artoria mengirimkan instruksi secara eksplisit.

Pola ini sangat efektif untuk pipeline seperti article production di mana setiap phase menghasilkan output yang menjadi input untuk phase berikutnya. Dengan shared context, setiap agent bisa bekerja secara asynchronous dan mengambil data yang dibutuhkan sesuai kebutuhan, bukan sesuai jadwal komunikasi.

Penggunaan Obsidian untuk Knowledge Management

Obsidian bukan sekadar text editor — ini adalah knowledge management system yang powerful untuk mengelola pengetahuan terstruktur. Dalam konteks Septem, Document store digunakan sebagai "otak jangka panjang" yang menyimpan semua pengetahuan yang tidak boleh hilang meskipun agent mengalami restart atau crash.

Setiap entry di Knowledge vault memiliki metadata yang kaya: tag untuk klasifikasi, importance level untuk menentukan TTL (permanent, long, medium, short, ephemeral), dan agent attribution untuk mengetahui siapa yang membuat entry. Metadata ini memungkinkan Septem melakukan query yang cerdas — misalnya, hanya mengambil entry permanent saat startup, atau hanya mencari entry yang dibuat oleh agent tertentu dalam 24 jam terakhir.

Pola Penyimpanan di Obsidian

Septem mengikuti pola penyimpanan yang konsisten untuk semua entry. Setiap entry memiliki format: judul yang deskriptif, isi dalam format markdown, tag yang relevan, dan metadata importance. Entry permanent berisi keputusan arsitektur, lesson learned, dan preferensi user. Entry temporary berisi progress task, session context, dan data transient lainnya yang tidak relevan setelah session berakhir.

Audit Trail dengan SQLite

SQLite memberikan jaminan ACID (Atomicity, Consistency, Isolation, Durability) yang krusial untuk audit trail. Setiap operasi memori tercatat dalam transaksi yang atomic —either semua perubahan berhasil tercatat atau none yang tercatat. Ini mencegah kondisi dimana data tercatat di Redis tetapi tidak tercatat di SQLite, atau sebaliknya.

Schema SQLite untuk audit trail sangat sederhana namun efektif. Tabel logs mencatat setiap operasi dengan field timestamp (waktu operasi), agent_name (agent yang melakukan), operation (jenis operasi: create, update, delete), key (nama memori yang diubah), old_value (nilai sebelum perubahan), dan new_value (nilai sesudah perubahan). Dengan indeks pada kolom timestamp dan agent_name, query untuk audit atau debugging bisa dilakukan dengan cepat.

SQLite juga menyediakan fitur WAL (Write-Ahead Logging) yang memungkinkan concurrent reads saat write sedang berlangsung. Ini penting dalam konteks multi-agent di mana beberapa agent mungkin sedang membaca memori sementara agent lain sedang menulis. WAL memastikan tidak ada blocking antar operasi sehingga performa sistem tetap optimal.

Performa dan Skalabilitas

Dalam lingkungan produksi dengan 16 agent aktif, Implementasi menunjukkan performa yang sangat baik. Cache layer memberikan latensi di bawah satu milidetik untuk operasi read/write, Document layer memberikan latensi di bawah 50 milidetik untuk query, dan SQLite layer memberikan latensi di bawah 10 milidetik untuk audit logging. Dengan total 328 keys aktif di Redis dan 144 files di Obsidian, sistem masih memiliki banyak headroom untuk pertumbuhan.

Skalabilitas Skalabilitas didorong oleh beberapa desain decisions. Pertama, penggunaan Cache sebagai hot storage memastikan bahwa operasi yang sering dilakukan tidak terpengaruh oleh pertumbuhan data di Obsidian. Kedua, penggunaan namespace per agent memastikan bahwa pertumbuhan jumlah agent tidak menyebabkan konflik atau degradation. Ketiga, penggunaan WAL di SQLite memastikan bahwa peningkatan volume audit logging tidak mempengaruhi performa operasi lainnya.

SQLite sebagai Audit Trail

SQLite memberikan keandalan ACID yang dibutuhkan untuk audit trail. Setiap operasi memori tercatat dalam transaksi yang atomic —either semua perubahan berhasil atau none yang tercatat. Ini penting untuk debugging ketika agent mengalami crash atau state yang tidak konsisten.

Schema SQLite untuk audit trail sangat sederhana: tabel logs dengan kolom timestamp, agent_name, operation (create/update/delete), key, old_value, dan new_value. Dengan indeks pada kolom timestamp dan agent_name, query untuk audit bisa dilakukan dengan cepat meskipun volume data sudah mencapai ratusan ribu baris.

Alur Data: Query dan Write

Alur query di Septem mengikuti pola router-first. Ketika agent meminta memori, unified-memory.py menerima request, memeriksa Redis terlebih dahulu untuk data yang mungkin masih ada di cache, lalu fallback ke Obsidian jika tidak ditemukan. Hasil query dikembalikan ke agent dalam format yang konsisten tanpa mempedulikan backend asal data.

Alur write mengikuti pola write-through. Ketika agent menyimpan memori, operasi dilakukan ke Redis (untuk kecepatan akses) dan Obsidian (untuk persistence) secara bersamaan. SQLite audit trail dicatat setelah kedua operasi berhasil. Jika salah satu operasi gagal, seluruh transaksi di-rollback dan error dikembalikan ke agent.

Statistik Produksi Aktual

Septem sudah berjalan di produksi dan melayani 16 agent aktif. Berikut adalah statistik aktual dari sistem yang sedang berjalan:

• Total Cache keys: 328 keys aktif di berbagai namespace agent
• Obsidian files: 144 total, 29 permanent, sisanya temporary dengan TTL
• Agent aktif: 16 agent dengan distribusi workload yang berbeda-beda
• Average query latency: Redis under 1ms, Obsidian under 50ms, SQLite under 10ms
• Uptime: 99.7% sejak deployment awal Juli 2026

Performa ini menunjukkan bahwa arsitektur hybrid memberikan hasil yang sangat baik dalam lingkungan produksi nyata. Redis memberikan kecepatan untuk operasi yang sering diakses, Document store memberikan keandalan untuk pengetahuan permanent, dan SQLite memberikan integritas untuk audit trail.

Best Practices Implementasi

Berdasarkan pengalaman implementasi di lingkungan produksi, ada beberapa best practices yang bisa diikuti oleh pengembang yang ingin membangun sistem serupa.

Desain Data yang Tepat

Pilih jenis penyimpanan yang sesuai dengan karakteristik data. Gunakan in-memory cache untuk data yang sering diakses dan membutuhkan kecepatan tinggi. Gunakan persistent storage untuk data yang harus bertahan lama. Dan gunakan document store untuk data terstruktur yang perlu diquery berdasarkan field tertentu.

Monitoring dan Alerting

Implementasikan monitoring menyeluruh untuk semua komponen sistem. Pantau latency, throughput, error rate, dan penggunaan memori secara real-time. Setup alerting untuk kondisi yang memerlukan perhatian segera seperti backend yang down atau latency yang melonjak secara tiba-tiba.

Backup dan Recovery

Meskipun sistem memiliki multiple layer persistence, backup reguler tetap diperlukan. Lakukan backup secara berkala dan test prosedur recovery untuk memastikan data bisa dipulihkan dengan benar jika terjadi kegagalan sistem yang parah.

Dokumentasi yang Baik

Dokumentasikan setiap aspek sistem dari arsitektur tinggi hingga detail implementasi. Dokumentasi yang baik membantu proses debugging, onboarding developer baru, dan evolusi sistem di masa depan. Pastikan dokumentasi selalu up-to-date dengan kondisi aktual sistem di produksi.

Perbandingan dengan Pendekatan Lain

Untuk memahami keunggulan Septem, penting untuk membandingkannya dengan pendekatan alternatif yang tersedia. Setiap pendekatan memiliki kelebihan dan kekurangan masing-masing tergantung pada konteks penggunaannya.

SQLite-Only

Pendekatan ini menggunakan SQLite sebagai satu-satunya backend penyimpanan. Kelebihannya adalah kesederhanaan — tidak perlu mengelola service Redis atau Obsidian. Kekurangannya adalah performa yang rendah untuk query yang sering dilakukan karena SQLite tidak dirancang untuk high-concurrent reads. Untuk sistem dengan satu atau dua agent, pendekatan ini mungkin cukup. Tetapi untuk 16 agent aktif, SQLite-only akan menjadi bottleneck yang serius.

In-Memory Only

Pendekatan ini menyimpan semua data di RAM tanpa persistent storage. Kelebihannya adalah kecepatan yang luar biasa. Kekurangannya adalah data hilang saat restart. Untuk aplikasi stateless yang tidak membutuhkan history, pendekatan ini bisa efektif. Tetapi untuk AI agent yang membutuhkan konteks historis dan pengetahuan yang terakumulasi, in-memory only tidak memadai.

Cloud-Based (AWS DynamoDB, Google Firestore)

Pendekatan ini menggunakan managed database service dari cloud provider. Kelebihannya adalah skalabilitas otomatis dan tidak perlu mengelola infrastruktur. Kekurangannya adalah biaya yang meningkat seiring volume data dan latensi yang lebih tinggi karena data harus dikirim ke cloud. Untuk startup dengan budget terbatas seperti VyuApp, pendekatan self-hosted lebih economical.

Pertanyaan Umum

Bagaimana Septem menangani agent yang crash?

Ketika agent mengalami crash, session context-nya masih tersimpan di Redis dengan TTL yang sudah ditentukan. Agent baru yang menggantikan bisa mengambil context dari Redis dan melanjutkan pekerjaan dari titik terakhir yang diketahui. Audit trail di SQLite juga mencatat semua operasi sebelum crash sehingga state bisa dipulihkan dengan tepat.

Apakah Septem bisa digunakan tanpa Redis?

Tidak untuk konfigurasi production. Redis sangat penting untuk performa query yang cepat. Namun untuk development atau testing, sistem bisa dijalankan dengan fallback ke SQLite sebagai primary storage. Performa akan menurun tetapi fungsionalitas tetap terjaga.

Bagaimana cara menambah agent baru ke dalam sistem?

Cukup tambahkan agent baru ke routing table di konfigurasi Hermes. Septem akan otomatis membuat namespace Redis dan entry Obsidian untuk agent baru. Tidak perlu melakukan migrasi atau konfigurasi ulang pada agent yang sudah ada.

Berapa biaya operasional Septem per bulan?

Redis berjalan di VPS yang sudah ada sehingga biaya tambahan nol rupiah. Obsidian berjalan sebagai file-based storage lokal tanpa biaya langganan. SQLite juga file-based tanpa biaya. Total biaya operasional Septem adalah nol rupiah per bulan di luar biaya VPS yang sudah ada.

Bagaimana performa Septem dibandingkan Mem0?

Septem 3-5 kali lebih cepat dibandingkan Mem0 untuk operasi query. Latency Redis di bawah satu milidetik dibandingkan Mem0 yang membutuhkan 50-200 milidetik per request. Selain itu, Septem tidak memiliki dependensi ke service eksternal sehingga lebih reliable dan tidak terpengaruh oleh downtime provider.

Kesimpulan

Septem mewakili evolusi signifikan dalam cara AI agent mengelola dan berbagi memori. Dengan arsitektur hybrid yang elegan, sistem ini menghadirkan perpaduan sempurna antara kecepatan, keandalan, dan fleksibilitas yang dibutuhkan untuk ekosistem multi-agent di lingkungan produksi.

Kunci keberhasilan Septem terletak pada pendekatannya yang praktis menggabungkan teknologi yang sudah terbukti seperti Redis, Obsidian, dan SQLite dengan desain yang bijaksana. Hasilnya adalah sistem yang tidak hanya berfungsi dengan baik hari ini tetapi juga siap untuk pertumbuhan dan evolusi di masa depan.

Bagi siapa saja yang membangun sistem AI multi-agent, pelajaran dari Septem jelas: investasikan waktu untuk membangun fondasi memori yang solid sejak awal. Manfaat jangka panjangnya berupa koordinasi yang lebih baik, konteks yang terjaga, dan pengetahuan yang terakumulasi akan menghasilkan sistem yang jauh lebih powerful dibanding pendekatan tanpa memori terpadu.

Sumber Referensi

• Panduan Gin Golang Web Framework — Backend framework untuk membangun API
• Redis Caching Patterns — Pola caching Redis untuk aplikasi scalable
• Hermes Agent GitHub
• Redis Documentation
• Obsidian Help