Ketika Kode Mulai Punya Rencana Sendiri: Agentic Workflows & AI-Driven Architecture di 2026

Sepanjang 2026, AI di dunia engineering pelan-pelan pindah kursi — dari asisten yang menyarankan baris kode, jadi eksekutor yang menjalankan tugas berlapis. Yang berubah bukan cuma tool-nya, tapi cara kita mendesain sistem dan membagi tanggung jawab.

Ada momen kecil yang mungkin kamu alami juga tahun ini.

Kamu buka issue tracker pagi-pagi, dan salah satu tiket sudah berpindah ke kolom in review. Ada branch baru, ada test yang lolos, ada deskripsi PR yang rapi. Yang mengerjakan bukan rekan setim — tapi agent yang kamu setel minggu lalu dan hampir lupa. Reaksi pertama biasanya campuran: sedikit lega, sedikit curiga, lalu langsung buka diff-nya baris per baris.

Perasaan campur aduk itu, menurut saya, adalah gambaran paling jujur tentang kondisi agentic workflows di 2026. Teknologinya sudah cukup matang untuk dipakai serius. Tapi kebiasaan kerja, arsitektur sistem, dan rasa percaya kita belum sepenuhnya menyusul.

Perpindahan yang tidak terasa dramatis, tapi nyata

Dua tahun lalu, sebagian besar penggunaan AI di software development berhenti di level suggestion: autocomplete pintar, refactor satu file, jelasin fungsi yang bikin pusing. Bantuannya nyata, tapi bentuknya tetap "kamu yang nyetir".

Yang berbeda sekarang adalah kemampuan model untuk bertahan di tugas panjang: menyusun rencana, memanggil tool, membaca hasilnya, sadar kalau salah, lalu mencoba jalur lain. Kedengarannya sederhana, tapi loop itulah yang mengubah AI dari penyaran jadi pelaksana. Dan begitu sesuatu bisa melaksanakan, pertanyaannya langsung berubah — dari "seberapa pintar dia?" jadi "seberapa jauh saya berani melepaskannya?"

Praktik yang muncul di lapangan cukup konsisten, dan sering diringkas jadi tiga kata: delegate, review, own.

• Delegate — agent mengambil pekerjaan lapisan pertama: scaffolding, implementasi rutin, penulisan test, dokumentasi, migrasi berulang.
• Review — manusia memeriksa hasilnya dari sisi kebenaran, risiko, dan kesesuaian dengan konteks bisnis.
• Own — keputusan arsitektur, trade-off, dan tanggung jawab atas apa yang jalan di produksi tetap di tangan manusia. Titik.

Bagian ketiga itu yang paling sering dilewati orang saat cerita soal produktivitas. Agent bisa menaikkan throughput, tapi tidak bisa memikul konsekuensi. Ketika insiden terjadi jam 2 pagi, tidak ada agent yang dipanggil ke war room.

Anatomi sebuah agentic workflow

Kalau dibongkar, hampir semua sistem agentic yang jalan dengan waras punya empat komponen yang sama — apa pun framework-nya.

1. Planner

Memecah tujuan besar jadi langkah-langkah yang bisa dieksekusi. Di sinilah kualitas scoping menentukan segalanya: tugas yang terlalu kabur menghasilkan rencana yang ngawur, dan tidak ada model sebesar apa pun yang bisa menyelamatkan brief yang buruk.

2. Executor

Menjalankan langkah lewat tool: baca file, jalankan test, panggil API, query database. Ini bagian yang paling terlihat "ajaib", padahal justru paling mekanis.

3. Verifier

Memeriksa apakah hasilnya benar sebelum dilanjutkan. Komponen inilah yang paling sering dilupakan, dan paling menentukan. Agent tanpa verifier itu seperti CI tanpa test — cepat, tapi cepat ke mana?

4. Memory / context

Menyimpan apa yang sudah dikerjakan supaya langkah berikutnya tidak mengulang atau bertabrakan. Konteks yang terlalu panjang justru menurunkan akurasi, jadi seni sebenarnya bukan "memasukkan sebanyak mungkin", tapi memilih apa yang layak dibawa.

Pola pikirnya mirip mendesain sistem terdistribusi: setiap langkah bisa gagal, jadi rancang batas, retry, dan titik pemeriksaan sejak awal.

# Loop agentic paling sederhana — sengaja dibikin telanjang
# supaya kelihatan bahwa "agent" itu pada dasarnya sebuah loop dengan rem.

MAX_STEPS = 12          # rem #1: batas iterasi, cegah loop tak berujung
plan = planner.create(goal)

for step in plan.steps[:MAX_STEPS]:
    result = executor.run(step, tools=TOOLS)      # eksekusi lewat tool
    check  = verifier.check(step, result)         # rem #2: validasi hasil

    if not check.ok:
        # jangan langsung menyerah, tapi juga jangan mencoba selamanya
        plan = planner.revise(plan, failure=check.reason)
        continue

    memory.append(step, result)                   # konteks untuk langkah berikutnya

    if check.needs_human:                         # rem #3: escalation gate
        return handoff_to_human(step, result, memory)

Perhatikan tiga "rem" di sana. Dalam pengalaman banyak tim, kegagalan sistem agentic jarang disebabkan model yang kurang pintar — lebih sering karena tidak ada satu pun mekanisme yang menghentikannya saat mulai melenceng.

Protokol: lapisan infrastruktur yang tumbuh diam-diam

Bagian paling "infrastruktur" dari tren ini justru yang paling sedikit dibicarakan di luar lingkaran engineering: standarisasi cara agent bicara dengan dunia luar dan dengan sesamanya.

Dua nama yang paling sering muncul:

• MCP (Model Context Protocol) — menstandarkan cara sebuah agent terhubung ke tool, sumber data, dan layanan eksternal. Dibuat Anthropic dan kemudian diserahkan ke yayasan terbuka, MCP kini didukung lintas vendor besar.
• A2A (Agent-to-Agent) — menstandarkan cara agent saling menemukan dan mendelegasikan tugas satu sama lain, lintas framework.

Cara paling gampang mengingat pembagiannya: MCP itu ke bawah, A2A itu ke samping. MCP menghubungkan agent ke tool yang dia butuhkan; A2A menghubungkan agent ke agent lain. Sistem multi-agent yang serius biasanya memakai keduanya sekaligus.

Kenapa ini penting buat kamu yang tidak sedang membangun platform AI? Karena efeknya sama seperti REST atau OpenAPI dulu: begitu ada standar, integrasi berhenti jadi proyek dan mulai jadi konfigurasi. Kalau layanan yang kamu bangun hari ini punya batas yang jelas dan bisa dideskripsikan mesin, dia akan jauh lebih murah untuk "dipakai agent" tahun depan.

AI-Driven Architecture: mendesain sistem yang ramah agen

Di sinilah trennya berubah dari "tool baru" jadi "keputusan arsitektur". Kalau agent akan jadi salah satu konsumen sistem kita, maka sistem itu perlu didesain agar bisa dipakai oleh sesuatu yang tidak bisa menebak maksud tersirat.

Beberapa prinsip yang mulai terasa jadi konsensus:

Batas yang eksplisit. Endpoint dan tool perlu deskripsi yang jelas, tipe yang ketat, dan efek samping yang tertulis. Manusia bisa menebak bahwa POST /sync itu berbahaya; agent tidak.

Operasi yang idempoten. Agent akan retry. Anggap itu given, bukan kemungkinan.

Least privilege, secara harfiah. Agent yang tugasnya membaca laporan tidak butuh kredensial tulis. Ini terdengar dasar, tapi jadi kritis begitu ada pihak non-manusia yang bisa mengeksekusi keputusan secara mandiri.

Observability yang menceritakan alasan, bukan cuma hasil. Log tradisional menjawab "apa yang terjadi". Sistem agentic butuh jawaban "kenapa langkah ini dipilih" — trace per langkah, tool yang dipanggil, hasil verifikasi, dan biaya token.

// Deskripsi tool yang "agent-friendly": eksplisit soal batas & efek samping.
export const refundOrder = {
  name: "refund_order",
  description:
    "Mengembalikan dana satu order. Hanya untuk order berstatus 'paid'. " +
    "Efek samping: memicu transaksi keuangan nyata dan mengirim email ke pelanggan.",
  input: {
    orderId:      { type: "string", required: true },
    amountCents:  { type: "integer", required: true, max: 5_000_00 }, // plafon keras
    reason:       { type: "string", required: true },
  },
  sideEffects: "irreversible",   // dibaca orchestrator → wajib approval manusia
  idempotencyKey: "orderId",     // aman saat agent melakukan retry
};

Yang menarik, semua prinsip di atas sebenarnya bukan hal baru. Itu praktik integrasi yang baik sejak dulu. Bedanya, sekarang ada konsumen yang benar-benar tidak toleran terhadap ambiguitas — dan itu memaksa kita disiplin.

Bagian yang jarang masuk demo

Demo agentic workflow hampir selalu mulus. Produksi tidak. Beberapa hal yang paling sering menggigit:

Non-determinisme. Input sama bisa menghasilkan jalur berbeda. Ini bukan bug yang bisa "diperbaiki", melainkan properti sistem yang harus diakomodasi — lewat evaluasi berbasis sampel, bukan satu test case.

Konteks yang membusuk. Semakin panjang sesi, semakin besar peluang agent memegang informasi usang dan bertindak berdasarkan itu. Sesi pendek dengan handoff eksplisit hampir selalu lebih andal daripada satu sesi maraton.

Biaya yang menyelinap. Loop yang berjalan lama itu mahal, dan mahalnya baru terasa di tagihan akhir bulan. Budget per task adalah fitur, bukan optimasi belakangan.

Beban review. Ini yang paling underrated. Menaikkan kecepatan produksi kode tanpa menaikkan kapasitas review hanya memindahkan antrean — dari "belum dikerjakan" ke "belum di-review". Bottleneck-nya pindah, bukan hilang.

Ambiguitas tanggung jawab. Kalau agent mengirim perubahan yang merusak produksi, siapa yang punya? Jawaban yang sehat: orang yang menyetujui merge. Kalau tidak ada nama di situ, alurnya yang perlu diperbaiki, bukan agent-nya.

Cara masuk tanpa membakar diri

Kalau timmu belum mulai dan ingin masuk dengan waras, urutan yang paling sering berhasil kira-kira begini:

1. Pilih pekerjaan yang membosankan dan mudah diverifikasi. Migrasi test, update dependency, penulisan dokumentasi dari kode. Kriterianya bukan "yang paling sulit", tapi "yang paling gampang dicek benar-salahnya".
2. Pasang gerbang manusia di titik yang tidak bisa dibatalkan. Merge, deploy, apa pun yang menyentuh uang atau data pelanggan.
3. Ukur end-to-end, bukan per-langkah. Metrik yang berguna: berapa persen output agent yang lolos review tanpa perubahan berarti, dan berapa lama siklusnya. Bukan jumlah baris kode.
4. Perlakukan prompt dan definisi tool seperti kode. Versi, review, dan changelog. Ini aset produksi sekarang.
5. Baru setelah itu, pikirkan multi-agent. Orkestrasi banyak agent menyelesaikan masalah skala, tapi menambah masalah koordinasi. Jangan bayar ongkos itu sebelum kamu butuh.

Penutup: yang sebenarnya sedang kita bangun

Kalau ditarik mundur, tren 2026 ini sebetulnya bukan tentang model yang makin pintar. Model memang membaik, tapi lompatan yang benar-benar terasa di keseharian engineering datang dari hal-hal yang lebih membosankan: protokol yang seragam, batas yang jelas, verifikasi yang otomatis, dan alur kerja yang tahu kapan harus berhenti dan bertanya.

Dengan kata lain, pekerjaan kita tidak hilang — dia naik satu lapis. Dari menulis setiap baris, jadi merancang sistem yang menghasilkan baris-baris itu dengan aman, lalu memutuskan mana yang layak hidup di produksi.

Dan keputusan terakhir itu, sejauh ini, masih pekerjaan yang sangat manusia.