Chat dengan AI Agent atau Beri Tugas? Kapan Menggunakan yang Mana

Anda bisa mengobrol dengan agen AI, atau menetapkannya sebuah Task. Tim yang menjalankan agen coding setiap hari memperlakukan keduanya sebagai dua alat yang berbeda, dan tim yang mencampuradukkannya akan menanggung akibatnya nanti: keputusan yang terkubur di riwayat obrolan pribadi, pekerjaan yang selesai tetapi tidak pernah ditinjau, dan rekan tim yang bertanya "di mana kita menyepakati itu?" tiga minggu setelah sesi tersebut hilang dari layar.

Sharkly membangun pembedaan ini langsung ke dalam produknya. Chat digunakan untuk mengeksplorasi, merencanakan, atau bertindak bersama Agent sebelum pekerjaan membutuhkan catatan yang terlacak. Task digunakan untuk pekerjaan yang membutuhkan kepemilikan, status, riwayat eksekusi, dan tinjauan. Keduanya dapat memulai proses Agent. Keduanya menyimpan catatan yang berbeda, dan perbedaan itulah intinya.

Panduan ini menjelaskan fungsi masing-masing antarmuka, bagaimana mode chat di Sharkly berperilaku, cara mengalihkan chat yang menjanjikan menjadi Task sungguhan, dan aturan keputusan yang menjaga catatan bersama tim Anda tetap jujur.

TL;DR

Ngobrollah dengan agen AI ketika Anda ingin mengajukan pertanyaan, menyelidiki suatu topik, atau menyusun rencana tanpa membuka task. Tetapkan Task ketika pekerjaan membutuhkan Assignee, status, kriteria penerimaan, tinjauan, atau catatan tahan lama yang bisa dilihat tim. Pesan chat tetap berada di dalam sesi; hasil Task kembali ke Task, tempat orang meninjau dan menerimanya.

Masalahnya: satu agen, dua jenis pekerjaan

Siapa pun yang menjalankan Claude Code atau Codex di terminal pasti sudah mengenal kedua jenis pekerjaan ini. Sebagian sesi berisi pertanyaan: apa fungsi modul ini, mengapa tes ini flaky, berapa biaya migrasinya. Sesi lainnya adalah komitmen: perbaiki bug ini, rilis endpoint ini, perbarui dokumentasi ini.

Terminal memperlakukan keduanya dengan cara yang sama. Setiap sesi adalah transkrip pribadi di mesin satu orang, entah sesi itu menjawab pertanyaan sekadar lewat atau menghasilkan perubahan yang menjadi tumpuan seluruh tim. Sesi pertanyaan tidak masalah di sana. Sesi komitmen tidak, karena tidak ada orang lain yang bisa melihat tujuannya, diff-nya, diskusinya, atau hasilnya.

Sebagian besar tim menemukan ini dengan cara yang pahit. Seorang developer mengobrol dengan agen untuk menyelesaikan perbaikan produksi, perbaikan itu dirilis, dan alasan di baliknya hanya tersimpan di buffer scrollback yang terhapus pada hari Jumat. Kegagalan sebaliknya juga terjadi: sebuah tim mengalirkan setiap pertanyaan kecil melalui pelacak task mereka, dan papan pun dipenuhi tiket mati berjudul "tanya soal caching".

Solusinya bukan aturan yang melarang salah satu antarmuka. Solusinya adalah memahami apa yang dicatat masing-masing antarmuka, lalu memindahkan pekerjaan di antara keduanya secara sengaja. Ini dimulai dari memahami apa yang disimpan oleh chat dengan agen AI, dan apa yang tidak.

Apa itu Agent Chat di Sharkly?

Agent Chat adalah chat mandiri dengan sebuah Agent atau Crew. Gunakan saat Anda ingin mengajukan pertanyaan, menyelidiki topik, menyusun rencana, atau memulai pekerjaan tanpa membuka task terlebih dahulu. Setiap chat mandiri didukung oleh sesi dan pesan tersendiri, dan sesi tersebut menjadi milik orang yang membuatnya.

Sharkly memiliki dua antarmuka chat, dan dokumentasinya sangat ketat dalam memisahkan keduanya:

• Standalone Agent Chat berada di luar task mana pun. Anda membuka tampilan chat sebuah Agent, mengirim pesan, dan sesi baru pun dimulai. Ini adalah ruang kerja Anda bersama Agent tersebut.
• Chat Agent pada sebuah task berada di dalam task tersebut. Ini bukan komentar task, dan tidak mengharuskan task tersebut ditetapkan ke Agent itu terlebih dahulu.

Ada tiga batas yang penting di sini, karena masing-masing adalah titik di mana orang yang berpikir wajar pun bisa salah tebak.

Chat bukan komentar. Mengirim pesan di Agent Chat tidak membuat komentar task. Mengirim pesan di chat Agent pada sebuah task juga tidak muncul di Activity sebagai komentar. Komentar task tetap menjadi catatan resmi untuk diskusi seputar task; chat adalah catatan terpisah di kedua antarmuka.

Chat tidak terlihat oleh tim secara default. Sesi mandiri menjadi milik orang yang membuatnya, dan anggota organisasi lain tidak mendapatkan akses ke sesi tersebut melalui API chat yang ada saat ini. Pada sebuah task, pesan chat baru memberi notifikasi kepada Assignee dan orang-orang yang sudah berada dalam percakapan itu. Pesan tersebut tidak disiarkan ke semua orang yang mengikuti task.

Chat tidak memerlukan penetapan. Anda bisa membuka sebuah task dan mengobrol dengan Agent mana pun di Space tentang task itu, terlepas dari apakah Agent tersebut adalah Assignee-nya atau bukan. Penetapan mengatur tanggung jawab eksekusi, bukan akses percakapan.

Jika Anda baru mengenal apa itu Agent (konfigurasi kerja tersimpan yang berisi instruksi, Runtime, Skill, dan repositori), penjelasan tentang Agent membahas dasar-dasarnya.

Apa yang diberikan Task yang tidak diberikan chat?

Task adalah unit kerja utama di Sharkly. Di dalamnya ada tujuan dan deskripsi, status, prioritas, label, orang yang bertanggung jawab, Agent atau Crew yang ditetapkan untuk mengeksekusi, komentar dan lampiran, serta status eksekusi, trace, dan hasil dari Agent. Segala hal tentang pekerjaan itu kembali ke Task, tempat siapa pun yang memiliki akses dapat memeriksanya.

Satu kalimat itu menyembunyikan empat jaminan konkret yang tidak bisa diberikan chat:

1. Kepemilikan. Sebuah Task punya Assignee. Ketika sesuatu macet, ada nama yang bisa disorot. Sesi chat hanya punya daftar peserta tanpa struktur akuntabilitas.
2. Status. Sebuah Task bergerak melalui alur kerja yang ditetapkan tim Anda: backlog, started, review, done. Siapa pun bisa melihat papan dan mengetahui posisi pekerjaan tanpa harus bertanya.
3. Riwayat eksekusi. Setiap run terhadap sebuah Task meninggalkan jejak: kapan masuk antrean, kapan dimulai, alat apa saja yang dipanggil, mengapa gagal. Ketika sebuah run rusak, Anda membaca catatan eksekusi alih-alih merekonstruksi kejadian dari ingatan.
4. Tinjauan. Sebuah Agent dapat membuat Task menunggu balasan manusia atau tinjauan manusia, dan sinyal-sinyal itu masuk ke Inbox orang yang bertanggung jawab. Penerimaan adalah langkah yang tercatat, bukan sekadar perasaan.

Eksekusi yang didukung Task juga punya keunggulan struktural. Pekerjaan repositori pada sebuah Task berjalan di direktori terisolasi, biasanya berupa git worktree terpisah untuk setiap run, sehingga beberapa Task dapat mengubah codebase yang sama secara paralel tanpa saling mengganggu. Mekanismenya dibahas dalam cara Sharkly menjalankan agen secara paralel. Komentar lanjutan pada Task yang sudah ditetapkan dapat memulai run lain, dan Sharkly menggabungkan komentar yang dikirim beruntun agar tidak memicu pekerjaan duplikat.

Inilah kontrak manusia-agen yang menjadikan Task rumah yang tepat bagi pekerjaan sungguhan: Agent melakukan riset, eksekusi, pengujian, dan pelaporan pada Task. Orang menetapkan arah, memberikan wewenang, dan menerima hasilnya. Sesi chat mendukung paruh pertama kontrak itu. Hanya Task yang mendukung paruh keduanya.

Chat Agent vs penetapan task: tabel keputusan

Keputusannya bergantung pada apa yang perlu dicatat oleh pekerjaan itu, bukan pada seberapa besar pekerjaannya.

Gunakan chat saat Anda bertanya, membandingkan, menyelidiki, atau menyusun sesuatu. Gunakan Task ketika pekerjaan membutuhkan Assignee, status, kriteria penerimaan, atau hasil yang harus disetujui seseorang.

Dua aturan penyeimbang yang jujur mencegah hal ini menjadi dogma:

Jangan buat Task untuk setiap pertanyaan. "Apa fungsi modul ini?" cukup dijawab lewat chat, bukan tiket. Papan yang penuh Task berbentuk pertanyaan hanyalah kebisingan yang mengubur pekerjaan sesungguhnya, dan kebisingan itulah yang justru ingin dicegah oleh sistem manajemen kerja untuk manusia dan agen.

Jangan biarkan sebuah chat diam-diam berubah menjadi proyek. Begitu sebuah percakapan menghasilkan sesuatu yang harus ditindaklanjuti, ditinjau, atau diingat tim, percakapan itu sudah melampaui kapasitas sesi. Jika tim perlu melihat kesimpulannya, salinlah ke deskripsi task atau komentar. Sesi aslinya tetap menjadi riwayat pribadi Anda; Task menjadi catatan bersama.

Tiga mode chat: Explore, Plan, Execute

Chat di Sharkly bukan satu perilaku tunggal. Kolom composer memiliki tiga mode, mode yang dipilih disimpan bersama sesi, dan Anda dapat mengubahnya sebelum giliran mana pun.

Explore adalah penyelidikan hanya-baca. Agent memeriksa, menjelaskan, membandingkan, dan merangkum tanpa membuat perubahan. Biarkan Explore tetap dipilih ketika Anda menginginkan analisis dan tidak yang lain. Ini adalah mode untuk "jelaskan alur autentikasi kepada saya" dan "dari dua library ini, mana yang sudah menjadi dependensi codebase".

Plan memungkinkan Agent mengusulkan tindakan untuk Anda tinjau. Agent menyusun draf task terencana beserta subtask-nya, dan tidak ada yang terjadi sampai Anda mengonfirmasi. Anda dapat mengedit usulan tersebut, mengonfirmasinya tanpa memulai pekerjaan, atau mengonfirmasi sekaligus langsung memulainya. Mode Plan adalah jembatan antara percakapan yang baik dan komitmen yang terlacak, dan mode inilah yang membuat serah terima dari chat ke Task menjadi praktis.

Execute memungkinkan Agent bertindak langsung melalui CLI yang dikonfigurasi dan mengembalikan hasilnya di dalam sesi. Chat baru dimulai dalam mode Execute kecuali Anda menetapkan default yang berbeda, dan ini penting diketahui sejak hari pertama: jika Anda menginginkan percakapan hanya-baca, beralihlah ke Explore sebelum mengirim pesan pertama, bukan setelah Agent mulai melakukan sesuatu.

Pasangan keputusan untuk mode ini mencerminkan keputusan yang lebih besar. Gunakan Explore atau Plan selama hasilnya masih berupa pertanyaan. Gunakan Execute di chat hanya untuk pekerjaan yang tidak masalah jika tidak masuk catatan tim, dan gunakan Task untuk segala hal lainnya.

Beberapa perilaku membuat chat nyaman digunakan dalam praktik. Output Agent dialirkan ke dalam sesi selama run berlangsung, dan Anda dapat menghentikan run kapan saja. Jika Anda mengirim pesan lain saat Agent sedang bekerja, Sharkly mengantrekannya untuk giliran berikutnya alih-alih memulai run duplikat yang paralel. Teks draf yang belum terkirim tetap tersimpan per percakapan saat Anda berpindah antar chat di browser yang sama. Sesi dapat diganti nama, diarsipkan, dan dibuka kembali dari riwayat; sesi yang diarsipkan tetap bisa dibaca tetapi hanya-baca.

Cara mengalihkan chat menjadi Task

Serah terima inilah titik pertemuan kedua antarmuka, dan dokumentasi Sharkly memberikan urutan yang konkret. Ketika sebuah diskusi menghasilkan tindakan yang layak dikomitmenkan:

1. Rangkum hasilnya di dalam chat. Minta Agent menyatakan tujuan, cakupan, batasan, dan kriteria penerimaan dalam satu pesan. Inilah paragraf yang dibutuhkan Task, dan Agent sudah memegang konteksnya untuk menuliskannya.
2. Gunakan mode Plan untuk menyusun draf Task. Beralih ke Plan dan minta Agent mengusulkan task beserta subtask-nya. Tinjau usulan itu dan edit sebelum mengonfirmasi. Anda juga bisa melewati langkah ini dan membuat Task secara manual; intinya adalah ada orang yang membentuk komitmen tersebut.
3. Konfirmasi, dengan atau tanpa memulai. Mengonfirmasi akan membuat Task yang direncanakan. Konfirmasi dan mulai jika pekerjaan harus dimulai sekarang; konfirmasi tanpa memulai jika pekerjaan harus menunggu Sprint atau dependensi.
4. Tetapkan Task-nya. Arahkan Task ke orang, Agent, atau Crew yang tepat melalui kontrol Assignee. Ringkasan chat yang cakupannya jelas inilah yang membuat task tersebut layak ditetapkan. Untuk pekerjaan multi-peran, Crew dengan Agent pemimpin dapat mengambil seluruh Task alih-alih satu eksekutor tunggal.
5. Pindahkan konteksnya, bukan transkripnya. Salin apa pun yang harus dipertahankan Task ke dalam deskripsi atau komentarnya. Sesi chat tetap menjadi riwayat terpisah milik Anda; jangan mengandalkannya sebagai memori tim, karena tim tidak bisa melihatnya.

Sejak titik itu, umpan balik mengikuti aturan Task. Diskusi bolak-balik yang khusus untuk task berlanjut di chat Agent pada task tersebut; kesimpulan yang perlu dilihat seluruh tim masuk ke komentar Activity; komentar yang memenuhi syarat pada Task yang sudah ditetapkan akan memulai run lanjutan. Hasil, penghambat, dan respons akhir kembali ke Task, dan itulah yang memungkinkan tinjauan di kemudian hari.

Satu catatan penempatan: Task yang ditetapkan ke sebuah Agent tidak akan dimulai selama masih berada di Backlog. Backlog adalah area parkir. Memindahkan Task keluar dari Backlog akan memulai Agent yang ditetapkan begitu Computer dan Runtime-nya siap, sehingga Anda dapat menyiapkan pekerjaan dari chat sekarang dan melepaskannya saat tim siap. Di mana eksekusi itu secara fisik berjalan adalah urusan terpisah, yang dibahas dalam penjelasan tentang Computer.

Quick chat: konteks task tanpa meninggalkan task

Ada antarmuka ketiga yang perlu diketahui setelah dasar-dasarnya dipahami. Detail task memiliki quick chat di toolbar header: kombinasi prompt dan Agent tersimpan yang berjalan dengan task saat ini sebagai konteks.

Setiap quick chat memiliki nama, prompt opsional, Agent atau Crew yang dipilih, dan pengaturan visibilitas. Quick chat privat hanya dapat dilihat dan dipicu oleh pembuatnya. Quick chat yang dibagikan dapat dilihat oleh semua orang di Space, meskipun hanya pembuatnya yang bisa mengeditnya. Memilih salah satunya akan membuka tampilan terbelah dengan task di sebelah kiri dan chat di sebelah kanan, lalu prompt, Agent, dan konteks task dikirim bersamaan.

Ini mengubah pertanyaan yang berulang menjadi operasi sekali klik. Quick chat bersama bernama "Estimate this" yang mengirim task ke Agent perencana, atau "Find related code" yang terhubung ke Agent yang memahami repositori, menjadi sesuatu yang bisa dipicu oleh setiap orang di Space pada task mana pun. Tesis yang sama juga mendasari Skill: nilainya datang dari berbagi konfigurasi yang baik, bukan dari setiap orang membuka lebih banyak chat.

Ada dua mekanisme yang perlu dipahami dengan jelas. Setiap pemicuan quick chat membuat percakapan tingkat task tersendiri, dan percakapan itu tetap berada di Task; percakapan tersebut tidak menggunakan kembali chat biasa milik Agent yang ditetapkan. Dan menghapus sebuah quick chat hanya menghilangkan konfigurasi tersimpannya, bukan percakapan yang sudah pernah dibuat darinya.

Bagaimana jika stack Anda tidak punya lapisan task?

Banyak tim menjalankan agen tanpa platform orkestrasi sama sekali: sesi terminal mentah, panel tmux, skrip shell. Konfigurasi semacam itu cukup baik dalam menangani paruh chat dari pembedaan di artikel ini. Sesi terminal adalah percakapan eksploratif yang privat dengan agen, sama seperti Agent Chat.

Yang tidak dimiliki stack DIY adalah paruh lainnya. Tidak ada Assignee, tidak ada status, tidak ada trace run yang bisa dibuka rekan tim, tidak ada langkah tinjauan, dan tidak ada tempat yang menjadi lokasi default hasil pekerjaan. Setiap sesi komitmen terlihat identik dengan sesi pertanyaan, dan perbedaannya baru muncul ketika ada yang rusak dan tidak ada yang bisa merekonstruksi penyebabnya. Perbandingan Claude Squad, Conductor, dan setup berbasis tmux menguraikan sampai di mana masing-masing pendekatan berhenti.

Anda tidak perlu membangun ulang proses Anda untuk menambahkan paruh yang hilang. Sharkly bukan pengganti Claude Code, Codex, atau alat eksekusi lainnya; Sharkly menambahkan lapisan task, konteks, dan tinjauan bersama di sekitar alat yang sudah tim Anda gunakan, dan penggunaan model tetap berjalan melalui langganan atau API key yang dikonfigurasi di alat-alat tersebut. Pertahankan terminal untuk pekerjaan coba-coba jika Anda lebih nyaman di sana. Alirkan pekerjaan yang sudah dikomitmenkan melalui Task, dan jika tiket Anda sudah berada di tempat lain, tiket Jira bisa langsung dikirim ke Agent tanpa tim Anda harus berpindah pelacak.

Tiga skenario yang dijalankan

Tes yang flaky. Seorang engineer menyadari ada tes yang gagal secara intermiten. Ia membuka chat dengan Code Reader Agent milik tim dalam mode Explore: "Mengapa auth_session_test gagal saat dijalankan paralel?" Sepuluh menit membaca, Agent menunjuk pada fixture bersama yang mengalami race. Sekarang ini menjadi komitmen: ia beralih ke mode Plan, Agent menyusun draf task SH-341 berisi cakupan perbaikan dan kriteria penerimaan ("tes lulus 50 kali run paralel berturut-turut"), ia mengonfirmasi dan memulainya, lalu menetapkannya ke Agent pelaksana perbaikan. Investigasinya tetap tersimpan di riwayat chat-nya. Perbaikan, diff, dan tinjauannya berakhir di SH-341.

Pertanyaan arsitektur. Seorang tech lead ingin tahu berapa biaya mengadopsi queue di tiga layanan. Ini membutuhkan berhari-hari membaca, tetapi tetap saja sebuah pertanyaan, jadi semuanya tetap berada di sesi chat mandiri yang ia beri nama "studi adopsi queue". Selama sepekan ia kembali ke sesi itu, mengajukan pertanyaan lanjutan, dan membiarkan Agent membandingkan opsi. Ketika manajemen menyetujui, ringkasan akhir sesi itu menjadi deskripsi Task bertingkat epic, yang diuraikan menjadi subtask dalam mode Plan. Tidak ada apa pun yang pernah setengah terlacak.

Pertanyaan standup yang terus muncul kembali. Sebuah tim menyadari bahwa setiap pagi ada saja yang meminta Agent merangkum perubahan kemarin pada task yang sedang mereka tinjau. Satu orang menyimpannya sebagai quick chat bersama bernama "What changed here?" yang terhubung ke Agent yang memahami repositori. Pertanyaan itu tidak perlu lagi diketik ulang, dan setiap pemicuannya meninggalkan percakapan pada task yang dijalankannya. Untuk ringkasan yang terjadwal alih-alih berdasarkan permintaan, insting yang sama berkembang menjadi Automation.

Dalam ketiga skenario itu, aturan yang sama menentukan antarmukanya: pertanyaan tetap di chat, komitmen mendapatkan Task, dan serah terima terjadi begitu jawabannya menyiratkan adanya pekerjaan.

Kesimpulan

Ngobrol dengan agen AI saat Anda sedang mengeksplorasi; tetapkan Task saat Anda berkomitmen. Sharkly sengaja menjaga kedua antarmuka tetap terpisah agar papan Anda mencatat pekerjaan sungguhan, bukan pertanyaan, dan pertanyaan Anda tidak hilang ke dalam catatan yang tak seorang pun membaca. Sesi chat adalah milik Anda. Task adalah milik tim, dan konteks, kemajuan, penghambat, hasil, serta tinjauan manusia tetap terlihat di dalamnya dari permintaan hingga rilis.

Pembedaan ini tidak memerlukan biaya apa pun untuk diterapkan karena kedua antarmukanya sudah ada di depan Anda. Buka chat dengan sebuah Agent dan tanyakan sesuatu yang biasanya harus Anda gali sendiri di codebase. Saat pertama kali percakapan itu menghasilkan sesuatu yang layak dikomitmenkan, beralihlah ke mode Plan dan biarkan Agent menyusun draf Task-nya. Hubungkan satu Computer, buat satu Agent, dan cobalah kedua paruh itu pada pekerjaan yang membosankan. Ikhtisar unggulan membahas sisa platformnya ketika Anda sudah siap.

Pertanyaan yang sering diajukan

Bisakah saya mengobrol dengan Agent tentang sebuah task tanpa menetapkannya?

Bisa. Buka task tersebut dan mulai chat dengan Agent mana pun di Space. Penetapan bukan syarat untuk bercakap-cakap; penetapan mengatur siapa yang mengeksekusi task, bukan siapa yang bisa Anda ajak bicara tentang task itu.

Apakah pesan chat muncul di feed Activity task?

Tidak. Komentar yang muncul di Activity untuk seluruh tim. Chat Agent pada sebuah task memberi notifikasi kepada Assignee dan orang-orang yang sudah berada dalam percakapan itu, dan disimpan terpisah dari komentar di kedua antarmuka.

Bisakah rekan tim saya membaca sesi Standalone Agent Chat milik saya?

Tidak. Setiap sesi mandiri menjadi milik orang yang membuatnya, dan anggota organisasi lain tidak mendapatkan akses melalui API chat yang ada saat ini. Jika sebuah kesimpulan penting bagi tim, salinlah ke deskripsi atau komentar task.

Apa yang terjadi jika saya mengirim pesan ke Agent yang offline atau diarsipkan?

Agent yang offline akan ditampilkan sebagai offline, bukan sedang berpikir atau dalam antrean, jadi jangan menunggu balasan yang tidak akan datang. Agent yang diarsipkan tidak dapat menerima pesan baru: composer-nya dinonaktifkan, meskipun riwayat sesinya tetap bisa dibaca.

Mode chat mana yang sebaiknya saya gunakan untuk memulai?

Chat baru dimulai dalam mode Execute kecuali Anda mengubah default-nya. Jika Anda menginginkan analisis tanpa perubahan, beralihlah ke Explore sebelum mengirim pesan pertama. Gunakan Plan ketika Anda ingin Agent mengusulkan task yang akan Anda tinjau dan konfirmasi.

Apakah mengobrol dengan Agent menggunakan konfigurasi eksekusi task saya?

Ya. Run chat melewati konfigurasi Agent yang sama: instruksinya, Runtime, dan Computer-nya. Dalam mode Execute, Agent bertindak melalui CLI yang dikonfigurasi, mesin yang sama yang menjalankan run task.

Kapan sebuah chat harus menjadi Task?

Begitu percakapan menghasilkan pekerjaan yang harus dimiliki, ditinjau, atau diingat seseorang. Rangkum tujuan, cakupan, batasan, dan kriteria penerimaannya, susun draf Task dalam mode Plan atau secara manual, lalu tetapkan. Riwayat chat bukan catatan tim.

Bisakah dua orang berbagi satu sesi chat dengan Agent?

Tidak untuk sesi mandiri, karena sesi tersebut hanya dimiliki satu orang. Pada sebuah task, chat Agent memberi notifikasi kepada Assignee dan peserta sebelumnya, sehingga sekelompok kecil orang dapat mengikuti satu percakapan tingkat task di sana. Untuk diskusi yang terlihat oleh tim, gunakan komentar task.