System Design #2: Arsitektur AI Agent untuk Bisnis -- Dari Ide ke Production

Tahun lalu gue bikin AI Agent buat bantu nulis artikel blog. Ide-nya simpel: lo kasih topik, dia riset, nulis draft, gue tinggal review.

Dua hari pertama jalan mulus. Hari ketiga? Dia ngirim artikel yang isinya ngaco — nyebutin CEO OpenAI itu Sam Altman punya startup coding bootcamp di Bali. Padahal dia cuma bikin prompt riset yang kurang spesifik.

Gue buang 3 jam buat debug: salah di prompt? salah di tool? atau agent-nya emang gak connected ke sumber yang bener?

Masalahnya bukan di model LLM-nya. Masalahnya gue gak punya arsitektur.

Artikel ini cerita apa yang gue pelajari dari situ — dan gimana lo bisa bikin AI Agent yang gak asal jawab, tapi beneran bisa lo andelin buat bisnis.

No jargon, no hype. Hanya arsitektur yang gue pake sendiri.

Kenapa Agent Lo Gagal di Hari Ketiga

Kebanyakan orang mulai dengan pertanyaan yang salah: "Model LLM apa yang paling canggih?"

Padahal pertanyaan yang bener: "Gimana caranya agent lo bisa ngambil keputusan yang konsisten?"

Gue liat pola yang sama di beberapa temen yang juga bikin agent:

Mereka mulai dengan stack terkeren. Multi-agent, vector DB, RAG pipeline, streaming, semua langsung dipasang. Hasilnya? Agent jalan 2-3 hari, lalu mulai ngawur. Karena mereka bangun house of cards — banyak layer teknologi tanpa fondasi.

Dari situ gue sadar: AI Agent itu bukan magic black box. Dia aplikasi distributed system biasa, bedanya compute-nya pake LLM yang probabilistic. Dan kalo lo gak design arsitekturnya dengan bener, lo bakal debug hal yang salah.

Empat Hal yang Wajib Ada

Dulu gue pikir bikin AI Agent tuh tinggal panggil API OpenAI, kasih system prompt bagus, selesai.

Ternyata enggak. Satu LLM call cuma bisa ngerjain satu langkah. Kalo lo mau agent ngerjain workflow yang butuh 5-10 langkah, lo butuh lebih dari sekedar prompt.

Otak: LLM dengan Tool Calling

Model lo harus bisa manggil fungsi. Bukan cuma jawab pertanyaan. Kalo model lo gak support function calling, hampir gak mungkin bikin agent yang reliable.

DeepSeek, Claude, GPT-4 — semuanya support. Tapi yang penting: pilih model yang konsisten, bukan yang paling pintar. Gue pribadi pake model yang cukup pintar tapi jarang hallucinate, daripada model jenius yang tiba-tiba ngaco.

Tangan: Tools dengan Batasan

LLM cuma bisa ngomong. Tools yang bikin dia bisa bertindak: web search, akses database, kirim email, generate file.

Tapi gue belajar dengan keras: kalo lo gak batasi tools-nya, dia bakal pake semuanya sekaligus dan bikin chaos.

Aturan gue sekarang: satu agent maksimal 3 tools. Lebih dari itu, split jadi agent terpisah.

Ingatan: Lebih dari Sekadar History Chat

Ini yang paling sering dilupain. Agent butuh tiga jenis memori:

Short-term: percakapan dalam satu sesi. Simpen di buffer, kompres kalo kepanjangan.

Long-term: knowledge yang bertahan. Bisa vector DB bisa juga Postgres biasa — gue pake Postgres karena lebih gampang di-debug.

Working memory: state sementara. JSON object yang di-update tiap langkah. Penting banget buat task multi-step.

Orkestrasi: Yang Nganggur Sering Dilupain

Ini yang paling boring tapi paling penting. Orkestrasi itu: retry logic, timeout, task queue, logging.

Gue punya agent yang jalan 3 bulan tanpa masalah. Suatu hari API OpenAI lagi down — dan agent gue hang karena gak ada timeout. Gak ngirim notifikasi, gak retry, cuma diem aja.

Sejak itu: setiap agent punya timeout 30 detik, retry 3x, dan fallback ke model cadangan.

Lo udah punya empat komponen di atas. Pertanyaan berikutnya: gimana cara nyusunnya?

Nah, ini bagian yang gue pelajarin paling mahal. Dulu gue langsung bikin sistem multi-agent karena keren. Ternyata buat 90% bisnis, satu agent doang udah cukup.

Satu Agent vs Banyak Agent

Gue dulu berpikir: "Bisnis gue butuh banyak workflow, berarti harus multi-agent."

Hasilnya: gue punya 5 agent yang saling nunggu, cost API naik 4x, dan debugging jadi nightmare karena lo gak tau error di agent yang mana.

Single Agent: Mulai dari Sini

Buat 90% use case bisnis, satu agent udah lebih dari cukup. Satu LLM, 2-3 tools, satu conversation buffer.

Contoh konkret: agent customer support. Dia terima pertanyaan, search knowledge base, kalo gak ketemu escalate ke human. Simple, mudah di-debug, cost rendah.

Kapan pake: lo baru mulai, satu workflow, tim di bawah 5 orang.

Batasan: kalo agent error, semuanya berhenti. Tapi untuk MVP, ini acceptable.

Multi-Agent: Buat yang Udah Tau Kebutuhannya

Multi-agent baru terasa gunanya kalo lo punya workflow yang BEDA secara fundamental. Misalnya: satu agent riset (pake web search), satu agent nulis (pake model bagus), satu agent review (pake model murah).

Tapi ada harga yang harus dibayar: cost naik (setiap agent butuh LLM call), debugging lebih susah (error di agent riset atau supervisor?), latency lebih gede (4 LLM calls = minimal 20-40 detik).

Gue pribadi pake aturan: mulai dengan 1 agent. Tambahin agent baru SETELAH agent pertama jalan stabil 2 minggu.

Oke, lo udah punya komponen dan tau kapan pake single vs multi. Tapi itu belom cukup.

Ada beberapa pattern yang gue temuin dari trial and error — yang bikin agent gue dari sering bikin salah jadi jarang bikin salah.

Pattern yang Bikin Agent Lo Gak Kacau

Router: Pake Model Murah buat 70% Task

Pengamatan: 70% task sehari-hari itu sederhana. Cuma 30% yang beneran butuh reasoning dalem.

Patternnya: input — classifier (prompt simpel) — kalo simpel pake model murah, kalo kompleks pake model mahal.

Hasilnya: cost turun 40-60%. Karena lo gak perlu pake model paling canggih buat ngecek cuaca.

Human-in-the-Loop: Biar Gak Kena Masalah

Gue pernah punya agent yang kirim email blast ke 500 orang. Isinya template yang belom di-edit.

Sejak itu: SEMUA action berdampak — kirim email, posting, delete data, bayar invoice — WAJIB lewat approval manusia. Agent bikin request, lo dapet notifikasi, lo approve. Kalo lo gak respon dalam 5 menit, auto-deny.

Budgeting: Biar Tagihan API Gak Ngagetin

Ini pelajaran yang gue dapet pas liat tagihan OpenAI bulan pertama: $347.

Sekarang setiap agent punya daily budget cap, cache buat task berulang, dan prioritas — task mahal cuma jalan kalo budget masih cukup.

Observability: Biar Lo Tau Agent Lagi Ngapain

Lo gak bakal debug masalah yang gak lo liat. Gue log SEMUA: prompt apa yang dikirim, response apa yang balik, tool apa yang dipanggil, berapa lama, berapa cost.

Kalo agent error, lo buka log dan langsung tau masalahnya. Gak perlu dashboard mahal. Cukup file JSON yang bisa lo grep.

Semua pattern di atas gue terapin di satu sistem yang gue pake tiap hari. Biar lebih konkret:

Sistem yang Jalan Tiap Hari

Gue punya sistem buat bantu daily operations. Bukan klien, tapi sistem internal gue sendiri:

Pagi: agent riset trending topik di HN, Dev.to, TechCrunch. Jadi 5 bullet points. Dulu 30 menit. Sekarang 2 menit.

Siang: agent content bikin draft postingan sosial media. Dulu 1 jam. Sekarang 5 menit review.

Sore: agent monitor pantau competitor dan komentar blog. Kalo ada yg perlu direspon, kirim alert.

Malam: agent compile daily report. Dulu 15 menit. Sekarang nol.

Arsitektur: 1 supervisor (model murah) + 3 specialist agents + Postgres memory + Telegram delivery. Cost: sekitar $0.50 per hari buat sekitar 100 agent runs.

Ini bukan sistem yang canggih. Tapi ini sistem yang ANDAL. Dan itu yang lebih penting buat bisnis.

Lo mungkin mikir: gue mulai dari mana?

Jawabannya: mulai dari yang paling sederhana.

Empat Fase — Dari Ide ke Production

Fase 1 (1-2 hari): Satu Agent, Satu Tool. Pilih satu workflow yang paling nyebelin. Bikin agent + 1 tool. Manual trigger dulu. Kalo udah jalan 3 hari tanpa error, lanjut.

Fase 2 (3-5 hari): Tambah Memory + Orkestrasi. Pasang conversation buffer. Bikin ReAct loop yang proper — bukan cuma satu prompt ke LLM. Tambah logging.

Fase 3 (1-2 minggu): Tambah Agent Lain. Specialist agent kedua. Supervisor/router. Schedule auto-run. Human-in-the-loop gates.

Fase 4 (1 minggu): Hardening: caching, model routing, observability dashboard, backup plan.

Yang penting: jangan lompat ke Fase 3 atau 4 sebelum Fase 1 stabil.

Intinya

Gue belajar dengan cara yang mahal: AI Agent bukan tentang model paling canggih.

Ini tentang arsitektur yang bener. Separation of concerns — setiap agent punya tanggung jawab jelas. Cost-aware design — jangan pake model mahal buat task sederhana. Observability — lo harus tau agent lagi ngapain. Incremental complexity — mulai dari yang paling sederhana.

Gue bakal nulis detail teknisnya di artikel selanjutnya: cara bikin ReAct loop dari scratch, milih database yang cocok, dan pattern caching yang ngurangin cost LLM sampe 60%.