AI Agent vs Otomatisasi Biasa: Jangan Bayar Kompleksitas yang Tidak Anda Butuhkan

AI agent terdengar seperti tahap berikutnya dari otomatisasi: beri tujuan, hubungkan tools, lalu biarkan sistem menentukan langkah. Tetapi otonomi bukan upgrade gratis. Setiap keputusan yang Anda serahkan ke model menambah ruang variasi, kebutuhan evaluasi, latency, biaya, permission, dan kemungkinan failure yang lebih sulit direproduksi.

Anthropic membedakan workflow LLM dan tools berjalan melalui code path yang sudah ditentukan dengan agent, ketika model secara dinamis menentukan proses dan penggunaan tool. Prinsip engineering mereka sederhana: mulai dari solusi paling sederhana dan tambah kompleksitas hanya jika hasilnya benar-benar membaik.

AIUpdateId setuju, tetapi kita perlu membuat prinsip itu operasional.

Ringkasan: pilih level otonomi, bukan label “agent”

Jangan bertanya “apakah kita perlu AI agent?”. Tanyakan:

Di titik mana workflow membutuhkan keputusan model yang tidak bisa ditentukan secara andal dengan rules?

Kemudian berikan otonomi hanya pada titik itu.

AIUpdateId Autonomy Ladder

Kesalahan umum adalah melompat dari level 1 ke level 5 karena demo terlihat impresif.

Kasus 1 — formulir masuk → CRM → email

Kebutuhan: setiap form valid dibuat menjadi lead dan menerima email konfirmasi.

Rules:

form valid → insert CRM → send template → log success

Apa yang harus “dipikirkan” agent? Hampir tidak ada.

Menambahkan LLM untuk memilih apakah data harus dimasukkan, tool mana dipanggil, dan email apa dikirim justru menambah kemungkinan output yang tidak konsisten.

Pilihan AIUpdateId: rules automation.

Kasus 2 — email support pelanggan

Input bahasa alami membuat rules mulai rapuh. “Barang belum sampai”, “paket saya nyangkut”, dan “kurir tidak datang” bisa memiliki intent serupa tetapi wording berbeda.

Di sini AI berguna untuk klasifikasi.

Workflow yang lebih aman:

email → AI klasifikasi intent + confidence → rules cek policy → draft response → approval untuk refund/aksi sensitif

AI menangani ambiguity. Rules menangani policy. Manusia menangani keputusan dengan konsekuensi.

Pilihan AIUpdateId: hybrid/fixed workflow.

Kasus 3 — riset vendor dari sumber yang berbeda

Tugas: cari vendor yang memenuhi kriteria, buka dokumentasi, bandingkan fitur, cari informasi yang hilang, lalu buat shortlist.

Jumlah langkah sulit ditentukan dari awal. Vendor A mungkin punya dokumentasi lengkap; vendor B membutuhkan pencarian tambahan; vendor C harus dikeluarkan setelah menemukan batasan tertentu.

Di sini kemampuan model memilih langkah berikutnya mulai memberi nilai.

Pilihan AIUpdateId: bounded agent, tetapi dengan batas sumber, tool, jumlah langkah, dan schema output.

Kasus 4 — agent boleh mengirim pembayaran atau menghapus data

Sekarang pertanyaannya bukan hanya akurasi. Ada blast radius.

Agent yang salah mengklasifikasi dokumen menghasilkan jawaban buruk. Agent yang salah memilih tindakan dengan permission besar dapat mengubah state dunia nyata.

Prinsipnya:

Semakin sulit tindakan dibatalkan, semakin kecil otonomi yang seharusnya diberikan tanpa approval.

Decision Matrix: kapan kompleksitas agent layak dibayar?

Nilai setiap dimensi secara kualitatif.

Jika kolom kiri mendominasi, “agent” kemungkinan hanya menambah kompleksitas.

Biaya tersembunyi agent

1. Error surface membesar

Satu call model punya satu ruang kegagalan. Agent multi-step dapat gagal pada planning, retrieval, tool selection, parameter, interpretation, state, atau stopping condition.

2. Latency menjadi kumulatif

Agent yang melakukan beberapa model/tool call secara serial lebih lambat daripada satu workflow sederhana. Ini trade-off, bukan bug.

3. Biaya menjadi variabel

Workflow fixed lebih mudah memperkirakan jumlah call. Agent yang menentukan langkah sendiri dapat memakai jumlah langkah berbeda untuk input berbeda.

4. Reproduksi lebih sulit

Jika path berubah, debugging tidak cukup melihat output final. Anda membutuhkan trace: tool apa dipilih, inputnya apa, state apa berubah, dan checkpoint mana gagal.

5. Permission menjadi masalah arsitektur

Jangan memberi agent permission “karena nanti mungkin dibutuhkan”. Gunakan least privilege dan pisahkan tindakan read-only dari tindakan yang mengubah data.

Failure taxonomy yang harus diuji

Sebelum production, jangan hanya test happy path.

Uji:

• salah memilih tool;
• tool timeout;
• data kosong;
• instruksi ambigu;
• sumber bertentangan;
• agent mengulang langkah;
• agent berhenti terlalu cepat;
• output tool berubah format;
• action membutuhkan approval;
• partial success: langkah 1 sukses, langkah 2 gagal;
• retry menyebabkan duplikasi aksi.

Anthropic pada 2026 menekankan eval untuk agent karena autonomy dan multi-turn behavior membuat sistem lebih sulit dievaluasi. Tanpa eval, tim mudah menemukan failure baru setelah production.

Minimum eval sebelum agent diberi lebih banyak otonomi

Buat set tugas nyata bukan hanya demo yang Anda tahu akan berhasil.

Untuk setiap task, catat:

Kemudian bandingkan workflow sederhana vs agent.

Jika agent lebih mahal dan lambat tetapi tidak meningkatkan task success secara berarti, Anda sudah memperoleh jawaban arsitektur: jangan pakai agent.

Pola hybrid yang sering lebih masuk akal

AI di tengah rules

rules → AI interpretation → rules

Bagus ketika hanya satu bagian yang ambigu.

Agent dengan approval gate

agent research → proposed action → human approval → deterministic execution

Bagus ketika planning membutuhkan fleksibilitas tetapi action berisiko.

Agent read-only

Berikan kemampuan mencari dan menganalisis tanpa permission mengubah sistem. Naikkan permission hanya setelah eval menunjukkan kebutuhan.

Deterministic shell, probabilistic core

Biarkan input validation, permission, logging, retry, dan final action ditangani code. Gunakan model pada bagian yang memang membutuhkan interpretasi.

Ini sering lebih mudah dioperasikan daripada menjadikan seluruh aplikasi “agentic”.

Tujuh pertanyaan sebelum Anda menyebut agent sebagai kebutuhan

1. Bagian mana yang tidak bisa diselesaikan rules?
2. Mengapa fixed workflow tidak cukup?
3. Keputusan apa yang benar-benar harus dibuat model saat runtime?
4. Bagaimana kita tahu keputusan itu benar?
5. Apa blast radius jika salah?
6. Apa tindakan yang wajib approval?
7. Eval apa yang membuktikan agent lebih baik daripada baseline sederhana?

Jika nomor 7 belum punya jawaban, Anda belum membuktikan kebutuhan agent. Anda baru memilih arsitektur.

Pandangan AIUpdateId

AI agent bukan tujuan akhir otomatisasi.

Tujuan akhirnya adalah workflow yang menyelesaikan pekerjaan dengan kualitas, biaya, kecepatan, dan risiko yang dapat diterima. Kadang jawabannya agent. Kadang satu call LLM. Kadang script 30 baris. Kadang tidak perlu AI sama sekali.

Prinsip AIUpdateId:

Berikan model otonomi hanya pada keputusan yang membutuhkan fleksibilitas model. Pertahankan sisanya deterministik selama mungkin.

Itu membuat sistem bukan hanya lebih sederhana, tetapi lebih mudah diuji, diaudit, dan diperbaiki ketika gagal.

Jalur lanjut

Untuk menilai apakah tugas bahkan layak memakai AI, baca kapan jangan pakai AI. Untuk memahami spektrum bantuan sebelum agent, baca apa itu AI Copilot.

Sumber utama

• Anthropic — Building Effective Agents
• Anthropic — Demystifying evals for AI agents
• OpenAI — Agentic workflows