Anda memulai sebuah fitur di Claude Code. Prosesnya tersendat karena error tipe yang rumit, jadi Anda menyerahkan repo yang sama ke Codex, yang lebih jago untuk urusan semacam itu. Codex memperbaikinya, tapi sekarang ia tidak tahu fitur itu untuk apa, file mana yang sudah Anda sepakati untuk tidak disentuh, atau apa arti "selesai" di konteks ini. Anda menjelaskan ulang semuanya dari ingatan. Sepuluh menit kemudian Anda beralih kembali, dan Claude Code juga sudah lupa. Kodenya maju. Konteksnya tidak.
Inilah pajak dari menjalankan lebih dari satu coding agent. Setiap alat menyimpan memoriya sendiri dalam formatnya sendiri dan sesinya sendiri, sehingga begitu pekerjaan berpindah dari satu agent ke agent lain, semua hal selain diff-nya terbuang percuma. Menjaga konteks saat berpindah antar coding agent berarti membuat konteks itu hidup di suatu tempat di luar agent mana pun, dalam bentuk yang bisa dibaca agent berikutnya tanpa Anda harus menceritakannya.
Artikel ini membahas cara melakukannya, menggunakan Sharkly sebagai alur kerjanya: lapisan yang berada di atas coding agent Anda dan menjaga konteks, progres, penghambat, hasil, dan tinjauan manusia tetap terlihat dari permintaan hingga rilis. Anda sudah punya coding agent. Masalahnya di sini adalah sambungan di antara mereka, dan sambungan itu makin lebar dengan setiap agent yang Anda tambahkan.
Mengapa konteks tidak berpindah antar agent
Konteks untuk sebuah tugas coding hidup di tiga tempat, dan hanya satu yang portabel.
Yang pertama adalah file instruksi: CLAUDE.md, AGENTS.md, GEMINI.md. Aturan tetap, konvensi, perintah untuk menjalankan tes. Yang kedua adalah status sesi: riwayat percakapan Anda dan agent, apa yang dicobanya, apa yang dikesampingkannya. Yang ketiga adalah artefaknya sendiri, diff di disk atau branch-nya.
Hanya yang ketiga yang berpindah secara gratis. Agent yang berbeda bisa membaca kodenya, tapi tidak bisa membaca percakapan yang tidak diikutinya, dan tidak akan membaca file instruksi yang ditujukan untuk alat lain. Itulah batas yang perlu dinyatakan dengan gamblang: berpindah agent mempertahankan kode dan membuang penalarannya. Commit-nya bertahan. Alasan "mengapa"-nya ada di buffer riwayat yang dilihat satu agent dan tidak akan pernah dilihat agent berikutnya.
Jadi menjaga konteks saat berpindah sebenarnya ada dua pekerjaan: membuat aturan tetap bisa dibaca oleh setiap agent, dan membuat status tugas yang sedang berjalan ada sebagai sesuatu selain memori satu alat. Bagian selanjutnya membahasnya secara berurutan. (Jika masalah Anda adalah kehilangan konteks antar proses dari agent yang sama, itu masalah yang terkait tapi terpisah, dibahas di mempertahankan konteks antar sesi AI.)
Buat aturan tetap menjadi satu file yang dibaca setiap agent
Mulai dari kemenangan yang mudah. Claude Code membaca CLAUDE.md, Codex membaca AGENTS.md, Gemini CLI membaca GEMINI.md. Pekerjaan yang sama, tiga nama file. Jika Anda mengelolanya secara terpisah, ketiganya akan melenceng, dan agent yang Anda pilih sekarang mengikuti aturan yang sudah kedaluwarsa sementara Anda mengira tidak demikian.
Tulis aturannya sekali dan arahkan nama file lainnya ke sana. Di macOS atau Linux:
# AGENTS.md is the source of truth; the others are aliases
ln -s AGENTS.md CLAUDE.md
ln -s AGENTS.md GEMINI.md
git add AGENTS.md CLAUDE.md GEMINI.md
Sekarang setiap agent yang membuka repo membaca konvensi yang sama, dan hanya ada satu file untuk diperbarui saat konvensinya berubah. Jaga agar singkat dan faktual: perintah tes, direktori yang dilarang disentuh, aturan tinjauan, bagaimana commit seharusnya terlihat. Ini adalah kontrak bersama yang diwarisi setiap agent begitu ia mulai, tidak peduli agent mana yang Anda pilih.
Mode kegagalan yang perlu diwaspadai: menaruh detail spesifik tugas di file-file ini. File instruksi diperuntukkan bagi aturan yang berlaku di setiap tugas di repo tersebut. "Kami pakai Vitest, bukan Jest" termasuk di sini. "Selesaikan logika retry checkout dan jangan sentuh middleware auth" tidak; itu benar untuk satu tugas minggu ini dan salah untuk tugas berikutnya. Mencampur keduanya berarti setiap agent membaca instruksi yang dimaksudkan untuk pekerjaan yang sudah selesai dirilis.
Bawa konteks kerja, bukan hanya aturannya
File aturan membawa agent baru ke garis start. Ia tidak mengatakan apa-apa tentang tugas yang sedang berjalan: apa yang sudah diputuskan, apa yang setengah selesai, apa yang masih belum pasti. Pengetahuan itulah yang menguap saat Anda berpindah, karena ia hanya pernah hidup di sesi agent sebelumnya.
Perbaikan manualnya adalah catatan serah terima. Sebelum berpindah agent, minta agent yang sekarang menuliskan posisinya: tujuannya, file yang diubahnya, apa yang diverifikasinya, dan satu hal yang ia belum yakin. Tempelkan itu ke agent berikutnya sebagai pesan pertama. Ini berhasil, dan untuk sekali perpindahan itu sudah cukup. Pola ini layak diinternalisasi sendiri; bentuk catatan yang baik dibahas di template serah terima agent.
Mode kegagalannya adalah catatan itu tidak hidup di mana pun yang tahan lama. Ia hanya paragraf di terminal yang akan Anda tutup, atau pesan yang Anda ketik ulang setiap kali. Berpindah bolak-balik dua kali dan Anda mengelola catatan serah terima itu dengan tangan, di kepala Anda, di tiga alat. Konteksnya ada, tapi Anda sudah menjadi basis data tempatnya disimpan. Itu bertahan untuk satu tugas. Tidak bertahan saat Anda menjalankan beberapa tugas sekaligus, dan di situlah pendekatan DIY mulai kewalahan.
Di mana pendekatan DIY berhenti berskala
Aturan yang di-symlink plus catatan serah terima yang ditempel membawa Anda cukup jauh dengan satu repo dan dua agent. Tambahkan agent ketiga, repo kedua, atau tugas yang berlangsung seharian, dan hitungannya berbalik melawan Anda. Setiap perpindahan adalah ekspor dan impor manual. Setiap tugas punya alur "apa yang sudah selesai"-nya sendiri yang hanya hidup di tempat agent terakhir meninggalkannya. Tidak ada yang memberi tahu Anda bahwa Agent backend sudah menyelesaikan endpoint yang ditunggu Agent frontend, karena "memberi tahu" hanyalah pesan di terminal yang tidak ada yang mengawasi.
Pada titik itu, solusinya bukan catatan yang lebih baik. Solusinya adalah memindahkan konteks kerja dari agent sepenuhnya ke sebuah Task bersama yang dibaca dan ditulisi kembali oleh setiap agent dan orang. Sebuah Task di Sharkly menyimpan tujuan, kriteria penerimaan, diff, penghambat, dan diskusi dalam satu catatan. Eksekusi, penghambat, hasil, dan tindak lanjut kembali ke timeline Task itu, sehingga berpindah agent tidak lagi menjadi proses ekspor sama sekali. Anda cukup mengalihkan Task-nya; agent berikutnya membaca catatan yang sama dengan yang ditulis agent sebelumnya.
Di sinilah juga pembagian manusia-agent menjadi rapi. Agent meneliti, mengeksekusi, menguji, dan melapor ke Task. Manusia menetapkan arah, memberikan wewenang, dan menerima hasilnya. Otomasi berhenti di titik yang memerlukan pertimbangan tim, dan catatan yang dibaca pekerja berikutnya adalah catatan yang sama yang dibaca peninjau. Itu hanya bisa berhasil karena konteksnya tidak lagi terperangkap dalam sebuah sesi.
Inilah pasangan keputusan yang jujur. Jika Anda menjalankan satu agent di satu terminal pada satu repo, Anda tidak memerlukan semua ini; konteksnya tidak pernah keluar, jadi tidak ada yang perlu dipertahankan. Gunakan Task bersama begitu konteks harus bertahan melewati sebuah perpindahan, baik perpindahan itu agent-ke-agent, agent-ke-manusia, atau sekadar Anda besok pagi. Jika Anda ingin tetap menggunakan beberapa coding agent alih-alih berkomitmen pada satu ekosistem, portabilitas itulah intinya: alur kerja Anda bertahan apa pun agent yang Anda pilih berikutnya, karena konteksnya tidak pernah disimpan di dalam agent mana pun. Itu juga pengaturan yang memungkinkan Anda menjalankan Claude Code dan Codex bersamaan di satu codebase tanpa salah satunya menjadi buta saat serah terima, dan ini berpadu alami dengan worktree, satu checkout per tugas, agar agent paralel tidak bertabrakan.
Daftar periksa yang bisa Anda jalankan hari ini
Kerjakan ini secara berurutan. Tiga yang pertama tidak memakan biaya apa pun; yang keempat adalah langkah yang Anda ambil saat tiga yang pertama mulai kewalahan.
- Satukan file aturannya. Symlink-kan
CLAUDE.md,AGENTS.md, danGEMINI.mdke satu sumber. Batasi hanya pada konvensi seluruh repo, tanpa detail tugas. - Tulis catatan serah terima sebelum setiap perpindahan. Tujuan, file yang diubah, apa yang diverifikasi, pertanyaan terbuka. Agent yang sekarang bisa menyusunnya; Anda menempelkannya ke agent berikutnya.
- Tentukan perpindahan berdasarkan tugas, bukan kebiasaan. Cocokkan agent dengan pekerjaan di depan Anda, menggunakan panduan perutean alih-alih sekadar memakai terminal yang sedang terbuka.
- Pindahkan konteks dari agent saat catatan mulai kewalahan. Begitu Anda mengelola lebih dari beberapa agent atau repo, taruh tujuan, status, dan tinjauan pada Task bersama agar berpindah cukup dengan mengalihkan, bukan menjelaskan ulang.
Jika Anda sudah menjalankan beberapa agent dan menceritakan ulang konteks yang sama setiap kali berpindah, itulah masalah yang Sharkly dibangun untuk mengatasinya: satu tempat di mana tugas, progres, dan hasil setiap agent tetap terlihat, sehingga konteksnya hidup lebih lama daripada perpindahannya.
