AI agent yang bisa demo 5 menit belum tentu siap dipakai kerja beneran. Demo biasanya cuma nunjukin jalur bahagia: user nanya, agent jawab, semua kelihatan pintar. Masalahnya, sistem produksi hidup di jalur yang jauh lebih berantakan: pertanyaan ambigu, data kurang lengkap, output salah, biaya jalan terus, dan user tetap butuh alasan kenapa jawaban itu layak dipercaya.
Artikel ini membahas kenapa agentic AI produksi butuh harness, observability, evaluation, dan recovery, bukan cuma prompt panjang. Contoh utamanya datang dari studi kasus PRINCE Bayer yang ditulis Martin Fowler dan Thoughtworks: sebuah research assistant untuk data preclinical yang berevolusi dari search biasa menjadi sistem Agentic RAG dan Text-to-SQL. Buat developer, poin pentingnya sederhana: skill masa depan bukan cuma “jago prompt”, tapi jago mendesain sistem AI yang bisa diuji, dijelaskan, dan diperbaiki saat gagal.
Apa itu agentic AI produksi?
Agentic AI adalah sistem AI yang bukan cuma menjawab satu prompt, tapi bisa memecah tujuan, memilih langkah, memakai tool, membaca data, mengevaluasi hasil sementara, lalu menyusun jawaban akhir. Kalau chatbot biasa mirip orang yang menjawab pertanyaan, agentic AI lebih mirip asisten kerja yang punya alur: klarifikasi, rencana, eksekusi, validasi, lalu laporan.
Tapi kata “agentic” sering bikin orang keburu membayangkan multi-agent rumit, diagram penuh panah, dan demo yang kelihatan canggih. Menurut gua, itu jebakan. Agentic AI produksi bukan soal seberapa banyak agent yang lu punya. Ukurannya: apakah sistem itu bisa membantu kerja nyata dengan tingkat kepercayaan yang cukup, biaya yang masuk akal, dan kegagalan yang bisa dilacak.
PRINCE Bayer menarik karena kasusnya bukan mainan. Sistem ini dipakai untuk membantu researcher menavigasi data preclinical. Di artikel Martin Fowler, arsitekturnya mencakup klarifikasi intent, planning, researcher agent, reflection agent untuk mengecek kecukupan data, dan writer agent untuk menyusun jawaban. Ini bukan sekadar “LLM + dokumen”, tapi workflow yang sengaja dibangun supaya jawaban bisa lebih transparan dan lebih bisa dipercaya.
Masalah produksi bukan model mana yang paling pintar
Banyak tim masih memulai dari pertanyaan: “pakai model apa?” Itu penting, tapi bukan pertanyaan pertama yang paling menentukan. Di produksi, pertanyaan yang lebih mahal biasanya begini:
- Kalau user nanya sesuatu yang ambigu, sistem minta klarifikasi atau nebak?
- Kalau data yang ditemukan kurang cukup, sistem bilang kurang cukup atau tetap pede menjawab?
- Kalau tool gagal, sistem berhenti, retry, atau diam-diam bikin jawaban palsu?
- Kalau output salah, tim bisa melacak langkah mana yang rusak?
- Kalau biaya naik, tim tahu agent muter di bagian mana?
Ini alasan kenapa prompt panjang saja cepat mentok. Prompt bisa memberi aturan, tapi sistem tetap butuh mekanisme di luar prompt: logging, evaluation, guardrail, benchmark internal, fallback, dan cara buat manusia membaca jejak kerja agent.
Harness: sabuk pengaman buat agent
Gua suka memakai istilah harness buat menjelaskan lapisan pengaman dan penguji di sekitar agent. Harness bukan model. Harness adalah lingkungan yang membuat kerja model bisa diarahkan, diamati, diuji, dan dihentikan kalau mulai ngawur.
Cloudflare pernah membahas vulnerability harness untuk workflow security. Poin besarnya relevan ke banyak sistem AI: model sebaiknya dianggap komponen yang bisa diganti, sementara pipeline validasi, reproducibility, dan coverage tetap jadi fondasi. Kalau hasil agent tidak bisa direproduksi atau tidak punya bukti, tim security bakal kesulitan membedakan temuan valid dari noise.
GitHub juga punya pelajaran mirip dari Secret Scanning. Mereka tidak cukup hanya mendeteksi pola yang mirip secret, karena alert yang terlalu banyak false positive bikin developer kehilangan trust. GitHub menambahkan verifikasi dan reasoning kontekstual supaya alert lebih berguna. Ini contoh penting: AI yang “menemukan banyak hal” belum tentu membantu kalau sinyalnya tidak bisa dipercaya.
Dari tiga contoh ini, polanya sama: AI produksi butuh sistem yang mengubah output mentah menjadi keputusan yang bisa dipakai.
Checklist sebelum agent masuk workflow tim
Kalau lu lagi membangun AI agent buat kerja nyata, gua bakal mulai dari checklist ini:
1. Definisikan batas tugas agent
Jangan mulai dari “agent ini bisa bantu apa saja?” Mulai dari satu workflow spesifik. Misalnya: merangkum issue GitHub, mencari referensi teknis, membuat draft artikel, atau mengecek indikasi false positive. Semakin kabur batasnya, semakin susah mengukur berhasil atau gagal.
2. Pisahkan planning, execution, dan writing
PRINCE Bayer memberi contoh menarik: ada tahap klarifikasi, planning, pencarian data, refleksi, lalu penulisan. Ini penting karena jawaban akhir sering terlihat rapi walau prosesnya berantakan. Dengan memisahkan tahap, lu bisa tahu apakah masalahnya ada di pemahaman intent, retrieval, tool call, atau sintesis jawaban.
3. Buat evaluation yang dekat dengan kerja asli
Benchmark publik boleh jadi referensi, tapi jangan berhenti di sana. Kalau agent lu dipakai buat workflow internal, buat test case dari pekerjaan nyata: pertanyaan user, data yang tersedia, jawaban yang diharapkan, dan contoh failure yang sering muncul. Evaluation yang terlalu generik sering gagal menangkap bug yang benar-benar bikin tim rugi.
4. Log jejak keputusan, bukan cuma output akhir
Observability untuk AI agent bukan cuma token usage. Lu butuh melihat input, tool call, dokumen yang dipakai, keputusan routing, error, retry, dan alasan kenapa output tertentu dipilih. Tanpa ini, debugging agent rasanya kayak debugging server tanpa log.
5. Desain failure mode dari awal
Agent yang baik bukan agent yang selalu kelihatan yakin. Agent yang baik tahu kapan harus bilang: “data kurang”, “tool gagal”, atau “butuh konfirmasi manusia”. Untuk use case berisiko, jawaban tidak lengkap yang jujur lebih aman daripada jawaban lengkap yang halu.
Kapan lu tidak butuh multi-agent?
Ini bagian yang sering dilupakan. Tidak semua problem butuh agentic architecture. Kalau workflow lu cuma mengambil dokumen, mencari potongan relevan, lalu menjawab dengan sumber, RAG sederhana mungkin sudah cukup. Kalau keputusan bisa dibuat dengan aturan deterministic, jangan dipaksa jadi AI agent cuma karena terlihat modern.
Multi-agent masuk akal kalau ada alasan teknis yang jelas: tugas perlu routing spesialis, validasi silang, audit trail, tool yang berbeda-beda, atau recovery dari langkah yang gagal. Tanpa alasan itu, multi-agent cuma menambah biaya, latency, dan permukaan bug.
Pelajaran buat developer: context engineering + harness engineering
Menurut gua, dua skill ini bakal makin penting: context engineering dan harness engineering. Context engineering adalah cara lu memberi agent konteks yang tepat: instruksi repo, dokumen, data, batasan, dan contoh. Harness engineering adalah cara lu membuat agent bisa diuji, dipantau, dan dikendalikan.
Ini juga nyambung dengan workflow builder sehari-hari. Di sistem seperti Hermes Agent, Obsidian, Ghost CMS, atau automation internal, kualitas output AI bukan cuma datang dari model. Kualitasnya datang dari catatan yang rapi, prompt yang bisa diwariskan, backlog yang jelas, script yang bisa diulang, dan gate sebelum output dikirim ke user.
Dengan kata lain: agent yang berguna lahir dari sistem kerja yang rapi. AI mempercepat eksekusi, tapi engineering tetap menentukan apakah hasilnya bisa dipercaya.
Takeaway praktis
- Agentic AI produksi bukan chatbot dengan prompt lebih panjang.
- Model pintar tetap butuh evaluation, observability, recovery, dan guardrail.
- Harness bikin output agent lebih bisa diuji dan lebih mudah dipercaya.
- Multi-agent hanya masuk akal kalau kompleksitasnya menyelesaikan masalah nyata.
- Developer yang bisa mendesain sistem AI yang bisa gagal dengan aman bakal makin bernilai.
FAQ singkat
Apakah semua tim perlu membangun agentic AI?
Nggak. Kalau workflow masih bisa diselesaikan dengan automation biasa, search, atau RAG sederhana, mulai dari sana. Agentic AI cocok saat tugas butuh beberapa langkah, tool, validasi, dan adaptasi terhadap kondisi yang berubah.
Apa beda prompt engineering dan harness engineering?
Prompt engineering fokus ke instruksi untuk model. Harness engineering fokus ke sistem di sekitar model: test, logging, validation, sandbox, fallback, dan aturan kapan manusia harus masuk.
Kenapa false positive penting di sistem AI?
Karena trust bisa habis. Kalau agent terlalu sering memberi alert atau jawaban yang tidak berguna, user akan mengabaikan semuanya, termasuk output yang sebenarnya penting.
Penutup
Kalau ada satu kalimat yang gua pegang dari topik ini: AI agent yang bisa demo belum tentu bisa dioperasikan. Demo membuktikan kemungkinan. Produksi menuntut reliability.
Buat developer, ini kabar baik. Skill yang dibutuhkan bukan sekadar hafal prompt sakti. Yang lebih penting adalah kemampuan merancang workflow, membaca failure, membuat evaluation, dan membangun sistem yang tetap masuk akal saat model salah. Itu area tempat builder bisa punya edge yang kuat.
Kalau lu lagi membangun agent buat kerja nyata, jangan mulai dari bikin agent kelihatan pintar. Mulai dari bikin agent bisa diaudit, diuji, dan dihentikan saat dia mulai ngaco.
