Agentic, Tapi Deterministic: Cara Mendesain AI Agent yang Bisa Dipercaya

AI agent yang bagus bukan agent yang bebas melakukan apa saja.

Justru sebaliknya: AI agent yang bagus punya batas yang jelas.

Saya makin yakin bahwa agent yang bisa dipakai di pekerjaan serius harus punya dua sisi yang sengaja dipisah:

1. sisi yang fleksibel untuk memahami masalah,
2. sisi yang kaku untuk menjalankan pekerjaan.

Kalau dua sisi ini dicampur, agent memang bisa terlihat pintar di awal. Dia bisa memahami maksud user, membuat rencana, menjawab dengan percaya diri, bahkan menjalankan command. Tapi di production, pola seperti ini berbahaya.

Masalahnya bukan AI-nya kurang pintar. Masalahnya adalah cara kerjanya terlalu bebas.

AI boleh kreatif saat membaca konteks, memahami intent, dan menyusun opsi. Tapi saat sudah menyentuh eksekusi, sistem harus masuk ke jalur yang deterministic: ada rule, script, workflow, approval, log, dan verification.

Kalimat ringkasnya begini:

Otaknya boleh generative. Tangannya harus deterministic.

Bahasa bayinya

Deterministic itu seperti kalkulator. Kalau input-nya sama, output-nya sama.

Generative AI itu seperti teman pintar yang bisa bantu mikir, membaca konteks, menulis, dan menebak maksud. Tapi jawabannya bisa berubah. Kadang bagus. Kadang ngawur. Kadang terlalu percaya diri.

Maka pola yang aman bukan:

User minta sesuatu -> AI langsung melakukan semuanya

Pola yang lebih sehat:

User minta sesuatu
-> AI memahami maksud
-> workflow mengecek aturan
-> tool menjalankan aksi
-> hasil dicatat
-> manusia bisa audit

Contoh paling gampang: refund.

Customer bilang, "Saya mau balikin barang."

AI boleh membaca kalimat itu dan menyimpulkan: "Ini request refund."

Tapi proses refund-nya jangan diserahkan ke imajinasi AI. Sistem harus tetap mengecek tanggal pembelian, status pembayaran, policy retur, eligibility barang, dan jumlah yang boleh dikembalikan. Setelah itu baru workflow menjalankan refund dengan langkah yang sama setiap kali.

AI menjadi penerjemah maksud. Workflow menjadi eksekutor.

Itu bedanya agent yang sekadar "pintar" dengan agent yang bisa dipercaya.

Kenapa ini penting untuk OpenClaw dan Hermes Agent

OpenClaw dan Hermes Agent, buat saya, bukan sekadar chatbot atau CLI pembantu. Mereka bisa jadi operator kerja.

Mereka bisa membaca repo, menjalankan command, memperbaiki bug, membuat script, memantau server, mengatur cron, mengelola file, dan menyiapkan automation.

Makin kuat agent-nya, makin besar juga risiko kalau cara kerjanya tidak didesain dengan benar.

Kalau agent hanya disuruh:

Tolong beresin project ini sampai selesai.

Instruksi itu terlalu longgar.

Kadang memang jalan. Tapi untuk project serius, instruksi seperti itu membuat agent terlalu banyak menebak:

• menebak prioritas,
• menebak definisi selesai,
• menebak stack,
• menebak route mana yang penting,
• menebak bug mana yang boleh ditinggal,
• menebak apakah perubahan boleh dipush atau belum.

Di sinilah deterministic workflow masuk.

Agent tetap boleh berpikir. Tapi cara kerjanya harus punya jalur.

Empat pilar workflow agentic yang sehat

Saat ini saya melihat workflow agentic yang sehat sebagai empat pilar:

1. Planning
2. Builder
3. Executor
4. Maintainer

Ini bukan fase yang selalu linear. Kadang Maintainer membawa temuan baru ke Planning. Kadang Builder menambah tool karena Executor menemukan pekerjaan berulang. Kadang Planning harus diperbaiki setelah verification menunjukkan asumsi awal salah.

Tapi empat pilar ini membantu agent tidak bekerja seperti orang panik.

Pilar 1: Planning

Planning adalah tempat AI boleh banyak berpikir.

Di fase ini saya biasanya mulai dari brainstorming sampai lahir blueprint.md. Setelah itu turunannya bisa berkembang menjadi:

• prd.md
• brd.md
• frd.md
• techstack.md
• design.md
• wireframe.md
• ui-ux.md
• security.md
• roadmap.md
• deployment.md
• qa.md
• runbook.md

Saya tidak menganggap file-file ini sebagai formalitas. Justru ini pagar pertama supaya agent tidak liar.

blueprint.md menjawab: "Kita sedang membangun apa?"

prd.md menjawab: "User butuh apa?"

brd.md menjawab: "Bisnisnya butuh apa?"

frd.md menjawab: "Fitur konkretnya apa?"

techstack.md menjawab: "Kita pakai teknologi apa dan kenapa?"

security.md menjawab: "Bagian mana yang tidak boleh sembarangan?"

runbook.md menjawab: "Kalau sudah jalan, cara operasi dan recovery-nya bagaimana?"

Planning yang bagus membuat agent tidak perlu banyak menebak. Agent tinggal mengikuti kontrak.

Best practice di fase Planning:

• Baca dokumen satu per satu sebelum mulai coding.
• Pisahkan asumsi dari keputusan.
• Tulis acceptance criteria yang bisa dicek.
• Tentukan mana yang boleh agent kerjakan sendiri dan mana yang butuh approval manusia.
• Buat daftar risiko, bukan cuma daftar fitur.
• Jangan mulai dari UI kalau domain dan flow bisnisnya belum jelas.
• Jangan mulai dari database kalau lifecycle datanya belum jelas.

Planning bukan birokrasi. Planning adalah cara mengurangi improvisasi yang tidak perlu.

Pilar 2: Builder

Builder adalah fase membangun alat.

Di sini saya tidak suka menyuruh agent mengerjakan semua hal secara manual. Kalau ada pekerjaan yang dilakukan lebih dari sekali, itu kandidat tool.

Bentuknya bisa macam-macam:

• script smoke test route production,
• script backup sebelum migrasi,
• skill untuk membaca dokumen project,
• command untuk deploy dan cek health,
• tool untuk generate report,
• cron untuk cek status server,
• template untuk membuat blueprint.md baru,
• script untuk audit secret dan file sensitif.

Kenapa ini penting?

Karena tool membuat agent lebih deterministic.

Kalau agent mengetik command manual setiap kali, variasinya besar. Kalau agent menjalankan script yang sama, hasilnya lebih bisa diulang dan dicek.

Best practice di fase Builder:

• Tool harus kecil dan punya tujuan jelas.
• Input dan output tool harus eksplisit.
• Kalau tool menyentuh data penting, buat mode dry-run.
• Kalau tool bisa merusak, wajib ada backup atau approval gate.
• Log hasil penting, terutama untuk deploy, migrasi, dan cleanup.
• Jangan membuat tool yang diam-diam melakukan terlalu banyak hal.
• Tool harus bisa dijalankan manusia juga, bukan hanya agent.

Agent yang baik bukan cuma menjawab. Dia memperbaiki cara kerja.

Pilar 3: Executor

Executor adalah fase agent menjalankan pekerjaan.

Di sinilah deterministic workflow paling penting.

Saya biasanya membagi pekerjaan menjadi dua:

1. pekerjaan berulang,
2. pekerjaan tidak berulang.

Kalau pekerjaan berulang, agent harus membuat automation:

• trigger,
• cron,
• queue,
• scheduled check,
• watcher,
• health monitor,
• report periodik.

Kalau pekerjaan tidak berulang, agent harus membuat skenario:

• langkah eksekusi,
• command yang dipakai,
• expected result,
• rollback plan,
• kriteria selesai,
• bukti verifikasi.

Dengan begitu, manusia tidak perlu menyuruh agent dari nol setiap kali. Manusia cukup memanggil skenario yang sudah disiapkan.

Contoh:

Jalankan skenario deploy production.

Agent harus tahu bahwa itu berarti:

1. cek git status,
2. jalankan test,
3. build,
4. deploy,
5. smoke test URL,
6. cek log error,
7. catat hasil.

Bukan:

Langsung deploy karena user bilang deploy.

Best practice di fase Executor:

• Eksekusi harus punya preflight check.
• Agent harus tahu kapan berhenti.
• Setiap aksi penting harus punya bukti hasil.
• Untuk aksi high-risk, gunakan approval gate.
• Untuk deploy, selalu ada smoke test.
• Untuk migrasi, selalu ada backup atau rollback path.
• Untuk automation, selalu ada cara disable.
• Untuk cron, selalu ada log dan batas frekuensi.

Executor bukan tempat agent berimprovisasi terlalu bebas. Executor adalah tempat agent membuktikan bahwa rencana bisa dijalankan.

Pilar 4: Maintainer

Maintainer adalah bagian yang paling sering disalahpahami.

Saya tidak ingin agent saya "disuruh-suruh 24 jam".

Tapi saya ingin agent saya "kerja 24 jam".

Itu beda.

"Disuruh-suruh 24 jam" berarti manusia terus mengetik perintah kecil:

Cek ini.
Benerin itu.
Lihat lagi.
Deploy lagi.
Kenapa error?
Coba ulang.

Itu melelahkan. Agent cuma jadi operator pasif.

"Kerja 24 jam" berarti sistemnya sudah punya loop:

• ada hal yang dipantau,
• ada trigger yang jelas,
• ada threshold kapan agent perlu bertindak,
• ada tugas yang bisa dilakukan otomatis,
• ada tugas yang harus minta approval,
• ada laporan yang dikirim saat penting,
• ada backlog maintenance yang bisa dikerjakan tanpa mengganggu production.

Maintainer bukan berarti agent bebas mengubah apa saja kapan saja. Maintainer berarti agent punya tanggung jawab observasi dan perawatan dengan batas yang jelas.

Best practice di fase Maintainer:

• Buat daftar hal yang harus diamati: uptime, error log, queue, disk, expired token, failed job, broken route.
• Pisahkan auto-fix dan human-review.
• Untuk bug kecil yang aman, agent boleh patch dan test.
• Untuk perubahan schema, payment, auth, permission, atau data user, agent harus minta approval.
• Catat semua perubahan.
• Buat changelog atau daily note untuk pekerjaan maintenance.
• Jangan biarkan agent bekerja tanpa audit trail.

Maintainer yang baik membuat project terasa hidup tanpa membuat manusia kehilangan kendali.

Deterministic dan agentic itu spektrum

Saya suka cara Deepset membingkai ini: deterministic workflow dan agentic AI bukan dua kubu yang harus dipilih salah satu. Mereka spektrum.

Ada pekerjaan yang harus sangat deterministic:

• auth,
• billing,
• refund,
• deployment,
• database migration,
• permission,
• security policy,
• cleanup data.

Ada pekerjaan yang boleh lebih agentic:

• membaca dokumen,
• meringkas issue,
• mencari opsi solusi,
• membuat draft UI,
• mengeksplor bug,
• membuat proposal arsitektur,
• menyusun test plan.

Ada juga pekerjaan hybrid:

• AI membaca request customer, workflow menjalankan action.
• AI membuat rencana deploy, script deploy yang mengeksekusi.
• AI menemukan bug, test deterministic yang membuktikan fix.
• AI menyusun rekomendasi, manusia approve, agent menjalankan skenario.

Jadi pertanyaannya bukan, "Pakai agent atau workflow?"

Pertanyaan yang lebih tepat:

Bagian mana yang butuh fleksibilitas, dan bagian mana yang harus repeatable?

Pattern yang paling sehat

Untuk OpenClaw, Hermes Agent, atau sistem AI agent lain yang dipakai serius, pattern yang saya rasa paling sehat seperti ini:

1. Intent Layer
 User menjelaskan tujuan dengan bahasa manusia.

2. Planning Layer
 Agent menyusun blueprint, asumsi, risiko, dan acceptance criteria.

3. Tooling Layer
 Agent membuat atau memilih tool yang bounded.

4. Execution Layer
 Tool, script, atau workflow menjalankan aksi secara deterministic.

5. Verification Layer
 Test, smoke check, log check, diff check, atau output proof.

6. Maintenance Layer
 Agent memantau, memperbaiki yang aman, dan meminta approval untuk yang riskan.

Layer ini membuat agent tidak menjadi black box.

Kalau ada yang gagal, kita bisa tanya:

• Salah paham intent?
• Blueprint kurang jelas?
• Tool-nya salah?
• Execution layer tidak punya guardrail?
• Verification kurang kuat?
• Maintenance terlalu bebas?

Debugging jadi lebih manusiawi.

Checklist awal untuk project agentic

Ini checklist awal yang saya pakai untuk project-project agentic:

• Selalu mulai dari blueprint.md untuk project baru atau perubahan besar.
• Turunkan blueprint menjadi dokumen yang lebih spesifik sesuai kebutuhan. Tidak semua file wajib dibuat kalau tidak relevan.
• Baca ulang dokumen sebelum coding.
• Jadikan script dan skill sebagai alat utama, bukan command manual berulang.
• Buat skenario untuk pekerjaan one-off.
• Buat trigger atau cron untuk pekerjaan berulang.
• Pisahkan AI interpretation dari deterministic execution.
• Buat approval gate untuk aksi berisiko tinggi.
• Selalu punya preflight check sebelum deploy, migrasi, cleanup, atau publish.
• Selalu punya verification step setelah aksi.
• Simpan audit trail untuk perubahan penting.
• Buat rollback path untuk perubahan yang bisa merusak service.
• Batasi permission agent sesuai tugas.
• Jangan kasih agent akses luas hanya karena nyaman.
• Buat mode dry-run untuk tool yang menyentuh data atau resource eksternal.
• Untuk maintenance, tentukan mana yang boleh auto-fix dan mana yang wajib human review.

Checklist ini mungkin terlihat sederhana. Tapi justru di hal-hal sederhana seperti ini agentic workflow sering gagal.

Banyak tim terlalu cepat bicara multi-agent, memory, tool calling, dan autonomous execution, padahal belum punya rule dasar: kapan agent boleh bertindak, kapan harus berhenti, dan bagaimana hasilnya diverifikasi.

Kesimpulan operasional

Menurut saya, masa depan agentic workflow bukan agent yang makin bebas.

Masa depan yang sehat adalah agent yang makin paham batas.

Agent harus bisa membaca konteks, menyusun rencana, membuat tool, menjalankan workflow, dan menjaga sistem tetap sehat. Tapi semua itu perlu pagar: dokumen, script, trigger, test, audit, approval, dan rollback.

Untuk perusahaan, ini juga berarti pelatihan AI tidak cukup berhenti di prompt. Tim perlu belajar cara mengubah AI dari alat bantu personal menjadi sistem kerja yang punya SOP, permission, dan alur verifikasi.

Di Rama Digital, angle seperti ini masuk dalam Pelatihan AI Perusahaan: bukan cuma "pakai AI", tapi mendesain workflow AI yang realistis, aman, dan bisa dipakai tim.

Kalimat paling ringkasnya tetap sama:

Otaknya boleh generative. Tangannya harus deterministic.

Atau versi kerja hariannya:

Agent tidak perlu disuruh-suruh 24 jam. Agent perlu sistem kerja yang membuat dia bisa bekerja 24 jam dengan benar.

Bacaan yang mempengaruhi tulisan ini

• Deterministic AI: What it is and when to use it - Zapier
• Understanding the Three Faces of AI: Deterministic, Probabilistic, and Generative - MyMobileLyfe
• What Is Deterministic AI? - Lorka AI
• AI Agents and Deterministic Workflows: A Spectrum, Not a Binary Choice - Deepset