Agen Selalu Merupakan Rekrutan Hari Pertama. Sudah Saatnya Kita Merancang untuk Hal Itu.

Pada tahun 2027, 74% perusahaan diperkirakan akan menggunakan agen dalam beberapa kapasitas, menurut sebuah studi Deloitte terbaru. Selama bertahun‑tahun, kami telah merancang dan membangun perangkat lunak untuk meningkatkan pengalaman manusia dalam menavigasi aplikasi, situs web, sistem operasi, dan dokumen kami. Sekarang, pengguna bukan lagi manusia sama sekali. Hal ini memiliki implikasi yang lebih luas selain beralih dari dasbor dan alur kerja terkontrol yang kami rancang untuk tugas manusia. Kita berada pada momen di mana kita perlu merancang lingkungan operasional agen, sambil juga merancang alur kerja manusia untuk secara efektif membimbing pengalaman agen dalam lingkungan tersebut.  

Kami masih berada pada tahap awal pembelajaran tentang apa yang sebenarnya dibutuhkan agen dari kami agar dapat berhasil secara berulang dan dapat diandalkan. Instingnya adalah memperlakukan integrasi agen semata‑mata sebagai masalah prompt atau antarmuka pengguna. Merancang lingkungan eksekusi yang terkelola dengan baik adalah wilayah baru bagi kami secara budaya. Namun, prinsip dasar desain yang baik dan manajemen yang baik tidak berubah: kami berutang kepada agen konteks yang jelas, arahan yang tidak ambigu, dan niat yang eksplisit.

Konteks: Mengapa Pengkodean Muncul Pertama

Konteks mungkin merupakan masukan paling penting jika kita menginginkan agen dapat memberikan hasil secara konsisten pada tingkat yang kita harapkan. Pengembangan perangkat lunak mencatatnya lebih banyak daripada hampir semua bidang lain: repositori, skema API, hubungan antar sistem, tinjauan kode, dan diskusi komunitas. Jadi tidak mengherankan bahwa laboratorium frontier AI memulai dengan pengkodean. Ini adalah salah satu dari sedikit domain di mana banyak konteks sudah dituliskan. 

Namun, seperti yang akan diberitahukan oleh setiap rekrutan baru di tim perangkat lunak, meskipun memiliki semua data tersebut, agen tetap akan kekurangan memori institusional yang tertanam dalam aturan tak tertulis yang tidak pernah didokumentasikan. Kesenjangan itu meluas: 43% pengembang khawatir bahwa alat AI kekurangan konteks yang memadai tentang proyek atau basis kode spesifik mereka. Pengetahuan tacit mencakup segala hal mulai dari konvensi sehari‑hari, seperti perpustakaan pilihan untuk tugas tertentu, hingga bayangan operasional berisiko tinggi: perbaikan mendadak larut malam yang terus bertahan selamanya, atau kolom basis data yang tampak kosong namun diam‑diam menjadi dasar laporan pendapatan khusus. Konteks ini berada di dalam kepala insinyur senior, dalam thread Slack terbaru, atau bahkan tidak ada sama sekali. Jarang sekali konteks ini terdapat dalam basis kode itu sendiri.  

Jika hal ini berlaku dalam perangkat lunak, salah satu bidang yang paling terdokumentasi, maka mudah dipahami mengapa agen kesulitan tampil efektif sejak hari pertama di banyak industri lain. Di bidang kesehatan dan hukum, sebagian besar pengetahuan institusional yang membentuk pekerjaan sehari‑hari dipelajari dan diinternalisasi. Pengetahuan itu hidup dalam pengalaman orang, bukan dalam dokumentasi formal. Agen hukum mungkin tidak mengetahui struktur, nada, atau cara argumentasi yang disukai oleh mitra tertentu untuk sebuah brief, sementara agen kesehatan mungkin tidak memahami alur kerja lokal dan praktik eskalasi yang digunakan klinik sibuk untuk mendukung triase yang dipimpin klinisi. Dokumentasi saja tidak dapat menutup kesenjangan itu, karena tantangannya bukan sekadar akses informasi; melainkan transfer konteks. Untuk memberi agen apa yang mereka butuhkan agar berhasil, kita harus mengintegrasikan mereka sebagaimana kita melakukannya pada rekrutan baru.

Arah: Mengapa Osmosis Tidak Berfungsi

Menyambut rekan tim baru memerlukan lebih dari sekadar menyediakan materi dan akses yang tepat. Ketika kami berinvestasi pada keberhasilan orang di sekitar kami, kami memberikan arahan yang kuat tentang apa yang harus dilakukan dengan materi dan akses baru: harapan, kejelasan tentang apa yang ingin dicapai, dan umpan balik sepanjang proses. Saya menerapkan pola pikir yang sama ini dalam merancang untuk agen. Saya memberikan arahan yang jelas dan spesifik (sesuai dengan tugas yang sedang dihadapi). Itu berlaku untuk setiap rekan tim, terlepas dari masa kerjanya. Namun, dalam skenario rekrutan baru, arahan harus lebih jauh, karena mereka belum memiliki konteks institusional.

Anggaplah agen sebagai rekrutan baru yang tidak pernah berhenti menjadi baru. Ia bersemangat dan mampu (dan sejujurnya, memiliki energi tak terbatas), namun tidak dapat menyerap dan menyimpan sebanyak aturan tak tertulis sebagaimana seseorang melakukannya seiring waktu. Manusia belajar melalui osmosis dan pengalaman, sementara agen belajar dari arsitektur yang secara eksplisit dibangun ke dalam lingkungan kerja mereka.

Dengan rekrutan baru, Anda dapat menutup kesenjangan tersebut seiring waktu melalui pertanyaan, umpan balik, dan wawasan baru yang mereka peroleh tentang proses dan preferensi organisasi. Misalnya percakapan di mesin kopi atau makan siang tim. Dengan agen, Anda harus membangun penutupan kesenjangan ke dalam desain itu sendiri. Ini dapat mencakup: 

• Memberikan agen jendela konteks terstruktur yang memisahkan aturan yang tahan lama, fakta spesifik tugas, dan riwayat relevan, alih-alih menumpahkan tumpukan dokumen ke dalamnya. 
• Mendefinisikan izin dan batas keputusan sejak awal: apa yang dapat dilakukannya secara mandiri, apa yang memerlukan persetujuan, dan apa yang tidak boleh diaksesnya. 
• Menyematkan beberapa contoh konkret hasil yang kuat langsung dalam pengalaman, sehingga agen memiliki model yang jelas tentang bagaimana pekerjaan harus dilakukan.
• Membagikan jalan buntu sebelumnya yang pernah Anda temui.

Merancang lingkungan agen yang terkelola dengan baik bukanlah untuk mempermudah kerja model. Ini tentang melindungi tim rekayasa manusia dari hutang teknis yang tak terlihat. Namun bahkan agen yang diarahkan dengan baik dapat mengikuti instruksi secara sempurna namun tetap melewatkan maksudnya. Arahan memberi tahu apa yang harus dilakukan, tetapi tidak memberi tahu seperti apa “yang baik”. Kesenjangan itulah tempat niat berperan.

Niat: Mengapa Agen Mengarah ke Tengah

Penting untuk diingat bahwa agen adalah mesin pencocokan pola, dilatih dengan sejumlah besar pengetahuan dan secara alami cenderung menghasilkan rata‑rata statistik. Tanpa niat yang jelas dan eksplisit, output rata‑rata tersebut adalah apa yang akan dihasilkan agen. Minta agen untuk “menambahkan endpoint otentikasi pengguna,” dan ia akan menghasilkan rute Express standar dengan hashing kata sandi dasar. Itu berfungsi, tetapi sepenuhnya mengabaikan layanan otentikasi kustom tim Anda, melewatkan telemetri yang diperlukan, dan merusak format error standar Anda. Itu adalah fitur yang memadai di atas kertas, tetapi tergantung pada konteks, itu menjadi bug arsitektural dalam praktik. Kemudahan munculnya “bug” seperti ini tidak dapat dilebih‑lebhikan.

Untuk mencegah hal ini, arahan harus dipasangkan dengan verifikasi niat yang aktif dan pencatatan. Batasan tidak boleh hanya memeriksa apakah kode dapat dikompilasi, meskipun hal itu penting. Batasan harus secara eksplisit menegakkan standar yang berpendirian, aturan kasus tepi, dan konteks domain yang mengubah output generik menjadi pekerjaan siap produksi. Pencatatan penting sebagai indikator status sistem bagi kami manusia. Keterlacakan ini sangat penting untuk kepercayaan. 

Dalam interaksi manusia, terdapat banyak ruang untuk ketidakpastian. Seseorang dapat membagikan versi pertama kepada Anda, dan bersama‑sama Anda dapat membahas apa yang kuat dan apa yang perlu diperbaiki. Ini berhasil karena kami tidak mengharapkan rekan kerja manusia kami menjadi mesin otonom. Untuk benar‑benar memanfaatkan kekuatan dan janji rekan kerja agen (yang memang perlu beroperasi lebih otonom…), kita dapat merancang banyak pemeriksaan arahan ini. Pertukaran balik tetap diperlukan, namun tidak dapat sepenuhnya bergantung pada upaya manual. Dengan menyiapkan kriteria penerimaan dan aturan verifikasi yang jelas di awal, Anda memungkinkan agen menjalankan siklus umpan balik internalnya sendiri. Merancang Pencegahan Kesalahan adalah prinsip UX yang kuat lainnya yang dapat kami terapkan di dunia baru ini: memberikan agen kemampuan untuk menandai rendahnya keyakinan sebelum melakukan tindakan, alih‑alih diam‑diam beralih ke tebakan terbaik.

Di Mana Metafora Gagal

Kerangka kerja rekrutan baru berfungsi, sampai tidak lagi. Dengan rekrut manusia, pengalaman menghasilkan kompetensi yang kemudian menghasilkan penilaian. Mengamati rekrutan baru Anda menginternalisasi “mengapa” di balik konteks dan arahan adalah apa yang membangun kepercayaan seiring waktu, dan secara umum, ini bersifat kumulatif. Agen tidak memiliki tempat untuk mengakumulasi dan menyimpan pengalaman ini.

Minggu pertama dan minggu ke‑seratus seorang rekrutan baru tampak berbeda. Tugas pertama dan tugas ke‑seribu seorang agen tampak identik, kecuali Anda merancang dan membangun sesuatu untuk membuatnya berbeda. Ini adalah tantangan desain baru kami.

Tanggung Jawab Agen Bergantung pada Desain

Jika tanggung jawab tidak dapat berada dalam agen, maka harus berada dalam kerangka di sekitarnya. Ini kembali ke tiga pertanyaan yang sama yang akan saya ajukan sebelum menyerahkan pekerjaan kepada rekrutan baru: Konteks apa yang mereka miliki? Arahan apa yang telah saya berikan? Apa niat sebenarnya saya?

Lain kali Anda menyerahkan tugas kepada agen, jangan hanya memeriksa hasilnya. Periksa masukan Anda terlebih dahulu. Apakah Anda memberikannya konteks yang dibutuhkan rekrutan baru pada hari pertama? Apakah arahan Anda cukup spesifik untuk bertahan bila diartikan secara harfiah? Apakah niat Anda cukup jelas sehingga “jawaban median” bukanlah yang terbaik yang dapat ia lakukan?

Dengan panduan jelas ini di tangan (dalam byte?), sesuatu yang menarik terjadi: sebuah agen tidak memerlukan jalur panjang untuk menjadi dapat dipercaya. Konteks, arahan, dan verifikasi yang Anda bangun di awal menentukan cara ia beroperasi pada setiap tugas. Seorang rekrutan baru memperoleh kepercayaan Anda seiring waktu; agen harus memperoleh kepercayaan itu setiap kali melalui sistem yang Anda rancang. Tanggung jawab bukan sesuatu yang berkembang, melainkan dibangun sejak awal. Pertanyaannya bukan kapan agen Anda akan siap untuk tanggung jawab lebih. Melainkan apakah Anda merancangnya untuk memperoleh tanggung jawab itu pada setiap tugas.