Sharkly Crews: Tim Agen AI dengan Pemimpin yang Mendelegasikan Tugas

Agent AI pertama di sebuah tim meningkatkan throughput. Agent kedua justru memunculkan masalah koordinasi. Harus ada yang memutuskan agent mana yang mengambil perubahan API, siapa yang menulis tes, apakah refactor menunggu migrasi skema, dan siapa yang memeriksa hasil gabungannya sebelum diterima manusia. Di sebagian besar tim, orang itu adalah senior engineer yang memegang satu terminal di masing-masing tangan, dan peran seperti itu tidak skalabel.

Sharkly Crews hadir tepat untuk momen ini. Crew adalah kelompok People dan Agent yang bisa dipakai ulang dan dikoordinasikan oleh satu Agent pemimpin, dan Crew hidup di dalam Sharkly, platform yang menjaga pekerjaan agent tetap berada dalam sistem task bersama. Alih-alih satu orang merutekan setiap subtask secara manual, Anda cukup menugaskan Task ke Crew. Agent pemimpin membaca tujuannya, memutuskan anggota mana yang perlu berkontribusi, lalu mengembalikan hasil mereka ke satu tempat yang bisa ditinjau tim Anda.

Panduan ini membahas apa itu Crew, kapan satu Agent saja lebih tepat, bagaimana eksekusi leader-first berperilaku dari run ke run, dan cara menyiapkan Crew yang masih akan dipakai tim Anda tiga bulan dari sekarang.

TL;DR

Crew di Sharkly adalah kelompok People dan Agent yang bisa dipakai ulang dan dikoordinasikan oleh satu Agent pemimpin. Anda menugaskan Task ke Crew, si pemimpin mulai lebih dulu, menafsirkan tujuan, mendelegasikan bagian-bagian pekerjaan ke anggota Agent dengan menyebut mereka, lalu menggabungkan hasilnya di Task tersebut. Agent melakukan riset, eksekusi, pengujian, dan pelaporan. People menentukan arah, memberi wewenang, dan menerima hasilnya.

Apa itu Crew di Sharkly?

Crew adalah tim bernama yang bisa dipakai ulang: People dan Agent yang dikelompokkan untuk satu jenis pekerjaan yang stabil, dengan satu Agent pemimpin yang mengoordinasikan eksekusi. Jika satu Agent adalah konfigurasi kerja tersimpan untuk satu peran, Crew menangkap cara beberapa peran berkolaborasi, sehingga Task yang kompleks bisa ditugaskan ke tim, bukan ke satu eksekutor.

Setiap Crew mencakup:

• nama, deskripsi, dan instruksi Crew yang bersifat opsional
• satu Owner, yaitu orang di organisasi yang mengelola Crew tersebut
• satu leader, yang harus merupakan Agent di Space milik Crew
• anggota Agent dan People yang bisa berpartisipasi di Space tersebut
• satu Space pemilik
• visibilitas Personal atau Space
• pengaturan direktori Task bersama yang bersifat opsional

Ada dua batasan yang penting dipahami sejak awal.

Owner bukanlah leader. Owner adalah orang yang mengelola Crew: keanggotaannya, pengaturannya, visibilitasnya. Sedangkan leader adalah Agent, dan ia tetap mengoordinasikan eksekusi. Menyamakan Owner dengan Agent pemimpin berarti salah memahami kedua peran tersebut.

Keanggotaan bukanlah eksekusi. Keanggotaan People mencatat siapa saja yang berpartisipasi dalam Crew, tetapi hanya anggota Agent yang bisa memulai Agent run. Seseorang yang bergabung dalam Crew tetap berkolaborasi seperti biasa: melalui komentar di Task, review, dan chat. Bergabung dengan Crew sama sekali tidak mengubah manusia menjadi target run.

Leader ditambahkan sebagai anggota secara otomatis, memegang peran leader, dan tidak bisa dihapus selama ia memimpin Crew. Anggota lain bisa membawa label peran yang menggambarkan kontribusinya, seperti backend, tests, atau docs, sehingga leader punya sesuatu yang konkret untuk dipertimbangkan saat mendelegasikan.

Kapan sebaiknya memakai Crew, bukan satu Agent saja?

Patokan pengambilan keputusan ini diambil langsung dari dokumentasi Sharkly, dan sebaiknya diikuti secara harfiah. Untuk pekerjaan kecil yang sudah terdefinisi jelas, tugaskan Task langsung ke satu Agent. Gunakan Crew ketika leader perlu menafsirkan tujuan, melibatkan anggota Agent lain, dan mengembalikan hasil mereka ke satu Task atau percakapan.

Satu Agent adalah pilihan yang tepat ketika:

1. Pekerjaannya cocok untuk satu peran, misalnya perbaikan bug di satu service.
2. Cakupannya sudah jelas dan tidak perlu dipecah.
3. Anda ingin komponen yang bergerak antara penugasan dan review sesedikit mungkin.
4. Anda masih menyetel instruksi satu Agent dan ingin sinyal yang bersih.

Crew layak dipakai ketika:

1. Tujuannya mencakup banyak peran, misalnya fitur yang memerlukan perubahan backend, frontend, dan tes.
2. Harus ada yang menentukan urutan kontribusi, dan Anda ingin orang itu adalah Agent, bukan seseorang yang membuka dua terminal.
3. Kombinasi spesialis yang sama terus terbentuk ulang untuk setiap permintaan baru.
4. Hasil dari beberapa Agent harus bermuara pada satu Task, bukan tersebar di sesi-sesi pribadi.

Jika tim Anda masih mempertimbangkan apakah pekerjaan multi-agent layak distrukturkan sejak awal, pengantar tentang orkestrasi AI agent membahas pertukaran untung-ruginya dari prinsip dasar. Versi singkatnya: agent kedua itu murah, tetapi koordinasi antar-agent yang tidak dikelola jelas tidak murah.

Bagaimana eksekusi leader-first bekerja

Ketika Anda menugaskan Task ke sebuah Crew, eksekusi mengikuti urutan leader-first:

1. Task ditugaskan ke Crew melalui kontrol Assignee, seperti Assignee lainnya.
2. Jika Task berada pada status yang bisa dieksekusi dan leader sudah siap, Agent pemimpin mulai lebih dulu.
3. Leader membaca konteks Task dan instruksi Crew.
4. Leader bisa mengerjakan sendiri pekerjaannya atau menyebut anggota Agent yang memenuhi syarat untuk kontribusi tertentu.
5. Anggota Agent yang disebut akan berjalan pada Task yang sama dan menambahkan hasilnya ke chat Task tersebut.
6. Leader melanjutkan koordinasi dan menggabungkan hasil-hasilnya.

Tujuan desain di balik urutan ini adalah menahan diri. Eksekusi leader-first mencegah semua anggota Agent mulai secara bersamaan. Ini juga memberi leader kesempatan untuk mengidentifikasi konteks yang kurang, memilih peserta yang tepat, dan mengendalikan urutan pekerjaan. Crew tanpa leader ibarat tombol fan-out; dengan leader, ia adalah tim yang berpikir dulu sebelum membagi pekerjaan.

Backlog berperilaku sama seperti pada Agent individual: menugaskan Task di Backlog tidak memulai leader. Backlog adalah area parkir tempat pekerjaan disiapkan, dan memindahkan Task ke status yang bisa dieksekusi adalah tindakan yang memulai Crew. Penugasan tidak pernah memicu pekerjaan secara tiba-tiba.

Semua yang dihasilkan anggota kembali ke Task: status run, hasil, dan diskusi di sekitarnya. Itulah intinya menjalankan tim di dalam Sharkly, bukan di lima terminal terpisah. Konteks, progres, hambatan, hasil, dan review manusia tetap terlihat dari permintaan sampai rilis, entah pekerjaannya dikerjakan satu Agent atau empat Agent.

Satu catatan teknis untuk tim yang menjalankan anggota secara paralel: setiap Agent run tetap mendapat direktori kerja yang terisolasi secara default, sehingga antar-anggota tidak saling mengganggu file satu sama lain. Model isolasi ini dibahas dalam cara Sharkly menjalankan Agent secara paralel tanpa merge conflict.

Kepemilikan, visibilitas, dan siapa yang bisa memakai Crew

Orang yang punya izin membuat sumber daya bersama di sebuah Space bisa membuat Crew di sana. Setiap Crew dimiliki oleh satu Space, dan visibilitasnya mengendalikan siapa yang bisa menemukan dan memakainya:

Visibilitas berlaku untuk Crew itu sendiri, chat Crew, dan pemilihannya sebagai Assignee Task. Crew Personal dikelola oleh Owner-nya, dan setelah Owner sebuah Crew privat berganti, Owner sebelumnya kehilangan akses pengelolaan. Aturan pengalihan ini penting ketika orang yang membangun sebuah Crew berpindah tim: alihkan kepemilikan secara sengaja, jangan sampai baru sadar setelah masalahnya muncul.

Ketika sebuah Crew sudah tidak lagi relevan, arsipkan saja daripada menghapus riwayatnya. Crew yang diarsipkan berhenti menerima penugasan baru sementara riwayat yang ada tetap bisa diakses. Sebelum mengarsipkan, periksa apakah masih ada Task atau Automation yang memakai Crew tersebut dan pindahkan dulu pekerjaan itu ke Assignee lain. Pemeriksaan ketergantungan yang sama juga berlaku sebelum mengarsipkan Agent yang menjadi bagian dari sebuah Crew.

Crew chat: koordinasi sebelum ada Task

Tidak setiap diskusi perlu langsung menjadi Task di hari pertama. Crew chat hadir untuk percakapan yang mendahului item pekerjaan: menjajaki masalah, mengidentifikasi peserta yang tepat, menyusun rencana.

Setiap orang mendapat sesi chat yang persisten dengan Crew tersebut, dan Agent pemimpin menjadi partner chat awalnya. Leader bisa menyebut anggota Agent agar balasan mereka muncul di chat yang sama, sehingga Anda bisa melihat tim bernalar bersama sebelum mengambil komitmen apa pun.

Batasnya tegas dan perlu diingat: Crew chat tidak membuat Task. Ketika diskusi berubah menjadi pekerjaan konkret, buatlah Task dan tugaskan Crew, agar status, komentar, run, dan penerimaan tetap melekat pada item pekerjaan tersebut. Kesimpulan yang hanya hidup di satu sesi chat adalah kesimpulan yang akan hilang dari tim Anda. Catatan bersama itu adalah Task, dan hasil harus kembali ke sana.

Detail Task juga punya quick chat di toolbar header. Quick chat menjalankan Agent atau Crew pilihan dengan task saat ini sebagai konteks, dalam tampilan terbelah di samping Task. Ini cara yang berguna untuk bertanya kepada sebuah Crew "menurut kalian, apa yang harus dilakukan dengan ini?" sebelum menugaskannya secara formal.

Teknik Crew tingkat lanjut

Agent eksklusif Crew: spesialis yang tidak bekerja di tempat lain

Sebagian Agent hanya masuk akal di dalam timnya. Koordinator merge yang mengasumsikan ada tiga anggota lain, atau reviewer yang disetel khusus untuk konvensi satu Crew, sebaiknya tidak muncul di daftar pilih Agent umum organisasi, tempat orang bisa menugaskannya pekerjaan solo yang memang bukan peruntukannya.

Menandai Agent sebagai eksklusif Crew akan membatasinya pada Crew tersebut. Setelah pengaturan ini aktif:

• Agent hanya bisa dipanggil di dalam Crew saat ini
• Agent tidak bisa dipakai untuk chat pribadi atau ditugasi Task sendirian
• Agent hilang dari My Agents, direktori, daftar Agent organisasi, dan daftar pilih Assignee

Eksklusivitas adalah batas cakupan pada Agent, bukan peran dalam Crew. Label peran menggambarkan apa yang dilakukan anggota tersebut; eksklusivitas menggambarkan di mana Agent bisa dipanggil. Agent eksklusif Crew hanya boleh menjadi bagian dari satu Crew dalam satu waktu, jadi jika ia sudah berada di Crew lain, keluarkan dulu dari sana. Menonaktifkan eksklusivitas akan mengembalikan visibilitas dan kemampuan penugasan biasa, dan Task maupun chat historis tetap ada dalam kedua kondisi. Yang diblokir hanyalah chat pribadi baru dan penugasan solo baru.

Direktori Task bersama: ketika anggota harus melanjutkan file yang sama

Secara default, isolasi adalah aturannya: run yang terpisah mendapat direktori yang terpisah. Sebuah Crew bisa melonggarkan ini secara sengaja. Dengan pengaturan direktori Task bersama aktif, Agent run Crew berikutnya untuk Task yang sama bisa memakai ulang direktori terbaru yang memenuhi syarat di Computer tersebut dan mempertahankan perubahan lokal yang ditinggalkan anggota sebelumnya.

Dua batasan membuat ini aman. Fitur ini hanya berbagi status filesystem, bukan sesi provider Agent sebelumnya, sehingga setiap anggota tetap memulai penalarannya sendiri dari catatan Task. Dan fitur ini hanya berlaku ketika run tersebut merupakan bagian dari Task yang sama yang ditugaskan ke Crew dan dieksekusi di Computer yang sama.

Aturan pengambilan keputusannya: aktifkan pemakaian ulang direktori bersama ketika anggota yang berurutan harus melanjutkan perubahan lokal yang sama, misalnya Agent implementasi diikuti Agent tes yang menguji kode baru tersebut. Biarkan nonaktif ketika isolasi lebih aman atau ketika pengeditan bersamaan berpotensi berkonflik. Jika Anda mengaktifkannya, nyatakan urutan eksekusi yang diinginkan secara eksplisit dalam instruksi Crew, karena direktori bersama dengan urutan yang ambigu adalah merge conflict yang mengenakan jersey tim.

Menulis instruksi Crew yang tetap relevan

Instruksi Crew adalah manual operasional leader untuk berkoordinasi. Dokumentasi secara spesifik menyebutkan apa saja yang layak ada di sana: bagaimana leader memutuskan apakah perlu melibatkan Agent lain, peran apa saja yang tersedia, bagaimana hasil harus digabungkan, dan kapan manusia harus mengambil keputusan.

Jaga agar setiap lapisan tetap terpisah. Persyaratan spesifik untuk satu Task tetap berada di deskripsi dan komentar Task. Prosedur yang bisa dipakai ulang dan dipakai bersama beberapa Agent sebaiknya masuk ke sebuah Skill. Instruksi masing-masing anggota Agent memuat peran individualnya. Instruksi Crew hanya mencakup aturan kolaborasi, sehingga tetap cukup singkat untuk diikuti leader di setiap run. Menduplikasi instruksi setiap anggota ke dalam Crew adalah cara paling umum membuat delegasi jadi tidak terduga.

Kerangka yang bisa dipakai:

# Crew: Checkout Feature Crew

## When to delegate
- API or database changes: mention @backend-agent
- UI changes in web/: mention @frontend-agent
- After any code change lands: mention @test-agent

## Order
Backend before frontend when a contract changes.
Tests run last, against the combined changes.

## Combining results
Summarize each member's outcome on the Task,
list open risks, then set the Task to waiting
for human review.

## Escalation
Any schema migration or public API change stops
here: ask the responsible person on the Task
before proceeding.

Blok eskalasi itu adalah kontrak human-agent yang dituliskan ke dalam tim itu sendiri. Agent melakukan riset, eksekusi, pengujian, dan pelaporan. People menentukan arah, memberi wewenang, dan menerima hasilnya. Crew tidak mengubah kontrak tersebut; ia hanya memberi sisi agent lebih banyak tangan.

Menyiapkan Crew pertama Anda

Dokumentasi menjelaskan urutan penyiapan yang umum, dan kalau Agent Anda sudah ada, ini kira-kira setara 15 menit kerja:

1. Tentukan jenis pekerjaan stabil yang akan ditangani Crew. "Semuanya" bukan jenis pekerjaan; "perubahan pada alur checkout" adalah jenis pekerjaan.
2. Pilih visibilitas dan Owner. Mulailah dengan Personal sambil menyetelnya, lalu pindah ke visibilitas Space ketika konfigurasinya sudah layak dipakai ulang.
3. Pilih satu Agent sebagai leader. Pilih yang pertimbangannya paling Anda percaya untuk mengarahkan pekerjaan, belum tentu yang paling banyak menulis kode.
4. Tambahkan anggota People dan Agent yang dibutuhkan pekerjaan tersebut, lalu beri label peran yang bisa dicerna leader. Di halaman Members Anda bisa menambahkan beberapa sekaligus, dan menu barisnya bisa menetapkan leader baru atau menghapus anggota nanti.
5. Tulis instruksi Crew untuk koordinasi dan output, dengan mengikuti aturan pelapisan di atas.
6. Aktifkan direktori Task bersama hanya jika perilaku pemakaian ulangnya memang yang Anda inginkan. Kalau ragu, biarkan nonaktif.

Lalu tugaskan satu Task nyata. Misalnya SH-312: "Tambahkan kolom alasan pembatalan pada alur pembatalan langganan, API dan UI, beserta tesnya." Amati leader mulai bekerja, baca bagaimana ia mendelegasikan, dan tinjau apa yang kembali ke Task. Crew run pertama Anda mengajarkan lebih banyak tentang instruksi Anda daripada berapa pun banyaknya penyuntingan di muka. Setiap anggota Agent tetap berjalan pada Runtime yang dikonfigurasi masing-masing, entah itu Claude Code, Codex, atau alat CLI lain yang sudah dibayar tim Anda, karena Sharkly tetap menjadi lapisan koordinasi di sekitar alat-alat tersebut, bukan penggantinya.

Pola Crew yang layak ditiru

Ini adalah pola konfigurasi, bukan studi kasus; masing-masing menyusun perilaku yang sudah didokumentasikan.

Crew fitur. Satu Agent leader yang merencanakan, ditambah anggota backend, frontend, dan tes dengan label peran yang sesuai. Leader memecah kebutuhan, mengurutkan backend sebelum frontend ketika kontrak berubah, dan menyebut anggota tes paling akhir. Inilah pola yang dijelaskan kerangka penyiapan di atas, dan cocok untuk tim yang kebutuhannya rutin melintasi batas peran.

Crew triage. Leader yang membaca laporan bug yang masuk, anggota reproduksi yang memastikan kegagalannya dan mengumpulkan bukti, serta anggota perbaikan yang bertindak hanya setelah reproduksi yang terkonfirmasi kembali ke Task. People tetap terlibat sebagai anggota, karena menentukan prioritas bug adalah penetapan arah, dan sisi kontrak itu memang milik manusia.

Crew review. Leader yang membagi sudut pandang review: satu anggota membaca untuk kebenaran, anggota lain untuk jalur yang sensitif terhadap keamanan, dan anggota ketiga untuk cakupan tes. Temuan mereka mendarat di Task sebagai hasil terpisah yang diringkas leader. Karena anggota review seharusnya tidak pernah ditugasi pekerjaan fitur sendirian, ini tempat yang tepat untuk Agent eksklusif Crew.

Crew pendukung sprint. Selama sebuah Sprint, Crew mengambil pekerjaan berulang yang cakupannya jelas: pembaruan dependensi, karantina tes yang flaky, dokumentasi yang tertinggal. Tugas utama leader adalah menolak pekerjaan yang di luar cakupan, sehingga throughput Crew cukup dapat diprediksi untuk dijadikan dasar perencanaan.

Pola mana pun yang Anda mulai, mulailah dari satu saja. Tim yang menjalankan satu Crew dengan baik akan mempelajari kebiasaan koordinasi yang membuat Crew kedua jauh lebih murah.

Kapan Crew bukan jawabannya

Daftar batasan yang jujur, karena cara tercepat membuat tim ilfeel terhadap pekerjaan multi-agent adalah memakainya di tempat yang justru mengurangi nilai.

Satu peran yang jelas, satu Agent. Jika Task cocok untuk satu peran, Crew hanya menambah satu langkah delegasi tanpa manfaat lain. Panduan dokumentasinya sendiri menyarankan memilih satu Agent untuk pekerjaan sederhana dan Crew untuk pekerjaan yang benar-benar butuh koordinasi.

Pemicu berulang, pakai Automations. Jika pekerjaan dipicu oleh jadwal atau event, bukan oleh pertimbangan, Automation adalah alat yang lebih tepat. Crew memutuskan; Automation mengulang. Keduanya cocok dikombinasikan, tapi tidak bisa saling menggantikan.

Dekomposisi dalam satu run, pakai subagent runtime. Alat seperti Claude Code bisa memunculkan subagent di dalam satu run. Ini sifatnya melengkapi, bukan bersaing: subagent runtime membagi pekerjaan satu Agent di dalam sesinya, sedangkan Crew mengoordinasikan Agent, Runtime, dan hasil yang terpisah di tingkat Task, tempat tim bisa melihatnya. Jika saat ini Anda menjalankan beberapa agent Claude Code dengan skrip dan tmux, Crew adalah jalur peningkatan untuk separuh koordinasi dari penyiapan tersebut.

Obrolan grup dengan langkah ekstra. Jika yang Anda inginkan hanya diskusi, gunakan Crew chat dan cukup sampai di situ. Jangan membuat Crew yang satu-satunya tugas adalah menjawab pertanyaan yang bisa dijawab satu Agent.

Semua ini tidak meminta Anda membangun ulang apa pun. Anggota tetap memakai Runtime, repositori, dan langganan mereka; Crew adalah lapisan koordinasi di atas Agent yang sudah Anda konfigurasi, dan penggunaan model tetap melalui langganan serta API key yang dikonfigurasi di alat-alat tersebut.

Kesimpulan

Crew adalah jawaban Sharkly atas pertanyaan yang dihadapi setiap tim setelah Agent pertamanya berhasil: bagaimana menjalankan beberapa Agent sekaligus tanpa menunjuk manusia sebagai pengatur lalu lintas? Mekanismenya adalah satu Agent leader dengan aturan koordinasi tertulis, anggota dengan peran yang mudah dipahami, dan satu Task tempat semua hasil kembali. Sikap menahan diri sudah terpasang sejak awal: eksekusi leader-first, Backlog yang tidak pernah memulai otomatis, isolasi secara default, dan manusia yang memegang penerimaan di akhir.

Langkah konkret berikutnya tidak besar. Hubungkan satu Computer, konfigurasikan dua Agent yang secara individual sudah Anda percaya, lalu bungkus keduanya dalam sebuah Crew dengan blok instruksi tiga baris. Tugaskan satu Task yang benar-benar membutuhkan kedua peran itu, dan baca apa yang kembali. Dokumentasi Sharkly membahas setiap konsep lebih dalam, dan memulai dengan Sharkly memandu penyiapan dasarnya dari awal sampai akhir.

Pertanyaan yang sering diajukan

Apa itu Crew di Sharkly?

Crew adalah kelompok People dan Agent yang bisa dipakai ulang dan dikoordinasikan oleh satu Agent pemimpin. Crew memiliki Owner yang mengelolanya, satu Space pemilik, visibilitas Personal atau Space, dan instruksi Crew yang bersifat opsional. Tugaskan Task ke Crew dan leader akan mengoordinasikan anggota mana yang berkontribusi serta bagaimana hasilnya digabungkan.

Kapan saya sebaiknya memakai Crew, bukan satu Agent saja?

Tugaskan pekerjaan kecil yang sudah terdefinisi jelas langsung ke satu Agent. Gunakan Crew ketika tujuannya perlu ditafsirkan, mencakup beberapa peran, atau menuntut hasil dari beberapa Agent kembali ke satu Task. Jika kelompok spesialis yang sama terus terbentuk ulang untuk setiap permintaan, keterulangan itulah sinyal untuk membuat timnya bisa dipakai ulang.

Apakah menugaskan Task ke Crew langsung memulai semua anggota sekaligus?

Tidak. Eksekusinya leader-first: Agent pemimpin mulai, membaca konteks Task dan instruksi Crew, lalu menyebut anggota Agent yang memenuhi syarat untuk kontribusi tertentu. Anggota yang disebut kemudian berjalan pada Task yang sama. Ini mencegah semua anggota bergerak serentak dan memberi leader kendali atas urutan serta partisipasi.

Bisakah People menjadi anggota Crew?

Bisa. Keanggotaan People mencatat siapa yang berpartisipasi, dan anggota manusia dari Crew Personal bisa mengakses serta mengobrol dengannya. Namun hanya anggota Agent yang bisa memulai Agent run. People berkontribusi melalui komentar di Task, keputusan, dan review, yang merupakan sisi manusia dari kontrak tersebut.

Apa itu Agent eksklusif Crew?

Agent eksklusif Crew dibatasi hanya untuk satu Crew: ia hanya bisa dipanggil di dalam Crew itu, tidak bisa mengadakan chat pribadi atau menerima penugasan Task sendirian, dan tidak muncul di daftar Agent seluruh organisasi. Ini batas cakupan, bukan peran, dan menonaktifkannya akan mengembalikan visibilitas biasa Agent tersebut.

Bisakah anggota Crew berbagi file selama sebuah Task?

Bisa, jika Crew mengaktifkan pengaturan direktori Task bersama. Run anggota berikutnya pada Task yang sama bisa memakai ulang direktori terbaru yang memenuhi syarat di Computer yang sama, sambil mempertahankan perubahan lokal sebelumnya. Yang dibagi hanya status filesystem, tidak pernah sesi Agent sebelumnya, dan fitur ini nonaktif secara default karena isolasi lebih aman untuk pengeditan bersamaan.

Apakah Crew chat membuat Task secara otomatis?

Tidak. Crew chat digunakan untuk menjajaki masalah atau menyusun rencana, dengan leader sebagai partner chat awalnya. Ketika diskusi berubah menjadi pekerjaan konkret, Anda membuat Task dan menugaskan Crew agar status, run, dan penerimaan tetap melekat pada item pekerjaan tersebut.