Memilih Platform AI Agent

Platform paling powerful bisa menjadi pilihan paling merepotkan kalau kekuatannya tidak dibutuhkan oleh workflow lo.

Bukan karena platform-nya jelek. Masalahnya, kata “terbaik” hampir selalu kehilangan context: terbaik untuk pekerjaan apa, dipakai lewat interface mana, berjalan kapan, mengakses data apa, dan dirawat oleh siapa?

Agent yang membantu coding di repository punya kebutuhan berbeda dari agent yang menerima instruksi lewat chat sepanjang hari. Agent untuk dokumen internal berbeda dari workflow yang akan mengirim pesan ke pelanggan. Membandingkan semuanya dengan satu ranking bikin keputusan terlihat simpel, padahal constraint-nya beda.

Karena itu, jangan mulai dari logo, ranking, atau daftar fitur. Mulai dari bentuk pekerjaan dan constraint yang harus dipenuhi.

Definisikan Pekerjaan Sebelum Membandingkan Tools

Tulis satu pekerjaan yang cukup spesifik. Bukan “membantu operations”, tetapi misalnya “mengubah meeting notes menjadi draft keputusan dan action items untuk direview sebelum dikirim”.

Dari sana, petakan trigger, input, output, tool, approval, dan success criteria. Baru tanyakan apakah platform yang sedang dipertimbangkan mendukung flow tersebut dengan tingkat kontrol yang dibutuhkan.

Tanpa definisi pekerjaan, tim gampang terpikat kemampuan yang sebenarnya tidak relevan. Browser automation terlihat menarik, padahal use case pertama hanya butuh membaca tiga dokumen dan membuat draft. Runtime 24/7 terasa advanced, padahal agent hanya dipakai sesekali oleh satu orang di laptop.

Cakupan yang jelas membuat perbandingan lebih adil. Lo tidak lagi bertanya, “Platform A atau B lebih bagus?” Pertanyaannya berubah menjadi, “Mana yang paling sesuai dengan kebutuhan dan batas alur ini?”

Periksa Interface Pengguna

Cara orang memberi instruksi akan memengaruhi adoption dan control.

Ada pekerjaan yang natural dilakukan lewat web atau desktop. Ada yang dekat dengan terminal dan repository. Ada juga yang membutuhkan chat karena pengguna sering mobile atau ingin memberi instruksi singkat dari HP.

Interface bukan sekadar preferensi. Ia menentukan bagaimana context diberikan, bagaimana preview ditampilkan, dan bagaimana approval diminta. Workflow yang perlu memperlihatkan diff file mungkin lebih nyaman di environment yang mendukung repository. Workflow yang menunggu konfirmasi cepat dari tim lapangan mungkin membutuhkan channel lain.

Tanyakan juga siapa penggunanya. Setup yang nyaman buat engineer belum tentu masuk akal buat tim sales atau operations. Kalau setiap action membutuhkan langkah teknis yang tidak familiar, capability yang kuat bisa tetap tidak terpakai.

Tentukan Kebutuhan Runtime

Apakah agent hanya aktif ketika seseorang membukanya, atau harus tersedia saat laptop user mati?

Agent yang dipakai untuk sesi coding dapat berjalan ketika developer bekerja. Agent yang memantau trigger terjadwal atau menerima instruksi sepanjang hari mungkin membutuhkan runtime yang terus tersedia.

Kebutuhan ini akan memengaruhi pilihan managed cloud, VPS, server, atau komputer lokal. Tidak ada jawaban universal. Runtime selalu aktif membawa kebutuhan monitoring dan recovery. Runtime lokal membawa ketergantungan pada perangkat, koneksi, dan permission di mesin tersebut.

Jangan membayar kompleksitas 24/7 kalau use case tidak membutuhkannya. Sebaliknya, jangan menaruh workflow yang harus selalu siap di setup yang mati ketika laptop ditutup.

Petakan Data, Tools, dan Permission

Platform baru berguna kalau ia bisa mengakses resource yang memang dibutuhkan dengan batas yang masuk akal.

Daftarkan file, aplikasi, API, database, atau channel yang akan dipakai. Lalu tentukan level akses minimum: read, create, update, send, atau delete. Cek apakah permission dapat dibatasi per workspace, folder, repository, account, atau action.

Perhatikan juga lokasi data dan jalur pemrosesannya. Runtime lokal tidak otomatis berarti semua data tetap lokal jika model atau tool memakai provider eksternal. Managed service juga tidak otomatis unsafe; evaluasinya bergantung pada konfigurasi, policy, connector, dan kebutuhan organisasi.

Pertanyaan yang tepat bukan cuma “bisa connect ke apa?”, tetapi “siapa yang boleh menghubungkan, credential disimpan di mana, dan action mana yang harus menunggu approval?”

Hitung Beban Operasional

Platform self-hosted dapat memberi kontrol lebih besar atas runtime, model provider, storage, dan integrasi. Kontrol itu datang bersama ownership.

Siapa yang melakukan deployment? Siapa yang menangani update, backup, firewall, logging, dan incident ketika service gagal? Kalau satu-satunya orang yang paham setup sedang tidak tersedia, apa yang terjadi?

Managed service dapat mengurangi sebagian pekerjaan infrastruktur, tetapi tim tetap perlu mengelola workspace policy, connector, credential, permission, dan penggunaan. “Managed” bukan berarti governance menghilang.

Nilai kemampuan operasional tim secara jujur. Platform yang fleksibel belum tentu fit kalau maintenance-nya tidak punya owner. Platform yang lebih constrained bisa jadi cukup jika pekerjaan dan risk boundary-nya memang sederhana.

Pahami Pola Biaya, Bukan Cuma Harga Awal

Ada biaya yang predictable melalui subscription. Ada yang berubah mengikuti model, token, storage, API, atau volume penggunaan. Ada pula biaya dalam bentuk waktu setup, maintenance, troubleshooting, dan review manusia.

Jangan membuat perbandingan dari angka yang tidak setara. Harga lisensi tidak mewakili total ownership. Estimasi penggunaan juga perlu berdasarkan workflow yang realistis, bukan asumsi bahwa agent akan selalu berjalan pada beban maksimum atau minimum.

Untuk tahap awal, lebih berguna membuat kategori biaya dan siapa pemiliknya. Angka bisa diisi setelah requirement dan provider aktual sudah jelas.

Lakukan Proof of Fit yang Terbatas

Sebelum mengunci platform untuk banyak workflow, uji satu pekerjaan dengan scope terbatas.

Gunakan input yang representatif. Cek apakah context mudah disiapkan, tool dapat dibatasi, approval terlihat, output bisa dievaluasi, serta error dapat dipahami. Catat juga effort untuk setup dan maintenance, bukan hanya kualitas demo pertama.

Uji kecocokan bukan lomba membuat agent paling rumit. Uji ini harus menjawab apakah platform tersebut masuk ke cara kerja tim tanpa menciptakan risiko dan beban yang tidak disadari.

Kalau dua platform sama-sama memenuhi kebutuhan, pilih setup yang lebih sederhana untuk dijalankan dan dijaga. Complexity perlu punya alasan.

Platform Adalah Keputusan Desain, Bukan Identitas

Hermes, OpenClaw, Claude, dan Codex punya karakter serta interface yang berbeda. Fitur dan ketentuan masing-masing juga bisa berubah, jadi klaim detail perlu diperiksa terhadap dokumentasi resmi saat keputusan dibuat.

Di Building AI Employees, Hermes dipakai sebagai laboratorium praktik. Itu bukan klaim bahwa Hermes selalu menjadi pilihan terbaik. Framework desainnya tetap melihat pekerjaan, interface, runtime, context, tools, permission, approval, evaluation, dan kemampuan operasional tim.

Dengan framework tersebut, lo bisa menerjemahkan keputusan ke platform lain tanpa menganggap semua implementasi identik.

Dalam sesi, lo akan memetakan kebutuhan workflow dan menguji apakah pilihan platformnya masuk akal sebelum menambah integrasi.

Workshop berlangsung Sabtu, 5 September 2026, pukul 08.30-11.00 WIB via Zoom. Lihat detail Building AI Employees.

Pilih platform setelah pekerjaan punya bentuk. Fitur baru meaningful ketika lo tahu siapa yang memakainya, action apa yang boleh dilakukan, dan siapa yang menjaga sistemnya setelah demo tidak lagi menjadi pusat perhatian.