Apa Itu Chain of Recall? Cara Stable ID Memberikan Memori pada Agen AI

Chain of Recall adalah cara untuk memberikan memori kepada agen AI yang berjalan lama tanpa harus menjejalkan semuanya ke dalam context window-nya. Setiap Trigger, Thread, dan Worker mendapatkan ID yang stabil. Konteks hanya menyimpan ID, ringkasan singkat, dan pesan-pesan terdekat, lalu agen menelusuri tautan antar-ID untuk mengambil fakta-fakta lama hanya dalam beberapa langkah (hops).

Istilah ini berasal dari esai desain DeepSeek Harness bertajuk “Exploring Super-agent Design” yang dipublikasikan pada 01-11-2026. Satu catatan penting sebelum Anda melangkah lebih jauh: esai tersebut memaparkan sebuah arsitektur, bukan fitur yang sudah dirilis. Sebagian darinya diimplementasikan dalam sebuah plugin purwarupa, dsh-superagent-prototype, yang oleh para penulisnya disebut sebagai “bukan produk resmi DeepSeek”. Tidak ada sakelar untuk mengaktifkan Chain of Recall. Ini adalah pola arsitektur yang perlu Anda bangun sendiri.

Masalah context window pada agen yang berjalan lama

Agen yang berjalan lama (long-running agent) cepat atau lambat akan membentur batas konteksnya karena pekerjaan tidak pernah berhenti berdatangan. Super-agent yang memantau obrolan, GitHub, dan CI melihat ratusan peristiwa setiap hari, dan jendela konteks yang menampung pekerjaan kemarin tidak akan mampu menampung pekerjaan hari ini sekaligus.

Solusi yang biasa digunakan masing-masing memiliki konsekuensi tersendiri:

• Menyimpan semuanya. Jendela konteks lekas penuh dan biaya komputasi melonjak di setiap giliran percakapan.
• Meringkas percakapan lama. Ringkasan kerap menghilangkan detail pesan eror atau nomor PR spesifik yang justru Anda butuhkan nanti.
• Mengambil berdasarkan kemiripan (similarity retrieval). Cara ini efektif sampai fakta yang Anda butuhkan ternyata memiliki redaksi yang sama sekali berbeda dari kueri Anda.

Panduan Anthropic mengenai rekayasa konteks untuk agen AI memandang konteks sebagai sumber daya terbatas yang harus dikurasi. Chain of Recall adalah salah satu cara konkret untuk melakukan kurasi tersebut, dan panduan kami tentang cara kerja memori agen AI mengulas berbagai opsi lain yang lebih luas.

Inline vs spill: memperlakukan konteks layaknya cache

Esai tersebut memperlakukan context window layaknya sebuah cache dengan dua pendekatan:

• Inline apa yang kemungkinan besar dibutuhkan agen saat ini: ID, ringkasan singkat, dan pesan-pesan terdekat.
• Spill sisanya: potong informasinya dan tinggalkan pointer (penunjuk) yang bisa ditelusuri agen nanti.

Item yang di-spill tidak dihapus; melainkan hanya pointernya yang tetap tersimpan di dalam prompt.

Beginilah gambarannya saat sebuah kegagalan CI masuk ke Router. Struktur ini bersifat ilustratif, bukan kode resmi dari DeepSeek:

{
  "trigger_id": "trg_8f21",
  "source": "github.check_run",
  "thread_id": "thr_pr_412",
  "summary": "CI failed on PR #412: 3 of 118 tests red in payments/",
  "neighbours": ["trg_8f1c: review comment asking for retry logic"],
  "spilled": {
    "full_log": "GET /triggers/trg_8f21/payload (41 KB, truncated)"
  }
}

Jika ringkasan satu baris tersebut sudah cukup, agen tidak perlu membayar biaya token untuk log sebesar 41 KB. Jika tidak, agen tinggal mengambil log lengkap berdasarkan ID-nya.

ID yang stabil dan graf referensi

Chain of Recall dapat bekerja karena ID tidak pernah berubah. Dalam rancangan esai tersebut, ada tiga jenis objek yang memilikinya:

Trigger merupakan bagian dari Thread, Thread dimiliki oleh satu atau beberapa Worker, dan laporan Worker mengutip Trigger yang telah ditindaklanjutinya. Tautan-tautan tersebut membentuk graf referensi, dan graf itulah yang menjadi memori agen.

Recall dilakukan dengan menelusuri tautan selangkah demi selangkah (hop by hop), bukan dengan memuat seluruh riwayat atau mencari teks yang mirip. Panduan pendamping kami tentang cara membangun super-agent menjelaskan posisi Trigger, Thread, dan Worker dalam rancangan lengkap Router dan Worker.

Panduan penelusuran multi-hop recall

Katakanlah seorang rekan kerja bertanya kepada Router pada hari Jumat: “Mengapa kita menambahkan logika retry ke klien pembayaran?” Diskusi awalnya terjadi pada hari Selasa dan sudah di-spill sejak lama. Berikut tahapan penelusurannya:

1. Hop 1: temukan Thread. Konteks Router masih menyimpan entri indeks satu baris: thr_pr_412: payments retry PR, merged Wed. Router mengambil data melalui GET /threads/thr_pr_412.
2. Hop 2: temukan Worker. Catatan Thread mencantumkan owner_workers: ["wkr_77a0"]. Router memanggil GET /workers/wkr_77a0 dan membaca laporan akhirnya.
3. Hop 3: temukan penyebabnya. Laporan tersebut mengutip trg_8f21, yaitu kegagalan CI. Router mengambil payload Trigger tersebut dan membaca eror batas waktu (timeout) di dalam log.
4. Jawaban. “CI pada PR #412 gagal karena 3 masalah payment timeout pada hari Selasa. Worker wkr_77a0 menambahkan retry dengan strategi backoff, dan PR tersebut di-merge pada hari Rabu.”

Tiga pemanggilan data yang kecil dan presisi. Tidak ada yang ditebak-tebak, dan tidak ada data yang perlu mengendap di dalam prompt selama tiga hari.

Chain of Recall vs memori vektor dan ringkasan

Chain of Recall tidak menggantikan teknik memori lainnya, melainkan menjawab pertanyaan yang berbeda. Retrieval berbasis vektor, yang dipopulerkan oleh makalah retrieval-augmented generation, menjawab pertanyaan “apa yang mirip dengan ini?” Sedangkan Chain of Recall menjawab pertanyaan “apa yang terhubung dengan ini?”

Dalam praktiknya, Anda akan menggabungkan keduanya: indeks vektor bertugas menemukan Thread ID awal, lalu Chain of Recall menelusurinya hingga ke fakta-fakta yang tepat. Hierarki memori bergaya sistem operasi pada makalah MemGPT memiliki konsep yang sangat berdekatan. Jika Anda lebih memilih memulai dengan solusi penyimpanan siap pakai, simak panduan kami tentang menambahkan memori persisten ke agen AI dengan MCP.

Ada dua batasan yang perlu dicatat. Esai tersebut menempatkan memori jangka panjang sebagai masalah terbuka dan tidak mengklaim bahwa Chain of Recall menyelesaikannya. Selain itu, dalam eksperimennya, penghapusan Thread pass-through meningkatkan token pembacaan cache dari 23,2 juta menjadi 31,8 juta per run (naik sekitar 37%): ini adalah biaya akibat ketiadaan fitur, bukan penghematan yang dihasilkan oleh Chain of Recall.

Jaminan yang wajib dipenuhi oleh API di baliknya

Setiap hop dalam alur penelusuran tersebut merupakan panggilan API. Jika satu panggilan saja mengembalikan catatan yang berbeda, atau tidak mengembalikan apa pun, rantai akan terputus dan agen akan macet atau menjawab berdasarkan tebakan semata. Oleh karena itu, API di balik Chain of Recall wajib mematuhi empat kontrak:

1. ID tidak pernah berubah. ID yang dihasilkan hari ini harus selalu merujuk ke objek yang sama di bulan depan. Tidak boleh digunakan kembali setelah penghapusan, dan tidak boleh dinomori ulang setelah migrasi data.
2. Fetch-by-ID harus murah dan presisi. GET /threads/{id} harus mengembalikan tepat satu catatan tersebut. Endpoint ini tidak melakukan pencarian, dan tidak mengembalikan hasil “paling mirip”.
3. ID yang tidak dikenal harus gagal secara tegas (fail loudly). ID yang tidak ditemukan harus mengembalikan 404 Not Found, sebagaimana didefinisikan oleh RFC 9110, disertai error body yang jelas. Respons 200 dengan objek kosong justru akan mengecoh agen bahwa memori tersebut ada padahal kenyataannya tidak.
4. Paginasi kursor tanpa celah. GET /threads/{id}/events?cursor= harus menelusuri Thread yang panjang secara berurutan. Setiap peristiwa hanya muncul satu kali, tidak ada yang terlewat, dan kursor tetap valid meski ada peristiwa baru yang masuk.

Kontrak-kontrak ini kerap rusak tanpa disadari saat refaktorisasi kode, sehingga pengujian otomatis mutlak diperlukan. Respons tool juga harus tetap ringkas, sebagaimana dibahas secara mendalam dalam panduan kami mengenai respons tool agen dan context window.

Uji API recall bersama coding agent menggunakan Apidog CLI

Keandalan Chain of Recall sepenuhnya bergantung pada endpoint fetch-by-ID miliknya, dan sebuah coding agent dapat menulis serta menjalankan ulang pengujian tersebut untuk Anda. Apidog CLI menyediakan perintah-perintah bagi agen untuk mendefinisikan endpoint, membuat skenario pengujian, dan menjalankannya langsung dari terminal.

Konfigurasikan sekali saja:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Kemudian berikan satu prompt berikut ke Claude Code, Codex, atau agen apa pun yang Anda gunakan:

In Apidog project <projectId>, define three endpoints for our agent memory
service: GET /threads/{id}, GET /threads/{id}/events?cursor=, and
GET /workers/{id}. Then create test cases that check:
1. A thread_id returned by GET /threads/{id} resolves to the same record
   on a second call, and each owner worker ID resolves via GET /workers/{id}.
2. An unknown thread ID and an unknown worker ID both return 404.
3. Paging GET /threads/{id}/events with the cursor returns every event
   once, in order, with no gaps.
Run them against the staging environment and summarize any failures.

Agen akan membaca setiap skema payload, memvalidasi JSON-nya sebelum menulis apa pun, lalu membuat dan menjalankan skenario pengujian tersebut:

apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file thread-get.json
apidog endpoint create --project <projectId> --file thread-get.json

apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file id-resolves.json
apidog test-case create --project <projectId> --file id-resolves.json

apidog run --test-case <caseId> --project <projectId> -e <envId> -r cli,json

Reporter cli akan mencetak status berhasil dan gagal per asersi di terminal, sedangkan laporan json memberi agen sebuah berkas yang dapat dibaca untuk menjelaskan hop mana yang terputus. Jika suatu ID tidak lagi dapat diakses setelah migrasi, Anda akan mengetahuinya dari laporan sebelum agen Anda mulai memberikan jawaban berdasarkan rantai yang terputus. Untuk menjalankan pemeriksaan yang sama di setiap proses merge, ubah reporter menjadi -r junit; panduan kami tentang Apidog CLI di Claude Code memperlihatkan alur kerja agen secara lengkap.

Kapan Chain of Recall tepat digunakan

Gunakan Chain of Recall saat memori agen Anda berupa riwayat peristiwa diskret yang dapat saling ditautkan: PR, tiket masalah, eksekusi CI, utas dukungan pengguna, deployment. Peristiwa-peristiwa ini sudah memiliki ID alami, dan pertanyaan yang diajukan orang mengenainya (“mengapa kita melakukan ini?”, “apa yang terjadi setelah itu?”) pada dasarnya adalah pertanyaan seputar keterkaitan hubungan antar-peristiwa.

Gunakan retrieval vektor untuk dokumen tidak terstruktur dan pertanyaan yang tidak pasti, serta gunakan ringkasan untuk sesi-sesi singkat di mana hilangnya detail tidak menjadi masalah.

Chain of Recall bermula dari satu esai dan sebuah purwarupa: sebuah ide yang jelas dan dapat diuji, bukan sebuah produk jadi. Untuk mempelajari tool di balik esai tersebut, mulailah dengan membaca artikel apa itu DeepSeek Harness.

FAQ

Apakah Chain of Recall merupakan fitur DeepSeek yang bisa saya aktifkan? Tidak. Ini adalah istilah dari esai super-agent DeepSeek Harness, dan sebagian implementasinya berada dalam plugin purwarupa yang oleh penulisnya dinyatakan bukan produk resmi DeepSeek. Anda perlu mengimplementasikan pola arsitektur ini sendiri.

Apa perbedaan antara inline dan spill? Inline mempertahankan ID, ringkasan singkat, dan pesan-pesan terdekat di dalam prompt. Sementara spill memangkas sisanya dan meninggalkan pointer yang dapat dipanggil agen berdasarkan ID saat diperlukan.

Apakah Chain of Recall menggantikan RAG? Tidak. RAG bertugas menemukan konten yang serupa; Chain of Recall menelusuri tautan ID yang pasti. Banyak agen yang menggunakan kombinasi keduanya.

Apakah Chain of Recall memangkas konsumsi token hingga 37%? Tidak. Angka 37% tersebut berkaitan dengan Thread pass-through: menghapusnya justru meningkatkan token pembacaan cache dari 23,2 juta menjadi 31,8 juta per run dalam eksperimen di esai tersebut. Esai itu tidak mencatat adanya penghematan token khusus untuk Chain of Recall itu sendiri.

Apa yang seharusnya dikembalikan oleh API fetch-by-ID jika ID tidak dikenal? Mengembalikan 404 Not Found disertai error body yang jelas. Mengembalikan status 200 dengan objek kosong justru akan membuat agen mengira data tersebut ada, yang berakibat pada putusnya rantai recall tanpa terdeteksi.

Bagaimana cara memastikan API memori agen saya tetap stabil? Buat skenario pengujian yang memverifikasi bahwa ID dari satu pemanggilan dapat diakses pada pemanggilan berikutnya, ID yang tidak dikenal menghasilkan respons 404, dan kursor halaman berfungsi tanpa celah data. Sebuah coding agent dapat membuat dan menjalankan pengujian ini menggunakan Apidog CLI di setiap merge.