Sebagian besar alur kerja multi-agen tidak gagal pada bagian yang sulit. Agen berhasil menulis kode, menjalankan pengujian, dan membuat pull request. Kegagalan justru terjadi pada titik transisinya: momen ketika pekerjaan keluar dari satu agen dan seharusnya berpindah ke pihak lain. Agen backend menyelesaikan sebuah endpoint, tetapi agen frontend tidak pernah tahu bahwa endpoint tersebut sudah siap. Sebuah refactor mendarat di worktree dan terbengkalai begitu saja dalam status hijau, hanya karena tidak ada manusia yang diminta untuk memeriksanya. Masalahnya bukan pada tugas itu sendiri, melainkan pada proses handoff-nya.
Handoff agen AI adalah pemindahan suatu pekerjaan, beserta konteksnya, dari satu pekerja ke pekerja berikutnya: baik dari agen ke agen, maupun dari agen ke manusia. Ketika Anda menjalankan satu coding agent di satu terminal, handoff tidak terasa karena memang tidak terjadi perpindahan. Namun begitu Anda menjalankan dua agen, atau satu agen dan satu reviewer, setiap langkah yang selesai harus bermuara di tempat yang bisa ditemukan oleh pekerja berikutnya. Titik temu itulah kunci penentunya.
Artikel ini mengulas pola-pola handoff yang terbukti efektif dalam praktik, menggunakan Sharkly sebagai fondasi alur kerja: lapisan yang berada di atas coding agent Anda untuk menjaga agar konteks, progres, hambatan, hasil, dan tinjauan manusia tetap transparan dari tahap permintaan hingga rilis. Anda mungkin sudah memiliki coding agent. Masalah yang dipecahkan artikel ini adalah apa yang terjadi di celah antara agen-agen tersebut.
Versi singkatnya
Handoff adalah proses berpindahnya pekerjaan beserta konteksnya dari satu pekerja ke pekerja berikutnya. Handoff antar-agen meneruskan sub-tugas yang telah selesai ke agen berikutnya; handoff agen-ke-manusia menghentikan pekerjaan otonom pada gerbang peninjauan (review gate). Buat keduanya jelas dan terukur menggunakan status: Agen memindahkan Task ke Ready for review, Manusia memindahkannya ke Done. Ketika handoff berbentuk perubahan status pada Task bersama—bukan sekadar pesan di terminal—tidak akan ada pekerjaan yang terabaikan secara diam-diam.
Apa sebenarnya handoff agen itu?
Sebuah handoff terdiri dari tiga komponen penting, dan melewatkan salah satunya akan menyebabkan pekerjaan hilang arah: artefak (diff, PR, migrasi), konteks (apa yang diminta, apa yang diubah, apa yang masih belum pasti), dan penerima (agen atau individu spesifik yang memegang langkah berikutnya).
Alur kerja berbasis terminal biasanya hanya membawa artefak dan kehilangan dua komponen lainnya. Commit memang tercatat, tetapi alasan di baliknya terkubur di riwayat scrollback terminal yang hanya dilihat oleh satu agen, dan penanggung jawab langkah berikutnya menjadi tidak jelas. Inilah alasan mengapa orkestrasi agen bukan sekadar tentang meluncurkan mereka, melainkan tentang bagaimana mengarahkan apa yang mereka hasilkan.
Handoff yang rapi memindahkan ketiga komponen tersebut secara bersamaan: perubahannya, ringkasan tentang apa yang sudah dan belum selesai, serta sinyal tegas bahwa giliran telah beralih ke penerima. Dalam konsep Sharkly, eksekusi, hambatan, hasil, dan diskusi lanjutan kembali ke linimasa Task, sehingga pekerja berikutnya cukup membaca satu catatan terpadu alih-alih mereka ulang dari berbagai sumber terpisah.
Dua pola handoff
Kedua pola ini terlihat serupa tetapi memiliki pengaturan default yang bertolak belakang. Handoff antar-agen seharusnya berjalan otomatis: Agen berikutnya mengambil sub-tugas yang sudah siap dan langsung melanjutkan pekerjaan. Sebaliknya, handoff agen-ke-manusia secara default harus berhenti: Agen menyelesaikan bagian tugasnya lalu menunggu, karena manusialah yang harus mengambil keputusan.
| Agent-to-agent | Agent-to-human | |
|---|---|---|
| Pemicu | Sub-tugas ditandai siap | Pekerjaan mencapai gerbang peninjauan |
| Default | Lanjut secara otomatis | Berhenti dan menunggu |
| Muatan | Artefak + konteks + kriteria penerimaan | Diff + ringkasan perubahan + batasan umum |
| Risiko jika terlewat | Pekerjaan duplikat atau bentrok | Kode yang belum ditinjau di-merge tanpa pengawasan |
Berikut panduan keputusan yang menjaga alur kerja Anda tetap terarah. Otomatiskan handoff antar-agen ketika langkah berikutnya sudah terdefinisi dengan jelas dan kriteria penerimaannya telah tertulis: “jalankan rangkaian tes,” “buat migrasi,” “perbarui spesifikasi OpenAPI.” Terapkan handoff agen-ke-manusia ketika langkah selanjutnya membutuhkan pertimbangan yang tidak bisa diambil oleh agen: melakukan merge ke branch main, mengubah kontrak API publik, menyentuh autentikasi atau penagihan, maupun menyetujui hasil akhir pekerjaan.
Kesalahan umum adalah memperlakukan setiap handoff secara seragam. Menjalankan semuanya serba otomatis berisiko me-merge pekerjaan yang belum diperiksa; sebaliknya, memasang gerbang persetujuan di setiap langkah hanya akan menciptakan alur kerja manual yang lambat dengan birokrasi berlebih. Ini berkaitan erat dengan pemahaman tentang di mana menempatkan gerbang persetujuan agar agen berhenti sebelum terjadi kesalahan fatal yang mahal, bukan berhenti di setiap langkah sepele.
Status mengubah handoff menjadi gerbang kendali, bukan sekadar harapan
Model operasional ini bertumpu pada empat kata kerja dan pembagian perannya: siapa yang menugaskan, siapa yang menjalankan, siapa yang meninjau, dan siapa yang menyetujui. Agen bertugas meriset, mengeksekusi, menguji, dan melaporkan. Manusia bertugas menentukan arah, memberi wewenang, dan menyetujui hasil akhir. Otomatisasi harus berhenti saat pertimbangan tim manusia diperlukan.
Status adalah mekanisme yang mengubah kesepakatan tersebut menjadi sistem yang pasti, bukan sekadar niat baik. Setiap Task bergerak melalui alur yang sama:
- Todo: telah ditugaskan, belum dimulai. Dimasukkan ke sini oleh manusia atau Leader Agent.
- In progress: telah diambil oleh Agen dan sedang dikerjakan dalam worktree yang terisolasi.
- Ready for review: batas wewenang Agen. Agen telah menjalankan typecheck, pengujian, dan build, melampirkan ringkasan perubahan beserta batasan yang diketahui, lalu berhenti.
- Done: batas wewenang manusia. Seseorang telah menyetujui hasilnya dan mengambil keputusan untuk merge serta rilis.
Aturan dasar yang membuat seluruh proses ini tertib: Agen memindahkan Task ke Ready for review; Manusia memindahkannya ke Done. Agen tidak boleh menandai pekerjaannya sendiri sebagai Done, dan manusia tidak perlu menebak-nebak apakah Task yang berstatus hijau sudah aman. Status itulah wujud nyata dari handoff. Ketika sepuluh agen bekerja bersamaan, Anda tidak perlu memeriksa sepuluh terminal; cukup lihat papan kerja untuk mengetahui secara pasti apa yang sedang menunggu tindakan Anda, apa yang menunggu agen lain, dan apa yang masih diproses. Visibilitas inilah yang membedakan antara melacak apa yang telah diselesaikan agen dan sekadar berharap riwayat commit bisa menjelaskan semuanya nanti.
Contoh studi kasus: dari tiket hingga PR di-merge
Mari kita lihat contoh Task nyata, SH-312: “Tambahkan rate limiting ke API publik.” Cermati proses handoff-nya, bukan kodenya.
Seseorang menguraikan kebutuhan menggunakan bahasa sehari-hari dan menugaskannya. Sebuah Leader Agent meriset basis kode serta riwayat tugas sebelumnya, merumuskan ruang lingkup dan kriteria penerimaan (pembatasan per API key, respons 429 dengan header Retry-After, mencakup tiga endpoint tersibuk), lalu membagi SH-312 menjadi tiga sub-tugas yang siap dikerjakan. Itulah handoff antar-agen pertama: instruksi masuk, sub-tugas yang terstruktur keluar.
Sub-tugas mengalir secara otomatis. Backend Agent menangani logika rate limiter; test Agent mengambil alih cakupan pengujian. Karena masing-masing berjalan di worktree yang terisolasi, keduanya tidak akan bentrok pada berkas yang sama, dan setiap hasil pekerjaan tercatat kembali ke tiket SH-312, bukan tersimpan di sesi lokal. Ketika backend Agent selesai, ia tidak perlu memanggil manusia; agen cukup menandai sub-tugasnya siap, dan test Agent akan langsung menguji implementasi nyata tersebut, bukan sekadar kode tiruan (stub).
Setelah itu, pola handoff berganti. Dengan limiter yang sudah selesai dibangun, typecheck bersih, pengujian lolos, dan build berstatus hijau, pekerjaan tiba di gerbang agen-ke-manusia. Agen memindahkan status SH-312 ke Ready for review serta melampirkan diff, ringkasan perubahan, dan satu batasan teknis: “Counter berbasis Redis mengasumsikan satu wilayah (single region); penerapan multi-wilayah memerlukan penanganan lanjutan.” Peninjau memeriksa seluruh informasi tersebut di satu tempat, memastikan fungsionalitas respons 429, lalu memindahkan statusnya ke Done, yang otomatis memicu proses merge. Dari tiket hingga PR di-merge, tersimpan riwayat transparan mengenai siapa yang mengerjakan apa di setiap tahap transisi. Inilah alur yang sama dari persyaratan ke kode yang dapat ditelusuri secara menyeluruh.
Di mana handoff kerap gagal, dan cara mengatasinya
Handoff umumnya mengalami kendala dalam tiga skenario yang mudah diantisipasi, dan masing-masing memiliki solusi berbasis sistem, bukan sekadar mengandalkan daya ingat.
Konteks menguap. Agen memahami alasan teknis di balik pilihannya; peninjau tidak mengetahuinya. Solusi: handoff wajib menyertakan ringkasan perubahan dan batasan yang diketahui saat status dipindahkan ke Ready for review, bukan sebagai lampiran susulan. Kepemilikan menjadi kabur. Dua agen mengambil pekerjaan yang sama, atau tidak ada yang mengerjakannya sama sekali. Solusi: tentukan Assignee pada setiap Task dan sub-tugas, sehingga giliran kerja menjadi data yang jelas, bukan sekadar tebakan. Peninjauan tidak pernah terlaksana. Pekerjaan otonom langsung di-merge karena tidak ada pengingat untuk menghentikannya. Solusi: buat status kendali yang tidak bisa dilewati sendiri oleh agen.
Anda tentu bisa membangun semua ini secara manual menggunakan worktree, konvensi penamaan, dan kedisiplinan alur kerja. Namun cara itu rentan runtuh begitu jumlah agen, tugas, dan repositori bertambah banyak. Jika Anda sudah menjalankan beberapa agen, Sharkly menyediakan satu tempat terpadu untuk mengelola tugas dan hasil kerja mereka: Task bersama, Assignee per Task, worktree yang terisolasi, serta alur status tempat Agen mencapai Ready for review dan Manusia menentukan status Done. Tetap gunakan coding agent pilihan Anda; tambahkan lapisan yang membuat proses handoff mereka terpantau jelas. Unduh Sharkly ketika celah transisi antar-agen mulai memakan biaya lebih besar daripada pekerjaan itu sendiri.
FAQ
Apa itu handoff agen AI? Handoff adalah proses pengalihan suatu tugas, beserta konteksnya dan sinyal bahwa giliran telah beralih ke pihak lain, dari satu pekerja ke pekerja berikutnya. Dua bentuk utamanya adalah antar-agen (sub-tugas yang telah selesai diteruskan ke agen berikutnya) dan agen-ke-manusia (pekerjaan otonom berhenti di gerbang peninjauan).
Apa perbedaan antara handoff antar-agen dan agen-ke-manusia? Handoff antar-agen seharusnya berlanjut secara otomatis ketika kriteria penerimaan langkah berikutnya sudah ditentukan. Sebaliknya, handoff agen-ke-manusia harus berhenti dan menunggu, karena manusia perlu mengambil keputusan: melakukan merge, mengubah kontrak API publik, atau menyetujui hasil akhir.
Bolehkah agen menandai pekerjaannya sendiri sebagai Done? Tidak. Biarkan Agen memindahkan Task ke Ready for review setelah menjalankan pengujian dan melampirkan ringkasan; serahkan pemindahan ke status Done, beserta keputusan merge, kepada manusia. Pemisahan kedua batasan inilah yang mencegah dirilisnya kode tanpa peninjauan. Lihat coding agent human-in-the-loop.
Bagaimana status mencegah pekerjaan terabaikan? Ketika handoff berupa perubahan status pada Task bersama—bukan sekadar pesan di terminal—pekerja berikutnya dapat melihat dengan jelas apa yang sedang menanti tindakan mereka. Tidak ada yang terlewat hanya karena lupa membaca riwayat terminal pada waktu yang tepat. Fitur Inbox agen secara otomatis menampilkan hal-hal yang membutuhkan perhatian Anda.
Apakah saya memerlukan alat khusus untuk ini, atau bisa dilakukan secara manual? Anda bisa menjalankannya dengan worktree dan papan tugas bersama. Namun, sistem khusus akan sangat bermanfaat begitu Anda mengoordinasikan banyak agen di beberapa repositori sekaligus, di mana pelacakan manual mulai menjadi kendala. Bandingkan model mental asisten versus rekan tim untuk membantu menentukan pilihan.
