Titen dan Memory Level 6: Cara Membangun Ingatan Bersama untuk Tim AI Agent

Setiap AI agent bisa terlihat cerdas saat bekerja sendirian. Masalah baru muncul ketika pekerjaan berpindah tangan.

Agent penjualan menyelesaikan percakapan dengan calon pelanggan. Agent proposal bangun beberapa menit kemudian, tetapi tidak tahu diskon mana yang sudah dilarang, siapa pengambil keputusan, dan mengapa tanggal implementasi diundur. Agent customer success lalu membaca ringkasan yang berbeda. Sementara itu, agent operasional mengulang pengecekan yang sebenarnya sudah selesai. Semua agent punya akses ke model yang bagus. Yang tidak mereka punya adalah ingatan bersama yang tertib.

Ini bukan sekadar masalah "kurang panjang konteks". Menambahkan seluruh riwayat chat ke prompt biasanya hanya memindahkan masalah: biaya membengkak, informasi lama bercampur dengan informasi terbaru, instruksi berbahaya ikut terbawa, dan tidak jelas fakta mana yang boleh dilihat agent tertentu. Vector search membantu menemukan teks yang mirip, tetapi kemiripan bukan bukti kebenaran. Knowledge base membantu menyimpan dokumen, tetapi tidak otomatis menjawab siapa sedang mengerjakan apa, hasil mana yang sudah dibatalkan, dan konteks persis apa yang diterima agent ketika mengambil keputusan.

Titen mencoba menangani celah tersebut. Dokumentasinya mendefinisikan Titen sebagai open-source collaborative memory fabric for AI agents: lapisan memori bersama yang memisahkan bukti, kesimpulan, paket konteks, dan state koordinasi. Repositorinya tersedia di GitHub dengan lisensi Apache-2.0.

Titen menyebut desain kolaboratif ini Memory Level 6. Istilah itu perlu dibaca dengan disiplin: Level 1 sampai Level 6 adalah taksonomi produk Titen sendiri, bukan standar industri AI, bukan sertifikasi, dan bukan skala yang ditetapkan badan standar mana pun. Artikel ini memakai istilah tersebut hanya untuk menjelaskan model Titen.

Status fitur juga tidak akan dicampur. Bila dokumentasi menyatakan sesuatu sebagai desain produk, artikel ini menyebutnya klaim atau definisi resmi Titen. Bila kode dan dokumentasi menunjukkan fitur sudah tersedia, disebut sudah diimplementasikan atau dikirim saat ini. Bila roadmap belum menuntaskannya, disebut direncanakan. Penilaian tentang penerapan di perusahaan Indonesia disebut inferensi atau rekomendasi, bukan bukti pelanggan maupun janji hasil.

Masalah sebenarnya: agent bangun tanpa memori bersama

Bayangkan tiga agent menangani pengadaan barang.

Agent pertama memeriksa penawaran pemasok dan menemukan harga yang tidak sesuai kontrak. Agent kedua diminta meminta revisi. Agent ketiga bertugas menyiapkan persetujuan direktur. Jika ketiganya hanya membaca chat history, mereka mungkin melihat percakapan panjang tanpa tahu kalimat mana yang merupakan bukti asli, mana tafsir agent, dan mana keputusan yang sudah dicabut.

Jika mereka memakai basic RAG, sistem dapat mengambil tiga potongan dokumen yang semantik mirip dengan "harga kontrak". Tetap belum jelas apakah dokumen itu masih berlaku, apakah sumbernya boleh dilihat agent tersebut, atau apakah ada bukti yang bertentangan. Jika semuanya dimasukkan ke satu vector database, pencarian bisa cepat, tetapi database tersebut tidak otomatis menjadi ledger kebenaran, mekanisme handoff, atau kontrol akses.

Ada lima pertanyaan operasional yang harus dijawab:

1. Apa yang sungguh terjadi, dan dari sumber mana?
2. Kesimpulan apa yang ditarik dari bukti itu?
3. Apakah kesimpulan tersebut masih berlaku atau sudah diperselisihkan?
4. Informasi apa yang benar-benar diberikan kepada agent saat bertindak?
5. Siapa yang sedang memegang pekerjaan, sudah sampai mana, dan siapa penerusnya?

Titen memecah pertanyaan tersebut menjadi objek dan proses yang berbeda. Pemisahan ini lebih penting daripada kapasitas penyimpanannya. Satu tumpukan memori yang besar memang mudah dibuat. Memori yang bisa ditelusuri, dibatasi, dikoreksi, dan diserahkan ke actor berikutnya jauh lebih sulit.

Bagi pembaca yang ingin melihat gambaran lebih luas tentang state dan memory agent, baca Second Brain Agentic AI: Arsitektur Memori untuk Agent. Untuk persoalan orkestrasi, batas peran, dan koordinasi, lihat juga cara menghubungkan beberapa AI agent tanpa membuat operasional kacau.

Apa itu Titen?

Secara praktis, Titen adalah memory dan context plane, bukan agent yang mengerjakan tugas bisnis. Ia menyimpan evidence, membuat atau menerima claim yang merujuk evidence, menyusun context pack sesuai scope dan anggaran token, merekam feedback, serta menyediakan primitive koordinasi seperti checkpoint, lease, dan handoff.

Titen bukan pengganti:

• CRM atau ERP sebagai system of record;
• API stok, pembayaran, saldo, dan status pesanan;
• agent framework atau orchestrator;
• scheduler dan retry engine;
• secret manager, IAM, atau kontrol jaringan;
• knowledge base editorial;
• persetujuan manusia untuk tindakan berisiko.

Perbedaan ini penting. Jika chatbot pelanggan menanyakan status pembayaran, angka terbaru harus datang dari sistem transaksi pemilik data. Memory boleh membantu agent memahami konteks pelanggan dan kebijakan yang relevan. Memory tidak boleh mengarang saldo dari claim lama.

Dalam product invariants Titen, dua aturan menonjol. Pertama, vector adalah indeks, bukan sumber kebenaran. Kedua, memory yang diambil adalah data referensi, bukan instruksi. Aturan kedua melindungi caller dari stored prompt injection hanya jika integrasinya ikut patuh: blok memory harus diperlakukan sebagai kutipan yang tidak dipercaya, bukan ditaruh setara dengan system instruction.

Tangga Memory Level 1-6 menurut Titen

Dokumentasi memory levels Titen memakai tangga berikut untuk menerangkan perkembangan kapabilitas. Sekali lagi, ini bahasa produk Titen, bukan standar universal.

Level	Kapabilitas dalam taksonomi Titen	Pertanyaan yang dijawab
Level 1	Session context dan file mentah	Apa yang ada di percakapan atau berkas sesi ini?
Level 2	Semantic retrieval dari penyimpanan eksternal	Teks mana yang paling mirip dengan pertanyaan?
Level 3	Jenis memori dan relasi yang terstruktur	Apakah ini fakta, preferensi, kejadian, atau prosedur?
Level 4	Ekstraksi, konsolidasi, dan pelupaan otomatis	Apa yang perlu disimpan, digabung, atau dilupakan?
Level 5	Kompilasi konteks temporal berbasis evidence dan outcome feedback	Apa yang seharusnya dilihat satu actor sekarang, dalam batas token?
Level 6	Memori kolaboratif, governance, dan federation opsional	Bagaimana banyak actor berbagi ingatan dan pekerjaan dengan aman?

Level 1: session context dan raw files

Ini bentuk paling umum. Agent membaca percakapan aktif, dokumen terlampir, atau file di workspace. Cepat dan sederhana, tetapi rapuh ketika sesi berakhir atau pekerjaan berpindah agent. Riwayat juga membawa noise: sapaan, percobaan gagal, instruksi usang, dan informasi yang seharusnya tidak ikut ke tugas berikutnya.

Level 2: semantic retrieval

Di level ini, memory berada di luar prompt dan dapat dicari dengan makna. Embedding membantu ketika istilah pertanyaan tidak sama persis dengan dokumen. Misalnya "termin pembayaran" dapat menemukan teks yang berbicara tentang jatuh tempo invoice. Namun hasil terdekat belum tentu terbaru, benar, atau boleh diakses.

Level 3: typed memory dan relationships

Memori tidak lagi sekadar potongan teks. Sistem membedakan fakta, preferensi, keputusan, episode, prosedur, dan hubungan. Relasi membantu menjawab sumber dan kaitan antarobjek. Struktur ini mengurangi ambiguitas, tetapi belum otomatis mengelola perubahan sepanjang waktu.

Level 4: extraction, consolidation, dan forgetting

Sistem mulai mengekstrak memory dari interaksi, menggabungkan duplikasi, dan melupakan informasi. Ini mengurangi pekerjaan manual. Risiko barunya adalah ekstraksi yang keliru atau konsolidasi yang menghapus perbedaan penting. "Pelanggan meminta pengiriman Jumat" dan "pelanggan membatalkan pengiriman Jumat" tidak boleh diringkas menjadi satu preferensi statis.

Level 5: evidence-grounded context compiler

Menurut Titen, lompatan utama terjadi di sini. Fokusnya bukan hanya apa yang tersimpan, tetapi apa yang pantas ditampilkan kepada agent sekarang. Evidence punya asal, claim punya lifecycle, konflik dipertahankan, dan compiler mengemas informasi di bawah batas token. Outcome feedback kemudian memengaruhi utility ranking tanpa menulis ulang bukti.

Level 6: collaboration dan governance

Level 6 menambahkan identity, scope, visibility, checkpoint, lease, handoff, audit, channel release, dan pertukaran event antardeployment. Tujuannya agar banyak actor dapat berbagi memory tanpa otomatis kehilangan perspektif privat atau mengerjakan resource yang sama bersamaan.

Label "lebih tinggi" tidak berarti setiap organisasi perlu langsung ke Level 6. Satu agent FAQ yang hanya membaca dokumen publik mungkin cukup dengan RAG. Level 6 baru masuk akal ketika biaya koordinasi, audit, handoff, dan konflik lebih besar daripada biaya operasional lapisan memory itu sendiri.

Level 5 dan Level 6: kernel berpikir versus lapisan bekerja bersama

Catatan keputusan arsitektur resmi membedakan kernel Level 5 dari produk kolaboratif Level 6.

Loop Level 5 dapat diringkas sebagai:

observe → derive claims → compile context → act → feedback

Satu actor berwenang mengumpulkan bukti, menarik kesimpulan, menerima paket konteks yang terbatas, bertindak, lalu memberi outcome feedback. Level ini sudah berguna untuk satu agent karena memory tetap perlu provenance, masa berlaku, dan koreksi.

Loop Level 6 menambahkan:

identify → share → coordinate → hand off → govern → exchange

Kini pertanyaannya bukan hanya "apa yang perlu diketahui?" tetapi juga "siapa boleh melihat?", "siapa memegang pekerjaan?", "state mana yang harus dilanjutkan?", dan "snapshot mana yang boleh dirilis ke channel eksternal?".

Checkpoint berada di kernel karena satu agent pun perlu melanjutkan state setelah proses berhenti. Nilai kolaboratif muncul ketika checkpoint dirujuk dalam handoff ke actor lain. Titen sendiri bukan scheduler. Pemilihan agent, strategi retry, model loop, dan urutan workflow tetap tanggung jawab caller atau orchestrator.

Tiga objek inti: observation, claim, dan context

Arsitektur ini paling mudah dipahami lewat satu contoh. Seorang pelanggan menulis, "Mulai Agustus, invoice kirim ke [email protected], jangan lagi ke alamat lama."

Observation: apa yang terjadi?

Observation menurut Titen adalah evidence append-only dan memiliki content hash. Rekaman dapat membawa jenis sumber, trust, visibility, subject, project, agent, run, waktu kejadian, dan waktu ingestion.

Pernyataan pelanggan tadi dapat disimpan sebagai observation berjenis user_statement. Isi asli tidak ditimpa jika kemudian ada koreksi. Sistem menambah observation baru.

Titen memisahkan occurred_at dari ingested_at. Pesan dapat terjadi Senin, tetapi baru masuk sistem Selasa karena antrean integrasi. Perbedaan ini penting untuk penyelidikan insiden dan aturan temporal.

Content hash membuktikan byte yang diterima, bukan bahwa isinya benar. Hash juga bukan deduplication key. Dua pesan dengan teks identik dapat mewakili dua kejadian berbeda.

Claim: apa yang disimpulkan dari evidence?

Claim dapat menyatakan: "Alamat penerima invoice pelanggan adalah [email protected], berlaku mulai 1 Agustus." Claim tersebut wajib merujuk setidaknya satu observation melalui relasi supports. Sumber lain dapat contradicts atau qualifies.

Jenis claim resmi mencakup semantic fact, episodic event, preference, procedural, decision, dan relationship. Trust claim tidak boleh melebihi supporting evidence. Visibility claim juga tidak boleh lebih luas daripada sumber yang paling sempit.

Bila staf finance kemudian memberi evidence bahwa perubahan ditunda sampai September, Titen tidak harus memaksa konsensus palsu. Claim dapat berstatus disputed sampai actor berwenang menyelesaikannya.

Saat ini, proses consolidation Titen dinyatakan deterministik dan mengembalikan model_used: false. Ekstraksi claim berbasis model masih direncanakan. Artinya, implementasi sekarang tidak boleh dipasarkan seolah otomatis memahami dan memvalidasi seluruh fakta organisasi. Caller masih berperan besar dalam authoring claim.

Context: apa yang benar-benar dilihat agent?

Context bukan salinan seluruh memory. Ia adalah rekaman paket yang dikompilasi untuk task tertentu. Dokumentasi compile menyebut context run dapat mencatat task, scope, batas token, token terpakai, claim yang dipilih, evidence ID, skor, konflik, policy snapshot, dan kemampuan yang sedang menurun.

Inilah bagian yang membuat audit lebih berguna. Setelah agent salah mengirim invoice, perusahaan dapat bertanya bukan hanya "apa yang ada di database saat ini?", melainkan "informasi apa yang tersedia bagi agent saat keputusan dibuat?". Dua pertanyaan itu sering menghasilkan jawaban berbeda.

Provenance, lifecycle, dan konflik

Provenance adalah rantai asal. Claim menunjuk evidence yang mendukung, menyanggah, atau memberi kualifikasi. Ketika claim sudah tidak berlaku, evidence lama tetap dipertahankan. Perubahannya dilakukan pada lifecycle claim: aktif, disputed, superseded, revoked, atau expired.

Contoh sederhana:

• Observation A: kontrak awal menyebut jatuh tempo 30 hari.
• Claim A: termin pembayaran pelanggan adalah 30 hari.
• Observation B: addendum baru mengubahnya menjadi 14 hari mulai 1 September.
• Claim B: termin menjadi 14 hari sejak tanggal berlaku.
• Claim A: superseded, bukan dihapus seolah tidak pernah ada.

Model ini memungkinkan pertanyaan, "Mengapa agent menyarankan 30 hari pada bulan Agustus?" tanpa menganggap jawaban Agustus harus sama dengan jawaban Oktober.

Titen membedakan trust dan confidence. Trust berasal dari otoritas evidence atau credential. Confidence adalah keyakinan author atas claim. Agent yang sangat percaya diri tidak otomatis membuat sumbernya lebih berwenang.

Ada pula batas informasi saat evidence tersembunyi. Dokumentasi menyatakan hidden evidence dapat ditampilkan sebagai jumlah, bukan isi, sementara record lintas organisasi tidak mengungkap jumlah. Ini mencegah detail privat bocor hanya karena claim punya sumber tersembunyi.

Namun provenance bukan mesin kebenaran. Jika sumber resmi memasukkan angka yang salah, Titen dapat mencatat dengan akurat bahwa angka salah itu berasal dari sumber resmi. Organisasi tetap membutuhkan validasi sumber, review manusia, dan kewenangan jelas untuk revoke atau supersede.

Context compilation: scope dulu, ranking kemudian

Compiler Titen mengikuti jalur:

scope → candidates → hydrate → rank → pack

Urutannya punya dampak keamanan. Organization, subject, project, status lifecycle, masa berlaku, trust, dan visibility diterapkan saat candidate query, sebelum ranking. Item yang tidak boleh dilihat tidak seharusnya ikut menghitung candidate atau menormalkan skor.

Bobot yang didokumentasikan saat ini adalah:

Komponen	Bobot	Fungsi
Relevance	0,45	Kecocokan lexical atau semantic terhadap task
Trust	0,20	Otoritas evidence
Recency	0,15	Peluruhan usia; dokumentasi memakai half-life 90 hari
Utility	0,10	Riwayat usefulness dari feedback
Conflict	0,10	Nilai positif untuk disputed claim agar konflik tidak tersembunyi

Final score dikalikan confidence claim. Konflik diberi komponen positif, keputusan yang cukup masuk akal: agent sebaiknya melihat adanya sengketa daripada menerima ringkasan yang tampak rapi tetapi menyesatkan.

Tetap saja, bobot itu kebijakan produk, bukan hukum universal. Dokumen compliance berusia dua tahun mungkin lebih penting daripada percakapan kemarin. Greedy packing juga dapat melewatkan kombinasi beberapa item kecil yang bersama-sama lebih berguna. Perusahaan perlu eval set sendiri.

Hard token budget

Compiler memakai batas 128 sampai 32.000 token menurut dokumentasi. Item dipak berdasarkan ranking. Claim yang tidak muat dilewati utuh, bukan dipotong menjadi fragmen yang tampak lengkap. Estimasi token dibuat deterministik dan konservatif, dengan ruang cadangan envelope serta batas maksimal tiga item per claim kind.

Empty pack adalah hasil valid. Integrasi yang sehat harus mampu berkata, "Tidak ada evidence yang cukup," lalu meminta klarifikasi atau mengambil data dari sistem sumber. Empty context tidak boleh menjadi izin untuk mengarang.

Untuk perusahaan Indonesia, pengujian perlu mencakup singkatan internal, typo WhatsApp, campuran bahasa Indonesia-Inggris, istilah pajak, nama cabang, dan istilah industri. Belum ada bukti primer bahwa Titen memiliki benchmark khusus bahasa Indonesia.

Feedback tidak boleh menulis ulang fakta

Outcome yang didukung adalah used, useful, irrelevant, incorrect, dan harmful. Feedback yang menunjuk claim memengaruhi utility claim. Feedback level run tanpa claim ID hanya direkam. Di bawah tiga sinyal, utility tetap netral 0,5; setelah itu dihitung dari hasil positif dan negatif. Bobot utility hanya 0,10.

Dokumentasi feedback memasang batas yang sehat: feedback tidak mengubah observation, tidak menaikkan trust, dan tidak mengubah pendapat populer menjadi fakta. Label incorrect atau harmful juga bukan perintah revoke. Revocation membutuhkan tindakan terpisah oleh actor berwenang.

Risikonya tetap ada. Agent bisa menilai outputnya sendiri secara bias. Actor jahat dapat mencoba meracuni utility. Karena itu gunakan credential per agent, idempotency, monitoring pola feedback, serta antrean review untuk cluster incorrect dan harmful.

Identity, visibility, dan batas yang benar-benar berlaku

Titen membedakan beberapa identitas yang sering tercampur dalam aplikasi agent:

• actor: principal dari credential yang melakukan operasi;
• subject: orang, akun, proyek, atau entitas yang dibahas memory;
• observer: perspektif yang direpresentasikan sebuah claim;
• agent: identitas software;
• service: otomasi non-agent;
• organization: batas tenant.

Ada enam dimensi scope: organization, workspace, project, subject, agent, dan run. actor_id berasal dari credential. Label agent_id atau run_id yang dikirim caller tidak memberi kewenangan baru.

Visibility meliputi private, team, dan organization. Tetapi ada batas implementasi saat ini yang tidak boleh disembunyikan. Menurut dokumentasi identity Titen, workspace dan membership sudah tersimpan serta dapat diaudit, tetapi workspace_id belum menjadi retrieval predicate. Akibatnya, team dan organization saat ini berperilaku sama di dalam satu organization.

Jangan menjanjikan isolasi workspace yang belum enforced. Untuk data sensitif, pertimbangkan organization atau deployment terpisah, atau visibility private sesuai threat model. Berikan satu credential untuk satu agent. Jika beberapa proses berbagi credential, private boundary mengikuti principal tersebut, bukan mesin atau proses fisiknya.

Checkpoint, lease, dan handoff

Tiga primitive ini menjawab tiga masalah berbeda.

Checkpoint: sudah sampai mana?

Checkpoint menyimpan execution state, bukan evidence. Contohnya: halaman kontrak terakhir yang sudah diperiksa, daftar item tersisa, atau draft ID yang sedang dikerjakan. Ia di-upsert berdasarkan organisasi, subject, agent, dan kind; punya TTL 60 detik sampai 30 hari; serta batas state 64.000 byte serialized.

Checkpoint tidak dapat menjadi source claim. Pemisahan ini mencegah state sementara dianggap fakta. Saat ini include_checkpoints pada compile melaporkan checkpoint tidak tersedia, sehingga caller harus mengambilnya terpisah. Compare-and-swap checkpoint juga belum tersedia; concurrent write masih last-write-wins.

Lease: siapa memegang resource sekarang?

Lease memberi ownership advisory untuk resource selama 10 sampai 86.400 detik. Collision menghasilkan HTTP 409. Ini membantu mengurangi dua agent memproses invoice atau deployment yang sama.

Namun lease bukan fencing lock. Ia tidak memblokir write, tidak memiliki route renew, dan agent yang mengabaikannya tetap dapat bertindak. API tindakan destruktif harus mempunyai idempotency key, version check, atau fencing token sendiri. Jangan menyerahkan keselamatan transaksi hanya kepada lease.

Handoff: siapa melanjutkan?

Handoff menyebut target principal, subject, pesan, dan secara opsional context atau checkpoint. Penerima harus accept atau reject. Handoff yang sudah resolved tidak dapat dibalik hanya dengan retry.

Alur yang sehat untuk proposal penjualan bisa seperti ini:

1. Agent riset mengumpulkan evidence dan menulis checkpoint.
2. Ia membuat handoff kepada agent proposal dengan context yang relevan.
3. Agent proposal menerima handoff, memperoleh lease atas draft, lalu bekerja.
4. Reviewer menerima handoff berikutnya dan memeriksa claim terhadap evidence.
5. Manusia menyetujui pengiriman final.

Events atau webhook dapat mendorong notifikasi, tetapi orchestrator tetap mengatur siapa bangun dan kapan retry dilakukan. Rincian resmi tersedia di checkpoints dan leases serta handoffs.

Channel releases: benar belum tentu boleh dipublikasikan

Titen memisahkan tiga sumbu:

Sumbu	Pertanyaan
Trust	Seberapa berwenang evidence ini?
Visibility	Siapa di dalam organisasi yang boleh mengambilnya?
Release	Bolehkah snapshot ini disajikan ke audience tertentu?

Channel releases memakai alur draft, explicit publish, active, lalu optional revoke. Hanya claim aktif dengan trust verified atau policy_approved yang eligible. Disputed claim gagal dirilis. Publish, revoke, dan channel read dicatat dalam audit.

Pola yang disarankan adalah gateway CRM atau chatbot memakai service credential terbatas untuk mengakses channel context. Pelanggan eksternal tidak menerima credential canonical memory.

Kemampuan ini sudah ada, tetapi belum lengkap. Channel pack belum melakukan task relevance ranking; task baru di-echo. Kolom redacted/localized ada, tetapi belum tersedia route untuk mengisinya. Signed customer assertion dan exact claim-version pinning belum dikirim. Policy dapat disimpan, tetapi belum ditegakkan secara luas di semua jalur.

Federation: pertukaran event, bukan satu otak global

Istilah federation mudah menimbulkan harapan berlebihan. Federation Titen yang tersedia saat ini bertukar metadata event log yang ditandatangani dan difilter. Ia tidak otomatis menyinkronkan isi observation dan claim menjadi canonical shared memory antardeployment.

Terdapat route untuk peer, filter, pull, push, suspend, dan log. HMAC signature memverifikasi batch dari peer, sementara API key tetap diperlukan. Duplicate event ID menghasilkan conflict, bukan overwrite. Titen tidak mengklaim memakai CRDT, last-write-wins global, atau konsensus global.

Canonical recallable-memory federation masih direncanakan. Destination ingestion, authorization, indexing, lifecycle, dan recall semantics belum selesai. Ada pula gap replay protection: signature belum memiliki nonce atau timestamp window penuh. Karena itu federation layak dipertimbangkan hanya jika ada boundary nyata seperti data residency, kepemilikan terpisah, atau isolasi jaringan. Jika semua tim dapat memakai satu deployment, itu biasanya lebih sederhana.

Vector search: indeks yang bisa dibangun ulang, bukan hakim kebenaran

Semantic retrieval pada runtime Bun/SQLite saat ini memakai sqlite-vec dan endpoint embedding yang kompatibel dengan OpenAI. Vector hit hanya menominasikan claim ID. SQL canonical lalu menerapkan filter organization, subject, project, status, temporal, trust, dan visibility.

Desain ini mencegah satu kesalahan umum: menjadikan hasil nearest-neighbor sebagai fakta. Score embedding menunjukkan kedekatan dalam satu query, bukan confidence atau truth yang terkalibrasi.

Kehilangan vector index tidak menghapus evidence canonical. Namun dokumentasi vectors menyebut full re-index command belum tersedia; claim lama sebelum index loss tidak otomatis seluruhnya di-embed ulang. Perubahan model atau dimensi harus diperlakukan sebagai proyek re-index eksplisit.

Jalur Cloudflare Vectorize dan Workers AI aktif masih direncanakan. Adapter mungkin sudah ada, tetapi jangan menyebut semantic vector Cloudflare sebagai kemampuan production yang sudah terbukti.

Dibanding chat history, RAG, vector DB, dan knowledge base

Tabel ini adalah analisis arsitektur, bukan benchmark vendor.

Pendekatan	Unit utama	Provenance dan lifecycle	Koordinasi agent	Pengemasan token	Catatan
Chat history	Urutan pesan	Biasanya implisit	Tidak ada	Truncation atau ringkasan	Mudah dimulai, cepat penuh, actor dan fakta sering kabur
Basic RAG	Potongan dokumen	Link sumber bisa ada; lifecycle claim biasanya tidak eksplisit	Tidak ada	Top-k chunks	Bagus untuk pencarian dokumen, tidak otomatis menangani konflik atau handoff
Vector database	Embedding dan metadata	Bergantung implementasi	Tidak native	Nearest-neighbor	Cepat untuk similarity; authorization, revocation, dan truth harus dibangun sendiri
Shared knowledge base	Artikel atau record terkurasi	Versioning bervariasi	Kolaborasi manusia kuat	Butuh retrieval layer	Baik untuk pengetahuan resmi, lemah untuk execution state agent
Titen	Observation, claim, context, coordination state	Eksplisit, temporal, tersitasi	Identity, checkpoint, lease, handoff, audit	Scope-rank-pack dengan hard budget	Lebih tertib, tetapi integrasi dan governance lebih berat; produk masih dini

Pilihan ini tidak selalu saling menggantikan. Titen dapat berada di atas knowledge base dan data dari CRM, memakai vector index untuk retrieval, lalu memberikan context kepada agent framework. Pertanyaannya bukan "mana satu alat terbaik?", tetapi "lapisan mana menjadi sumber data, indeks, memory, dan orchestrator?".

Use case untuk perusahaan Indonesia

Berikut rekomendasi penerapan berdasarkan kontrak arsitektur, bukan klaim bahwa perusahaan tertentu sudah mendapatkan ROI dari Titen.

Customer service multi-agent

Agent klasifikasi, agent pencari kebijakan, dan agent penyusun jawaban dapat berbagi evidence tanpa merilis claim disputed. Channel release membantu memisahkan pengetahuan internal dari jawaban eksternal. Status pesanan dan pembayaran tetap diambil real-time dari owner API.

Sales, account management, dan customer success

Observation menyimpan hasil meeting dan tool. Claim memisahkan preferensi, keputusan, serta fakta akun. Checkpoint merekam posisi penyusunan proposal. Handoff dari SDR ke account executive lalu customer success menjadi eksplisit. Ini mendukung pola setiap staf punya satu AI agent tanpa membuat semua agent membaca semua data.

Operasi cabang dan waralaba

SOP lama dapat disupersede saat aturan pusat berubah. Perbedaan laporan cabang tidak dipaksa menjadi satu ringkasan. Namun karena workspace narrowing belum enforced, desain tenant perlu konservatif. Cabang dengan data sensitif mungkin membutuhkan organisasi atau deployment terpisah.

IT operations dan DevOps

Hasil tool menjadi observation. Kebijakan deployment menjadi procedural claim. Lease mengurangi kemungkinan dua agent mengeksekusi perubahan yang sama, sedangkan handoff memindahkan investigasi ke on-call berikutnya. Tetap pasang approval manusia, idempotency, dan fencing di deployment API.

Procurement dan compliance

Tim dapat menelusuri evidence keputusan pemasok, tanggal berlaku, serta approval trail. Append-only pada aplikasi tidak otomatis setara arsip WORM atau memenuhi regulasi. Legal dan security assessment masih diperlukan.

Continuity ketika staf berganti

Alasan keputusan tidak hilang di grup chat. Agent baru menerima context yang terbatas dan relevan, bukan seluruh riwayat pegawai lama. Data pekerja dan pelanggan tetap harus mengikuti pemetaan retensi, penghapusan, serta hak akses menurut kebutuhan UU PDP dan kebijakan internal.

Tim riset dan konten

Researcher menyimpan sumber sebagai observation, writer membentuk claim, reviewer menandai konflik, dan publisher hanya memakai channel release yang disetujui. Draft opinion tidak tercampur dengan verified fact. Checkpoint menjaga state produksi ketika tugas melewati beberapa hari.

Keterbatasan dan risiko yang harus masuk keputusan

Titen masih produk tahap awal; dokumentasi mencantumkan package titen-memory v0.1.1. Banyak kontrak sudah diimplementasikan dan diuji lokal pada Bun/SQLite serta workerd/D1. Recorded live verification yang paling jelas berlaku pada containerized Bun service. Roadmap canonical masih menempatkan real provisioned Cloudflare deployment dan beberapa kemampuan enterprise sebagai pekerjaan berikutnya.

Risiko utama:

• Provenance bukan truth. Sumber yang salah tetap menghasilkan riwayat asal yang rapi.
• Prompt injection tetap mungkin. Caller dapat mengabaikan warning dan menjalankan teks dari memory.
• Policy belum enforced menyeluruh. Menyimpan baris policy berbeda dengan memastikan semua route tunduk padanya.
• Visibility team belum sempit. Saat ini ia praktis setara organization dalam tenant.
• Checkpoint dapat tertimpa. Belum ada compare-and-swap; concurrent write last-write-wins.
• Lease advisory. Ia tidak menghentikan actor yang tidak patuh.
• Feedback dapat diracuni. Bobot kecil dan threshold membantu, tetapi tidak menghapus bias.
• Vector recovery belum lengkap. Full rebuild command belum dikirim.
• Federation belum canonical memory. Ada gap replay dan threat-model review.
• Self-hosting punya biaya tersembunyi. Backup, patch, TLS, monitoring, restore drill, dan incident response tetap harus dikerjakan.
• Append-only membawa kewajiban privasi. Retention dan deletion workflow harus dirancang, terutama untuk PII.

Jangan menyimpan credential, token, NIK, data kesehatan, payroll, atau rahasia pelanggan ke embedding provider eksternal tanpa dasar, kontrak, dan kontrol yang tepat. Lakukan data inventory, pemetaan tujuan pemrosesan, residency review, serta evaluasi subprocessor. Ini rekomendasi operasional, bukan nasihat hukum.

Self-host Bun/SQLite atau managed edge?

Titen bersifat open-source dan self-hostable. Sumber primer tidak menunjukkan managed Titen SaaS resmi. "Managed edge" di sini berarti menjalankan komponen pada infrastruktur seperti Cloudflare atau melalui integrator, bukan membeli SaaS resmi Titen.

Pertimbangan	Self-host Bun + SQLite	Managed edge/infrastruktur vendor
Kontrol data	Tinggi; dapat ditempatkan di VPS atau lingkungan privat	Tergantung region, kontrak, dan subprocessor
Beban operasi	Tim menanggung backup, patch, TLS, HA, monitoring	Sebagian beban infrastruktur dipindahkan
Bukti kematangan saat ini	Jalur dengan recorded live verification	Real Cloudflare production path masih planned di roadmap
Semantic retrieval	sqlite-vec live dengan endpoint embedding eksternal	Vectorize/Workers AI active path belum dinyatakan shipped
Portabilitas	Export canonical dan Apache-2.0 membantu	Service platform dapat menambah lock-in
Skalabilitas	Perlu load, concurrency, dan HA test sendiri	Platform edge membantu infra, bukan bukti aplikasi siap produksi

Untuk pilot perusahaan Indonesia, pilihan konservatif adalah Bun + SQLite pada lingkungan terisolasi. Mulai tanpa vector jika FTS cukup. Tambahkan embedding setelah klasifikasi data dan benchmark membuktikan manfaat. Cloudflare layak dievaluasi setelah deployment nyata, region, biaya, limit D1, Vectorize, serta recovery diuji sendiri.

Jika memakai integrator, minta version pinning, SBOM, export dan restore test, hasil tenant-isolation test, RPO/RTO, syarat pemrosesan data, no-training clause untuk evidence, serta exit plan.

Roadmap implementasi 30/60/90 hari

Roadmap berikut adalah rekomendasi independen, bukan roadmap resmi Titen.

Hari 1-30: buktikan Level 5 pada satu proses

Pilih satu workflow yang sering macet tetapi dapat dibalik, misalnya riset proposal internal atau triase dokumen SOP. Jangan mulai dari pembayaran, payroll, atau tindakan produksi.

Tentukan systems of record. Buat aturan bahwa Titen menjadi memory/context plane, bukan sumber transaksi. Petakan actor, subject, project, visibility, trust ceiling, masa retensi, dan jenis data yang dilarang.

Jalankan Bun + SQLite secara terisolasi. Integrasikan alur observe, claim deterministik, compile, feedback, dan trace. Mulai FTS-only. Siapkan set evaluasi bahasa Indonesia yang memuat fakta kedaluwarsa, konflik, singkatan, typo, empty result, serta percobaan prompt injection.

Gate hari ke-30:

• setiap claim kritis dapat ditelusuri ke evidence;
• context tidak membocorkan record di luar scope;
• empty pack ditangani tanpa halusinasi;
• block memory dipisahkan dari system instruction;
• tim bisa menjelaskan mengapa suatu claim dipilih.

Hari 31-60: rapikan lifecycle dan hardening

Buat SOP supersede, revoke, dan expire. Terapkan credential per agent dengan least privilege. Lakukan backup, restore drill, export validation, dan rotasi credential.

Bangun monitoring untuk degraded capability, conflict rate, feedback anomaly, token usage, dan unauthorized attempts. Review bobot ranking terhadap eval set; jangan mengubahnya hanya berdasarkan intuisi.

Jika semantic retrieval diperlukan, uji model multilingual terhadap FTS baseline. Ukur critical-evidence recall dan false positive, bukan hanya impresi demo. Dokumentasikan prosedur jika vector index hilang atau dimensi model berubah.

Gate hari ke-60:

• restore berhasil dalam target waktu;
• lifecycle change memiliki owner dan audit;
• harmful/incorrect feedback masuk review queue;
• tidak ada shared credential antar-agent;
• evaluasi menunjukkan retrieval membantu tanpa menurunkan kontrol akses.

Hari 61-90: tambahkan kolaborasi secara terbatas

Pilih dua atau tiga peran, misalnya researcher, writer, dan reviewer. Gunakan checkpoint untuk execution state, bukan evidence. Tambahkan lease sebagai sinyal ownership, lalu lindungi API tindakan dengan idempotency atau fencing sendiri.

Gunakan handoff yang harus diterima target. Tempatkan human approval sebelum pengiriman eksternal atau tindakan irreversible. Jangan bergantung pada isolasi workspace yang belum enforced.

Jika ada channel eksternal, buat gateway service dengan credential terbatas. Release harus eksplisit dan diaudit. Data transaksi tetap diambil langsung. Federation belum perlu disentuh kecuali ada boundary data yang nyata.

Gate hari ke-90:

• duplicate work berkurang dan dapat diukur;
• handoff gagal dapat dipulihkan tanpa kehilangan evidence;
• reviewer melihat konflik, bukan ringkasan palsu;
• tindakan berisiko tetap memerlukan kontrol pada owner API;
• security, legal, dan operasi menyetujui keputusan lanjut, tunda, atau hentikan.

Checklist keputusan sebelum mengadopsi

Jawab pertanyaan berikut secara tertulis:

1. Apakah masalah utama kami retrieval dokumen atau koordinasi banyak agent?
2. Adakah kebutuhan audit tentang informasi yang dilihat agent saat bertindak?
3. Mana system of record untuk pelanggan, stok, pembayaran, dan approval?
4. Siapa actor, subject, observer, agent, dan service dalam workflow?
5. Data apa yang sama sekali dilarang masuk memory atau embedding?
6. Apakah boundary organization cukup, mengingat workspace narrowing belum enforced?
7. Siapa boleh membuat, supersede, revoke, dan merilis claim?
8. Bagaimana disputed claim ditangani sebelum tindakan eksternal?
9. Apa respons aman jika compiler menghasilkan empty pack?
10. Apakah caller memperlakukan memory sebagai untrusted reference?
11. Adakah idempotency dan fencing di API yang mengubah sistem nyata?
12. Bagaimana backup, restore, export, retention, dan deletion diuji?
13. Apakah FTS sudah cukup sebelum menambah vector dan provider embedding?
14. Apa metrik evaluasi bahasa Indonesia untuk relevance, leakage, dan stale memory?
15. Apakah federation benar-benar dibutuhkan, atau satu deployment lebih sederhana?
16. Siapa on-call ketika memory, vector index, atau webhook gagal?
17. Apa kriteria menghentikan pilot jika risiko lebih besar daripada manfaat?

Jika sebagian besar jawaban belum ada, masalahnya bukan kekurangan fitur Titen. Organisasi belum siap menjalankan shared memory sebagai infrastruktur.

Dari pilot ke sistem perusahaan: kapan perlu pelatihan, kapan perlu instalasi?

Teknologi memory tidak memperbaiki proses yang belum punya owner, batas data, dan aturan approval. Jika tim Anda masih menentukan peran agent, SOP handoff, use case prioritas, serta cara staf dan AI bekerja bersama, mulai dari Pelatihan AI untuk Perusahaan. Fokusnya adalah kesiapan tim, pemilihan workflow, governance, dan kemampuan operasional manusia. Ini cocok ketika pertanyaan utamanya masih "proses mana yang aman dan bernilai untuk diautomasi?".

Jika use case sudah jelas dan kebutuhan Anda lebih teknis, misalnya menyiapkan runtime agent privat, integrasi tool, credential, deployment, observability, dan kontrol akses, lihat Jasa Install OpenClaw. Ini lebih tepat ketika pertanyaannya sudah berubah menjadi "bagaimana sistem dijalankan dengan tertib di infrastruktur kami?".

Keduanya tidak harus dibeli bersamaan. Tim yang sudah matang secara proses mungkin hanya membutuhkan implementasi. Tim yang masih bereksperimen biasanya lebih aman menyelesaikan desain operasi dulu, baru memasang sistem.

Kesimpulan

Gagasan utama Titen cukup tajam: memori agent perusahaan sebaiknya tidak berbentuk satu gudang chat yang terus membesar. Evidence, claim, compiled context, dan state koordinasi perlu dipisahkan. Dengan pemisahan itu, organisasi bisa melacak asal kesimpulan, mempertahankan konflik, membatasi apa yang dilihat agent, dan menyerahkan pekerjaan tanpa menyamakan checkpoint dengan fakta.

Dalam taksonomi Titen, Level 5 membangun evidence loop untuk context yang terbatas dan dapat diaudit. Level 6 menambahkan identity, visibility, coordination, governance, channel release, dan federation opsional. Nama "Level 6" adalah milik Titen, bukan cap kematangan industri.

Arsitekturnya menjanjikan disiplin yang sering hilang dalam proyek multi-agent. Implementasinya tetap perlu dibaca konservatif. Bun/SQLite adalah jalur paling terbukti saat ini. Workspace isolation, policy enforcement luas, beberapa semantik channel, production Cloudflare vectors, dashboard operasional penuh, dan canonical memory federation masih parsial atau direncanakan.

Mulailah dari satu proses, satu ledger evidence, dan satu eval set yang jujur. Buktikan Level 5 sebelum menambah banyak agent. Tambahkan handoff dan governance setelah boundary akses benar. Jangan memulai dari federation, dan jangan pernah menganggap similarity sebagai truth atau retrieved memory sebagai instruksi. Dengan urutan itu, shared memory dapat menjadi alat continuity dan accountability, bukan sekadar prompt yang lebih panjang.