System Design #2: AI Agent Architecture for Business -- From Idea to Production

Banyak developer mulai bangun AI Agent dengan semangat tinggi. Id nya simpel: kasih topic, agent riset, nulis draft, kita tinggal review.

Dua hari pertama lancar. Hari ketiga, agent mulai ngeluarin output yang gak masuk akal , fakta yang dip fabricated, konteks yang campur aduk.

Bisa makan berjam-jam debugging: prompt? tool? atau source yang salah?

Masalahnya bukan model LLM nya. Masalahnya adalah saya tidak punya arsitektur.

Artikel ini menceritakan apa yang saya pelajari dari pengalaman itu , dan bagaimana anda bisa membangun AI Agent yang tidak sekadar jawab random, tapi bisa diandalkan untuk bisnis.

No jargon, no hype. Cuma arsitektur yang saya pakai sendiri.

Kenapa Agent Gagal di Hari Ketiga

Kebanyakan orang mulai dengan pertanyaan yang salah: "Apa model LLM paling canggih?"

Tapi pertanyaan yang benar adalah: "Bagaimana agent anda bisa bikin keputusan yang konsisten?"

Saya lihat pola yang sama di beberapa teman yang juga build agent:

Mereka mulai dengan stack paling keren. Multi-agent, vector DB, RAG pipeline, streaming, semua diinstall sekaligus. Hasilnya? Agent jalan 2-3 hari, lalu mulai berantakan. Karena mereka bikin rumah kartu , banyak layer teknologi tanpa fondasi.

Dari situ saya sadar: AI Agent bukan magic black box. Itu aplikasi distributed system biasa, bedanya cuma di compute yang pakai probabilistic LLM. Dan kalau anda tidak design arsitekturnya dengan bener, anda akan debug hal yang salah.

Empat Komponen Wajib

Dulu saya kira bikin AI Agent cuma call OpenAI API, kasih system prompt yang bagus, dan selesai.

Ternyata tidak. Satu LLM call cuma bisa lakuin satu step. Kalau anda mau agent ngerjain workflow yang butuh 5-10 step, anda butuh lebih dari sekadar prompt.

Brain: LLM dengan Tool Calling

Model anda harus bisa call function. Bukan cuma jawab pertanyaan. Kalau model anda tidak support function calling, hampir mustahil bikin agent yang reliable.

DeepSeek, Claude, GPT-4 , semuanya support. Tapi yang penting: pilih model yang konsisten, bukan yang paling pintar. Pribadi, saya pakai model yang cukup pintar tapi jarang hallucinate, daripada model jenius yang tiba-tiba ngomong ngawur.

Hands: Tools dengan Batasan

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

Tapi saya belajar dari pengalaman pahit: kalau anda tidak batasi tools-nya, dia akan pakai semuanya sekaligus dan bikin chaos.

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

Memory: Lebih dari Sekadar Chat History

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

Short-term: percakapan dalam satu session. Simpan di buffer, compress kalau kepanjangan.

Long-term: knowledge yang persisten. Bisa vector DB atau Postgres biasa , saya pakai Postgres karena lebih gampang debug.

Working memory: state sementara. JSON object yang di-update setiap step. Sangat penting untuk multi-step tasks.

Orchestration: Hal Membosankan yang Sering Dilupain

Ini bagian paling membosankan tapi paling penting. Orchestration adalah: retry logic, timeout, task queue, logging.

Agent berjalan stabil berminggu-minggu, lalu API provider down tanpa peringatan , dan agent saya hang karena tidak ada timeout. Tidak ada notifikasi, tidak ada retry, cuma diam.

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

Anda sudah punya empat komponen di atas. Pertanyaan berikutnya: gimana cara menyusunnya?

Nah, ini bagian yang saya pelajari dengan keras. Dulu saya langsung bikin multi-agent system karena keren. Ternyata untuk 90% bisnis, single agent sudah cukup.

Single Agent vs Multi-Agent

Dulu saya kira: "Bisnis saya butuh banyak workflow, berarti harus multi-agent."

Hasilnya: saya punya 5 agent yang saling nunggu, API cost naik 4x, dan debugging jadi mimpi buruk karena anda tidak tau agent mana yang error.

Single Agent: Mulai dari Sini

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

Contoh konkret: customer support agent. Dia terima pertanyaan, search knowledge base, kalau tidak ketemu escalate ke human. Simpel, gampang debug, biaya rendah.

Kapan dipakai: Anda baru mulai, satu workflow, tim di bawah 5 orang.

Limitations: Kalau agent error, semua berhenti. Tapi untuk MVP, ini acceptable.

Multi-Agent: Untuk yang Sudah Tau Kebutuhannya

Multi-agent cuma terasa berguna kalau anda punya workflow yang fundamentally BEDA. Contoh: satu research agent (pakai web search), satu writing agent (pakai model bagus), satu review agent (pakai model murah).

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

Aturan saya pribadi: mulai dengan 1 agent. Tambah agent baru SETELAH agent pertama jalan stabil selama 2 minggu.

Oke, anda punya komponen dan tau kapan pakai single vs multi. Tapi itu belum cukup.

Ada beberapa pola yang saya temuin dari trial and error , yang bikin agent saya dari sering salah jadi jarang salah.

Pola yang Bikin Agent Gak Gampang Salah

Router: Pakai Model Murah untuk 70% Task

Observasi: 70% task harian adalah simple. Cuma 30% yang bener-bener butuh deep reasoning.

Polanya: input , classifier (prompt simple) , kalau simple pakai model murah, kalau complex pakai model mahal.

Hasilnya: cost turun 40-60%. Karena anda tidak perlu pakai model paling canggih cuma buat cek cuaca.

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

Pernah ada agent yang mengirim email massal tanpa review. Isinya template yang belum di-edit.

Sejak itu: SEMUA aksi yang berdampak , kirim email, posting, hapus data, bayar invoice , WAJIB lewat human approval. Agent bikin request, anda dapat notifikasi, anda approve. Kalau tidak respon dalam 5 menit, auto-deny.

Budgeting: Biar Tidak Kaget Tagihan API

Ini pelajaran yang saya dapat pas lihat tagihan OpenAI bulan pertama: ratusan dolar per bulan.

Sekarang setiap agent punya daily budget cap, cache untuk task berulang, dan prioritas , task mahal cuma jalan kalau budget masih cukup.

Observability: Biar Tau Agent Lagi Ngapain

Anda tidak bisa debug masalah yang tidak bisa anda lihat. Saya log SEMUA: prompt apa yang dikirim, response apa yang balik, tool apa yang di-call, berapa lama, berapa cost.

Kalau agent error, buka log dan langsung tau masalahnya. Tidak perlu dashboard mahal. Cukup JSON file yang bisa di-grep.

Saya terapin semua pola di atas dalam satu sistem yang saya pakai setiap hari. Biar lebih konkret:

Sistem yang Berjalan Setiap Hari

Saya punya sistem untuk bantu operasional harian. Bukan untuk klien, tapi untuk sistem internal sendiri:

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

Siang: content agent bikin draft social media post. Dulu makan 1 jam. Sekarang 5 menit review.

Siang: monitor agent track kompetitor dan blog comments. Kalau ada yang perlu respon, kirim alert.

Malam: agent kompilasi daily report. Dulu makan 15 menit. Sekarang nol.

Arsitektur: 1 supervisor (model murah) + 3 specialist agent + Postgres memory + Telegram delivery. Biaya: relatif rendah untuk ~100 agent runs per hari.

Ini bukan sistem yang sophisticated. Tapi ini sistem yang RELIABLE. Dan itu yang lebih penting untuk bisnis.

Anda mungkin mikir: mulai dari mana?

Jawabannya: mulai dari yang paling simpel.

Empat Fase , dari Ide ke Production

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

Fase 2 (3-5 hari): Tambah Memory + Orchestration. Setup conversation buffer. Bikin ReAct loop yang bener , bukan sekadar single prompt ke LLM. Tambah logging.

Fase 3 (1-2 minggu): Tambah Agent Baru. 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.

Penting: jangan loncat ke Fase 3 atau 4 sebelum Fase 1 stabil.

Penutup

Saya belajar dengan cara keras: AI Agent bukan soal model paling canggih.

Tapi soal arsitektur yang benar. Separation of concerns , setiap agent punya tanggung jawab yang jelas. Cost-aware design , jangan pakai model mahal untuk task simple. Observability , anda harus tau agent lagi ngapain. Incremental complexity , mulai dari yang paling simpel.

Saya akan tulis technical detail di artikel berikutnya: cara build ReAct loop from scratch, memilih database yang tepat, dan caching pattern yang bisa kurangi LLM cost sampai 60%.