Tingkat Otonomi Agen

• Rekayasa agentic semakin mendekati desain operasional daripada penulisan prompt, dan untuk tiap tugas perlu ditentukan bersama tingkat otonomi yang diizinkan serta metode verifikasi yang menopangnya
• Model tangga tunggal berguna untuk mengekspresikan kepercayaan terhadap satu agen dalam bentuk angka, tetapi kemampuan menangani banyak agen sekaligus perlu dilihat dalam dua sumbu: agency dan orchestration
• Model level 0~5 membentang dari Assist yang hanya memberi saran hingga Managed-by-exception orchestration di mana manusia hanya turun tangan dalam situasi pengecualian; makin tinggi levelnya, makin jelas tujuan, cakupan, bukti, wewenang, dan anggarannya
• Dalam analisis Anthropic atas Claude Code, melalui data sekitar 400 ribu sesi dan sekitar 235 ribu pengguna, terlihat pola bahwa manusia menangani sekitar 70% keputusan perencanaan, sementara Claude menangani sekitar 80% eksekusi
• Pemanfaatan agen yang matang bukan soal memamerkan otonomi tinggi, melainkan menerapkan calibrated autonomy sesuai risiko dan tingkat kemudahan rollback, serta mengelola bottleneck verifikasi

---

Rekayasa agentic bergerak dari penulisan prompt ke desain operasional

• Pusat rekayasa agentic sedang bergeser dari penulisan prompt ke desain operasional
• Software factory, tujuan, loop, sesi latar belakang, subagen, hook, sandbox, dan cara agen menyetujui agen lain kini tampil di garis depan
• Claude Code dan Codex dibahas sebagai produk representatif yang menunjukkan perubahan ini
• Engineer dapat memakai otonomi rendah untuk mengurangi risiko dan mempermudah rollback, sementara untuk aktivitas yang jelas atau refactoring codebase berskala besar dapat memakai otonomi lebih tinggi dan armada agen paralel
• Pertanyaan intinya adalah tingkat otonomi seperti apa yang boleh diizinkan untuk tiap tugas, dan verifikasi seperti apa yang dapat mempertahankan level tersebut

Melihat otonomi lewat dua sumbu, bukan satu tangga tunggal

• Tangga sumbu tunggal yang disebut dalam “Welcome to Gas Town” karya Steve Yegge berguna untuk mengekspresikan kepercayaan terhadap satu agen dalam bentuk angka
• Pada awal 2026, bahkan ketika pekerjaan bergeser dari delegasi ke orkestrasi, sumbu tunggal masih berfungsi sebagai indikator pengganti kasar untuk mengukur risiko
• Begitu banyak agen dapat dijalankan bersamaan, satu level saja sulit menjelaskan kemampuan multi-agen
• Diskusi tentang otonomi sering mencampur dua pertanyaan yang berbeda
  • Seberapa jauh satu agen bisa dilepas dari manusia
  • Seberapa baik banyak agen bisa dikoordinasikan
• Untuk memisahkannya, dibutuhkan dua sumbu
  • agency: seberapa otonom satu agen dalam memberi usulan, menjalankan tugas terbatas, atau mencapai tujuan
  • orchestration: seberapa baik koordinasi dilakukan, mulai dari satu thread hingga banyak pohon tugas dan pekerjaan berkelanjutan berbasis backlog, issue tracker, dan jadwal

Makna agency dan orchestration

• Pada level rendah sumbu agency, agen mengusulkan tindakan kandidat lalu menunggu keputusan manusia
• Pada level menengah, agen menjalankan tugas tertentu dengan cakupan terbatas, dan terus melaporkan apa yang telah dilakukan beserta buktinya agar manusia bisa menyesuaikan arah
• Pada agency tinggi, agen dapat bereksperimen, belajar, menguji, menangani pemblokir, bertanya, dan mencoba pendekatan lain untuk mencapai tujuan, lalu mengembalikan semuanya sebagai bukti
• Level rendah sumbu orchestration berarti satu agen dan satu thread
• Pada level menengah, banyak agen menjalankan tujuan berbeda masing-masing di worktree yang terpisah
• Pada level tinggi, orchestrator mengubah backlog, issue tracker, jadwal, dan queue menjadi pekerjaan berkelanjutan, dan manusia hanya turun tangan saat gagal, dalam bentuk management by exception
• Contoh fitur dan produk terkait adalah sebagai berikut
  • Claude Code: /plan, /goal, /loop, /background, /batch, /code-review, /security-review, subagen, hook, checkpoint, cara delegasi dan pengelolaan agen, sesi latar belakang, pola tim agen, argumen /schedule
  • Codex: thread lokal dan cloud, Goal mode, worktree, Automations, subagen, panel review, GitHub code review, hook, sandbox, Auto-review, rerun

Tiga era dan enam level

• Jika tangga dibaca dari bawah ke atas, kesannya agency dan orchestration naik bersamaan
• Enam level itu terbagi menjadi tiga era
  • Era ketika manusia berada di kursi pengemudi dan agen hanya membantu sambil menunggu operasi dari manusia
  • Era ketika agen menangani tugas atau tujuan terbatas tetapi manusia tetap mengarahkan dan memverifikasi
  • Era orkestrasi ketika sistem membagikan pekerjaan ke banyak agen dan manusia terutama turun tangan saat ada masalah
• Dalam engineering nyata, wajar bila seseorang berpindah-pindah antarlevel selama satu hari kerja

Level 0: Assist

• Agen biasanya memberi usulan yang baik, kadang sempurna, tetapi keputusan untuk mengeksekusi selalu ada pada manusia
• Contohnya adalah autocomplete, saran edit inline, atau mendiskusikan perubahan yang belum dimiliki siapa pun di chat
• Cocok untuk kesalahan yang mahal, perubahan yang sangat kecil, atau pekerjaan ketika penilaian masih sedang dibentuk
• Verifikasi sebagian besar terjadi secara lokal

Level 1: Supervised action

• Agen mengedit atau menjalankan perintah atas nama pengguna, tetapi meminta izin manusia sebelum eksekusi penting
• Ini mendekati postur dasar yang dipakai kebanyakan orang
• Dapat dilakukan di sandbox lokal dengan persetujuan sebelum perubahan diterapkan, atau dalam sesi interaktif
• Tiap persetujuan berfungsi sebagai verifikasi independen untuk memastikan perubahan itu aman diterapkan
• Mode kegagalan utama adalah kelelahan persetujuan
  • Apa pun yang disetujui bisa terasa serupa
  • Responsnya bisa berupa menelusuri diff secara kasar, mengikuti heuristik, meminta orang lain mengecek, atau membiarkan agen menanggung tanggung jawab
• Codex Auto-review menangani masalah ini dengan mendelegasikan persetujuan akhir pada kondisi batas kepada agen reviewer terpisah

Level 2: Scoped task delegation

• Ini adalah tahap menyerahkan tugas terbatas kepada agen
• Tugas harus memiliki tujuan yang jelas, batasan, dan definisi pekerjaan selesai yang operasional
• Manusia tetap berada dekat dan bisa menghentikan, tetapi biasanya tidak terlibat langsung
• Ini diperlakukan sebagai level yang dekat dengan pusat software engineering
• Verifikasi bergeser dari pengecekan langsung oleh manusia ke bukti yang dapat dihasilkan agen
  • tes otomatis yang lulus
  • tipe yang sesuai
  • saran lint
  • screenshot
  • langkah reproduksi
  • sumber berbasis contoh

Level 3: Goal-driven autonomy

• Agen melakukan apa yang diperlukan untuk mencapai tujuan sampai kondisi tertentu terpenuhi
• Dalam mode prompt, prompt itu sendiri menjadi tujuannya
  • Contoh: “Bisakah time-to-interactive halaman ini diturunkan hingga di bawah 1 detik?”
• Di Codex, ini sesuai dengan Goal mode, di mana agen mengulang langkah plan -> act -> test -> review lalu berhenti saat kriteria sukses tak lagi bisa dipenuhi
• Di Claude Code, ini sesuai dengan perintah /goal, /loop, dan /schedule
• Agar level ini berguna, kondisi berhenti harus terukur dengan cara yang bisa diotomatisasi
• Tujuan samar seperti “meningkatkan pengalaman pengguna secara keseluruhan” atau “membuat codebase lebih mudah diuji” tidak cocok
• Tujuan yang lebih cocok harus spesifik, terukur, dan dapat diotomatisasi
  • menemukan bug produksi yang lolos dari analisis statis
  • mengurangi waktu muat
  • memastikan build TypeScript yang strict tanpa any eksplisit
  • mengklasifikasikan seluruh dependensi agar hanya tersisa dependensi yang dapat dipahami dan lolos tes
• Untuk menemukan bug produksi, agen harus berada di lingkungan yang mirip produksi

Level 4: Parallel delegation

• Ini adalah tahap ketika banyak agen bekerja secara paralel
• Masing-masing agen menangani potongan tugas yang terpisah
• Bottleneck terbesar adalah dekomposisi, yaitu memutuskan potongan mana yang akan didelegasikan
• Fitur pendukungnya meliputi subagen, sesi latar belakang, /batch, worktree, dan tim agen
• Mode kegagalan utamanya adalah paralelisme palsu
  • Jika banyak agen menangani potongan yang tumpang tindih secara bersamaan, hasilnya bisa berupa merge conflict dan keputusan duplikat alih-alih lebih banyak pekerjaan selesai
• Agar berjalan baik, agen harus saling terisolasi
  • Masing-masing harus punya file dan state yang dimiliki sendiri
  • Masing-masing juga harus punya queue review sendiri
• Tiap agen menimbulkan biaya token, dan itu sebanding dengan jumlah agen yang berjalan bersamaan
• Dari sisi manusia, setelah jumlah tertentu, biaya marginal menambah agen meningkat karena pajak orkestrasi

Level 5: Managed-by-exception orchestration

• Manusia mendefinisikan arti keberhasilan dan kebijakan yang akan diterapkan, lalu manager agent bangun berdasarkan trigger dan mendistribusikan pekerjaan
• Contoh trigger adalah issue baru, tugas baru, atau jam
• Manager agent men-deploy worker agent, memantau progres, memverifikasi output, dan mencoba ulang saat gagal
• Jika syarat tertentu terpenuhi, ia melakukan eskalasi ke agen yang lebih mampu atau ke manusia, lalu menggabungkan hasil dan mengembalikan artefak kerja seperti PR beserta bukti ke sistem eksternal
• Tahap ini dianalogikan sebagai pabrik
  • Inputnya adalah issue tracker atau backlog
  • Outputnya adalah banyak issue atau bug yang terselesaikan
• Agen bekerja dalam lingkungan terisolasi dengan batas yang memadai dan jalur keluar bila diperlukan
• Apa yang harus dilakukan pabrik ini ditentukan oleh sistem operasi yang didefinisikan manager agent
• OpenAI mengusulkan spec untuk Symphony dengan papan Linear sebagai pusatnya
  • Tiap issue memiliki workspace agen sendiri
  • Agen memeriksa apakah ia terus membuat progres menuju tujuan yang didefinisikan di file spec dalam workspace-nya
• Garis depan orkestrasi adalah membangun pabrik agen berkelanjutan dengan ratusan atau ribuan agen yang berjalan
• Pada tahap ini verifikasi independen menjadi makin penting
  • pemisahan implementer dan reviewer
  • pemisahan pelaksana tes dan QA
  • pemisahan pemeriksaan keamanan
  • pemisahan process gate untuk penerimaan

Risiko dan tingkat kemudahan rollback menentukan batas atas otonomi

• Dalam riset terkait Claude Code dari Anthropic, pada sebagian tugas tersulit Claude Code mengajukan pertanyaan klarifikasi secara eksplisit lebih dari dua kali lebih sering dibanding pengguna menghentikannya
• Pengguna berpengalaman, yaitu pengguna dengan sekitar 750 sesi, cenderung lebih sering memakai auto-approve dan interupsi serta mengawasi progres dibanding pengguna dengan kurang dari 50 sesi
• Analisis Anthropic yang lebih luas mencakup sekitar 400 ribu sesi dari sekitar 235 ribu pengguna dari Oktober 2025 hingga April 2026
• Di tiap sesi, dapat diidentifikasi keputusan seperti jumlah tindakan yang diminta pengguna per prompt, item yang di-auto-approve, dan frekuensi interupsi
• Manusia membuat sekitar 70% keputusan perencanaan, sementara Claude melakukan sekitar 80% eksekusi
• Otonomi tinggi bukan berarti mengeluarkan manusia dari loop, melainkan berpindah dari manusia yang melakukan tiap langkah ke manusia yang menentukan arah berikutnya
• Untuk menilai apakah sistem AI besar beroperasi dengan otonomi tinggi, dibutuhkan tiga pertanyaan
  • Seberapa cepat kita bisa tahu apa yang sedang salah
  • Seberapa bersih kita bisa membatalkan apa yang sedang dilakukan
  • Apa yang membuktikan bahwa yang sedang dilakukan itu benar
• Jika jawabannya “tidak bisa cepat tahu, sulit dibatalkan, dan harus percaya pada ringkasan”, maka itu bukan otonomi tinggi

Hal-hal yang harus masuk ke kontrak sebelum agen dijalankan

• Sebelum setiap eksekusi agen, diperlukan kontrak yang mendefinisikan apa yang hendak dilakukan
• Kontrak harus mencakup hal-hal berikut
  • Tujuan: hasil yang ingin dicapai, bukan aktivitas atau tekniknya
  • Cakupan: domain kerja dan teknik yang diizinkan
  • Non-tujuan: hal-hal yang tidak termasuk dalam tujuan
  • Alat dan wewenang: cara agen berinteraksi dengan dunia luar
  • Kondisi berhenti: kapan harus berhenti, sebisa mungkin berupa variabel terukur
  • Bukti: tes, screenshot, log, record database, dan lain-lain yang memungkinkan verifikasi penyelesaian secara independen
  • Eskalasi: dalam situasi apa siapa yang turun tangan, dan siapa yang menjalankan agen
  • Anggaran: batas waktu, usaha, dan token
• Token adalah anggaran untuk model AI besar, dan juga dapat mencakup batas jumlah percobaan dan tingkat paralelisme

Metrik membuat otonomi sedikit lebih dapat dipercaya

• Menentukan metrik setelah kejadian saja mungkin tidak cukup
• Metrik bisa ditempatkan lebih dulu dalam dokumen ringkas dan membuat otonomi lebih dapat dipercaya
• Contoh metrik yang bisa dilacak per level otonomi adalah sebagai berikut
  • rata-rata waktu antar intervensi
  • durasi terlama eksekusi tanpa pengawasan untuk pekerjaan yang diterima
  • rasio tindakan yang dijalankan di sandbox terhadap tindakan yang dieskalasikan
  • rasio tindakan yang di-auto-approve terhadap tindakan yang ditolak
  • rata-rata jumlah tindakan agen per satu instruksi manusia
  • tingkat permintaan klarifikasi
  • tingkat permintaan interupsi
  • waktu review per perubahan yang diterima
  • tingkat rework per level kepercayaan
  • tingkat defect leakage per level kepercayaan
  • biaya token per perubahan yang diterima
• Satu agen yang terus sibuk dengan pekerjaan yang diserahkan manusia lebih mendekati Level 4 dengan dashboard, sedangkan agen konservatif yang memiliki intake otomatis, retry, dan tidak maju tanpa bukti yang cukup lebih mendekati Level 5 dengan gate nyata

Kesiapan dan pemilihan level otonomi

• Tugas harus diklasifikasikan berdasarkan risiko dan tingkat kemudahan rollback
• Otonomi harus diterapkan secara konservatif, dan hanya dinaikkan ketika bukti yang mendukung level lebih tinggi telah terkumpul
• Refactoring payment engine dengan tes kuat, agen reviewer, dan jalur rollback yang bersih dapat mendukung otonomi lebih tinggi daripada pekerjaan otomatisasi dokumen yang tidak memiliki ground truth
• Level otonomi harus mengikuti proses verifikasi, bukan nama tugasnya

Empat antipola otonomi

• Autonomy as status

  • Rating otonomi agen berfungsi seperti lencana status yang tak bermakna
  • Otonomi tinggi diperlakukan sebagai bukti kemampuan, bukan keselamatan, sehingga agen dijalankan pada level yang tidak didukung verifikasi
  • Orang yang memilih level otonomi yang tepat dan tidak melewati batas harus dipuji dan diberi penghargaan

• Permission laundering

  • Karena kelelahan persetujuan, agen dan alat AI diberi hak akses yang lebih luas dari yang diperlukan
  • Batas seperti profil sandbox, root tulis dengan cakupan terbatas, daftar perintah yang diizinkan, hook, dan Auto-review harus diperkuat

• Summary substitution

  • Ringkasan pekerjaan agen menggantikan review
  • Paket bukti seperti review manual harus ikut dibundel
  • Ini bisa mencakup diff, tes, log, screenshot, temuan reviewer, risiko, dan celah

• Fleet cosplay

  • Puluhan agen dijalankan paralel, tetapi manusia tetap terus mengoordinasikan semua dependensi secara manual
  • Shared state, aturan kepemilikan, dan pelacakan dependensi yang lebih baik mengurangi kebutuhan koordinasi manual
  • Batas WIP yang lebih kecil dapat mendorong fokus pada pengodean dan pendokumentasian tahap koordinasi, yang kemudian bisa berujung pada otomatisasi orkestrasi

Cara naik level dengan aman

• Disarankan latihan kalibrasi dengan meninjau 10 pekerjaan terbaru yang dibantu agen
  • level otonomi tiap pekerjaan
  • risiko
  • tingkat kemudahan rollback
  • bukti yang dihasilkan untuk memenuhi kebutuhan verifikasi
  • waktu review
  • apakah terjadi rework
  • apakah level otonomi yang sama masih cocok di waktu berikutnya
• Naiklah satu sumbu pada satu waktu
• Titik mulanya adalah satu supervised agent yang menjalankan satu tugas terbatas dan menghasilkan bukti keberhasilan yang dapat dipertahankan
• Setelah itu, perluas secara bertahap ke tiga arah
  • memparalelkan pekerjaan eksplorasi yang berpusat pada pembacaan
  • menambahkan agen penulis di worktree terpisah dengan aturan kepemilikan file yang terbatas
  • menambahkan otomasi berulang, lalu orkestrasi yang digerakkan agen berbasis issue atau suara dan sejenisnya
• Setiap kenaikan level memerlukan pengaman baru untuk menghadapi mode kegagalan baru
• Mode kegagalannya meliputi
  • eksekusi agen tunggal yang panjang: drift, korupsi konteks, komunikasi yang terlewat, penyimpangan tujuan
  • pekerjaan latar belakang: asumsi usang, handoff yang lemah
  • pekerjaan paralel berlebihan: merge conflict, keputusan duplikat
  • pekerjaan berulang berlebihan: pengeluaran token yang diam-diam, prompt usang
  • managed-by-exception: queue review panjang, kelelahan notifikasi
• Yang dibutuhkan bukanlah mempercayai lebih keras, melainkan mempersempit cakupan, mendapatkan bukti yang lebih baik, membuat jalur rollback yang lebih murah, memperkuat gate, dan memperjelas aturan kepemilikan

Penggunaan yang cocok per level

• Level 0 paling cocok untuk pekerjaan yang halus dan situasi ketika penilaian masih sedang dibentuk
• Level 1 cocok untuk sebagian besar eksplorasi yang dekat dengan batas yang sudah dipahami dengan baik
• Level 2 cocok untuk sebagian besar tugas terbatas yang mungkin memiliki dependensi tak diketahui dan masalah tak terduga
• Level 3 cocok jika kondisi keberhasilan bisa dinyatakan dengan cukup jelas
• Level 4 cocok ketika pekerjaan bisa dibagi dengan bersih berdasarkan kondisi keberhasilan
• Level 5 cocok setelah koordinasi dan komunikasi yang diperlukan di antara banyak kondisi keberhasilan telah sepenuhnya dienkodekan

Verifikasi tetap menjadi bottleneck

• Terlepas dari tingkat kepercayaan dan level alat saat ini, sikap tim engineering yang matang saat bekerja dengan agen AI adalah calibrated autonomy
• Dalam waktu dekat, perlu dirancang loop yang tahu kapan harus bekerja, kapan harus memverifikasi, dan kapan harus bertanya
• Kemampuan engineer tetap terletak pada memilih level otonomi yang tepat, serta membangun pola dan bukti yang bisa dipertahankan untuk menahan sisi gelapnya