AI Model, Workflow, dan Agent: Apa Bedanya?

AI Model, Workflow, dan Agent: Apa Bedanya?

Istilah “AI biasa” dan “AI agent” sering dipakai seolah dua teknologi yang sepenuhnya berbeda. Kenyataannya, agent biasanya tetap memakai model AI sebagai komponen pengambil keputusan. Perbedaannya berada pada sistem di sekeliling model: tools, state, loop eksekusi, permission, dan mekanisme evaluasi.

Tiga Tingkat yang Perlu Dibedakan

Model menerima input dan menghasilkan output. Contohnya model bahasa yang menjawab pertanyaan atau membuat ringkasan. Model sendiri tidak otomatis memiliki akses ke email, database, browser, atau terminal.

Workflow menghubungkan model dan tools melalui jalur yang ditentukan developer:

input → klasifikasi → pilih template → buat draf → validasi → output

Control flow relatif mudah diprediksi. Model mungkin mengisi satu langkah, tetapi kode menentukan urutannya.

Agent diberi tujuan dan dapat menentukan langkah berikutnya berdasarkan hasil sementara:

tujuan → rencana → panggil tool → amati hasil → perbaiki rencana → selesai

Definisi tidak seragam antarproduk. Karena itu, dokumentasi arsitektur lebih berguna daripada sekadar label “agentic”.

Tools Mengubah Dampak Kesalahan

Jawaban chatbot yang salah dapat menyesatkan pembaca. Agent yang salah dapat mengirim email, mengubah file, menjalankan query, atau membeli layanan jika tools dan permission mengizinkannya.

Setiap tool sebaiknya memiliki:

• schema input dan output yang ketat;
• autentikasi terpisah;
• permission paling kecil;
• timeout dan batas pemakaian;
• idempotency untuk operasi yang dapat diulang;
• audit log tanpa membocorkan secret;
• konfirmasi manusia untuk tindakan penting.

Jangan memberikan shell umum ketika agent hanya perlu membaca status deployment. Buat tool sempit seperti getDeploymentStatus(projectId).

Memory Bukan Ingatan Ajaib

Agent dapat menyimpan state percakapan, hasil tool, atau ringkasan pekerjaan. Itu bukan berarti seluruh konteks selalu benar dan permanen.

Bedakan:

• working context untuk satu eksekusi;
• checkpoint agar pekerjaan dapat dilanjutkan;
• user preference yang memang disetujui pengguna;
• knowledge base yang memiliki sumber dan waktu pembaruan.

Data sensitif memerlukan retensi, access control, penghapusan, dan audit. Jangan memasukkan password atau token ke memory model.

Kapan Workflow Lebih Tepat?

Gunakan workflow deterministik jika:

• proses dan cabangnya sudah diketahui;
• auditability penting;
• kesalahan memiliki dampak besar;
• latency dan biaya harus dapat diprediksi;
• langkah harus selalu dijalankan dalam urutan tertentu.

Contoh: validasi invoice, approval dokumen, atau pipeline penerbitan.

Gunakan agent jika:

• jumlah langkah sulit ditentukan sebelumnya;
• task membutuhkan eksplorasi dan penggunaan tool berulang;
• ada cara objektif untuk memeriksa hasil;
• kegagalan dapat dibatasi dan dipulihkan.

Contoh: menelusuri penyebab test gagal pada repository dengan sandbox dan test suite.

Agent menambah fleksibilitas, tetapi biasanya juga menambah latency, biaya, dan variasi hasil.

Loop Agent Harus Memiliki Batas

Loop tanpa batas dapat menghabiskan token, API quota, atau melakukan aksi berulang. Tetapkan:

• jumlah langkah maksimum;
• budget waktu dan biaya;
• daftar tool yang diizinkan;
• kondisi berhenti;
• deteksi pengulangan;
• mekanisme cancel;
• escalation kepada manusia.

Output tool juga tidak selalu tepercaya. Halaman web, dokumen, atau issue dapat berisi instruksi berbahaya. Perlakukan sebagai data, bukan perintah dengan prioritas yang sama seperti kebijakan sistem.

Evaluasi Berdasarkan Task

Demo yang terlihat lancar belum membuktikan agent dapat diandalkan. Buat kumpulan task representatif dan nilai:

• task success;
• ketepatan tool dan argumennya;
• jumlah langkah, latency, dan biaya;
• pelanggaran permission;
• kemampuan berhenti dan meminta klarifikasi;
• efek samping yang tidak diinginkan;
• kemampuan pulih dari error tool.

Untuk tindakan yang mengubah state, gunakan sandbox atau mock pada evaluasi. Simpan trace keputusan dan tool call agar kegagalan dapat dianalisis.

Risiko Prompt Injection

Agent yang membaca web, email, issue, atau dokumen dapat menemukan teks yang menyuruhnya mengabaikan tujuan pengguna, membocorkan data, atau memanggil tool tertentu. Instruksi di dalam data eksternal tidak menjadi tepercaya hanya karena terlihat meyakinkan.

Pertahanan perlu berlapis:

• pisahkan instruksi sistem dari content;
• batasi tool dan data berdasarkan task;
• jangan berikan secret yang tidak diperlukan;
• validasi output sebelum menjadi argumen tool;
• minta approval untuk write, pembayaran, atau komunikasi eksternal;
• uji dengan dokumen yang memuat instruksi adversarial.

Tidak ada prompt tunggal yang menjamin keamanan. Permission boundary dan validasi aplikasi harus tetap bekerja jika model membuat keputusan yang salah.

Reliability Bukan Hanya Akurasi

Sistem agent juga perlu menangani tool timeout, response parsial, perubahan schema, rate limit, dan restart. Simpan checkpoint sebelum tindakan penting serta gunakan idempotency key agar retry tidak membuat pembayaran atau pesan ganda.

Tentukan siapa yang bertanggung jawab ketika agent berhenti di tengah task. Status seperti pending, needs_review, completed, dan failed lebih mudah dioperasikan daripada satu flag sukses.

Pola Implementasi Bertahap

1. Mulai dengan satu model call tanpa tool.
2. Tambahkan retrieval atau satu tool read-only.
3. Buat workflow eksplisit untuk langkah yang stabil.
4. Berikan routing dinamis hanya jika evaluasi menunjukkan manfaat.
5. Tambahkan write action terakhir, dengan approval dan rollback.

Prinsipnya sederhana: gunakan sistem paling sederhana yang dapat menyelesaikan task secara terukur. “Agent” bukan tujuan produk; hasil yang benar, aman, dan dapat diverifikasi adalah tujuannya.

Referensi

• NIST AI glossary: Agent
• NIST: AI Agent Standards Initiative
• Anthropic: Building effective agents
• Anthropic: Demystifying evals for AI agents