Apa itu penggunaan komputer dan mengapa hal tersebut penting? Penggunaan komputer adalah gagasan sederhana dengan implikasi luas: alih-alih meminta model menjawab pertanyaan, kita memintanya mengoperasikan perangkat lunak—menjelajahi situs web, mengisi formulir, mengklik berbagai tahap alur kerja, dan menyelesaikan tugas secara otonom dari awal hingga akhir.
Hal ini membuka peluang untuk menangani banyak jenis tugas di dunia nyata yang saat ini terfragmentasi di berbagai antarmuka, seperti pemesanan dari awal hingga akhir, checkout e-commerce, perencanaan perjalanan bertahap, dan alur kerja back-office yang tidak memiliki padanan API yang memadai. Masalah-masalah ini bukanlah hal baru. Yang baru adalah kelayakan untuk menyelesaikannya dengan model serbaguna.
Sistem terbaru dari Anthropic dan OpenAI telah memperlihatkan agen yang tidak hanya bertindak, tetapi juga menalar status, memulihkan diri dari kesalahan, dan menyusun solusi khusus untuk tugas secara langsung. Hal ini menjadikan browser sebagai lingkungan eksekusi umum bagi agen, tetapi langsung memunculkan pertanyaan desain: seberapa banyak bagian lingkungan tersebut yang perlu kita paparkan kepada model?
Sistem generasi awal menjawabnya dengan membungkus browser ke dalam serangkaian tindakan aman yang telah ditentukan. Seperti yang akan kami uraikan dalam tulisan ini, pendekatan tersebut mulai mencapai batasnya.
Ada naluri yang lazim saat membangun agen browser: jangan terlalu memercayai model.
Karena itu, kita membungkus browser. Kita menyediakan alat yang telah ditentukan seperti click, type, scroll, select, dan read_text. Kita menyederhanakan Document Object Model (DOM). Kita mempersempit ruang tindakan. Kita berupaya membuat perilaku mudah dipahami dan dikendalikan melalui abstraksi yang kita rancang.
Ini merupakan titik awal yang masuk akal. Namun, pendekatan ini juga semakin menjadi arsitektur jangka panjang yang keliru.
Seiring peningkatan model terdepan, keterbatasannya bukan lagi sekadar model yang kekurangan alat. Masalahnya, kita memaksa model beroperasi melalui abstraksi yang menghilangkan terlalu banyak bagian dari sistem dasarnya. Kita memadatkan lingkungan yang kompleks dan dinamis menjadi antarmuka tindakan tetap, lalu meminta model bekerja dengan baik di tengah hilangnya informasi tersebut.
Kompromi tersebut semakin tidak menarik.
Pergeseran yang kami jajaki mudah dijelaskan, tetapi berdampak besar. Alih-alih memperlakukan agen sebagai pemilih tindakan yang telah ditentukan, kami memperlakukannya sebagai penyintesis program yang beroperasi dalam runtime terbatas.
Kemampuan model telah meningkat pesat sehingga model tidak lagi memerlukan pagar pengaman abstrak buatan Anda—model memerlukan ruang tindakan lengkap untuk merancang, mengeksekusi, dan mengulangi tugas hingga tujuannya tercapai.
Tulisan ini membahas pergeseran dari otomatisasi browser yang sarat abstraksi menuju penggunaan komputer yang dibatasi, serta perubahan yang terjadi ketika sistem dirancang dengan cara ini.
Masalahnya bukan karena konsep antarmuka tindakan tetap itu keliru. Masalahnya adalah web tidak dapat mengakomodasinya.
Antarmuka modern dibangun dengan React, Vue, dan Angular, disertai pembaruan status asinkron, sistem peristiwa sintetis, serta widget pihak ketiga tersemat yang berada dalam iframe lintas origin dan memiliki siklus hidup sendiri. Wrapper yang memerintahkan “ketik ke dalam input ini” hanya akan berfungsi jika definisi halaman tentang mengetik sesuai dengan definisi Anda. Banyak halaman tidak demikian. Menetapkan nilai secara langsung sering kali sepenuhnya melewati deteksi perubahan milik framework. Input tampak sudah terisi. Validasi tidak pernah terpicu. Formulir tetap tidak berfungsi.
Anda dapat menambalnya. Anda dapat menambahkan penanganan khusus untuk input React, mengirimkan peristiwa blur setelah focus, dan menunggu jaringan tidak aktif sebelum membaca status. Setiap tambalan tepat untuk kasusnya masing-masing. Secara keseluruhan, tambalan tersebut menumpuk menjadi sistem yang makin sulit dipelihara dan makin spesifik untuk situs yang pernah Anda temui.
Masalah yang lebih mendasar adalah Anda mengodekan asumsi tentang cara kerja interaksi ke dalam lapisan abstraksi, lalu mendapati bahwa web memiliki asumsi yang berbeda.
Bayangkan formulir pembayaran yang disematkan melalui Stripe atau Adyen di dalam iframe lintas origin. Wrapper Anda tidak dapat mengaksesnya secara langsung karena formulir tersebut berada di origin yang berbeda. Alat read_text Anda tidak dapat mengamati status internalnya. Alat type Anda tidak dapat mengakses inputnya. Agen berbasis wrapper menemui jalan buntu di sini. Abstraksi tersebut dirancang untuk dokumen utama. Tugas sebenarnya berada di tempat yang tidak dapat dilihat oleh abstraksi.
Ketidakcocokan serupa muncul dalam alur yang tidak begitu kentara. Menu tarik-turun yang dikendalikan framework mungkin sama sekali tidak merespons klik langsung karena elemen yang terlihat bukanlah kontrol yang sebenarnya. Menu tersebut mungkin memerlukan serangkaian peristiwa papan ketik untuk memicu transisi status yang mendasarinya. Dari luar, UI tampak dapat diklik. Abstraksi memerintahkan “klik”. Tidak terjadi apa-apa.
Atau bayangkan alur modal bertahap ketika pembaruan DOM yang terlihat tertinggal dari perubahan status internal. Tindakan berikutnya yang tepat bergantung pada transisi status yang belum tercermin dalam elemen yang dapat dilihat wrapper Anda. Agen berbasis wrapper akhirnya bertindak terlalu dini atau membaca status lama karena beroperasi dengan gambaran sistem yang tidak lengkap.
Dalam setiap kasus, abstraksi menyembunyikan sinyal yang sebenarnya diperlukan agen.
Model yang beroperasi pada tingkat lebih rendah—memeriksa DOM aktif, menalar batas frame, dan menyintesis urutan interaksi untuk permukaan tertentu—dapat menangani situasi ini. Bukan berarti model tersebut pada dasarnya lebih cerdas. Model hanya memiliki akses ke informasi yang sebelumnya dihilangkan.
Perubahan yang tengah kami upayakan mudah dijelaskan: alih-alih meminta model memilih tindakan yang telah ditentukan, kami memberinya permukaan eksekusi tingkat rendah dan membatasi permukaan tersebut melalui kebijakan runtime, bukan desain abstraksi.
Pilihan desain ini lahir dari pergeseran industri yang lebih luas menuju alat primitif tingkat rendah—alat yang memanfaatkan kemampuan bawaan agen untuk melakukan koreksi saat runtime dan menghasilkan kode berkualitas tinggi, alih-alih alat khusus yang ditanamkan dalam kode dan andal tetapi menghilangkan kemampuan model untuk beradaptasi dengan lingkungan berbeda.
Pertimbangkan keberhasilan Claude Code sebagai pilihan utama dalam perangkat kerja banyak pengembang, serta pergeseran industri secara umum menuju agen berbasis terminal. Keunggulan terbesar Claude Code bukanlah modelnya, melainkan harness tingkat rendahnya. Memberikan lebih sedikit alat yang lebih modular dan berada di tingkat lebih rendah kepada model—yaitu terminal—menghasilkan performa pemanggilan alat yang lebih baik, terutama karena agen dapat menalar dan membuat skrip khusus untuk tugas yang dihadapi, alih-alih mencoba menggunakan alat umum yang memenuhi jendela konteks.
Dalam praktik otomatisasi browser, ini berarti model dapat langsung memeriksa status halaman aktif, menelusuri frame, dan menyusun kode interaksi khusus untuk antarmuka saat ini, alih-alih memetakan semuanya ke serangkaian tindakan siap pakai yang tetap.
Model tidak lagi sekadar bertindak sebagai pemilih, tetapi lebih sebagai pembuat runtime. Model memeriksa status saat ini, menalar antarmuka, dan menyintesis logika interaksi untuk situasi tersebut. Model dapat menyusun rangkaian bertahap, beradaptasi dengan alur yang tidak lazim, dan memvalidasi hasil sebelum melanjutkan. Ketika suatu tindakan gagal, model melihat kesalahan yang mendasarinya dan mengoreksi diri. Pendekatan ini lebih andal sekaligus lebih berisiko—tetapi jauh lebih sesuai dengan bentuk masalah yang sebenarnya.
Yang terpenting, menghapus lapisan abstraksi tidak membuat sistem menjadi kurang disiplin. Disiplin tersebut hanya dipindahkan.
Pekerjaan yang dahulu dilakukan dalam desain wrapper dan penanganan kasus ekstrem berpindah ke tiga tempat: prompt (yang menjadi bentuk pelatihan operasional), runtime (yang menerapkan batasan seperti cakupan navigasi, tindakan sensitif, dan perilaku percobaan ulang), serta lapisan evaluasi (yang menilai bukan hanya keberhasilan tugas, tetapi juga ketepatan langkah-langkah perantaranya). Lebih sedikit abstraksi yang rapuh. Sistem pendukung yang lebih andal.
Salah satu dampak pergeseran ini adalah kode produk sering kali menjadi lebih sederhana, meski kemampuan sistem secara keseluruhan meningkat. Alih-alih mengodekan pola interaksi sebagai wrapper yang dapat digunakan kembali, agen menyintesis perilaku saat runtime. Anda memelihara sejumlah kecil primitif yang andal dan lingkungan eksekusi yang dibatasi, bukan kumpulan alat khusus dan logika kasus ekstrem yang terus bertambah.
Hal ini juga mengubah cara sistem melakukan generalisasi. Agen berbasis wrapper mampu melakukan generalisasi dengan baik untuk tugas yang menyerupai wrapper yang telah Anda buat. Agen dengan runtime terbatas mampu melakukan generalisasi untuk tugas yang menggunakan landasan eksekusi yang sama, sekalipun antarmuka yang terlihat berbeda.
Misalnya, interaksi dengan formulir pencarian, alur pemesanan, atau halaman pengaturan mungkin terlihat sama sekali berbeda pada tingkat UI. Namun, di baliknya terdapat pola yang sama: membaca status, memicu peristiwa, memvalidasi hasil, dan menangani pembaruan asinkron. Sistem yang beroperasi pada tingkat tersebut dapat beralih antartugas secara lebih alami.
Komponen yang dapat digunakan kembali bukanlah daftar tindakan, melainkan kemampuan model untuk memeriksa status, bertindak dengan aman, dan memverifikasi hasil.
Pelajaran paling jelas dari pekerjaan ini adalah bahwa keandalan tidak diperoleh dengan memberi model lebih banyak fungsi pembantu. Keandalan justru sering diperoleh dengan memberikan lebih sedikit primitif yang lebih andal, lalu membatasinya secara tepat. Bantuan yang berlebihan menanamkan asumsi tentang cara suatu tugas harus dilakukan ke dalam kode. Batasan menetapkan koridor operasi yang aman dan memungkinkan model menemukan solusi lokal yang lebih baik.
Permukaan eksekusi yang lebih andal juga memerlukan model keamanan yang lebih tegas. Begitu agen tidak lagi dibatasi pada sejumlah kecil tindakan yang telah ditentukan, pada dasarnya agen beroperasi langsung pada perangkat lunak nyata. Hal itu langsung mengubah profil risikonya.
Ada empat hal yang perlu dipertimbangkan dalam desain:
Paparan data. Jika agen berinteraksi dengan antarmuka nyata, agen akan sering menjumpai informasi sensitif. Karena itu, penyamaran data dan kontrol akses harus diterapkan secara disiplin. Data hanya boleh diungkapkan jika diperlukan untuk eksekusi, sedangkan log dan rekaman jejak harus ditangani dengan cermat agar observabilitas tidak menjadi bagian paling sensitif dari sistem.
Cakupan eksekusi. Agen yang andal tidak boleh beroperasi secara sembarangan. Dalam praktiknya, ini berarti membatasi lokasi yang dapat dituju, domain yang dapat diakses, dan sistem yang boleh diajak berinteraksi. Batasan ini harus diterapkan pada tingkat runtime, bukan sekadar dijadikan kebiasaan dalam penyusunan prompt.
Kepercayaan terhadap lingkungan. Antarmuka modern dapat memuat instruksi, konten, atau alur yang menyesatkan maupun secara aktif menyerang. Injeksi prompt melalui konten halaman merupakan vektor serangan nyata. Sistem memerlukan hierarki instruksi, pemeriksaan validasi, dan kondisi penghentian yang jelas agar agen tidak mengikuti arahan yang tidak dimaksudkan.
Spektrum otonomi. Tidak semua tindakan harus sepenuhnya otonom. Dalam banyak lingkungan produksi, otonomi perlu diperlakukan sebagai sebuah spektrum. Sistem dapat sangat agentik saat menjelajah dan mengeksekusi, tetapi tetap memerlukan persetujuan untuk kategori tindakan tertentu.
Prinsip dasarnya sederhana: memberi model lebih banyak kuasa menuntut penguatan sistem di sekelilingnya. Otonomi tanpa kebijakan belum siap untuk produksi.
Kami berhenti bertanya: tindakan browser apa yang tepat untuk disediakan?
Kami mulai bertanya: apa yang dapat kami lakukan untuk memberi model ruang tindakan yang lengkap—dan bagaimana kami dapat membuat kebijakan runtime di sekelilingnya agar tetap aman?
Sudut pandang baru tersebut mengubah hal-hal yang perlu Anda prioritaskan. Taksonomi tindakan dan kelengkapan wrapper menjadi kurang penting. Kebijakan runtime, observabilitas, dan evaluasi pada tingkat langkah menjadi lebih penting. Kemampuan model dan desain sistem tidak dapat saling menggantikan. Seiring peningkatan model, peran sistem justru menjadi semakin penting.
Agen browser yang berfungsi dalam demo sering berhasil karena tugasnya sempit dan lingkungannya kooperatif. Sistem produksi memerlukan pendekatan berbeda: eksekusi terbatas, perilaku yang terinstrumentasi, dan evaluasi yang dapat membedakan hasil yang benar dari hasil yang sekadar beruntung.
Kurangi desain wrapper. Perbanyak rekayasa sistem.
Meski kami berfokus pada agen browser, hal ini menunjukkan cara pandang yang lebih luas terhadap penggunaan komputer sebagai disiplin sistem.