Dari LLM ke Agentic AI: Anatomi, Alur Kerja, dan Kenapa Ini Berbeda

LLM yang dibahas di artikel sebelumnya adalah “otak” yang sangat kapabel — ia bisa bernalar, menulis, dan menjawab pertanyaan kompleks. Tapi otak saja tidak bisa memesan tiket pesawat, memperbaiki bug di repository, atau memonitor server sepanjang malam dan bertindak saat ada masalah. Untuk tugas-tugas semacam itu, LLM perlu dibungkus dalam sistem yang lebih besar — sistem yang bisa memanggil tools, mengingat konteks lintas langkah, dan memutuskan sendiri kapan harus berhenti. Sistem inilah yang disebut agentic AI, dan artikel ini membedah anatominya secara menyeluruh: dari komponen penyusun, pola reasoning, manajemen memory, sampai risiko yang perlu diwaspadai saat membangunnya.

Batasan Fundamental LLM Murni

Sebelum masuk ke agentic, penting mengingat kembali apa yang tidak bisa dilakukan LLM murni — bukan karena kurang pintar, tapi karena keterbatasan struktural.

Knowledge cutoff. Model dilatih pada data sampai titik waktu tertentu, lalu bobotnya dibekukan. Apapun yang terjadi setelah itu tidak diketahui model, kecuali diberi tahu lewat konteks tambahan.

Tidak bisa verifikasi. LLM menghasilkan jawaban berdasarkan pola yang dipelajari, bukan dengan mengecek fakta secara aktif. Ia bisa terdengar sangat yakin sambil tetap salah — fenomena yang dikenal sebagai halusinasi.

Tidak bisa bertindak. Output LLM murni adalah teks. Ia tidak bisa mengeksekusi kode, mengirim email, atau mengubah file kecuali ada sistem eksternal yang menjembatani teks itu menjadi aksi nyata.

Single-shot secara default. LLM merespons satu prompt dengan satu jawaban. Ia tidak secara inheren tahu bagaimana memecah tugas besar jadi langkah-langkah kecil dan mengeksekusinya satu per satu — kecuali diberi struktur untuk melakukan itu.

Keempat batasan ini adalah alasan kenapa agentic AI muncul: bukan untuk menggantikan LLM, tapi untuk melengkapi LLM dengan kemampuan bertindak, mengingat, dan bekerja secara bertahap.

Apa itu Agentic AI

Agentic AI adalah sistem yang membungkus LLM dalam sebuah loop — siklus berulang antara reasoning (berpikir), action (bertindak), dan observation (mengamati hasil) — sampai tugas selesai atau kondisi berhenti tertentu terpenuhi. Alih-alih satu kali forward pass menghasilkan satu jawaban, agent bisa menjalankan puluhan bahkan ratusan iterasi, masing-masing membangun di atas hasil iterasi sebelumnya.

Perbedaan mendasar antara chatbot biasa dan agent bukan soal seberapa pintar modelnya, tapi soal struktur interaksi. Chatbot menjawab satu pertanyaan dan berhenti, menyerahkan kendali sepenuhnya kembali ke pengguna. Agent, begitu diberi tugas, bisa terus berjalan secara otonom — memutuskan langkah berikutnya sendiri, memanggil tools yang dibutuhkan, dan hanya kembali ke pengguna saat tugas selesai atau butuh klarifikasi.

flowchart TD
    A["Terima Tugas"] --> B["Think:<br/>Model bernalar,<br/>rencanakan langkah"]
    B --> C{"Butuh aksi<br/>eksternal?"}
    C -- Ya --> D["Act:<br/>Panggil tool"]
    D --> E["Observe:<br/>Baca hasil tool"]
    E --> B
    C -- Tidak --> F{"Tugas selesai?"}
    F -- Tidak --> B
    F -- Ya --> G["Kembalikan hasil<br/>ke pengguna"]

Loop Think → Act → Observe inilah jantung dari hampir semua sistem agentic modern, apapun implementasi spesifiknya.

Anatomi Agentic AI — Komponen Utama

Sebuah sistem agentic yang lengkap terdiri dari beberapa komponen yang bekerja bersama. LLM hanyalah satu bagian — meski bagian paling penting — dari keseluruhan arsitektur.

Reasoning/planning layer adalah tempat model memecah tugas kompleks jadi langkah-langkah kecil yang bisa dieksekusi. Ini bisa eksplisit (model menulis rencana bertahap sebelum eksekusi) atau implisit (model memutuskan langkah berikutnya secara reaktif, satu per satu, tanpa rencana penuh di awal).

Tool use / function calling adalah mekanisme yang memungkinkan model memanggil fungsi eksternal — pencarian web, eksekusi kode, query database, API pihak ketiga — dan membaca hasilnya untuk melanjutkan reasoning. Ini yang menjembatani “otak” LLM dengan dunia nyata.

Memory menyimpan state yang perlu bertahan antar langkah atau bahkan antar sesi. Ada dua level: short-term memory yang hidup dalam context window selama satu sesi, dan long-term memory yang persisten lintas sesi, biasanya disimpan di luar model (database, vector store, atau sistem penyimpanan lain).

Orchestration/control loop adalah lapisan yang mengatur keseluruhan siklus — memutuskan kapan agent lanjut ke iterasi berikutnya, kapan berhenti, dan bagaimana menangani error di tengah eksekusi. Ini sering kali kode “biasa” (bukan LLM) yang menjadi kerangka tempat LLM beroperasi.

Sandbox/execution environment adalah lingkungan terisolasi tempat aksi benar-benar dieksekusi — misalnya container terpisah untuk menjalankan kode yang dihasilkan model. Isolasi ini penting karena aksi yang dihasilkan model, meski umumnya masuk akal, tetap bisa keliru atau berbahaya jika dieksekusi langsung di lingkungan produksi tanpa batasan.

flowchart TD
    subgraph "Sistem Agentic"
        A["Reasoning/Planning Layer<br/>(LLM)"]
        B["Tool Use / Function Calling"]
        C["Memory<br/>(short-term + long-term)"]
        D["Orchestration / Control Loop"]
        E["Sandbox / Execution Environment"]
    end
    D --> A
    A --> B
    B --> E
    E --> C
    C --> A
    D --> F["Kondisi Berhenti<br/>Terpenuhi?"]
    F -- Ya --> G["Selesai"]

Tool Use / Function Calling Secara Detail

Tool use adalah komponen yang paling sering jadi pembeda antara “LLM biasa” dan “agent yang benar-benar berguna”. Mekanismenya bertumpu pada satu ide sederhana: model diberi daftar tools yang tersedia beserta skema dan deskripsinya, lalu model memutuskan sendiri kapan dan bagaimana memanggilnya.

Secara teknis, provider LLM modern menyediakan format terstruktur untuk ini — model tidak menulis kode untuk memanggil tool secara langsung, melainkan menghasilkan output terstruktur (biasanya JSON) yang berisi nama tool dan parameter yang ingin dipanggil. Sistem di luar model yang benar-benar mengeksekusi tool tersebut, lalu mengembalikan hasilnya kembali ke model sebagai bagian dari konteks berikutnya.

sequenceDiagram
    participant User
    participant Agent as LLM (Agent)
    participant Tool as Tool Eksternal

    User->>Agent: "Cek status server produksi"
    Agent->>Agent: Reasoning: perlu data terkini
    Agent->>Tool: call check_server_status()
    Tool-->>Agent: {"status": "degraded", "cpu": "94%"}
    Agent->>Agent: Reasoning: CPU tinggi, perlu investigasi lanjut
    Agent->>Tool: call get_top_processes()
    Tool-->>Agent: [proses A, proses B, ...]
    Agent->>User: "Server degraded, CPU 94%,<br/>disebabkan oleh proses X. Rekomendasi: ..."

Kualitas deskripsi tool punya dampak besar terhadap seberapa andal model memanggilnya dengan benar:

// ANTI-PATTERN: deskripsi tool ambigu, tidak jelas kapan dipakai
{
  "name": "search",
  "description": "Search for stuff"
}

// BENAR: deskripsi jelas, spesifik tentang kapan dan untuk apa
{
  "name": "search_internal_docs",
  "description": "Cari dokumen internal perusahaan berdasarkan
    keyword. Gunakan untuk pertanyaan tentang kebijakan internal,
    SOP, atau data perusahaan — BUKAN untuk pengetahuan umum
    atau informasi publik di luar perusahaan."
}

Model bisa saja memanggil tool yang salah, dengan parameter yang salah, atau memanggil tool padahal tidak perlu — semua ini biasanya berakar dari deskripsi tool yang tidak jelas atau daftar tools yang terlalu banyak dan tumpang tindih fungsinya.

Reasoning Patterns dalam Agentic System

Ada beberapa pola desain yang umum dipakai untuk mengatur bagaimana agent bernalar dan bertindak:

ReAct (Reasoning + Acting) menggabungkan reasoning eksplisit dengan aksi dalam satu loop berulang: model menulis alasan singkat, memutuskan aksi, mengamati hasil, lalu menulis alasan berikutnya berdasarkan hasil itu. Pola ini fleksibel dan reaktif — cocok untuk tugas yang butuh eksplorasi, di mana langkah berikutnya sangat bergantung pada hasil langkah sebelumnya.

Plan-and-execute memisahkan fase perencanaan dari fase eksekusi: model membuat rencana lengkap di awal (daftar langkah yang perlu dilakukan), baru kemudian mengeksekusi langkah-langkah itu satu per satu. Pola ini lebih efisien untuk tugas yang strukturnya sudah cukup jelas di awal, karena tidak perlu bernalar ulang dari nol di setiap langkah.

Reflection/self-critique loop menambahkan tahap tambahan di mana model mengevaluasi hasil kerjanya sendiri sebelum melanjutkan atau menyelesaikan tugas — semacam “proofreading” internal. Ini meningkatkan kualitas output tapi menambah biaya komputasi dan latensi.

Pilihan pola ini bukan eksklusif — banyak sistem agentic produksi mengombinasikan beberapa pola sekaligus, misalnya plan-and-execute untuk struktur besar, dengan ReAct di dalam setiap langkah eksekusi.

Memory dan State Management

Context window saja sering tidak cukup untuk tugas yang panjang atau berlangsung lintas sesi. Semakin panjang konteks yang harus dibawa model di setiap iterasi, semakin besar juga risiko lost in the middle yang sudah dibahas di artikel sebelumnya — dan semakin mahal juga biaya komputasinya.

Beberapa strategi umum untuk mengelola memory dalam sistem agentic:

Summarization — meringkas riwayat panjang jadi versi lebih pendek secara berkala, mempertahankan inti informasi sambil membuang detail yang tidak lagi relevan.

Retrieval-augmented memory — menyimpan informasi di luar context window (biasanya di vector database), lalu mengambil kembali hanya bagian yang relevan dengan query saat ini, bukan membawa seluruh riwayat setiap saat.

External structured storage — menyimpan state penting (misalnya progress tugas, keputusan yang sudah diambil) dalam format terstruktur seperti key-value store atau database, terpisah dari context window model.

Memory yang terlalu kaya bukan selalu lebih baik. Semakin banyak informasi yang dijejalkan ke konteks, semakin besar risiko context pollution — informasi yang tidak relevan justru mengaburkan sinyal yang penting, membuat model lebih mudah bingung atau bahkan mengikuti instruksi yang sudah tidak relevan lagi. Kurasi memory sama pentingnya dengan menyimpannya.

Loop Engineering — Konsep yang Sedang Naik di 2026

Salah satu pergeseran paling signifikan dalam pengembangan agentic AI belakangan ini adalah munculnya loop engineering sebagai disiplin tersendiri — desain eksplisit terhadap siklus kontrol antara model dan tools, bukan sekadar menulis prompt yang bagus lalu berharap agent berperilaku benar.

Bedanya dengan prompt engineering tradisional: prompt engineering fokus pada apa yang dikatakan ke model dalam satu kali interaksi. Loop engineering fokus pada struktur interaksi berulang itu sendiri — kapan loop harus berhenti, bagaimana menangani kegagalan tool di tengah iterasi, bagaimana mencegah agent terjebak mengulang aksi yang sama tanpa progres, dan bagaimana memberi observability ke setiap langkah supaya masalah bisa didiagnosis.

Ini punya keterkaitan langsung dengan pendekatan Spec-Driven Development (SDD) dan Agentic Development yang sudah dibahas di series sebelumnya — SDD memberi spesifikasi yang jelas sebagai kontrak sebelum eksekusi, sementara loop engineering memastikan proses eksekusi itu sendiri berjalan terkendali. Keduanya saling melengkapi: spesifikasi yang baik tanpa loop yang terkendali tetap bisa menghasilkan eksekusi yang kacau, dan sebaliknya.

Prinsip desain loop yang baik:

• Kondisi berhenti yang jelas — jangan biarkan agent berjalan tanpa batas iterasi maksimum atau kriteria “selesai” yang eksplisit.
• Observability di setiap langkah — log setiap keputusan dan aksi, supaya kegagalan bisa didiagnosis, bukan jadi kotak hitam.
• Guardrail terhadap aksi berisiko — aksi yang tidak bisa dibatalkan (menghapus data, mengirim pesan ke pihak luar) harus punya lapisan konfirmasi ekstra.
• Deteksi kebuntuan — mekanisme untuk mengenali saat agent mengulang aksi yang sama tanpa progres, dan menghentikannya sebelum boros resource.

Risiko dan Guardrail dalam Sistem Agentic

Kemampuan agent bertindak otonom membawa risiko yang tidak ada pada LLM murni yang hanya menghasilkan teks.

Runaway loop terjadi saat agent tidak pernah mencapai kondisi berhenti — terus beriterasi tanpa progres nyata, menghabiskan resource komputasi (dan biaya) tanpa henti. Ini sering terjadi saat kondisi “selesai” tidak didefinisikan dengan cukup jelas, atau saat agent terjebak dalam siklus mencoba aksi yang sama berulang kali karena gagal memahami kenapa aksi sebelumnya tidak berhasil.

Tool misuse dan prompt injection adalah risiko di mana hasil dari satu tool (misalnya konten halaman web yang diambil agent) berisi instruksi tersembunyi yang dirancang untuk memanipulasi reasoning model pada langkah berikutnya. Karena model memperlakukan hasil tool sebagai bagian dari konteks yang perlu dipertimbangkan, konten berbahaya yang disisipkan di dalamnya bisa memengaruhi keputusan model tanpa disadari.

Kebutuhan human-in-the-loop muncul untuk aksi-aksi berisiko tinggi atau tidak bisa dibatalkan. Sistem agentic yang baik membedakan antara aksi yang aman dijalankan sepenuhnya otonom (misalnya membaca data) dengan aksi yang butuh konfirmasi eksplisit dari manusia sebelum dieksekusi (misalnya mengirim email ke pihak eksternal atau menghapus data produksi).

// ANTI-PATTERN: agent dengan akses penuh tanpa batas
agent.execute(task, {
  maxIterations: Infinity,
  requireConfirmation: false,
  allowedActions: "*"
});

// BENAR: agent dengan guardrail eksplisit
agent.execute(task, {
  maxIterations: 25,
  requireConfirmation: ["delete", "send_email", "deploy_production"],
  allowedActions: ["read_file", "search", "run_tests"],
  onStuckDetected: (context) => pauseAndNotify(context)
});

Kapan Butuh Agentic AI vs Cukup LLM Biasa

BUTUH AGENTIC AI jika:
  ✓ Tugas butuh banyak langkah dengan keputusan bertahap
  ✓ Perlu akses data eksternal/real-time di luar knowledge model
  ✓ Perlu mengeksekusi aksi nyata (kode, API call, perubahan file)
  ✓ Hasil satu langkah menentukan langkah berikutnya secara dinamis

CUKUP LLM BIASA jika:
  ✗ Tugas single-shot: tanya-jawab, ringkasan, generasi konten sekali jalan
  ✗ Tidak butuh verifikasi atau data eksternal
  ✗ Struktur tugas sudah sepenuhnya diketahui di awal (tidak butuh eksplorasi)

Membangun sistem agentic untuk tugas yang sebenarnya cukup diselesaikan LLM sekali jalan adalah overengineering — menambah kompleksitas, biaya, dan potensi kegagalan tanpa manfaat sepadan. Agentic AI paling bernilai justru saat batasan LLM murni (knowledge cutoff, tidak bisa bertindak, single-shot) benar-benar jadi hambatan nyata untuk tugas yang dihadapi.

Contoh Alur Nyata — Agent Coding Menyelesaikan Bug Report

Untuk mengikat semua konsep di atas jadi satu gambaran utuh, mari telusuri contoh konkret: seorang developer memberi agent tugas “perbaiki bug di mana endpoint /api/users mengembalikan 500 error saat parameter email kosong”.

Iterasi 1 — Reasoning awal. Agent belum tahu penyebab bug, jadi langkah pertamanya adalah investigasi, bukan langsung menulis kode. Model memutuskan perlu membaca kode endpoint terkait.

Iterasi 1 — Act & Observe. Agent memanggil tool read_file pada file yang menangani endpoint tersebut. Hasilnya dikembalikan sebagai teks kode, ditambahkan ke konteks agent.

Iterasi 2 — Reasoning. Dari kode yang dibaca, model melihat ada pemanggilan fungsi validasi yang tidak menangani kasus string kosong dengan benar — kemungkinan penyebab bug. Tapi model belum yakin, jadi memutuskan mereproduksi masalah terlebih dahulu.

Iterasi 2 — Act & Observe. Agent memanggil tool run_tests dengan skenario spesifik (email="") untuk memverifikasi hipotesis. Hasil tes menunjukkan error yang sama seperti dilaporkan — hipotesis terkonfirmasi.

Iterasi 3 — Reasoning. Dengan hipotesis terkonfirmasi, model merancang perbaikan: menambahkan pengecekan eksplisit untuk string kosong sebelum masuk ke logika validasi berikutnya.

Iterasi 3 — Act & Observe. Agent memanggil tool edit_file untuk menerapkan perubahan, lalu langsung memanggil run_tests lagi untuk memverifikasi perbaikan tidak merusak kasus lain (regression check).

Iterasi 4 — Reflection. Sebelum menyatakan tugas selesai, agent melakukan self-critique singkat: apakah ada kasus tepi lain yang belum tercakup (misalnya email=null vs email="")? Jika ada keraguan, agent bisa memilih menambah satu iterasi verifikasi lagi sebelum berhenti.

Selesai. Kondisi berhenti terpenuhi — semua test relevan lulus, perubahan sudah diterapkan. Agent melaporkan ringkasan perbaikan ke developer, termasuk file yang diubah dan hasil test.

Contoh ini menunjukkan bagaimana komponen-komponen yang dibahas sebelumnya bekerja bersama secara konkret: reasoning layer memutuskan strategi di tiap iterasi, tool use menjembatani ke kode nyata, memory menyimpan hasil tiap langkah sebagai konteks untuk langkah berikutnya, dan orchestration layer yang menentukan kapan loop berhenti — dalam kasus ini, saat semua test lulus dan tidak ada lagi ketidakpastian yang perlu diverifikasi.

Perhatikan juga bahwa pola yang dipakai di sini adalah kombinasi ReAct (setiap iterasi bereaksi terhadap hasil sebelumnya) dengan reflection singkat di akhir — persis seperti yang disebutkan sebelumnya bahwa pola-pola ini sering dikombinasikan dalam praktik, bukan dipilih secara eksklusif.

Arah ke Depan — Konteks Ekosistem 2026

Tren loop engineering yang dibahas di atas bukan fenomena terisolasi — ia berjalan beriringan dengan pertumbuhan pesat agentic coding tools sepanjang 2025-2026, di mana developer semakin banyak mendelegasikan tugas coding kompleks ke agent yang bisa merencanakan, mengeksekusi, dan memverifikasi hasil kerjanya sendiri secara berulang, bukan sekadar menghasilkan snippet kode satu kali.

Ini juga makin menyatu dengan filosofi Spec-Driven Development: spesifikasi yang jelas menjadi “kontrak” yang membatasi ruang gerak agent, sementara loop yang terkendali memastikan agent bergerak menuju kontrak itu secara terverifikasi, bukan secara acak. Kombinasi keduanya adalah arah yang tampaknya akan terus berkembang — sistem agentic bukan lagi eksperimen, tapi makin jadi bagian standar dari cara software dikembangkan.

Ringkasan

• LLM murni terbatas oleh knowledge cutoff, tidak bisa verifikasi aktif, tidak bisa bertindak nyata, dan bersifat single-shot secara default.
• Agentic AI membungkus LLM dalam loop Think → Act → Observe yang berulang sampai tugas selesai.
• Anatomi sistem agentic terdiri dari reasoning/planning layer, tool use, memory, orchestration/control loop, dan sandbox eksekusi.
• Tool use menjembatani reasoning model dengan dunia nyata; kualitas deskripsi tool sangat menentukan keandalan pemanggilannya.
• Pola reasoning umum: ReAct (reaktif, eksploratif), plan-and-execute (terstruktur di awal), dan reflection (self-critique untuk kualitas).
• Memory dikelola lewat summarization, retrieval-augmented memory, atau external storage — bukan sekadar mengandalkan context window mentah.
• Loop engineering adalah disiplin desain eksplisit terhadap siklus kontrol agent, melengkapi (bukan menggantikan) spesifikasi yang jelas dari pendekatan SDD.
• Risiko utama sistem agentic: runaway loop, tool misuse/prompt injection, dan kebutuhan human-in-the-loop untuk aksi berisiko tinggi.
• Agentic AI paling bernilai untuk tugas multi-langkah yang butuh aksi nyata dan data eksternal — bukan pengganti universal untuk semua kebutuhan LLM.
• Tren 2026 menunjukkan agentic coding dan loop engineering makin menyatu dengan praktik Spec-Driven Development sebagai standar baru pengembangan software.