Perusahaan sering memulai proyek second brain dari pertanyaan yang salah: vector database mana yang paling canggih? Enam minggu kemudian ingestion sudah jalan, tetapi agent tidak bisa melanjutkan task, izin akses kacau, dan tidak ada yang tahu dokumen mana yang memicu sebuah action. Storage terpasang. Sistem kerja belum ada.
Fondasi: definisi kerja yang tidak kabur
Arsitektur agentic second brain adalah susunan komponen yang mengubah data menjadi konteks terpilih, menjaga posisi workflow, lalu memungkinkan agent memakai tools dalam batas policy. Komponen intinya mencakup connector, state store, memory store, retrieval, context builder, agent loop, tools, policy, approval, dan audit.
Dari sisi arsitektur, definisi kerja penting karena menentukan ekspektasi. stack yang salah kategori akan diberi tanggung jawab yang salah. Mesin pencari diberi izin menulis ke CRM. Ringkasan chat dianggap state. Preferensi sementara diangkat menjadi policy permanen. Pada skala operasi, kekeliruan kecil ini menumpuk menjadi biaya dan risiko.
Komponen yang perlu dibedakan
Capture dan connector
Menghubungkan file, email, CRM, database, browser, dan workflow. MCP dapat menstandarkan koneksi, tetapi tidak otomatis menyelesaikan kualitas memory atau hak akses.
State dan memory store
Checkpoint menyimpan posisi task. Memory store menyimpan informasi lintas waktu. Keduanya jangan disatukan menjadi histori chat besar.
Retrieval dan context builder
Retriever mencari kandidat; ranker menilai scope, recency, authority, dan confidence. Context builder memasukkan paket terkecil yang cukup untuk tugas.
Agent, tools, dan governance
Agent menjalankan loop observe-decide-act. Policy membatasi akses, approval menahan action sensitif, dan audit merekam read, write, tool call, serta perubahan.
Contoh bisnis: dari demo ke operasi
Bayangkan workflow account management. Email masuk lewat connector dan membuat task. State menyimpan bahwa brief sudah diekstrak dan deadline belum dikonfirmasi. Retriever mengambil profil klien serta keputusan campaign terakhir. Context builder hanya memasukkan data relevan. Agent membuat draft timeline lewat tool proyek. Karena perubahan deadline berdampak eksternal, policy meminta approval account lead. Setelah disetujui, action dijalankan, hasil diverifikasi, lalu keputusan final dikonsolidasikan ke memory.
Dari sisi arsitektur, perhatikan bahwa nilai operasi tidak datang dari jawaban yang terdengar pintar. Nilainya datang dari berkurangnya pekerjaan ulang, handoff yang lebih cepat, keputusan yang dapat ditelusuri, dan eksekusi yang tidak melampaui izin. Kalau metrik ini tidak berubah, proyek mungkin hanya menambah lapisan antarmuka.
Kontrak antarlapisan lebih penting daripada banyaknya komponen
Connector seharusnya menghasilkan event dengan identitas sumber, tenant, waktu, dan klasifikasi, bukan teks polos. Memory writer hanya mempromosikan event yang lolos aturan. Context builder menerima kebutuhan langkah saat ini lalu mengambil potongan yang punya scope dan authority tepat. Agent menghasilkan rencana; policy engine memutuskan tool mana yang tersedia. Setelah tool berjalan, verifier membaca hasil aktual dan state store membuat checkpoint.
Ambil contoh perubahan budget iklan. Agent membaca permintaan account manager, mengambil kontrak serta batas spend, lalu menyusun perubahan. Policy melihat kenaikan 30% dan meminta approval. Setelah disetujui, tool mengubah platform iklan. Verifier membaca kembali budget dari API; baru setelah cocok state ditandai selesai. Jika API timeout, statusnya "hasil belum diketahui", bukan otomatis gagal lalu mencoba ulang. Retry buta dapat menggandakan action.
Batas keamanan harus ikut mengalir. Tenant filter diterapkan sebelum retrieval. Kredensial tool dibatasi per operasi. Data dari email atau web diperlakukan sebagai data tidak tepercaya, bukan instruksi yang boleh mengubah policy. Audit event menyimpan siapa meminta, konteks yang dipakai, keputusan policy, approval, panggilan tool, dan hasilnya.
Fakta, interpretasi, dan klaim yang harus diuji
Dari sisi arsitektur, Fakta: request model pada umumnya tidak memperoleh kontinuitas lintas sesi tanpa state yang diteruskan atau disimpan oleh aplikasi. Context window juga memiliki batas, dan informasi yang dimasukkan memakai kapasitas perhatian. Dokumentasi OpenAI tentang conversation state dan panduan Anthropic tentang context engineering menjelaskan konsekuensi desain ini.
Dari sisi arsitektur, Fakta: framework orchestrator modern memisahkan short-term dari long-term memory operasional. Literatur CoALA juga menawarkan pembagian working, episodic, semantic, dan procedural untuk memahami fungsi memory operasional. Pembagian tersebut adalah model konseptual, bukan kewajiban memakai vendor atau database tertentu.
Dari sisi arsitektur, Interpretasi operasional kami: operasi sebaiknya menilai second brain dari kemampuan melanjutkan pekerjaan, ketepatan scope, koreksi memory operasional, dan kontrol eksekusi. Ini rekomendasi desain, bukan hukum ilmiah. Stack yang tepat tetap bergantung pada risiko, volume, latensi, serta pola query.
Kesalahan implementasi yang mahal
Dari sisi arsitektur, pertama, menyimpan semua chat. Histori mentah mengandung pengulangan, asumsi, dan keputusan yang sudah berubah. Retrieval kemudian menemukan kalimat yang mirip, bukan yang paling berwenang. Simpan event mentah untuk audit bila memang perlu, tetapi promosikan hanya informasi terpilih menjadi memory operasional.
Dari sisi arsitektur, kedua, menjadikan similarity sebagai hakim tunggal. Dua data sumber dapat sangat mirip tetapi berasal dari klien, negara, versi, atau periode berbeda. Filter tenant, hak akses, jenis data sumber, tanggal berlaku, dan authority harus berjalan sebelum atau bersama ranking semantik.
Dari sisi arsitektur, ketiga, membiarkan memory operasional menjadi izin. orchestrator yang tahu nomor rekening tidak otomatis boleh melakukan transfer. orchestrator yang membaca kalender tidak otomatis boleh mengundang pihak luar. Pengetahuan dan authority adalah dua hal terpisah.
Dari sisi arsitektur, keempat, tidak menyediakan jejak keputusan. Tim perlu melihat input, memory operasional yang diambil, versi policy, tool call, approval, dan hasil verifikasi. Tanpa itu, debugging berubah menjadi tebak-tebakan.
Checklist implementasi 30 hari
Dari sisi arsitektur, pada minggu pertama, pilih satu proses dengan histori panjang dan biaya lupa yang nyata. Petakan aktor, sumber data, keputusan, artifact, serta eksekusi eksternal. Tulis definisi selesai dan daftar risiko. Hindari scope "seluruh perusahaan".
Dari sisi arsitektur, minggu kedua, buat schema minimum. Setiap memory operasional setidaknya memiliki owner, scope, tipe, sumber, waktu dibuat, waktu berlaku, confidence, dan status. State workflow memiliki ID, langkah aktif, artifact, blocker, retry, serta approval pending.
Dari sisi arsitektur, minggu ketiga, pasang retrieval dan guardrail. Terapkan namespace, access control, metadata filtering, serta ranking. Batasi tool ke operasi read atau draft. Untuk write eksternal, destructive, finansial, dan sensitif, gunakan approval eksplisit.
Dari sisi arsitektur, minggu keempat, jalankan kasus nyata dan kasus jebakan. Masukkan data sumber lama, dua klien dengan istilah serupa, fakta yang dikoreksi, workflow yang terputus, dan input yang mencoba mengubah policy. Ukur bukan hanya kualitas jawaban, tetapi juga apakah orchestrator berhenti ketika ragu.
Pertanyaan audit untuk tim
- Informasi apa yang dipakai agent, dan dari sumber mana?
- Apakah scope user, organisasi, dan klien diterapkan sebelum retrieval?
- Bagaimana fakta lama diganti, dikoreksi, atau dihapus?
- Bisakah task dilanjutkan tanpa mengulang action yang sudah sukses?
- Action mana yang otomatis, mana yang wajib approval?
- Apakah hasil tool diverifikasi dari environment?
- Siapa yang dapat membaca audit log dan mengubah policy?
Dari sisi arsitektur, jawaban "belum tahu" bukan bencana. Itu tanda bahwa stack belum pantas diberi otonomi lebih luas.
Cara menerapkannya tanpa proyek raksasa
Bangun vertikal tipis terlebih dahulu. Pilih satu workflow, satu tenant, sedikit tools, dan dua atau tiga jenis memory. Definisikan schema state, sumber kebenaran, write gate, izin per tool, serta kondisi berhenti. Tambahkan observability sebelum otonomi. Ukur task completion, retrieval precision, correction rate, approval latency, dan insiden lintas scope; jangan puas dengan skor jawaban demo.
Dari sisi arsitektur, mulai dengan baseline manual. Catat berapa lama orang mencari konteks, berapa workflow yang diulang, berapa koreksi akibat data lama, dan berapa approval terlambat. Setelah orchestrator berjalan, bandingkan angka yang sama. Ukuran seperti jumlah data sumber terindeks atau banyaknya token bukan hasil operasi.
Bangun vertikal tipis, lalu sengaja rusakkan
Arsitektur pertama tidak perlu event bus besar atau lima database khusus. Satu database relasional dapat menyimpan state dan metadata memory; object storage menampung artifact; pencarian teks atau vector ditambahkan sesuai kebutuhan. Yang tidak boleh hilang ialah pemisahan logis, kontrak data, access control, serta audit. Pecah layanan ketika beban atau kepemilikan tim benar-benar menuntutnya.
Setelah jalur normal berjalan, lakukan failure injection. Matikan connector, buat retrieval mengembalikan dokumen kedaluwarsa, cabut izin tool, lewatkan masa approval, dan putuskan proses sesudah action. Sistem yang sehat memberi status jelas serta jalur pemulihan. Sistem rapuh menutupinya dengan jawaban optimistis atau retry tanpa batas.
Tetapkan service level per workflow, bukan untuk "AI" secara umum. Pembuatan draft mungkin toleran terhadap keterlambatan dan wajib review; perubahan budget perlu verifikasi kuat dan jejak lengkap. Ukur completion rate, waktu pemulihan, persentase retrieval dengan sumber valid, false approval, serta action duplikat. Dashboard token dan latensi model tetap berguna untuk biaya, tetapi tidak membuktikan bahwa pekerjaan selesai dengan benar.
Harness dan workflow: jangan cuma modal prompt
Vibe code tidak masalah. Yang bahaya itu kalau seluruh sistem cuma bergantung pada prompt panjang lalu dianggap selesai. Prompt bukan kontrol kualitas. Untuk agentic second brain, tetap perlu harness yang bisa menjalankan kasus uji, merekam input dan output, memeriksa sumber, memvalidasi tool call, serta memastikan action berhenti ketika syaratnya belum terpenuhi.
Workflow-nya juga harus jelas: plan, ambil context, build, test, review, approval bila berdampak, execute, lalu verifikasi hasil nyata. Setiap langkah punya state, acceptance criteria, timeout, dan jalur gagal. AI boleh ngebut. Kontrol kualitas tetap di kita.
Harness minimum tidak perlu mewah. Mulai dari sekumpulan kasus nyata dan jebakan, expected behavior, log retrieval, snapshot state, mock tool untuk action berisiko, serta regression test setiap ada perubahan model, prompt, policy, atau connector. Kalau sistem tidak bisa diuji ulang secara konsisten, itu belum workflow; masih demo.
Kesimpulan praktis
Arsitektur yang baik tidak harus rumit. Relational database, object storage, queue, dan search sering cukup. Kompleksitas baru layak ditambah ketika ada kegagalan terukur. Urutan yang aman adalah continuity dulu, retrieval kedua, action terbatas ketiga, lalu otonomi secara bertahap. Second brain bisnis dinilai dari pekerjaan yang selesai dengan benar, bukan jumlah komponen AI di diagram.
Referensi primer
- Anthropic -- Building Effective AI Agents
- OpenAI API -- Conversation State
- LangGraph -- Memory Overview
- Model Context Protocol -- Introduction
- CoALA -- Cognitive Architectures for Language Agents
Dari sisi arsitektur, ← Artikel sebelumnya · Hub Second Brain · Artikel berikutnya →
Founder Rama Digital. Menulis tentang digital marketing, web development, AI, dan sistem operasional untuk bisnis Indonesia.
Tentang Rama Digital
