Mulai dari Pekerjaan, Bukan Tools yang Lagi Hype

Tool baru sering memberi ilusi bahwa proyek AI sudah dimulai. Padahal, kalau pekerjaannya belum dipilih, tim baru punya perangkat lunak dan sederet kemungkinan.

Masalahnya ada di urutan. Ada tool baru yang terlihat mampu, tim langsung memasang, lalu semua orang diminta mencoba. Karena belum ada pekerjaan spesifik yang dipilih, cakupannya melebar: bantu pemasaran, operasional, penjualan, sekaligus produk. Beberapa minggu kemudian, demo mungkin ada, tetapi tidak ada alur yang benar-benar menjadi kebiasaan kerja.

Teknologinya belum tentu salah. Tim juga belum tentu kurang antusias. Yang belum jelas adalah pekerjaan apa yang mau didelegasikan, bagaimana prosesnya berjalan, dan kapan hasilnya dianggap beres.

Urutannya perlu dibalik: tentukan pekerjaan, batas, dan hasilnya dulu. Baru pilih tools yang memang dibutuhkan.

Kenapa Label Besar Susah Dieksekusi

“Bikin Marketing Agent” terdengar seperti arah yang jelas. Begitu masuk ke implementasi, label itu memuat terlalu banyak pekerjaan: riset kompetitor, menyusun content plan, menulis draft, membaca performa campaign, menyiapkan laporan, sampai mengirim follow-up.

Masing-masing punya input, risiko, owner, dan standar hasil yang berbeda. Menyatukannya sejak awal membuat tim sulit menjawab pertanyaan sederhana: kalau agent gagal, bagian mana yang sebenarnya perlu diperbaiki?

Scope yang terlalu lebar juga membuat kebutuhan tools terlihat lebih besar dari kondisi sebenarnya. Tim merasa perlu browser, akses spreadsheet, dashboard, email, CRM, dan kemampuan publish sekaligus. Padahal workflow pertama mungkin cuma membutuhkan akses baca ke satu sumber dan menghasilkan satu draft untuk diperiksa manusia.

Efek lainnya: ownership jadi blur. Karena agent ditujukan untuk membantu semua fungsi, tidak ada satu owner yang benar-benar memegang definisi input, output, dan kualitas. Ketika prioritas tim berubah, workflow ikut berubah tanpa kontrak yang jelas. Memilih satu pekerjaan sekaligus memilih siapa yang bertanggung jawab atas desain dan review-nya.

Memulai dari job yang sempit bukan berarti visinya kecil. Justru di situ asumsi bisa diuji satu per satu: sumbernya benar atau tidak, output-nya berguna atau tidak, dan checkpoint manusianya ditempatkan dengan tepat atau tidak.

Filter Pekerjaan Pertama

Pilih satu pekerjaan yang memenuhi beberapa karakteristik berikut:

• berulang cukup sering;
• punya input yang bisa dikenali;
• menghasilkan output yang jelas;
• punya aturan yang relatif stabil;
• dan manfaatnya terasa kalau waktu pengerjaannya berkurang.

Filter ini membantu membedakan pekerjaan nyata dari sekadar ide fitur. Pekerjaan berulang memberi kesempatan untuk mengamati pola. Input yang dikenali membuat trigger lebih mudah ditentukan. Output yang jelas memberi dasar untuk review. Aturan yang relatif stabil mengurangi kemungkinan agent harus menebak-nebak setiap kali berjalan.

Tidak semua poin harus sempurna sejak hari pertama. Namun, makin banyak yang masih kabur, makin sulit workflow tersebut dirancang dan dievaluasi.

Ubah Ambisi Menjadi Job Description

Bandingkan “bikin Marketing Agent” dengan instruksi berikut:

Setiap Jumat, kumpulkan performa campaign dari sumber yang disepakati, tandai perubahan penting, buat draft laporan satu halaman, lalu minta approval sebelum laporan dikirim ke tim.

Versi kedua belum otomatis siap dibangun, tetapi bentuk kerjanya sudah kelihatan.

Ada trigger: setiap Jumat.

Ada input: data performa campaign dari sumber yang disepakati.

Ada flow: kumpulkan, bandingkan, tandai, lalu rangkum.

Ada output: draft laporan satu halaman.

Ada approval: manusia memeriksa sebelum pengiriman.

Ada success criteria: angka sesuai sumber, perubahan penting tidak terlewat, dan tidak ada kesimpulan yang dikarang.

Detail seperti ini mengubah percakapan tim. Pertanyaannya tidak lagi “agent mana yang paling canggih?”, tetapi “kemampuan apa yang dibutuhkan untuk menjalankan flow ini dengan aman?”

Baru Petakan Kebutuhan Teknologi

Setelah bentuk pekerjaan jelas, pemilihan teknologi jadi lebih grounded.

Apakah agent perlu membaca spreadsheet atau dashboard? Perlukah browser, file, atau API? Apakah workflow harus berjalan terjadwal di cloud, lewat VPS, atau cukup dari komputer lokal? Model seperti apa yang memadai untuk tugas tersebut dan masih masuk budget?

Jawabannya mengikuti kebutuhan job, bukan tren tools.

Kalau agent hanya membuat draft laporan, akses tulis mungkin belum diperlukan. Kalau sumber datanya cuma satu spreadsheet, integrasi ke lima aplikasi lain belum memberi value. Kalau workflow dijalankan seminggu sekali dan selalu diperiksa owner, desain operasionalnya berbeda dari agent yang harus merespons event sepanjang hari.

Teknologi tetap penting. Namun, teknologi baru bisa dipilih dengan masuk akal setelah pekerjaan, batas, dan output-nya kelihatan.

Pilih Hasil yang Bisa Diperiksa

Ada satu filter tambahan: pilih workflow yang hasilnya bisa diperiksa oleh orang yang memahami pekerjaannya.

Jangan mulai dari proses yang kriterianya sendiri belum disepakati tim. Kalau dua manager masih punya definisi berbeda tentang “laporan yang bagus”, agent akan menerima target yang berubah-ubah. Ketika output-nya ditolak, tim juga tidak punya diagnosis yang solid: agent-nya bermasalah atau ekspektasi manusianya yang belum align?

Lebih aman mulai dari pekerjaan yang punya contoh output, sumber data, owner, dan aturan eskalasi yang jelas. Ambil tiga sampai lima contoh sebelumnya. Tandai bagian yang selalu sama, bagian yang membutuhkan judgment, serta kesalahan yang paling sering muncul.

Dari sana, pisahkan tiga jenis langkah:

1. langkah yang cukup mekanis dan dapat dijalankan agent;
2. langkah yang dapat disiapkan sebagai draft;
3. keputusan yang harus tetap dipegang manusia.

Pembagian ini membuat delegasi lebih realistis. Tujuannya bukan memaksa seluruh proses berjalan tanpa manusia, melainkan menempatkan kerja mekanis dan judgment di tempat yang tepat.

Sempit Dulu, Lalu Perluas dengan Alasan

Workflow pertama harus cukup sempit untuk diuji, tetapi tetap berguna untuk dipakai lagi. Setelah flow kecil itu stabil, baru tambah sumber data, akses, atau langkah baru.

Dokumentasikan perubahan tersebut. Catat kemampuan baru yang ditambahkan, alasan penambahannya, dan risiko yang ikut muncul. Kebiasaan kecil ini menjaga perluasan scope tetap intentional, bukan terjadi diam-diam karena setiap orang meminta satu fitur tambahan.

Dengan urutan ini, setiap upgrade punya alasan yang bisa diperiksa. Tim dapat melihat apakah penambahan tool benar-benar menyelesaikan bottleneck, atau hanya menambah kompleksitas. Ketika hasil meleset, area pencariannya juga lebih kecil: trigger, input, instruction, tool, approval, atau evaluation.

Sebelum membuka halaman perbandingan platform, tulis satu kalimat job description untuk workflow pertama lo. Sebutkan kapan pekerjaan dimulai, input yang dipakai, output yang dibuat, dan siapa yang memeriksanya. Kalau kalimat itu belum bisa ditulis, kebutuhan teknologinya juga belum cukup jelas untuk dibandingkan.

Di Building AI Employees, lo akan memetakan job description tersebut sebelum merancang agent dengan tools, batas, approval, dan output yang bisa dicek.

Latihannya dimulai dari pekerjaan nyata agar keputusan platform mengikuti kebutuhan, bukan tren.

Lihat detail Building AI Employees.