Kenapa Agent Butuh Lebih dari Sekadar Model yang Bagus
Setiap kali tim engineering menambahkan fitur "AI agent" ke produk mereka, godaan pertama adalah fokus penuh pada model: prompt mana yang paling pintar, model mana yang paling murah, atau versi mana yang paling baru. Tapi kalau agent kamu sering gagal di tengah jalan, tersesat di percakapan panjang, atau memanggil tool dengan parameter yang salah, masalahnya biasanya bukan di model — melainkan di infrastruktur yang membungkusnya. Infrastruktur itu disebut agent harness.
Secara sederhana, kalau model adalah "otak" yang bernalar dan memutuskan langkah berikutnya, harness adalah "tubuh" dan ruang kerja di sekitarnya yang benar-benar menjalankan aksi, menyimpan memori, dan menegakkan aturan. Rumus yang sering dipakai komunitas: Agent = Model + Harness.
Lima Lapisan Utama Sebuah Harness
Berbagai sumber industri—dari Firecrawl, Hugging Face, sampai Databricks—cenderung memecah harness menjadi komponen serupa meski istilahnya sedikit berbeda. Untuk backend dan platform engineer, lima lapisan berikut adalah yang paling krusial untuk dipahami dan dibangun sendiri.
1. Tool execution layer. Lapisan ini mendefinisikan apa saja yang bisa dilakukan agent di dunia nyata: membaca/menulis file, menjalankan kode, memanggil API, query database, atau mengakses web. Harness yang bertanggung jawab mengekspos fungsi yang bisa dipanggil, memvalidasi parameter sebelum eksekusi, dan mengembalikan hasil yang sudah dibersihkan. Tren terbaru bahkan bergerak menjauh dari koleksi tool yang sempit dan spesifik, menuju kemampuan umum seperti "tulis dan jalankan kode" agar model bisa menyusun alur kerja secara dinamis.
2. Memory dan state management. Ada tiga jenis memori yang perlu dikelola harness: working context (isi prompt saat itu), session state (log durasi tugas berjalan), dan long-term memory (pengetahuan lintas sesi, biasanya di vector store atau file terstruktur). Poin penting: memori bukan fitur tambahan, memori adalah bagian inti dari harness itu sendiri. Pertanyaan seperti di mana memori disimpan, siapa yang memilikinya, dan apa yang persisten antar sesi adalah pertanyaan rekayasa, bukan pertanyaan model.
3. Context management (compaction & retrieval). Context window itu terbatas, dan begitu penuh dengan riwayat tool call serta reasoning lama, model mulai kehilangan fokus pada instruksi awalnya — fenomena yang sering disebut "context rot". Harness yang baik melakukan compaction (meringkas riwayat lama) dan retrieval selektif (hanya menyuntikkan dokumen yang relevan di setiap langkah), sekaligus menempatkan informasi penting di awal atau akhir prompt karena konten di tengah cenderung diabaikan model.
4. Sandboxing. Sandbox adalah ruang kerja terisolasi tempat agent bisa menjalankan kode atau mengambil aksi tanpa memengaruhi sistem produksi. Ini penting karena menjalankan kode hasil generate agent langsung di server nyata itu berisiko. Dengan isolasi, tim bisa bereksperimen dengan aman, memonitor, mereset, atau mematikan environment kapan pun dibutuhkan, sekaligus memungkinkan banyak agent berjalan paralel dalam skala besar.
5. Verification dan feedback loop. Harness yang solid tidak hanya membiarkan model bertindak — ia memverifikasi hasilnya. Setelah setiap aksi, harness bisa menjalankan test suite, memeriksa output, atau meminta model mengevaluasi kembali pekerjaannya sebelum lanjut. Tanpa lapisan ini, agent sering menyatakan tugas selesai padahal belum diverifikasi sama sekali.
Loop Reason-Act-Observe: Di Mana Setiap Lapisan Berperan
Sebagian besar sistem agent produksi dibangun di atas siklus berulang yang disebut ReAct loop (reason, act, observe), diperkenalkan lewat paper akademik tahun 2022:
- Reason — model membaca task, memori, dan hasil sebelumnya, lalu memutuskan aksi berikutnya.
- Act — harness mengeksekusi aksi itu: menjalankan tool, mengeksekusi kode di sandbox, memanggil API, atau menulis ke storage.
- Observe — harness menangkap hasilnya dan menyuntikkannya kembali sebagai context baru.
- Repeat — model memakai hasil itu untuk memutuskan langkah berikutnya, sampai tugas selesai.
Di sinilah kelima lapisan tadi bertemu: tool execution menjalankan langkah "act", memory dan context management menyiapkan apa yang dilihat model saat "reason", sandboxing memastikan "act" berjalan aman, dan verification menutup loop dengan memastikan "observe" benar-benar mencerminkan hasil yang valid, bukan asumsi.
Contoh konkret: agent coding yang memperbaiki bug. Model mengusulkan perubahan kode (reason). Harness menjalankan kode itu di sandbox terisolasi (act), menangkap hasil test (observe), lalu mengembalikannya ke model. Kalau test gagal, model bernalar ulang tentang apa yang salah dan mencoba lagi.
Mengapa Kegagalan Agent Biasanya Struktural, Bukan Masalah Prompt
Tim yang menghadapi agent tidak stabil sering kali langsung menulis ulang prompt. Tapi data lapangan menunjukkan mayoritas kegagalan operasional justru datang dari harness, bukan dari model. Beberapa pola kegagalan yang paling umum:
| Pola Kegagalan | Penyebab |
|---|---|
| Context rot | Riwayat percakapan menumpuk tanpa strategi ringkasan, kualitas reasoning menurun |
| Tool overload | Terlalu banyak tool diberikan sekaligus, model bingung memilih |
| Brittle tool wiring | Perubahan kecil di deskripsi/skema tool membuat model salah memanggilnya |
| Halusinasi tool call | Tanpa validasi, agent memanggil fungsi dengan parameter salah atau API yang tidak ada |
| Weak verification | Tidak ada test loop, agent berhenti terlalu dini atau mengklaim sukses palsu |
| Missing guardrails | Aksi ireversibel (hapus data, kirim pesan, transaksi) berjalan tanpa persetujuan manusia |
Pendekatan yang lebih tepat adalah harness engineering: memperlakukan setiap kegagalan agent sebagai masalah rekayasa yang harus diperbaiki secara permanen, bukan sekadar mencoba ulang dengan prompt yang berbeda. Kalau agent gagal memvalidasi respons API, solusinya bukan menulis instruksi "tolong validasi responsmu ya" — solusinya adalah membangun response validator yang membuat kesalahan itu mustahil terjadi secara mekanis.
Strategi Praktis: Mulai dari Harness Terkecil yang Gagal Secara Terlihat
Alih-alih membangun harness lengkap dengan delapan komponen sekaligus di hari pertama, pendekatan yang lebih realistis adalah memulai dari harness minimal yang cukup untuk menjalankan tugas, lalu membiarkannya gagal secara jelas dan terlihat. Kegagalan yang terlihat itu jauh lebih berharga daripada kegagalan yang tersembunyi, karena setiap kegagalan nyata memberi sinyal komponen mana yang perlu ditambahkan berikutnya — apakah butuh sandbox, butuh memory tambahan, atau butuh lapisan verifikasi baru.
Siklusnya kurang lebih begini: jalankan versi paling sederhana, amati di mana ia tersandung, tambahkan satu komponen untuk mengatasi kegagalan spesifik itu, lalu ulangi. Ini menghindari over-engineering di awal sekaligus memastikan setiap komponen yang akhirnya ada di harness benar-benar punya alasan konkret untuk ada di sana.
Harness vs Framework vs SDK: Apa yang Perlu Kamu Bangun Sendiri
Ketiga istilah ini sering tertukar, padahal tanggung jawabnya berbeda:
| Konsep | Tanggung Jawab Utama |
|---|---|
| Framework (mis. LangChain) | Menyediakan library dan abstraksi untuk membangun agent |
| Harness | Sistem runtime yang benar-benar menjalankan agent: tool, memory, state |
| Orchestrator | Mengatur alur kontrol — kapan dan bagaimana model dipanggil |
Framework memberi komponen siap pakai. Harness merakit komponen itu menjadi sistem berjalan lengkap dengan default dan integrasi. Orchestrator memutuskan urutan pemanggilan model, terutama saat mengoordinasikan banyak sub-agent.
Untuk backend dan platform engineer, praktiknya adalah: manfaatkan SDK atau framework untuk hal-hal generik seperti dispatch tool dan manajemen sesi, tapi tetap bangun sendiri bagian yang spesifik ke domain kamu — skema validasi tool, kebijakan guardrail, strategi context compaction, dan mekanisme verifikasi yang sesuai dengan use case bisnis. Bagian-bagian itulah yang menentukan apakah agent kamu benar-benar bisa diandalkan di produksi, bukan cuma di demo.
Penutup
Harness adalah tempat sebagian besar nilai rekayasa agent AI sebenarnya berada. Model yang canggih dengan harness yang lemah akan tetap menghasilkan sistem yang rapuh, sementara harness yang solid bisa membuat model kelas menengah tampil jauh lebih andal. Kalau kamu sedang membangun fitur agentic untuk produk atau infrastruktur, mulai dari harness sekecil mungkin, biarkan ia gagal secara terlihat, lalu perbesar berdasarkan kegagalan nyata yang kamu temukan — bukan berdasarkan asumsi di awal.
Referensi
- Firecrawl, "What Is an Agent Harness? The Infrastructure That Makes AI Agents Actually Work" — https://www.firecrawl.dev/blog/what-is-an-agent-harness
- Hugging Face, "Harness, Scaffold, and the AI Agent Terms Worth Getting Right" — https://huggingface.co/blog/agent-glossary
- Databricks, "What is an AI Agent Harness?" — https://www.databricks.com/blog/ai-harness
