Kalau AI agent cuma dianggap chatbot yang bisa klik lebih cepat, kita bakal salah mendesain infrastrukturnya.
Cloudflare memulai Agents Week dengan tesis yang cukup jelas: web perlu menyiapkan lapisan baru untuk autonomous agents. Bukan cuma model dan endpoint API, tapi juga storage, execution, identity, security, observability, serta cara membatasi biaya dan dampak aksinya.
Intinya, agent production bukan browser yang dikasih prompt panjang. Agent adalah software yang bisa menyimpan state, memakai tool, menjalankan pekerjaan lama, dan mengambil keputusan di dalam batas tertentu. Buat developer dan builder, pertanyaannya bukan “apakah semua aplikasi harus jadi agent?”, tapi “bagian workflow mana yang memang layak diberi otonomi, dan boundary-nya ada di mana?”
Apa yang dimaksud dengan agent-native web?
Agent-native web adalah cara memandang web sebagai lingkungan yang juga harus bisa dipakai software otonom, bukan hanya manusia lewat browser. Manusia biasanya membuka halaman, membaca konteks, lalu mengklik tombol. Agent bisa melakukan rangkaian aksi: membaca data, memanggil API, mengubah file, menjadwalkan pekerjaan, dan mengulang langkah ketika terjadi error.
Perbedaan ini penting karena pola request-nya ikut berubah. Satu user manusia mungkin melakukan beberapa klik. Satu agent bisa menjalankan puluhan langkah untuk satu tujuan, dengan durasi lebih panjang dan kebutuhan state yang lebih besar. Kalau sistem cuma mengandalkan endpoint LLM dan token API, bagian paling sulit justru belum dimulai.
Lima primitive yang perlu dipikirkan developer
1. Identity: agent harus punya identitas sendiri
Agent jangan dipaksa memakai API key pribadi developer untuk semua hal. Kalau token itu bocor, lu sulit membedakan aksi manusia, aksi agent, dan aksi tool pihak ketiga.
Identitas agent sebaiknya bisa menjawab beberapa pertanyaan dasar:
- Agent ini milik siapa?
- Dia sedang menjalankan task apa?
- Tool dan resource apa yang boleh dipakai?
- Kapan credential-nya kedaluwarsa?
- Siapa yang bisa mencabut aksesnya?
Dokumentasi Cloudflare Agents menggambarkan setiap sesi agent dengan durable identity. Terlepas dari platform yang lu pilih, pola pikirnya bisa dipakai di mana pun: agent bukan user biasa yang diberi token permanen, melainkan workload yang perlu scope, expiry, dan audit.
2. State dan storage: agent perlu ingatan yang bisa dipertanggungjawabkan
Context window bukan database. Chat history juga bukan sistem pencatatan yang rapi. Agent yang bekerja lebih dari beberapa menit butuh state yang jelas: task sedang berada di langkah mana, keputusan apa yang sudah dibuat, hasil tool sebelumnya, dan apa yang harus dilakukan setelah restart.
Cloudflare menonjolkan local SQL storage, real-time connections, scheduled work, serta recoverable execution dalam runtime Agents. Buat workflow sederhana, lu mungkin cukup memakai database kecil dan job queue. Yang penting, state tidak hanya hidup di prompt atau memory proses yang bisa hilang ketika container restart.
Checklist minimal:
- Simpan status task secara eksplisit.
- Gunakan idempotency key untuk aksi yang bisa diulang.
- Pisahkan fakta dari asumsi model.
- Catat output tool dan waktu eksekusinya.
- Sediakan cara melanjutkan atau membatalkan task.
3. Execution: pekerjaan panjang perlu lifecycle
Agent yang benar-benar berguna jarang selesai dalam satu request HTTP. Dia mungkin perlu menunggu webhook, menjalankan retry, memproses file, atau menjadwalkan pekerjaan berikutnya.
Itulah sebabnya execution layer lebih penting daripada sekadar streaming jawaban. Dokumentasi Cloudflare menyebut durable execution, fibers, queue tasks, retries, dan workflow sebagai bagian dari pola agent. Ini bukan berarti semua project perlu memakai Cloudflare. Pelajarannya lebih umum: lifecycle task harus menjadi bagian dari desain, bukan ditambal setelah agent mulai gagal di production.
Lu perlu menentukan:
- batas waktu satu task;
- jumlah retry dan kondisi yang boleh diulang;
- aksi yang aman untuk diulang;
- aksi yang harus menunggu persetujuan manusia;
- cara menangani task yang berhenti di tengah jalan.
4. Tools dan sandbox: kemampuan harus punya pagar
Model yang pintar tetap bisa membuat keputusan yang salah. Karena itu, tool access tidak boleh dianggap sebagai bonus kecil. Setiap tool menambah capability sekaligus blast radius.
Agent yang boleh membaca issue tracker punya risiko berbeda dengan agent yang boleh menghapus data atau melakukan deploy. Agent yang boleh menjalankan shell command butuh sandbox, filesystem scope, network policy, dan batas resource yang lebih ketat.
Di artikel Cloudflare tentang Flue, agent dijelaskan melalui konteks, model, skills, sandbox, dan instructions. Buat gua, ini mental model yang sehat: instruksi menjelaskan tujuan, tapi sandbox membatasi konsekuensi ketika model salah.
5. Observability dan budget: agent harus bisa diaudit
Kalau agent bekerja selama 20 menit, chat bubble tidak cukup untuk menjelaskan apa yang terjadi. Lu butuh event yang bisa dicari: tool call, permission decision, retry, token usage, latency, error, perubahan state, dan approval manusia.
Tambahkan juga budget cap. Agent yang masuk loop bisa membuat biaya model, request, atau compute naik tanpa menghasilkan useful work. Batas biaya bukan tanda lu tidak percaya AI. Itu cara normal mengoperasikan software yang punya akses ke resource berbayar.
Jangan langsung mengubah semua fitur menjadi agent
Agents Week adalah arah platform dan product narrative dari Cloudflare, bukan bukti bahwa semua aplikasi harus memakai autonomous agent. Developer tetap perlu membedakan visi vendor dari kebutuhan produk yang sudah terbukti.
Gua akan memakai tiga pertanyaan ini sebelum memberi otonomi ke agent:
- Apakah task-nya berulang? Kalau setiap kasus butuh judgment berbeda, automation penuh mungkin terlalu mahal.
- Apakah hasilnya mudah diverifikasi? Generate draft dokumentasi lebih gampang dicek daripada mengubah data pembayaran.
- Apakah aksinya mudah di-undo? Agent yang membuat branch lebih aman daripada agent yang menghapus production data.
Mulai dari workflow yang menghasilkan artifact reviewable: pull request, draft artikel, laporan, diff konfigurasi, atau rekomendasi. Jangan mulai dari tombol “jalankan semua” hanya karena model terbaru terlihat meyakinkan.
Takeaway buat builder
Web yang ramah agent bukan web yang membiarkan semua bot masuk tanpa aturan. Web yang agent-native justru perlu kontrak yang lebih jelas: identitas siapa yang bertindak, data apa yang boleh dipakai, tool apa yang tersedia, task bisa dipulihkan bagaimana, dan siapa yang bertanggung jawab ketika hasilnya salah.
Model hanyalah satu lapisan. Production stack-nya adalah state, identity, execution, permission, observability, dan budget. Kalau enam hal ini belum jelas, menambah model yang lebih pintar biasanya cuma memperbesar kecepatan menuju masalah yang sama.
Kalau lu sedang membangun workflow AI, coba audit satu task minggu ini: tulis capability agent, data yang disentuh, aksi yang tidak bisa di-undo, stop condition, dan log yang tersedia. Dari situ biasanya kelihatan apakah lu benar-benar butuh autonomous agent atau cuma butuh automation biasa yang lebih rapi.
FAQ singkat
Apakah agent-native web berarti website harus menyediakan chatbot?
Nggak. Agent-native lebih luas dari chatbot. Fokusnya adalah membuat akses, identity, data, dan workflow bisa dipakai software secara aman dan terukur.
Apakah Cloudflare Agents cocok untuk semua project?
Belum tentu. Platform seperti Cloudflare menarik kalau lu butuh stateful agent, execution yang tahan lama, integrasi edge, atau channel yang beragam. Untuk task kecil, queue dan worker biasa bisa lebih sederhana.
Apakah sandbox bisa menghilangkan semua risiko agent?
Nggak. Sandbox mengurangi blast radius, tetapi tetap perlu permission, credential hygiene, logging, testing, dan human approval untuk aksi berisiko tinggi.