τ^τ-Bench: konfigurasi agen coding terbaik lolos 23,9%

τ^τ-Bench menunjukkan bahwa menghasilkan kode yang dapat dijalankan belum sama dengan membangun agen layanan pelanggan yang siap dipakai. Dalam pembahasan AI Understanding pada 7 September 2026, konfigurasi agen coding terbaik dilaporkan hanya lolos 23,9% simulasi evaluasi, sedangkan referensi buatan ahli mencapai 82,2%.

Prapublikasi τ^τ-Bench diajukan ke arXiv pada 4 September 2026 oleh Quan Shi, Keshav Dhandhania, Karthik Narasimhan, dan Victor Barres, dengan afiliasi Sierra dan Princeton University. Penelitian itu mencakup 53 tugas di empat domain dan menilai proses lengkap: memulihkan kebutuhan dari catatan bisnis dan klien simulasi, bekerja dengan API serta codebase, membangun sistem, lalu mengujinya melalui percakapan pengguna yang sebelumnya disembunyikan.

Benchmark menguji proyek layanan dari kebutuhan hingga hasil pengguna

Alur τ^τ-Bench mengubah catatan bisnis, kebutuhan klien, API, dan codebase menjadi agen layanan yang diuji lewat percakapan simulasi.

Setiap tugas memberi agen pengembang kombinasi bahan yang menyerupai proyek klien: dokumen operasional, transkrip dukungan, spreadsheet, surel, materi visual atau rekaman, persyaratan yang hanya diketahui klien simulasi, REST API milik klien, serta codebase kosong atau warisan. Agen juga harus memilih dari daftar model yang tersedia dan mematuhi batas biaya rata-rata per percakapan.

Hasil pembangunan tidak dinilai hanya dari keberhasilan kompilasi atau berjalannya program. Agen layanan ditempatkan dalam percakapan dengan pengguna simulasi yang memiliki tujuan tersembunyi, seperti membatalkan penerbangan atau menyanggah biaya. Tugas dianggap berhasil bila keadaan akhir basis data dan informasi yang disampaikan kepada pengguna sesuai dengan hasil yang telah dianotasi; pengeluaran di atas anggaran dapat mengurangi skor.

Perbedaan itu menjelaskan mengapa hasilnya tidak dapat disamakan dengan benchmark penulisan kode biasa. Dalam τ^τ-Bench, spesifikasi belum tersedia sebagai daftar persyaratan yang rapi. Menentukan aturan, menemukan informasi yang hilang, dan memutuskan apa yang perlu ditanyakan kepada klien merupakan bagian dari pekerjaan yang diukur.

Skor 23,9% melekat pada konfigurasi dan lingkungan tertentu

Konfigurasi terkuat dalam eksperimen adalah Claude Opus 5 yang dijalankan melalui Claude Code. Angka 23,9% bukan tingkat keberhasilan universal model tersebut ataupun seluruh agen coding, melainkan skor gabungan model dan harness itu pada rangkaian tugas, simulator, batas model, anggaran, serta prosedur penilaian τ^τ-Bench.

Pembanding 82,2% juga bukan rata-rata kemampuan pengembang manusia. Peneliti menyebutnya sebagai reference ceiling: konfigurasi terbaik untuk setiap tugas yang dibuat melalui kolaborasi seorang ahli dengan model. Ahli tersebut merupakan penulis benchmark dan memiliki akses ke kebenaran dasar yang justru harus dipulihkan oleh agen pengembang.

Komposisi tugas ikut membatasi pembacaan angka agregat. Domain penerbangan, ritel, dan telekomunikasi masing-masing memiliki enam tugas, sedangkan perbankan menyumbang 35 dari total 53 tugas. Konfigurasi terbaik memperoleh 55,9% pada penerbangan, 72,8% pada ritel, 48,2% pada telekomunikasi, tetapi hanya 5,9% pada perbankan, domain yang menurut peneliti memuat jauh lebih banyak fakta operasional.

Kegagalan utama terjadi di sekitar kode

Pemahaman catatan dan klarifikasi klien yang tidak lengkap berujung pada hasil layanan serta keadaan basis data yang salah.

Analisis lintasan kerja menemukan bahwa agen memang mencari kumpulan bukti, tetapi sering menggunakan pencarian kata kunci sebagai pengganti pembacaan mendalam. Pendekatan itu dapat melewatkan aturan yang tersimpan dalam transkrip, pengecualian yang disebut dengan istilah berbeda, atau hubungan antara beberapa catatan.

Komunikasi dengan klien juga sangat terbatas. Pada tugas yang menempatkan sebagian kebutuhan hanya pada klien simulasi, pengembang mengajukan paling banyak empat pertanyaan, padahal 20–25 persyaratan hanya dapat ditemukan melalui percakapan tersebut. Dalam seluruh panggilan alat yang direkam, komunikasi dengan klien hanya menyumbang 0,3%.

Masalah lain muncul pada integrasi, rancangan, dan biaya. Agen lebih mudah mengenali kegagalan API yang terlihat jelas daripada cacat diam-diam seperti hasil pencarian yang masih berlanjut di balik cursor. Hampir semua pembangunan berakhir sebagai satu loop model dengan alat, sementara 21 pembangunan melampaui anggaran dan penggunaan anggaran yang terlalu rendah justru lebih umum secara rata-rata.

Pengujian mandiri tidak selalu mengoreksi kesalahan itu. Bila pemahaman awal terhadap kebijakan sudah keliru, agen dapat menulis skenario yang mengabadikan asumsi yang sama. Benchmark menahan evaluasi akhir dan tujuan pengguna dari agen selama pembangunan, sehingga sistem diuji terhadap perilaku yang tidak dirancangnya sendiri.

Skor benchmark dapat diubah menjadi syarat penerimaan

Uji penerimaan memeriksa kebutuhan bisnis, klarifikasi klien, integrasi API, alternatif arsitektur, biaya serving, dan hasil pengguna.

Bagi perusahaan yang hendak memakai agen coding untuk membangun layanan pelanggan, hasil ini lebih berguna sebagai dasar uji penerimaan sistem daripada sebagai peringkat model tunggal. Skor 23,9% tidak memprediksi hasil perusahaan tertentu, tetapi desain benchmark menunjukkan bagian proyek yang perlu memiliki bukti penerimaan tersendiri.

Pemahaman catatan bisnis: aturan dan pengecualian penting dapat ditelusuri ke dokumen, transkrip, atau data operasional yang mendasarinya.
Klarifikasi kebutuhan: agen mengenali informasi yang hilang, mengajukan pertanyaan yang relevan, dan memasukkan jawaban pemangku kepentingan ke perilaku layanan.
Integrasi sistem: pengujian mencakup perubahan skema, pagination, operasi asinkron, serta penulisan data yang berhasil tetapi diikuti timeout.
Eksperimen arsitektur: lebih dari satu rancangan atau konfigurasi dibandingkan pada skenario yang sama sebelum implementasi dipilih.
Batas biaya: kualitas percakapan dan biaya rata-rata penyajian dinilai bersama, termasuk penalti ketika batas terlampaui.
Pengujian pengguna: skenario akhir disusun atau ditinjau secara independen dari agen pembangun dan memeriksa pesan kepada pengguna sekaligus perubahan data.

Checklist tersebut mempertahankan cakupan asli τ^τ-Bench: keberhasilan bukan hanya repositori yang berjalan, melainkan kesesuaian antara kebutuhan bisnis, implementasi, integrasi, biaya operasional, dan hasil yang diterima pengguna.

Temuan masih berupa prapublikasi dan hasil simulasi

τ^τ-Bench masih merupakan prapublikasi arXiv versi pertama. Penelitian ini belum menunjukkan bahwa pengguna simulasi selalu mewakili perilaku pelanggan nyata, bahwa skor tersebut berlaku di luar empat domain yang diuji, atau bahwa konfigurasi yang sama akan memperoleh hasil serupa pada codebase dan data perusahaan tertentu.

Belum ada validasi independen atas hasil eksperimen atau bukti hubungan langsung antara skor simulasi dan kinerja produksi. Replikasi, pengujian lebih banyak model dan harness, perluasan domain, serta evaluasi bersama pengguna nyata masih diperlukan. Untuk saat ini, kesimpulan yang didukung data lebih sempit tetapi penting: konfigurasi terbaik dapat menghasilkan agen yang berjalan, namun sebagian besar skenario tetap gagal ketika pemahaman bisnis, komunikasi, integrasi, perilaku pengguna, dan biaya dinilai sebagai satu sistem.

Agen coding hanya lolos 23,9%—membangun agen layanan masih jauh dari selesai