Agen pertama di sebuah tim adalah kisah produktivitas pribadi. Agen kelima adalah kisah organisasi. Di suatu titik di antara keduanya, sebuah kelompok berhenti menjadi tim yang sekadar memakai AI dan berubah menjadi tim agentik: manusia dan agen bekerja di papan yang sama, mengerjakan tugas yang sama, di bawah aturan yang harus dituliskan oleh seseorang.
Di transisi itulah sebagian besar pertanyaan menarik berada. Siapa yang memiliki pekerjaan yang dieksekusi agen? Apa isi standup ketika papan memperbarui dirinya sendiri? Berapa banyak agen yang bisa diserap satu peninjau? Panduan ini membahas komposisi tim agentik, pembagian kerja yang bertahan saat bersinggungan dengan pekerjaan nyata, dan kesepakatan kerja yang layak ditiru. Sharkly adalah platform yang kami bangun untuk bentuk tim seperti ini, dan mode kegagalan di bawah ini berasal dari pengamatan saat bentuk tersebut berjalan keliru.
TL;DR
Tim agentik adalah kelompok di mana manusia dan agen AI sama-sama memegang pekerjaan yang ditugaskan dalam satu sistem bersama, sementara manusia tetap memegang arah, otoritas, dan penerimaan hasil. Agen meneliti, mengeksekusi, menguji, dan melaporkan. Manusia menetapkan arah, memberikan otoritas, dan menerima hasilnya. Persyaratan praktisnya adalah catatan tugas yang bisa dibaca keduanya, penanggung jawab eksekusi yang terpisah dari penanggung jawab utama, status tinjauan yang sampai ke seseorang, dan lingkup tertulis yang cukup sehingga agen tidak perlu menebak-nebak.
Apa saja yang menyusun tim agentik
Ada tiga jenis peserta, dan penting untuk menyebutnya dengan tepat.
Manusia membuat dan memperbarui tugas, berkomentar, menerima item antrean, mendapat penugasan, meninjau hasil agen, dan mengelola pengaturan yang diizinkan oleh perannya. Merekalah satu-satunya peserta yang bisa dimintai pertanggungjawaban.
Agen adalah konfigurasi kerja yang tersimpan, bukan prompt sekali pakai: instruksi, runtime seperti Claude Code atau Codex, repositori, lingkungan, pengaturan eksekusi, dan skill yang terikat. Agen lebih mirip peran yang terdokumentasi daripada mirip seseorang. Penjelasan Sharkly Agents kami membahas apa saja yang menyusunnya.
Kru mengelompokkan agen di bawah satu agen pemimpin untuk pekerjaan yang butuh koordinasi. Eksekusi dimulai dari pemimpin: pemimpin membaca tugas dan instruksi kru, lalu menangani pekerjaan itu sendiri atau melibatkan anggota tertentu. Urutan ini ada untuk mencegah semua anggota mulai bekerja sekaligus. Detailnya ada di panduan kami tentang Sharkly Crews.
Akses dilapiskan di atasnya: peran organisasi menentukan kemampuan administratif secara luas, dan keanggotaan space menentukan area kerja mana yang bisa dijangkau seseorang. Agen dibatasi dengan cara yang sama, yaitu ke repositori dan mesin tertentu.
Pembagian kerja yang berhasil
Kontrak Sharkly sendiri adalah default yang baik karena cukup sempit untuk ditegakkan: agen meneliti, mengeksekusi, menguji, dan melaporkan; manusia menetapkan arah, memberikan otoritas, dan menerima hasilnya.
Empat tanggung jawab tetap di tangan manusia, seberapa pun mampunya agen.
- Arah. Menentukan apa yang layak dikerjakan dan dalam urutan apa.
- Konteks. Menulis lingkup yang bisa ditindaklanjuti agen: mengapa pekerjaan ini penting, apa yang berada di luar lingkup, file dan batasan yang relevan, serta bagaimana penyelesaiannya akan ditinjau.
- Penerimaan. Membaca buktinya dan memutuskan pekerjaan selesai. Eksekusi yang rampung bukan berarti hasil yang diterima.
- Eskalasi. Memutuskan apa yang harus dilakukan ketika agen terhambat, salah, atau menemui pertanyaan yang butuh penilaian.
Sisanya bisa dinegosiasikan dan bergantung pada seberapa besar tim Anda mempercayai rekam jejak agen tertentu pada jenis pekerjaan tertentu.
Bagaimana pekerjaan mengalir di dalam tim
Siklusnya pendek dan layak dibuat eksplisit, karena tim yang melewatkan satu langkah akan merasakannya dalam waktu seminggu.
- Seseorang menulis tugas dengan hasil yang dinyatakan dan kriteria penerimaan.
- Tugas itu mendapat penanggung jawab manusia untuk tanggung jawab dan agen atau kru sebagai penanggung jawab eksekusi. Keduanya adalah field terpisah, dan mengubah yang satu tidak mengubah yang lain.
- Memindahkan tugas keluar dari status backlog yang tertahan akan memulai eksekusi ketika agen yang ditugaskan sudah siap.
- Eksekusi berjalan di mesin yang terhubung, di direktori terisolasi, dengan kemajuan dan hambatan yang dilaporkan kembali ke tugas.
- Agen meninggalkan pekerjaan dalam status menunggu balasan manusia atau menunggu tinjauan manusia, yang masuk ke kotak masuk agen milik penanggung jawab.
- Seseorang membaca trace dan diff, lalu menerima, berkomentar untuk melanjutkan, atau menugaskan ulang.
Komentar adalah percakapan yang bertahan lama. Komentar pada tugas dengan agen yang siap bisa memasukkan eksekusi berikutnya ke antrean, sehingga umpan balik tinjauan dan eksekusi menjadi satu gerakan yang sama, bukan dua sistem terpisah.
Tiga bentuk yang berhasil
Developer berpasangan. Setiap developer memelihara satu atau dua agen untuk pekerjaan berulang mereka sendiri: cakupan tes, pembaruan dependensi, refactor yang sudah mereka lakukan dua puluh kali. Manfaatnya bagi tim adalah definisi agen tersebut dibagikan, sehingga karyawan baru mewarisi lima setup yang sudah berjalan di hari pertama, bukan membangun sendiri dari nol.
Skuad dengan kru bersama. Satu kru menangani satu kategori pekerjaan yang menjadi ketergantungan seluruh skuad, misalnya persiapan rilis atau triase insiden. Agen pemimpin memutuskan anggota mana yang berkontribusi, dan satu orang memiliki kategori tersebut. Inilah bentuk yang paling jauh skalanya sebelum kapasitas tinjauan menjadi penghambat.
Tim platform yang menstandardisasi. Tim platform atau developer experience memiliki definisi agen, skill, dan konfigurasi mesin untuk beberapa tim produk. Tim produk menugaskan pekerjaan; tim platform menjaga runtime, izin, dan instruksi tetap mutakhir. Bentuk ini menukar sebagian otonomi dengan konsistensi, dan biasanya itu pertukaran yang tepat setelah sekitar tiga puluh engineer.
Tak satu pun dari ketiganya menuntut reorganisasi apa pun. Semuanya adalah pola tentang siapa yang memiliki konfigurasi agen—pertanyaan yang menentukan apakah kemampuan agen menumpuk di seluruh tim atau tetap menjadi urusan pribadi.
Kesepakatan kerja yang layak diadopsi
Satu manusia yang bertanggung jawab per tugas. Bahkan ketika kru berisi empat agen yang mengerjakannya. Terutama saat itu.
Lingkup ditulis sebelum penugasan. Jika tidak ada yang bisa menjelaskan bagaimana hasilnya akan diperiksa, tugas itu belum siap untuk agen. Aturan ini saja sudah menghilangkan sebagian besar eksekusi yang buruk.
Tinjauan adalah kapasitas terjadwal, bukan waktu luang. Tentukan berapa banyak pekerjaan agen yang bisa diserap setiap peninjau per hari dan pegang angka itu. Tumpukan hasil agen yang belum ditinjau sama saja dengan utang pull request yang belum di-merge, dan tumpukannya bertambah lebih cepat.
Eksekusi yang gagal didiagnosis, bukan diulang begitu saja. Buka log eksekusi dan baca judul serta detail teknisnya terlebih dahulu. Error dari vendor yang terlihat serupa sering butuh perbaikan yang berlawanan, jadi mengulang secara refleks justru menyembunyikan penyebab sebenarnya.
Definisi agen punya pemilik dan tanggal peninjauan. Instruksi bisa basi. Developer yang menulis agen migrasi keluar, konvensinya berubah, dan agen itu terus dengan percaya diri menerapkan aturan kuartal lalu.
Apa yang pertama rusak saat tim bertumbuh
Kapasitas tinjauan selalu jadi yang pertama jebol. Kendala kedua adalah kapasitas mesin: eksekusi mengantre sambil menunggu slot konkurensi atau direktori kerja yang kosong, dan tim yang menambah agen tanpa menambah komputer akan menemukan antrean yang tidak terlihat dari papan.
Yang ketiga adalah pergeseran kepemilikan. Ketika beberapa agen berkontribusi pada tugas-tugas terkait dan tidak ada yang mengganti nama pemiliknya setelah serah terima, Anda berakhir dengan pekerjaan yang secara teknis punya penugasan tetapi secara praktis tidak bertuan. Menyisir tugas dengan penanggung jawab agen dan pemilik manusia yang sudah tak aktif sekali seminggu hanya butuh sepuluh menit dan mencegah versi berantakan dari masalah ini. Jika Anda lebih suka memulai dari sistem yang sudah memisahkan field-field ini, unduh Sharkly dan jalankan satu jenis pekerjaan berulang melaluinya selama seminggu.
FAQ
Berapa banyak agen per developer yang wajar? Mulai dari satu atau dua dan biarkan kapasitas tinjauan menentukan batas atasnya. Angka yang tepat adalah angka di mana hasil tidak menunggu keputusan manusia lebih dari satu hari kerja.
Apakah agen ikut standup? Pekerjaan merekalah yang hadir. Papan sudah membawa status, jadi standup menjadi daftar pengecualian: kegagalan, eksekusi yang terhambat, dan hasil yang menunggu manusia.
Haruskah agen menjadi satu-satunya penanggung jawab? Tidak. Tetap ada orang yang bertanggung jawab atas hasilnya, dengan agen di slot eksekusi. Panduan kami tentang manajemen proyek agen AI menjelaskan mengapa pemisahan itu makin penting seiring bertambahnya volume.
Bagaimana cara memperkenalkan agen baru ke tim? Sama seperti memperkenalkan orang baru: beri tugas pertama yang sempit, tinjau dengan cermat, lalu perluas lingkupnya. Simpan apa yang berhasil sebagai instruksi dan skill agen itu agar tim berikutnya tidak perlu menemukannya lagi dari awal.
