Agen penelitian menemukan akun pelanggan, mengonfirmasi paket, dan mengambil empat faktur terakhir. Agen itu menyerahkannya kepada agen penagihan dengan ringkasan satu baris: "Pelanggan ingin pengembalian dana." Agen penagihan, yang sekarang tidak tahu apa-apa tentang akun, paket, atau faktur, mulai dengan menanyakan ID akun.
Setiap fakta yang dikumpulkan agen pertama dibuang di batas serah terima. Itulah masalah serah terima, dan itu merugikan Anda dua kali: sekali dalam panggilan API yang diduplikasi, sekali dalam kesalahan yang berasal dari agen kedua yang bekerja dengan informasi lebih sedikit daripada agen pertama.
Panduan ini mencakup apa yang harus tetap ada setelah serah terima, tiga cara tim meneruskan status dan kapan masing-masing berfungsi, mengapa ringkasan kehilangan lebih banyak dari yang orang duga, dan cara menguji bahwa serah terima membawa apa yang diklaimnya. Postingan kami tentang mengapa agen gagal dalam produksi menganggap status yang hilang sebagai mode kegagalan inti; ini adalah versi multi-agennya.
Apidog muncul karena perbaikan termurah biasanya adalah berhenti meneruskan data sama sekali dan meneruskan pengenal saja, yang hanya berfungsi jika setiap agen dapat mengambil catatan yang sama dengan cara yang sama.
Apa yang sebenarnya perlu melewati batas
Tidak semuanya. Serah terima yang menyalin seluruh percakapan sama rusaknya dengan yang tidak menyalin apa pun, hanya saja dalam arah yang berlawanan: agen kedua mewarisi jendela konteks penuh dan harus mencari tahu bagian mana yang penting.
Empat kategori patut dipisahkan.
Pengenal. ID akun, ID pesanan, ID pekerjaan, nomor tiket. Ini kecil, stabil, dan memungkinkan agen penerima mengambil apa pun yang dibutuhkan. Ini adalah hal yang paling berharga untuk diteruskan dan yang paling sering dihilangkan.
Keputusan yang sudah dibuat. "Pelanggan berhak mendapatkan pengembalian dana berdasarkan kebijakan 3." Agen penerima tidak boleh membahas kembali ini. Jika itu terjadi, Anda akan mendapatkan dua agen yang tidak setuju dalam satu tugas.
Batasan. Batas anggaran, persetujuan yang diberikan, tindakan yang sudah diambil. Kehilangan ini adalah bagaimana suatu tugas berakhir dengan menagih dua kali atau meminta persetujuan yang sama untuk kedua kalinya. Ini berpasangan langsung dengan postingan kami tentang idempotensi untuk agen AI.
Pertanyaan terbuka. Apa yang tidak dapat diselesaikan oleh agen pertama. Meneruskan ini secara eksplisit menghentikan agen kedua dari asumsi diam-diam.
Apa yang tidak perlu dilintasi: respons API mentah, transkrip penalaran, dan apa pun yang dapat diambil oleh agen penerima sendiri dalam satu panggilan.
Tiga cara meneruskan status
Teruskan seluruh percakapan. Sederhana, dan berfungsi untuk dua agen dalam satu tugas singkat. Ini gagal segera setelah transkrip panjang, karena agen penerima menghabiskan sebagian besar anggarannya untuk membaca riwayat dan fakta yang relevan terkubur di tengah. Postingan kami tentang menjaga respons alat tetap di luar jendela konteks menjelaskan mengapa bagian tengah itulah tempat model kehilangan sesuatu.
Teruskan ringkasan. Agen pertama menulis pesan serah terima; yang kedua memulai dari sana. Ini adalah default di sebagian besar kerangka kerja dan bersifat hilang dengan cara tertentu: model meringkas ke arah narasi dan menjauhi pengenal. Mintalah ringkasan dan Anda akan mendapatkan "pelanggan telah berlangganan selama dua tahun dan frustrasi" alih-alih "akun 8812, paket pro, empat faktur, pengembalian dana disetujui untuk faktur inv_44."
Teruskan objek serah terima terstruktur. Agen pertama mengisi skema. Agen kedua membaca bidang, bukan prosa. Ini membutuhkan lebih banyak pekerjaan untuk disiapkan dan inilah yang bertahan.
{
"task_id": "task_2026_08_26_0031",
"from_agent": "research",
"to_agent": "billing",
"entities": {
"customer_id": "cus_8812",
"invoice_ids": ["inv_41", "inv_42", "inv_43", "inv_44"],
"subscription_id": "sub_119"
},
"decisions": [
{ "decision": "refund_eligible", "value": true, "basis": "policy 3.2, charged twice in one cycle" }
],
"constraints": {
"max_refund_cents": 4900,
"human_approval_granted": false,
"actions_taken": ["read_invoices"]
},
"open_questions": ["Customer has not confirmed which invoice to refund"],
"summary": "Customer cus_8812 was double-charged in August. Refund of one invoice is approved under policy 3.2, up to 4900 cents. Awaiting the customer's choice of invoice."
}
Prosa masih muncul, di bidang summary, karena membawa nuansa yang tidak dimiliki skema. Ini berada di samping bidang terstruktur daripada menggantikannya, yang merupakan intinya.
Validasi objek sebelum serah terima berjalan. Jika customer_id hilang, gagal secara jelas di batas daripada membiarkan agen kedua menemukannya tiga panggilan kemudian.
Teruskan referensi, bukan payload
Versi terkuat dari serah terima hampir tidak meneruskan data. Ini meneruskan ID, dan agen penerima mengambil apa yang dibutuhkan.
Ini berfungsi karena tiga alasan. Status tetap segar, jadi jika ada perubahan antara kedua agen, yang kedua melihat nilai saat ini daripada salinan yang kedaluwarsa. Serah terima tetap kecil, beberapa ratus byte alih-alih puluhan ribu token. Dan jejak audit meningkat, karena setiap pembacaan muncul sebagai panggilan API daripada sebagai teks yang disalin antar prompt.
Ini membutuhkan satu hal: setiap agen dapat mencapai API yang sama dengan izin yang benar. Itu tidak gratis. Setiap agen membutuhkan kredensialnya sendiri yang dicakupkan pada apa yang dilakukannya, yang merupakan argumen dalam postingan kami tentang kunci API hak istimewa terkecil untuk agen. Agen penagihan yang memegang token penelitian hanya-baca tidak dapat mengeluarkan pengembalian dana, dan agen penelitian yang memegang token penagihan adalah masalah radius ledakan.
Di mana pengambilan ulang akan mahal atau lambat, cache catatan di orchestrator Anda dan berikan referensi ke entri cache. Agen penerima masih meminta data secara eksplisit, jadi pola tetap sama, tetapi pembacaan kedua murah.
Di mana serah terima sebenarnya rusak
Empat kegagalan mencakup sebagian besar insiden.
Pengenal yang hilang. Ringkasan mengatakan "pelanggan" dan tidak pernah memberikan ID, jadi agen kedua mencari berdasarkan nama, menemukan dua kecocokan, dan memilih yang salah. Cegah ini dengan memvalidasi bahwa ID entitas yang diperlukan ada sebelum serah terima diizinkan untuk dilanjutkan.
Tindakan berulang. Agen pertama sudah mengirim email. Serah terima tidak mencatatnya. Agen kedua mengirimnya lagi. Catat actions_taken dalam objek serah terima dan periksa sebelum penulisan apa pun, didukung oleh kunci idempotensi yang membuat pengulangan tidak berbahaya.
Persetujuan yang hilang. Seorang manusia menyetujui pengembalian dana saat agen pertama sedang berjalan. Agen kedua, tidak mengetahui hal ini, bertanya lagi. Pengguna membaca prompt kedua sebagai sistem yang tidak mendengarkan. Bawa persetujuan sebagai batasan eksplisit, dan perlakukan sebagai dicakupkan pada tugas daripada pada agen.
Penemuan yang percaya diri. Agen penerima membutuhkan nilai yang tidak dibawa oleh serah terima, dan daripada bertanya, ia menciptakan satu yang sesuai dengan narasi. Ini adalah kegagalan paling berbahaya karena terlihat seperti tugas yang selesai. Pertahanan adalah bidang open_questions ditambah aturan keras dalam prompt agen penerima: jika pengenal yang diperlukan tidak ada, berhenti dan tanyakan.
Perulangan membuat keempatnya lebih buruk. Ketika agen A menyerahkan ke B dan B menyerahkan kembali ke A, status membusuk pada setiap lintasan, seperti fotokopi dari fotokopi. Batasi jumlah hop dan bawa objek tugas asli melalui setiap hop daripada membangunnya kembali di setiap batas.
Uji batas, bukan hanya agen
Serah terima adalah titik integrasi, jadi uji sebagai titik integrasi.
Tegaskan pada objek serah terima. Jalankan agen pertama terhadap skenario tetap dan periksa objek yang dihasilkannya: pengenal yang diperlukan ada, keputusan dicatat, tindakan terdaftar. Ini adalah pernyataan deterministik pada payload terstruktur meskipun agen yang menghasilkannya tidak deterministik, itulah yang menjadikannya tes yang dapat digunakan. Pendekatan umum ada dalam panduan kami untuk menguji agen AI non-deterministik.
Uji penerima secara terpisah. Berikan objek serah terima buatan tangan kepada agen penagihan dan periksa apa yang dilakukannya. Kemudian berikan objek yang sengaja rusak, dengan ID pelanggan dihapus, dan konfirmasikan bahwa ia bertanya alih-alih menebak. Tes kedua ini adalah yang menangkap penemuan.
Jalankan keduanya terhadap mock. Tes serah terima yang mengeluarkan pengembalian dana nyata adalah tes yang akan Anda jalankan sekali. Arahkan kedua agen ke titik akhir tiruan sehingga suite dapat berjalan pada setiap perubahan, mengikuti postingan kami tentang menjalankan agen terhadap mock alih-alih produksi. Di Apidog mock berasal dari definisi API yang sama yang dipanggil kedua agen, sehingga keduanya tidak pernah terpisah.
Catat setiap serah terima. Rekam objek lengkap di setiap batas dengan ID tugas. Ketika sebuah eksekusi multi-agen salah, log serah terima memberi tahu Anda agen mana yang memiliki informasi dan agen mana yang kehilangannya, yang biasanya merupakan seluruh investigasi. Postingan kami tentang melacak panggilan alat agen mencakup apa lagi yang termasuk dalam catatan itu.
Apa yang diberikan oleh kerangka kerja kepada Anda
Sebagian besar kerangka kerja orkestrasi mengirimkan primitif serah terima, dan ada baiknya untuk mengetahui apa yang sebenarnya dipindahkan oleh masing-masing kerangka kerja melintasi batas sebelum Anda mengandalkannya.
Dokumentasi serah terima OpenAI Agents SDK memodelkan serah terima sebagai alat yang dapat dipanggil agen, yang berarti model memutuskan kapan kontrol berpindah. Itu nyaman, dan itu menempatkan keputusan di bagian paling tidak deterministik dari sistem Anda, jadi pasangkan dengan validasi saat keluar.
Panduan multi-agen LangGraph mengambil pendekatan yang berlawanan: status adalah objek grafik eksplisit yang dibaca dan ditulis oleh setiap node. Ini sangat mirip dengan serah terima terstruktur yang dijelaskan di atas, dan pekerjaan utama yang tersisa bagi Anda adalah memutuskan bidang mana yang diperlukan.
Tulisan Anthropic tentang membangun sistem penelitian multi-agen layak dibaca untuk detail operasionalnya, terutama tentang seberapa banyak instruksi yang dibutuhkan sub-agen sebelum dapat bekerja secara berguna sendiri.
Inti umumnya: setiap kerangka kerja akan memindahkan sesuatu. Tidak ada yang memutuskan untuk Anda fakta mana yang menjadi penentu beban. Daftar itu adalah milik Anda untuk ditulis, dan itulah hal yang patut ditinjau ketika sebuah eksekusi berjalan salah.
Jaga objek tugas di luar percakapan
Satu perubahan struktural mencegah seluruh keluarga bug. Simpan status tugas di suatu tempat yang tahan lama, diindeks berdasarkan ID tugas, dan minta setiap agen membaca dan menulisnya daripada meneruskannya melalui pesan.
Percakapan adalah wadah yang buruk untuk status. Itu dipadatkan, dipotong, dan ditulis ulang oleh ringkasan, dan tidak ada operasi tersebut yang tahu bidang mana yang tidak dapat Anda rugi. Sebuah baris dalam database tidak memiliki masalah itu.
Pola ini kecil. Pada awal giliran, agen memuat objek tugas. Ketika mengambil tindakan, ia menambahkan ke actions_taken dan menyimpan. Saat serah terima, ia meneruskan ID tugas, dan agen penerima memuat objek yang sama. Tidak ada yang penting yang berjalan dalam prompt, jadi tidak ada yang penting yang bisa diringkas.
Ini juga memberi Anda titik melanjutkan. Jika sebuah eksekusi mati pada langkah keempat, objek tugas masih menyimpan semua yang ditetapkan oleh tiga langkah pertama, dan percobaan ulang dimulai dari sana alih-alih dari nol.
Di mana platform dapat menyimpan status
Jika agen Anda berjalan sebagai runtime CLI di mesin pengembang, objek tugas tahan lama yang dijelaskan di atas adalah sesuatu yang Anda bangun. Beberapa platform manajemen pekerjaan agen sudah memodelkannya, dan ada baiknya untuk mengetahui seperti apa itu sebelum Anda menulis sendiri.
Sharkly adalah sistem manajemen pekerjaan untuk orang dan agen yang dibangun di sekitar unit ini. Sebuah Tugas membawa tujuan, status, orang yang bertanggung jawab, Agen atau Kru yang ditugaskan untuk melaksanakannya, komentar, dan status eksekusi serta hasil agen. Sebuah Kru memasangkan Agen pemimpin dengan Agen dan orang lain, sehingga tugas yang membutuhkan beberapa spesialis ditugaskan ke grup yang dapat digunakan kembali daripada diteruskan tangan ke tangan melalui prompt. Karena status berada pada Tugas daripada dalam percakapan, serah terima antara dua agen tidak bergantung pada salah satunya yang meringkas dengan baik.
Runtime tetap apa pun yang sudah Anda gunakan. Claude Code, Codex, dan sisanya menjalankan pekerjaan pada Komputer yang Anda daftarkan; platform menyediakan catatan tugas, penugasan, dan lingkaran peninjauan di sekitarnya. Jika Anda membangun pola tugas tahan lama sendiri, dokumentasi Sharkly adalah referensi yang berguna untuk bidang mana yang ternyata penting.
Daftar periksa untuk serah terima
- Skema yang ditentukan ada untuk serah terima, dan divalidasi di batas.
- Pengenal entitas adalah bidang wajib, bukan opsional.
- Keputusan membawa dasar pemikirannya, sehingga penerima tidak mengulang penalaran.
- Tindakan yang sudah diambil dicatat dan diperiksa sebelum penulisan apa pun.
- Persetujuan dan anggaran berjalan dengan tugas, bukan dengan agen.
- Pertanyaan terbuka eksplisit, dan penerima bertanya daripada mengasumsikan.
- Data diteruskan melalui referensi di mana pengambilan ulang murah.
- Jumlah lompatan dibatasi, dan objek tugas asli bertahan di setiap lompatan.
- Setiap serah terima dicatat dengan ID tugas.
- Tes batas berjalan di CI terhadap mock, termasuk serah terima yang sengaja tidak lengkap.
Sebagian besar kegagalan multi-agen bukanlah kegagalan penalaran. Mereka adalah fakta yang ada di satu agen dan tidak ada di agen berikutnya. Rancang batas sebagai antarmuka, dengan skema dan tes, dan agen kedua berhenti menanyakan pertanyaan yang sudah dijawab oleh agen pertama. Unduh Apidog untuk menjaga mock dan tes batas di samping API yang diandalkan kedua agen.
Pertanyaan yang sering diajukan
Apakah serah terima terstruktur sepadan untuk dua agen? Untuk dua agen dalam tugas singkat, meneruskan percakapan biasanya baik-baik saja. Objek terstruktur menjadi sangat berharga pada tiga agen atau lebih, pada tugas yang panjang, atau di mana pun serah terima melintasi proses atau batas eksekusi.
Haruskah model menulis objek serah terima atau haruskah kode membangunnya? Kode di mana pun bisa. Pengenal, tindakan yang diambil, dan persetujuan harus diisi oleh orchestrator Anda dari apa yang sebenarnya terjadi, bukan dari ingatan model. Biarkan model hanya menulis summary dan pertanyaan terbuka.
Bagaimana cara menghentikan peluruhan konteks dalam sebuah perulangan? Bawa satu objek tugas melalui seluruh eksekusi dan perbarui, daripada membuatnya kembali di setiap batas. Kemudian batasi lompatan. Jika sebuah tugas membutuhkan lebih dari beberapa lompatan, dekomposisinya mungkin salah.
Bagaimana dengan kerangka kerja dengan dukungan serah terima bawaan? Gunakan, dan periksa apa yang sebenarnya mereka transfer. Banyak yang meneruskan riwayat pesan dan tidak ada yang lain, yang berarti pengenal bertahan hanya jika kebetulan muncul dalam teks. Tambahkan payload terstruktur di samping apa pun yang dibawa kerangka kerja.
Apakah sub-agen memerlukan kredensial API terpisah? Ya, dicakupkan pada apa yang dilakukan masing-masing. Berbagi satu kunci yang kuat di seluruh agen menghilangkan kemampuan Anda untuk membatasi kerusakan dan untuk mengetahui agen mana yang melakukan panggilan. Postingan kami tentang kunci API hak istimewa terkecil untuk agen mencakup penyiapan.
Seberapa banyak bidang ringkasan harus berisi? Beberapa kalimat, mencakup niat dan nuansa yang tidak dapat ditampung oleh bidang terstruktur. Jika mulai mencantumkan ID dan jumlah, itu termasuk dalam bidang terstruktur di mana dapat divalidasi.