Kalau session AI lu cuma bisa hidup di satu provider, itu bukan memory kerja. Itu lock-in yang kelihatan produktif sampai hari lu perlu audit, pindah model, atau nerusin kerja dari tool lain.
Artikel ini membahas kenapa AI agent butuh context portable: jejak kerja yang bisa dibaca ulang manusia, model lain, dan agent lain. Maksudnya bukan semua reasoning internal model harus dibuka mentah. Maksudnya, workflow AI yang serius perlu menyimpan instruksi, pesan penting, tool call, hasil tool, file diff, sumber, dan keputusan dalam format yang bisa lu bawa keluar dari satu platform.
Apa itu session portability di AI agent?
Session portability adalah kemampuan membawa konteks kerja AI dari satu tempat ke tempat lain tanpa kehilangan makna operasionalnya. Bukan cuma export chat. Chat transcript yang rapi sering cuma cerita akhir. Yang dibutuhkan developer biasanya lebih detail: apa instruksinya, file mana yang disentuh, command apa yang jalan, error apa yang muncul, sumber mana yang dipakai, dan kenapa keputusan tertentu diambil.
Artikel Earendil, The Session You Cannot Take With You, mengkritik arah inference API modern yang makin banyak menyimpan state dalam bentuk provider-bound: reasoning opaque, encrypted payload, hasil web search yang tidak sepenuhnya terlihat client, compacted context yang cuma bisa dibuka provider, sampai referensi file/vector store/container/cache yang tidak resolve di luar platform tersebut.
Menurut gua, poin ini penting banget buat developer yang mulai memakai AI agent sebagai bagian dari workflow harian. Selama output-nya cuma snippet kecil, lu mungkin masih aman. Tapi saat agent mulai ngubah banyak file, riset sumber, bikin draft, jalanin test, atau deploy sesuatu, chat history biasa mulai terasa terlalu tipis.
Masalahnya bukan anti-provider, tapi ownership jejak kerja
Gua tidak melihat ini sebagai argumen “jangan pakai provider besar”. Model dan platform tertutup sering nyaman, cepat, dan memang berguna. OpenAI sendiri punya dokumentasi conversation state untuk menjaga informasi lintas turn; Anthropic juga punya Claude Code memory lewat CLAUDE.md dan auto memory supaya context proyek bisa dibawa antar-session.
Masalahnya muncul ketika terlalu banyak state penting cuma hidup sebagai ID, blob, ringkasan, atau referensi internal provider. Dari luar, workflow lu kelihatan jalan. Tapi begitu lu butuh memindahkan session ke model lain, mengulang debugging, atau menjelaskan keputusan ke manusia lain, lu sadar yang lu punya cuma potongan cerita.
Di dunia software, ini mirip deploy tanpa log yang cukup. Aplikasi bisa jalan. Tapi saat incident, lu baru sadar observability-nya bolong. Dalam workflow AI agent, transcript dan artifact kerja itu observability.
Chat history bukan project memory
Chat history berguna buat nostalgia konteks, tapi bukan fondasi kerja jangka panjang. Project memory harus lebih dekat ke dokumentasi operasional: bisa dicari, bisa diedit, bisa di-version, bisa dibaca tanpa UI tertentu, dan tidak hancur kalau lu ganti tool.
Ini alasan gua suka workflow file-first seperti Obsidian, Markdown, Hermes notes, backlog riset, dan draft HTML lokal sebelum masuk Ghost CMS. Bukan karena Markdown paling keren. Justru karena Markdown boring. File teks biasa lebih gampang diaudit, di-diff, di-backup, dan dikasih ke tool lain.
Kalau sebuah keputusan penting cuma ada di chat provider, lu sebenarnya belum benar-benar punya keputusan itu sebagai asset kerja. Lu cuma punya akses sementara ke tampilan keputusan tersebut.
Minimal context yang harus lu simpan
Kalau lu memakai AI agent untuk coding, riset, atau konten, gua bakal mulai dari checklist sederhana ini:
- Instruksi utama: goal, constraint, style guide, dan batasan yang tidak boleh dilanggar.
- Input penting: link sumber, file yang dibaca, data awal, dan requirement dari user.
- Tool call dan hasilnya: command yang dijalankan, test result, error log, API response penting, dan hasil validasi.
- Perubahan file: diff, path file, alasan perubahan, dan cara rollback kalau perlu.
- Keputusan: kenapa opsi A dipilih, opsi B ditolak, dan risiko yang masih tersisa.
- Status akhir: apa yang sudah selesai, apa yang belum, dan next step yang jelas.
Checklist ini tidak harus kompleks. Bahkan folder kecil berisi README.md, decisions.md, sources.md, dan artifact hasil test sering sudah lebih sehat daripada 30 chat panjang yang tidak bisa dicari dengan rapi.
Contoh sederhana: agent coding yang pindah tool
Bayangin lu minta agent memperbaiki bug checkout. Agent baca 20 file, jalanin test, nemu error race condition, lalu mengubah logic retry. Kalau semua proses itu cuma tersimpan sebagai chat summary, agent lain mungkin cuma tahu “bug retry diperbaiki”. Itu terlalu dangkal.
Context portable harus menjawab pertanyaan yang lebih operasional:
- Test apa yang gagal sebelum fix?
- File mana yang paling relevan?
- Apakah fix mengubah kontrak API?
- Apakah ada edge case yang belum ditutup?
- Apakah agent sempat mencoba solusi lain dan gagal?
Dengan catatan seperti ini, lu bisa melanjutkan kerja di Claude Code, Codex, Cursor, Hermes, atau bahkan manual di terminal tanpa mulai dari nol. Model boleh ganti. Jejak kerja tetap punya lu.
Kapan provider-bound state masih masuk akal?
Biar adil, tidak semua state internal harus portable. Ada alasan teknis dan keamanan kenapa provider tidak membuka semua reasoning mentah: safety, IP, abuse prevention, dan desain produk. Gua tidak sedang bilang semua reasoning token harus diekspor mentah.
Yang gua anggap wajib adalah artifact yang cukup untuk audit dan handoff. Kalau model melakukan web search, user perlu tahu sumber penting yang membentuk jawaban. Kalau agent menjalankan tool, user perlu tahu input dan output yang relevan. Kalau agent mengubah file, user perlu diff dan alasan. Kalau context dipadatkan, user butuh ringkasan yang bisa diverifikasi, bukan cuma “trust me bro”.
Cara mulai bikin context portable minggu ini
Lu tidak perlu membangun sistem agent rumit. Mulai dari kebiasaan kecil:
- Bikin folder per task. Simpan brief, sumber, keputusan, dan output akhir dalam satu tempat.
- Tulis decision log pendek. Satu keputusan cukup 3 baris: konteks, pilihan, alasan.
- Simpan command penting. Jangan cuma screenshot hasil. Catat command dan output yang relevan.
- Export diff sebelum merge. AI boleh bantu, tapi perubahan tetap harus bisa lu review.
- Jangan jadikan chat sebagai satu-satunya arsip. Pindahkan insight penting ke Markdown atau issue tracker.
Kalau lu creator, pola yang sama juga kepakai. Riset artikel, sumber, outline, draft, dan caption turunan sebaiknya jadi artifact yang bisa dipakai ulang. Ini bikin satu riset bisa turun jadi blog post, carousel, Threads, dan short video tanpa ngulang kerja dari awal.
Takeaway buat developer dan builder
AI agent yang bagus bukan cuma yang jawabnya pintar. Dia harus meninggalkan jejak kerja yang cukup jelas supaya manusia bisa percaya, memperbaiki, dan melanjutkannya.
Menurut gua, arah yang sehat adalah kombinasi: pakai model terbaik yang tersedia, tapi simpan context penting dalam format yang lu kendalikan. Provider boleh jadi mesin kerja. Tapi project memory, decision log, dan artifact operasional sebaiknya tetap ada di ruang kerja lu sendiri.
Kalau workflow AI lu tidak bisa dijelaskan tanpa membuka satu chat provider tertentu, itu tanda kecil bahwa sistem lu belum portable. Bukan berarti harus langsung dibongkar. Tapi mulai sekarang, biasakan agent meninggalkan jejak yang bisa dibaca manusia.
FAQ singkat
Apakah context portable berarti semua chat AI harus diekspor?
Tidak. Yang penting bukan semua chat, tapi artifact yang membuat kerja bisa diaudit dan dilanjutkan: instruksi, sumber, tool result, diff, keputusan, dan status akhir.
Apakah Markdown cukup untuk project memory?
Untuk banyak workflow developer dan creator, iya. Markdown mudah dicari, di-diff, di-backup, dan dibaca lintas tool. Kalau butuh struktur lebih kuat, lu bisa tambah folder, frontmatter, atau database ringan.
Apakah ini berarti jangan pakai memory bawaan Claude Code atau platform lain?
Bukan. Memory bawaan tetap berguna. Tapi jangan jadikan itu satu-satunya sumber kebenaran. Simpan aturan dan keputusan penting di file proyek yang bisa lu kontrol.
