Protokol Serah Terima Terstruktur

Dalam sistem multi-agen hub-and-spoke, koordinator terus menerus menyerahkan pekerjaan kepada subagen dan menerima kembali hasilnya. Fakta yang CRITICAL: subagen NOT mewarisi riwayat percakapan koordinator — model tidak menyimpan keadaan, sehingga riwayat permintaan FULL dikirim dalam messages pada setiap giliran.

Artinya, setiap handoff harus membawa konteksnya sendiri secara eksplisit. Perintah tidak terstruktur seperti "perbaiki bug autentikasi" akan kehilangan ID kasus, hal-hal yang sudah dicoba, dan keputusan yang perlu dikembalikan kepada koordinator. Protokol handoff terstruktur mengatasi hal ini: setiap transfer membawa pengenal, ringkasan, tindakan yang telah dilakukan, dan rekomendasi.

Muatan handoff yang andal memiliki empat bidang, dan masing-masing mengatasi mode kegagalan tertentu:

• ID — kunci korelasi yang stabil (case_id, custom_id) agar hasil dapat dicocokkan dengan permintaan, bahkan pada pemanggilan paralel.
• Ringkasan — fakta transaksional secara verbatim yang diperlukan penerima (ID pelanggan terverifikasi, nomor pesanan, jumlah).
• Tindakan — hal-hal yang sudah dicoba, beserta hasilnya, agar pekerjaan tidak diulang.
• Rekomendasi — langkah atau keputusan berikutnya yang diusulkan dan harus dikonfirmasi atau ditolak oleh penerima.

Hal ini secara langsung sesuai dengan cara koordinator menguraikan, mendelegasikan, menggabungkan, dan merutekan pekerjaan.

Karena subagen dimulai dengan riwayat kosong, Anda tidak dapat mengandalkan asumsi "subagen sudah mengetahuinya". Masukkan handoff ke dalam prompt subagen itu sendiri. Perhatikan bahwa ID, ringkasan, dan tindakan sebelumnya dijelaskan secara terperinci — tidak ada yang diasumsikan.

Handoff berupa teks bebas mudah salah format. Untuk menjamin keempat bidang selalu ada, jadikan handoff sebagai alat dengan JSON Schema dan gunakan tool_choice untuk memaksa keluaran terstruktur. tool_use + JSON Schema menghilangkan kesalahan sintaks dan menegakkan bidang yang wajib.

Aturan utama dari lembar fakta: tandai suatu bidang sebagai required ONLY jika bidang tersebut selalu ada. id, summary, actions, dan recommendation selalu ada dalam handoff yang valid — jadi bidang-bidang tersebut memang wajib. Bidang opsional seperti escalation_reason MUST NOT diwajibkan, atau model akan mengarangnya.

Cara Anda mengatur tool_choice menentukan apakah Anda benar-benar mendapatkan handoff terstruktur:

• "auto" — model dapat menjawab dengan prosa, bukan handoff. Berisiko untuk protokol.
• "any" — model MUST memanggil suatu alat, sehingga keluaran terstruktur terjamin.
• {"type":"tool","name":"emit_handoff"} — memaksa penggunaan alat ini tepat. Gunakan ini saat tugas subagen adalah mengembalikan satu handoff yang terbentuk dengan baik.

ID memungkinkan koordinator menggabungkan hasil yang tiba tidak berurutan. Saat Anda mengeluarkan beberapa pemanggilan Task dalam satu respons, pemanggilan tersebut berjalan secara paralel — balasan tidak kembali dalam urutan saat dikirim. Tanpa kunci korelasi, Anda tidak dapat memetakan hasil ke permintaannya.

Ini adalah prinsip yang sama dengan custom_id milik Batch API, yang mengorelasikan permintaan sehingga Anda dapat mengirim ulang hanya yang gagal. Dalam alur multi-agen sinkron, id pada handoff Anda menjalankan peran tersebut.

Ringkasan adalah tempat handoff sering gagal tanpa disadari. Perangkuman progresif membuat angka, persentase, dan tanggal menjadi samar — padahal itulah bidang yang diperlukan penerima untuk bertindak ($420 berubah menjadi "beberapa ratus dolar"). Model juga lebih memperhatikan awal dan akhir konteks daripada bagian tengahnya (hilang di tengah).

Solusinya: pindahkan fakta transaksional ke dalam blok fakta kasus yang dipertahankan secara verbatim, di luar ringkasan prosa. Bidang summary pada handoff harus memuat fakta-fakta ini secara persis, bukan parafrasa yang menghilangkan rincian.

Bidang tindakan harus mencatat bukan hanya apa yang dijalankan, tetapi juga apa yang dikembalikan oleh setiap pemanggilan — dan harus membedakan FAILURE akses (mungkin dapat dicoba ulang) dari hasil EMPTY yang valid (tidak ada kecocokan, jangan coba ulang). Gunakan error terstruktur, bukan error generik.

Error terstruktur memuat isError, errorCategory (sementara / validasi / bisnis / izin), isRetryable, kueri yang dicoba, dan hasil sebagian. "Operasi gagal" yang generik menghambat pemulihan; konteks terstruktur memungkinkan penerima merutekan secara cerdas.

Bidang keempat adalah rekomendasi yang dapat dikonfirmasi atau ditolak oleh penerima — bukan tindakan sepihak. Ini menjaga wewenang pengambilan keputusan pada pihak yang tepat dan mendukung eskalasi yang tertata.

Pemicu eskalasi yang baik harus tercantum dalam rekomendasi: permintaan manusia yang eksplisit (segera eskalasikan), celah kebijakan, tidak ada kemajuan setelah beberapa percobaan, atau pelanggaran ambang batas. Pemicu BAD MUST NOT mengarahkannya: analisis sentimen, skor keyakinan yang dinilai sendiri oleh model, atau pengklasifikasi yang belum dilatih. Rekomendasi seperti "pelanggan terdengar frustrasi, eskalasikan" adalah pola yang harus dihindari.

Rekomendasi dalam handoff bersifat probabilistik — panduan prompt benar kira-kira 90% dari waktu. Jika tindakan berdasarkan handoff memiliki konsekuensi finansial, hukum, atau keselamatan, jaminannya harus deterministik, ditegakkan oleh hook, bukan oleh teks rekomendasi.

Hook panggilan keluar dapat memblokir tindakan yang melanggar kebijakan (misalnya pengembalian dana > $500), terlepas dari rekomendasi subagen. Prasyarat terprogram — memblokir process_refund sampai get_customer mengembalikan ID yang terverifikasi — memberikan jaminan yang tidak dapat diberikan prompt. Hook = 100% deterministik; prompt ≈ 90% probabilistik.

Terkadang handoff melanjutkan pekerjaan sebelumnya. --resume <name> melanjutkan sesi bernama, sedangkan fork_session membuat cabang dari titik bersama. Namun, berhati-hatilah: hasil alat yang dilanjutkan dapat bersifat STALE jika basis kode atau data berubah setelahnya.

Saat keadaan yang mendasarinya telah berubah, sesi baru yang diinisialisasi dengan handoff terstruktur (ID + fakta verbatim + tindakan + rekomendasi) sering kali lebih andal daripada melanjutkan sesi yang dipenuhi keluaran alat yang sudah usang. Handoff terstruktur membuat memulai ulang dengan bersih menjadi mudah.

Poin-poin penting:

• Subagen tidak mewarisi riwayat — setiap handoff membawa konteksnya sendiri secara eksplisit.
• Empat bidang: ID (mengorelasikan hasil paralel), ringkasan (fakta verbatim), tindakan (dengan error terstruktur), rekomendasi (konfirmasi/tolak).
• Paksa bentuknya dengan alat handoff + JSON Schema dan tool_choice; wajibkan hanya bidang yang selalu ada.
• Pertahankan angka dan tanggal secara verbatim dalam blok fakta kasus — perangkuman membuatnya samar.
• Dalam tindakan, bedakan kegagalan akses dari hasil kosong yang valid melalui errorCategory dan isRetryable.
• Gunakan hook deterministik untuk membatasi tindakan yang berkonsekuensi, jangan hanya mengandalkan rekomendasi.
• Jika keluaran alat yang dilanjutkan mungkin sudah usang, mulai ulang dengan handoff terstruktur.