Tidak ada yang memercayai rekan tim baru hanya karena resume-nya. Kepercayaan lahir dari struktur: tanggung jawab yang jelas batasnya, pekerjaan yang berlangsung di tempat yang bisa dilihat tim, dan peninjauan sebelum apa pun dirilis. Hilangkan salah satu saja, dan bahkan kolega yang brilian pun berubah menjadi risiko. Hal yang sama berlaku untuk AI agent sebagai rekan tim. Pertanyaannya tidak pernah "apakah modelnya cukup pintar", melainkan "apakah saya tahu apa yang boleh disentuh oleh sistem ini, bisakah saya melihat apa yang telah dilakukannya, dan apakah ada yang dirilis tanpa persetujuan manusia."
Sharkly menjawabnya dengan konfigurasi, bukan janji. Agent di Sharkly adalah konfigurasi kerja yang tersimpan, bukan prompt sekali pakai: instruksinya, Runtime, Skills, repositori, environment, dan pengaturan run membentuk cara ia menangani pekerjaan. Prompt hilang begitu terminal ditutup. Konfigurasi bisa diperiksa, dibagikan, dan konsisten di setiap run.
Jika Anda ingin melihat gambaran umum platform terlebih dahulu, mulailah dari apa itu Sharkly lalu kembali ke sini.
Ringkasan Singkat
Agent di Sharkly adalah konfigurasi kerja yang tersimpan dan dapat digunakan ulang untuk pelaku AI: instruksi operasional, pengikatan Computer dan Runtime, Skills yang terpasang, repositori Git, variabel environment, serta pengaturan run seperti concurrency, timeout, dan mode working directory. Anda memercayainya seperti memercayai rekan tim, melalui struktur, bukan keyakinan buta: cakupannya tertulis eksplisit dalam konfigurasi, status eksekusi dan trace-nya terlihat, dan hasilnya kembali ke Task tempat seseorang meninjau dan menerimanya. Agent meneliti, mengeksekusi, menguji, dan melaporkan. Manusia yang menentukan arah, memberikan kewenangan, dan menerima hasilnya.
Apa itu Agent (dan apa yang bukan)
Agent adalah pelaku AI yang dikonfigurasi untuk menangani pekerjaan di Sharkly. Ia dapat menerima Task yang ditugaskan, menulis komentar, memperbarui status Task melalui workflow yang tersedia, dan menghasilkan execution trace. Karena konfigurasinya tersimpan, sebuah tim dapat memelihara Agent terpisah untuk perubahan kode, review, pengujian, dokumentasi, atau triage operasional tanpa harus menulis ulang instruksi yang sama untuk setiap Task.
Ada dua batas yang penting diketahui sejak awal.
Agent bukan host eksekusi. Pekerjaannya berjalan melalui Runtime yang dipilih pada Computer yang terhubung. Agent menentukan bagaimana pekerjaan harus ditangani; Computer menyediakan host; Runtime menjalankan sesi sebenarnya; dan Task tetap menjadi catatan bersama. Setiap peran punya satu tugas, itulah sebabnya satu Computer dapat melayani beberapa Agent.
Agent tidak memilih modelnya sendiri. Ia mengikuti model default Runtime, dan tidak ada pemilih model atau kontrol kedalaman berpikir pada Agent. Untuk memakai model lain, ubah di konfigurasi tool Runtime atau Computer, misalnya di Claude Code atau Codex itu sendiri.
Kepercayaan adalah sifat sistem, bukan model
Inilah argumen yang menjadi dasar artikel ini: sebuah agent dapat dipercaya ketika pekerjaannya terbatas cakupannya, terlihat, dan dapat ditinjau. Bukan ketika modelnya mengesankan.
Cakupan terbatas berarti kewenangan Agent dituliskan sebelum ia berjalan: repositori mana yang boleh disentuh, Computer mana yang dipakai untuk eksekusi, apa yang diizinkan oleh instruksinya, berapa banyak Task yang boleh berjalan sekaligus, dan berapa lama sebuah run boleh berlangsung. Terlihat berarti status run, event trace, dan hasil dikembalikan ke Task tempat siapa pun dapat memeriksanya, bukannya menghilang ke dalam terminal pribadi. Dapat ditinjau berarti ada manusia di ujung proses: Agent dapat meninggalkan Task dalam keadaan menunggu balasan manusia atau menunggu review manusia, dan sinyal-sinyal itu masuk ke Inbox orang yang bertanggung jawab.
Itulah kontrak manusia-agent dalam praktik. Otomasi berhenti di titik yang membutuhkan pertimbangan tim. Jika Anda masih menimbang workflow-nya sendiri, panduan kami tentang agentic coding membahas pergeseran dari memberi prompt menjadi memberikan pekerjaan.
Area konfigurasi Agent
Agent dapat mencakup nama, deskripsi, avatar, dan pemilik; instruksi operasional; visibilitas dan penempatan Space; koneksi Computer dan penyedia Runtime; Skills yang ditugaskan; repositori Git khusus Agent; variabel environment biasa dan rahasia; argumen Runtime tambahan; pengaturan Task Working Directory; serta batas maksimum Task yang berjalan paralel plus timeout per Task. Setiap bagian adalah tuas kepercayaan.
Instructions disertakan pada setiap run. Gunakan untuk perilaku yang harus tetap berlaku di semua Task: cakupan dan peran, cara memeriksa Task sebelum bertindak, kapan harus meminta masukan manusia, pemeriksaan yang diharapkan, dan format pelaporan. Dokumentasi menarik garis tiga arah yang berguna: kebutuhan spesifik Task masuk ke deskripsi atau komentar Task, prosedur yang dapat digunakan ulang dan mungkin dipakai bersama beberapa Agent masuk ke Skill, dan instruksi milik Agent sendiri memuat identitasnya yang stabil. "Baca deskripsi Task dan komentar terbaru sebelum mengedit. Batasi perubahan hanya pada perilaku yang diminta. Jalankan pemeriksaan yang paling relevan dan laporkan kegagalan tanpa menyembunyikannya" sebaiknya ada di Agent, karena hal itu harus tetap berlaku hari Senin dan masih berlaku di bulan Maret. Deskripsi melayani pembaca yang berbeda: ia memberi tahu manusia apa yang bisa ditugaskan, sementara instruksi memberi tahu Agent cara bekerja.
Visibility bersifat Personal, hanya tersedia bagi pemiliknya saat ini, atau Space, tersedia bagi orang yang dapat mengakses Space milik Agent. Ini juga mengatur siapa yang boleh menugaskan Agent, memulai Agent Chat dengannya, atau memicunya lewat komentar atau mention. Mulailah dengan Personal saat menyetel konfigurasi; pindah ke Space ketika konfigurasi itu sudah layak dibagikan. Promosi itulah momen ketika praktik kerja satu developer menjadi infrastruktur tim.
Computer dan Runtime bergabung menjadi target eksekusi. Computer yang online hanya berarti layanan lokalnya mengirim heartbeat; itu tidak berarti Runtime yang dipilih dapat mengeksekusi Task. Jika Computer offline, run baru biasanya menunggu sampai tersambung kembali; jika Runtime yang dipilih sudah tidak ada, pilih Runtime lain yang memenuhi syarat. Kisah penyiapan selengkapnya ada di Computers in Sharkly.
Skills mengemas instruksi yang dapat digunakan ulang dan file pendukung: aturan review, checklist pengiriman, proses tim. Skills dari Runtime lokal otomatis tetap tersedia di Computer tersebut; Skills Space yang dibagikan harus ditugaskan secara eksplisit. Satu peringatan yang layak diulang: hindari mengikat banyak Skills yang saling tumpang tindih, karena instruksi yang bertentangan membuat eksekusi kurang dapat diprediksi. Lihat Skills in Sharkly untuk pembahasan mendalam.
Repositories adalah tuas pembatasan cakupan yang paling bersih. Lampirkan ke Agent ketika ia membutuhkan cakupan kode yang lebih sempit daripada default Space; jika tidak ada pengikatan, Sharkly kembali menggunakan repositori yang dikonfigurasi untuk Space milik Task tersebut. Agent dokumentasi yang terikat ke repositori docs tidak punya jalur ke layanan pembayaran Anda.
Environment dan pengaturan run membatasi apa yang dapat dikonsumsi sebuah run. Variabel environment biasa dan rahasia, plus argumen Runtime tambahan, memungkinkan sebuah run membawa konfigurasi tanpa ada yang menempelkan kredensial ke dalam Task. Jangan pernah menaruh token repositori, private key, atau token instalasi di deskripsi Task, komentar, instruksi Agent, atau Skill. Task Run Settings mengatur Task paralel, durasi run maksimum, dan mode working directory:
| Mode Temporary | Mode Specified | |
|---|---|---|
| Yang didapat sebuah run | Direktori terisolasi per Task; run yang berbasis repositori dapat menyiapkan worktree baru | Satu direktori lokal absolut terkonfigurasi dari kumpulan direktori milik Agent |
| Concurrency | Eksekusi paralel lebih aman; default-nya 50% dari batas Computer | Satu run per direktori pada satu waktu; default-nya sama dengan jumlah direktori |
| Ketersediaan | Computer mana pun yang terhubung | Hanya Computer lokal |
| Paling cocok untuk | Sebagian besar pekerjaan repositori, dan setiap kali beberapa Task berpotensi mengubah codebase yang sama secara paralel | Repositori yang sangat besar, cache lokal yang mahal, atau Task yang terikat pada layanan lokal |
Jika Anda menetapkan nilai concurrency manual lebih tinggi daripada jumlah direktori, produk akan memperingatkan bahwa penulisan bisa bertabrakan. Mekanisme isolasinya dibahas di bagaimana Sharkly menjalankan Agent secara paralel tanpa merge conflict.
Percakapan vs Task: dua antarmuka, satu aturan
Agent Chat adalah percakapan mandiri untuk mengajukan pertanyaan, menyelidiki suatu topik, atau menyusun rencana sebelum ada yang memerlukan Task yang terlacak. Chat mendukung tiga mode: Explore untuk penyelidikan read-only, Plan untuk proposal yang Anda tinjau dan konfirmasi sebelum Sharkly membuat task dan subtask yang direncanakan, dan Execute untuk tindakan langsung melalui CLI yang dikonfigurasi pada Agent. Setiap sesi menjadi milik orang yang membuatnya.
Task adalah tempat pekerjaan berlanjut ketika ia membutuhkan kepemilikan, status, riwayat eksekusi, atau review. Pasangan keputusannya: gunakan Chat untuk menjelajah, merencanakan, atau bertindak sebelum pekerjaan memerlukan Task yang terlacak; gunakan Task ketika pekerjaan membutuhkan Assignee, status, kriteria penerimaan, atau catatan yang bertahan lama.
Satu batas mencegah tim kehilangan konteks. Mengirim pesan di Agent Chat tidak membuat komentar task, dan pesan di Agent chat milik sebuah task tidak muncul di Activity sebagai komentar. Jika tim perlu melihat sebuah kesimpulan, salinlah ke deskripsi task atau komentar. Kepercayaan bergantung pada catatan bersama, dan catatan bersama itu adalah Task.
Apa yang diberitahukan status kepada Anda
Visibilitas di sini adalah sekumpulan status tertentu yang dapat Anda baca, bukan sekadar slogan dasbor.
Sebuah run Task bergerak melalui queued, dispatched, waiting for local directory, running, completed, failed, dan canceled. Status run terpisah dari status workflow Task: sebuah run bisa gagal sementara Task tetap terbuka untuk percobaan lain. Log eksekusi mencatat mengapa sebuah run diantrekan, kapan dimulai dan berakhir, panggilan tool dan event Runtime, sumber pemicunya, serta detail kegagalan.
Ketersediaan Agent adalah sinyal ketiga yang terpisah. Agent yang online bisa saja masih memiliki pekerjaan yang mengantre karena concurrency atau kapasitas direktori sudah penuh. Dan Backlog berfungsi sebagai area parkir: Task yang ditugaskan ke Agent akan menunggu selama berada di Backlog, dan memindahkannya ke status yang siap dikerjakan itulah yang memulai run. Menugaskan Agent tidak pernah memicu pekerjaan secara tiba-tiba.
Agent pertama Anda: panduan langkah demi langkah yang bisa dipercaya
Cara tercepat membangun kepercayaan adalah loop terkecil yang berguna dari dokumentasi Sharkly: hubungkan satu Computer, buat satu Agent, dan tugaskan satu Task berisiko rendah.
- Hubungkan sebuah Computer. Buka Settings, lalu Computers, dan pilih Connect Computer. Tunggu sampai statusnya terhubung dengan setidaknya satu Runtime yang tersedia.
- Buat Agent dengan peran yang sempit. Name: Code Reader. Description: membaca repositori, menjelaskan implementasi saat ini, dan melaporkan risiko tanpa mengubah file. Visibility: Personal.
- Tulis instruksi yang menegakkan cakupan tersebut: "Baca seluruh Task dan komentar yang relevan sebelum bertindak. Batasi cakupan pada permintaan. Untuk Task pertama, jangan mengedit file. Laporkan apa yang Anda periksa, bukti untuk setiap kesimpulan, dan hal apa pun yang masih belum pasti."
- Ikatkan kodenya. Lampirkan repositori Git atau konfigurasikan direktori lokal tertentu yang sudah memuatnya. Skills bisa menyusul.
- Buat Task kecil yang hanya berbasis teks: tinjau jalur error autentikasi, identifikasi tiga kasus kegagalan yang terlihat oleh pengguna, sebutkan file yang relevan untuk masing-masing, jangan ubah apa pun.
- Tugaskan dan mulai, dengan status yang siap dikerjakan, bukan Backlog. Amati status run berpindah dari queued ke running, lalu baca hasilnya di Task.
- Tinjau dengan sungguh-sungguh. Periksa bahwa Agent memeriksa kode yang dimaksud, tetap dalam batas tanpa edit, memberikan bukti, dan mencatat ketidakpastian alih-alih menebak.
Langkah terakhir itulah intinya. Task pertama yang hanya read-only memungkinkan Agent memperoleh kewenangan sebelum ia benar-benar memegangnya. Setelah loop-nya berjalan, perluas cakupan secara sengaja. Mekanisme penugasan selengkapnya ada di cara menugaskan Task pertama Anda ke AI coding Agent.
Dan jika sebuah Agent berhenti mendapatkan kepercayaan itu, pencabutannya bersih. Mengarsipkan akan menghapusnya dari penugasan dan mention serta membatalkan pekerjaan yang sedang berjalan, sementara Task, komentar, dan riwayat run sebelumnya tetap tersedia. Rekan tim yang bisa Anda lepas tanpa kehilangan catatan pekerjaannya adalah rekan tim yang layak untuk Anda rekrut.
FAQ
Apa sebenarnya Agent di Sharkly?
Agent adalah pelaku AI yang dikonfigurasi untuk menangani pekerjaan di Sharkly: konfigurasi tersimpan berisi instruksi, pengikatan Computer dan Runtime, Skills, repositori, variabel environment, dan pengaturan run. Ia dapat menerima Task yang ditugaskan, menulis komentar, memperbarui status Task, dan menghasilkan execution trace. Karena konfigurasinya tersimpan, praktik kerja satu orang menjadi dapat digunakan ulang ketika Agent dibagikan ke sebuah Space.
Model apa yang digunakan Agent Sharkly?
Agent mengikuti model default dari Runtime yang dipilihnya, seperti Claude Code atau Codex, dan tidak menampilkan atau menjanjikan nama model tertentu. Tidak ada pemilih model atau kontrol kedalaman berpikir pada Agent. Untuk mengganti model, perbarui konfigurasi tool Runtime atau Computer.
Apa perbedaan antara mengobrol dengan Agent dan menugaskannya sebuah Task?
Agent Chat adalah percakapan mandiri untuk menjelajah, merencanakan, atau bertindak sebelum pekerjaan memerlukan catatan yang terlacak. Task adalah unit kerja bersama, dengan Assignee, status, riwayat eksekusi, dan review. Pesan Chat tidak menjadi komentar task, jadi kesimpulan yang perlu dilihat tim harus diletakkan di Task.
Bagaimana cara membatasi apa yang bisa dilakukan Agent?
Cakupan diatur dalam konfigurasi: instruksi menentukan peran dan aturan kehati-hatian, pengikatan repositori membatasi kode yang dilihat Agent, dan Task Run Settings membatasi jumlah Task paralel serta durasi run. Mode working directory Temporary menambah isolasi dengan memberi setiap Task direktorinya sendiri. Penerimaan akhir tetap ada di tangan manusia.
Mengapa Task yang saya tugaskan tidak dimulai?
Periksa tiga hal. Task di Backlog memang menunggu secara desain; pindahkan ke status yang siap dikerjakan. Computer yang online hanya berarti heartbeat sedang masuk, jadi pastikan Runtime yang dipilih berstatus tersedia. Dan Agent yang online bisa saja tetap mengantrekan pekerjaan ketika concurrency atau direktori yang ditentukan sudah penuh.
