Cara Kerja Agen AI Percakapan dari Dalam

Cara Kerja Agen AI Percakapan dari Dalam (Arsitektur OpenClaw)

Cara kerja agen AI percakapan dalam praktik, giliran demi giliran? Postingan ini membuka kotak hitam OpenClaw: dari saat pesan pelanggan masuk di WhatsApp hingga teks yang ditulis kembali oleh agen. Ini akan teknis. Layak dibaca jika Anda menentukan arsitektur produk, jika Anda akan membeli solusi dan ingin mengevaluasi secara mendalam, atau jika Anda suka mengetahui apa yang terjadi di balik percakapan.

TL;DR: setiap giliran melewati 6 tahap — ingest, resolve konteks, seleksi skills, tentukan aksi berikutnya, eksekusi dengan guard-rails, persistensi memori. Seluruh siklus berjalan dalam <2 detik di edge Cloudflare, tanpa server tetap.

---

Mengapa arsitektur itu penting

Agen percakapan yang terlihat berfungsi di demo tapi rusak di produksi biasanya memiliki salah satu dari 4 masalah ini:

1. Latensi tinggi — pelanggan menunggu 8 detik untuk respons, percakapan mati.
2. Halusinasi tidak terkontrol — agen mengarang harga, jadwal, kebijakan.
3. Konteks hilang — pelanggan kembali setelah 2 hari dan agen "melupakan" semuanya.
4. Biaya tidak terkendali — setiap percakapan panjang memenuhi prompt dan Anda membayar mahal untuk token.

Keempat masalah ini adalah pilihan arsitektur, bukan keterbatasan model. OpenClaw dibangun untuk menghindari keempatnya — dan cara untuk memahaminya adalah melihat siklus satu giliran.

---

Siklus satu giliran (6 tahap)

Bayangkan pelanggan baru saja mengirim pesan "saya mau booking untuk Sabtu pagi". Apa yang terjadi antara "received" dan respons agen?

Tahap 1 — Ingest (edge worker, <50ms)

Pesan WhatsApp masuk via webhook Meta langsung ke Cloudflare Worker di titik kehadiran (PoP) terdekat secara geografis. Di Indonesia, ini berarti Jakarta atau Singapura, latensi jaringan < 20ms.

Worker melakukan tiga hal:

1. Memvalidasi tanda tangan webhook (HMAC terhadap secret WABA).
2. Mengidentifikasi tenant berdasarkan nomor telepon penerima (multi-tenant berdasarkan to_number).
3. Menormalisasi payload — audio menjadi transkripsi, gambar menjadi deskripsi, lokasi menjadi {lat,lng}, teks tetap apa adanya.

Di akhir tahap 1 Anda memiliki objek {tenant_id, conversation_id, user_message} yang siap untuk langkah berikutnya.

Tahap 2 — Resolve konteks (D1 + KV, ~80ms)

Agen membutuhkan 3 bagian konteks sebelum memutuskan:

• Riwayat terbaru percakapan (N giliran terakhir yang relevan).
• Memori jangka panjang pelanggan (preferensi, riwayat pembelian, catatan).
• State agen (persona, skill yang diaktifkan, aturan).

Semuanya berasal dari D1 (SQLite terdistribusi milik Cloudflare). D1 menggantikan Postgres/Mongo tradisional — tanpa server database yang perlu dikelola, akses dalam hitungan ms dari worker, multi-tenant berdasarkan tenant_id.

Poin kunci: kita tidak memuat seluruh percakapan ke dalam prompt. Memory Manager v2 dari OpenClaw (dijelaskan dalam dokumentasi internal kami) hanya memilih giliran yang relevan untuk giliran saat ini (N terakhir + N dengan relevansi semantik tinggi). Ini menjaga biaya token tetap dapat diprediksi bahkan dalam percakapan dengan 100+ giliran.

Tahap 3 — Pemilihan skill (policy engine, ~20ms)

Setiap agen memiliki sekumpulan skill yang tersedia — fungsi yang dapat dipanggilnya. Contoh: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Diberikan pesan "quero marcar pra sábado de manhã", policy engine memfilter:

• Skill yang kompatibel dengan intensi yang terdeteksi (penjadwalan).
• Skill yang diizinkan untuk fase percakapan ini (tidak semua skill tersedia setiap saat).
• Skill yang tenant ini aktifkan (calendar hanya muncul jika tenant sudah mengintegrasikannya).

Pada akhirnya Anda memiliki subset kecil skill yang diteruskan ke model — bukan 50 yang mungkin, hanya 4 yang masuk akal di sini. Ini secara drastis mengurangi kemungkinan model memanggil skill yang salah.

Tahap 4 — Keputusan (LLM call, 400-1200ms)

Sekarang model masuk. OpenClaw melakukan satu panggilan ke LLM frontier (Anthropic Claude, OpenAI GPT, Google Gemini — dapat dikonfigurasi per tenant) dengan:

• System prompt = persona agen + aturan + skill yang tersedia.
• History = giliran yang dipilih pada tahap 2.
• User message = pesan giliran saat ini.

Model merespons salah satu dari dua hal:

• Respons final (teks langsung ke pelanggan).
• Tool call (permintaan untuk menjalankan skill tertentu dengan parameter).

Pada contoh "quero marcar pra sábado de manhã", model biasanya mengembalikan:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

Tahap 5 — Eksekusi dengan guard-rails (variabel, ~100-500ms)

Skill tidak dijalankan di dalam model. Skill dijalankan di kode kami, yang:

1. Memvalidasi parameter (date_range memiliki format yang benar? apakah sesuai dengan aturan tenant?).
2. Memeriksa izin (apakah agen ini berhak mengakses kalender tersebut?).
3. Menjalankan panggilan (Google Calendar API dalam kasus ini).
4. Mengembalikan hasil terstruktur ke model.

Mengapa ini penting? Karena model tidak pernah memfabrikasi hasil. Jika kalender mengembalikan [10h, 11h], itulah yang persis diteruskan ke panggilan berikutnya. Jika skill gagal, model tahu bahwa itu gagal. Nol risiko agen "mengarang" bahwa ada jadwal jam 9 padahal tidak ada.

Untuk kasus yang melibatkan informasi sensitif (harga, tenggat waktu, nama klien), pipeline memaksa tool call — tidak membiarkan model menjawab dari "pengetahuan" sendiri. Ini menghilangkan kelas halusinasi yang paling umum pada agen komersial.

Tahap 6 — Respons dan persistensi (~50ms)

Dengan hasil skill di tangan, model melakukan panggilan kedua — kali ini untuk membentuk respons akhir ke klien. Contoh:

"Saya punya Sabtu jam 10 dan 11. Mana yang Anda pilih?"

Secara paralel, worker:

1. Mengirim pesan kembali melalui API WhatsApp.
2. Menyimpan giliran lengkap (user + assistant + tool calls + durasi) di D1.
3. Memperbarui memori jangka panjang jika giliran tersebut menghasilkan fakta baru (contoh: "klien lebih suka hari Sabtu").
4. Mengeluarkan event observabilitas (metrik latensi, biaya token, tingkat eskalasi).

Semua ini berjalan secara paralel. Persistensi tidak memblokir pengiriman pesan — klien tidak menunggu D1.

---

Di mana pertahanan terhadap halusinasi berada

Agen yang berhalusinasi di produksi kehilangan kepercayaan dengan cepat. OpenClaw memiliki 4 lini pertahanan:

1. Source-of-truth yang dipaksakan. Data faktual (harga, jadwal, nama) selalu berasal dari skill, tidak pernah dari model sendiri.
2. Verifikasi ganda pada data sensitif. Penjadwalan dikonfirmasi dengan klien sebelum disimpan. Pembayaran dikonfirmasi sebelum memberikan akses.
3. Aturan negatif eksplisit. Persona setiap agen mencakup "jangan pernah mengarang X, Y, Z" — model mematuhinya.
4. Fallback ke manusia. Ketika tidak ada skill yang mencakup pertanyaan tersebut, agen berkata "biar saya cek dulu dengan tim" dan membuka tiket — tidak menebak-nebak.

Dalam audit yang kami lakukan selama 6 bulan terakhir (percakapan nyata yang ditinjau secara manual), tingkat halusinasi faktual berada di bawah 0,3% dari giliran — dan hampir semua kasus disebabkan oleh konfigurasi (tenant lupa mengaktifkan skill yang relevan), bukan kesalahan model.

---

Biaya per percakapan

Arsitektur yang baik tidak terlihat sampai Anda melihat tagihannya. Mengingat setiap giliran melakukan 1-2 panggilan LLM + lookup di D1, biaya tipikal per percakapan lengkap (10-15 giliran) adalah: