Taksonomi Agen Amazon Quick Rilis: 4 Elemen Inti Arsitektur AI

Kenapa arsitektur agen AI sering bikin developer pusing?

Kekacauan arsitektur paling sering kelihatan saat sistem menerima permintaan umum dari pengguna. Ambil contoh kalimat sederhana ini: "Pantau channel Slack saya dan kirimkan ringkasan harian setiap pagi."

Bagi seorang perekayasa perangkat lunak, permintaan sesimpel itu langsung memicu serangkaian tanda tanya arsitektur. Apakah kita harus membuat satu agen baru khusus pemantau Slack? Atau ini cuma instruksi terjadwal yang kita tempelkan ke agen yang sudah ada? Apakah ini berbentuk alur kerja kaku (workflow), atau sekadar keahlian tambahan (skill)? Karena tidak ada kosakata bersama yang disepakati, semua pertanyaan berbeda ini biasanya langsung runtuh menjadi satu pilihan yang serba membingungkan.

Ketika definisi dasar tidak jelas, kode program cenderung membengkak. Pengembang sering membuat puluhan micro-agents untuk tugas-tugas kecil yang sebenarnya bisa diselesaikan oleh satu entitas tunggal. Di sisi lain, ada juga yang memaksakan semua logika rumit masuk ke dalam satu prompt raksasa yang rapuh dan boros token pemrosesan. Taksonomi agen Amazon Quick hadir memecah kebuntuan ini dengan menyusun kembali blok-blok pembangun sistem ke tempat asalnya masing-masing.

4 pilar taksonomi agen Amazon Quick: When, What, Who, dan How

AWS menyederhanakan seluruh kerumitan komputasi agen otonom menjadi empat pertanyaan paling mendasar yang biasa kita pakai dalam kehidupan sehari-hari:

1. When? (Kapan): Kapan pekerjaan harus dimulai dan sinyal apa yang menyalakannya?
2. What? (Apa): Apa tugas spesifik serta batasan instruksi yang harus diselesaikan?
3. Who? (Siapa): Siapa entitas atau aktor berakal yang memegang tanggung jawab pelaksanaan?
4. How? (Bagaimana): Bagaimana metode, instrumen, dan prosedur yang dipakai untuk menyelesaikannya?

Dalam kerangka kerja Amazon Quick, kombinasi pertanyaan When? dan What? dijawab oleh komponen yang disebut Triggers. Pertanyaan Who? dipegang seutuhnya oleh sang Agent. Sementara pertanyaan How? diselesaikan lewat kumpulan Capabilities yang terbagi dalam spektrum ketat: tools, skills, dan workflows. Mari kita kupas satu per satu mekanismenya.

Memahami Triggers: Jawaban untuk When dan What

Banyak orang mengira pemicu (trigger) hanyalah tombol sakelar atau jadwal jam dinding digital. Namun dalam taksonomi Amazon Quick, trigger punya peran ganda yang sangat penting: ia mengaktifkan pekerjaan (When?) sekaligus membawa muatan instruksi tugas (What?).

Ketika seorang pengguna mengetik pesan di ruang obrolan, pesan manusia itu bukan cuma penanda waktu kapan sistem harus aktif. Teks yang diketik manusia itu sendiri adalah deskripsi lengkap mengenai apa yang harus dikerjakan. Oleh karena itu, AWS membagi pemicu tugas menjadi empat kategori utama:

• Human-initiated: Pemicu yang dimulai langsung oleh manusia lewat sesi interaktif. Sifatnya sinkron, berbasis obrolan langsung, dan membutuhkan responsivitas tinggi.
• Agent-delegated: Pemicu yang dijalankan oleh satu agen kepada agen lain di tengah pengerjaan tugas besar. Pola ini berjalan secara programatis, bisa digabungkan, dan berpotensi berjalan berulang atau rekursif untuk menyelesaikan sub-masalah.
• Scheduled: Pemicu berbasis jadwal waktu yang sifatnya pasti atau deterministik. Contohnya perintah rutin: "Jalankan riset keuangan setiap hari Senin pukul 09.00 pagi." Instruksi yang dibawa selalu sama dan konsisten dari satu periode ke periode berikutnya.
• Event-driven: Pemicu berbasis peristiwa dari ekosistem luar. Sinyalnya bisa berupa email baru yang mendarat di inbox, tanda mention di kanal perpesanan kantor, perubahan dokumen di penyimpanan cloud, atau panggilan webhook pihak ketiga.

Jenis pemicu ini punya pengaruh langsung terhadap bagaimana agen mengeksekusi tugas. Tugas terjadwal di latar belakang (scheduled) biasanya diprogram untuk bertindak sangat hati-hati atau konservatif. Kalau agen menemukan ketidakpastian data di tengah malam, ia bakal memilih berhenti daripada membuat kesalahan fatal. Sebaliknya, pada pemicu obrolan manusia (human-initiated), agen bakal bersifat responsif: daripada berhenti diam-diam, agen akan langsung bertanya balik ke manusia untuk meminta klarifikasi.

Siapa sebenarnya sang agen (The Who)?

Definisi agen menurut AWS di sini sangat tegas dan mencerahkan. Agen adalah aktor persisten yang punya kemampuan belajar (persistent, learning actor). Agen adalah jawaban atas pertanyaan Who?, sekaligus jangkar utama tempat akumulasi pemahaman dan pengalaman disimpan dari waktu ke waktu.

Dua agen yang diberikan instruksi awal persis sama bisa menghasilkan keputusan yang berbeda di kemudian hari. Kenapa begitu? Karena keduanya membawa riwayat perjalanan, kapabilitas tambahan, dan rekaman pembelajaran yang berbeda. Agen bukan sekadar teks perintah sistem (prompt) yang ia baca, melainkan entitas cerdas yang menafsirkan perintah tersebut. Secara struktural, satu agen terdiri dari tiga fondasi:

• Instructions: Panduan berdiri (standing guidance) yang mendefinisikan persona, batasan peran, file konteks pendukung, dan prinsip-prinsip operasional utama. Agen Keuangan bakal bersikap beda dari Agen Pembantu Umum terutama karena instruksi dasar ini.
• Capabilities: Kumpulan instrumen kerja yang mencakup tools, skills, workflows, hingga sub-agen pembantu yang tersedia untuk dipakai. Kumpulan kapabilitas ini sifatnya sangat dinamis; sebuah pustaka grafik bisa ditempelkan ke agen pada sesi pagi hari dan dicopot kembali pada sesi sore hari.
• Learned context: Memori pengalaman yang menumpuk otomatis seiring pemakaian. Agen mencatat kueri mana yang paling manjur untuk sebuah alat, tata letak laporan yang paling disukai pengguna, hingga kasus batas (edge cases) yang paling dihindari pengguna. Lewat memori ini, eksekusi tugas ke-10 bakal jauh lebih rapi dibanding eksekusi pertama, tanpa ada satu baris instruksi pun yang diubah oleh developer secara manual.

Menariknya, AWS memandang semua hal di luar ketiga fondasi tadi hanyalah elemen ekstrinsik semata. Model bahasa besar (LLM) di balik layar cuma dianggap sebagai parameter model yang bisa ditukar kapan saja. Riwayat obrolan hanyalah status sementara per sesi, dan pemicu kerja adalah milik platform penampung.

Konsekuensi logis dari definisi ini sangat besar. Ketika pengguna kantor berkata, "Tolong bikin agen pemantau Slack harian," developer tidak perlu lagi membuat bot baru atau menulis kode alur kerja baru. Permintaan itu pada hakikatnya cuma menambahkan sebuah trigger baru ke dalam agen yang sudah ada. Agen obrolan, agen penjadwalan, dan agen mandiri akhirnya melebur jadi satu kesatuan aktor yang utuh: aktor yang bisa kamu ajak ngobrol, bisa kamu atur jadwalnya, serta mampu menginspeksi hasil kerjanya sendiri di masa lalu.

Capabilities: Spektrum antara fleksibilitas otonom dan kepastian kode

Kapabilitas adalah instrumen bagaimana (How?) seorang agen bertindak di dunia nyata. AWS membedahnya bukan sebagai kumpulan fungsi acak, melainkan sebagai sebuah spektrum berkesinambungan. Spektrum ini bergerak dari sisi yang sepenuhnya otonom (fully agentic) hingga sisi yang sepenuhnya kaku dan pasti (fully deterministic).

Sumbu spektrum ini pada dasarnya adalah sebuah kontrak keyakinan (confidence contract). Maksudnya, seberapa besar ruang kebebasan nalar yang ingin kamu percayakan kepada model AI, berbanding seberapa kaku kepastian aturan yang ingin kamu kunci lewat kode program sejak awal.

Dalam taksonomi agen Amazon Quick, kapabilitas dibagi menjadi tiga bentuk utama:

1. Tools (Alat Kerja Atomik)

Tools adalah operasi atomik dengan skema data bertipe ketat (typed schema). Contohnya fungsi sederhana seperti mengirim email, menarik data dari basis data SQL, atau membaca isi berkas teks. Mau wujudnya berupa fungsi Python lokal, server Model Context Protocol (MCP), atau agen lain di balik protokol jaringan, pemanggil tetap melihat antarmuka yang seragam: nama fungsi, deskripsi fungsi, parameter masukan, dan hasil kembalian. Integrasi protokol semacam ini mirip dengan ulasan yang pernah kita bahas di artikel MCP Server ECS Fargate.

2. Skills (Panduan Terstruktur Fleksibel)

Skills adalah bundel panduan terstruktur yang masih memberikan ruang pertimbangan luas bagi agen. Skill menggabungkan instruksi kerja mendalam bersama aset pendukung seperti template dokumen, skrip bantu, dan contoh keluaran. Berbeda dari alur kaku, skill mendeskripsikan sebuah pendekatan, bukan urutan langkah mati.

Yang paling keren, skill dimuat dengan metode pengungkapan bertahap (progressive disclosure). Saat agen sedang santai, ia cuma melihat daftar nama dan ringkasan pendek dari skill yang ia miliki di dalam memorinya. Baru ketika sebuah tugas membutuhkan keahlian itu, seluruh isi instruksi mendalamnya dibaca ke dalam memori kerja model. Teknik ini bikin agen bisa menampung segudang keahlian tanpa membebani biaya token secara terus-menerus.

3. Workflows (Koordinasi Pasti Terprogram)

Workflows adalah koordinasi deterministik di mana urutan langkah, percabangan logika (if-else), dan penanganan galat (error handling) dideklarasikan secara baku di dalam kode program, bukan diputuskan oleh inferensi model AI. Contoh paling pas adalah alur pengajuan belanja barang kantor: pertama cek sisa anggaran, minta persetujuan manajer, lalu lempar ke bagian akuntansi. Rute jalurnya dikunci mati oleh kode, namun pertimbangan halus di dalam setiap kotak langkah tetap diserahkan kepada penalaran sang agen.

Kenapa skills dan workflows tetap abadi meski LLM makin pintar?

Di kalangan komunitas teknologi sering muncul perdebatan: kalau model bahasa besar generasi baru nanti makin pintar dan minim halusinasi, bukankah keberadaan skill dan workflow bakal punah dengan sendirinya?

AWS dengan tegas menjawab: tidak. Keduanya punya nilai abadi yang independen dari kecerdasan sebuah model dasar. Skills adalah unit terbaik organisasi untuk mendokumentasikan, memberi nomor versi, dan mendistribusikan keahlian kerja institusi ke banyak tim. Sementara itu, workflows memberikan jaminan auditabilitas, transparansi visibilitas per langkah kerja, dan orkestrasi multi-layanan yang wajib patuh pada hukum logika biner.

Menariknya lagi, batas antara keduanya tidak bersifat permanen di Amazon Quick. Melalui kerangka kerja pembelajaran berkelanjutan (continuous learning framework), kedua kapabilitas ini bisa saling bertransformasi secara dinamis:

• Crystallization (Kristalisasi): Sebuah skill yang sudah sangat sering dijalankan dan polanya sudah sangat dipahami bisa mengeras atau memadat menjadi sebuah workflow kaku agar lebih hemat daya dan cepat.
• Dissolution (Pelarutan): Sebuah workflow kaku yang di lapangan terus-menerus menabrak kasus batas baru (edge cases) bisa mencair kembali menjadi skill yang lebih fleksibel supaya agen punya ruang bernalar mencari jalan keluar.

Proses pemadatan dan pelarutan kapabilitas ini berjalan otomatis di balik sistem Amazon Quick, yang detail arsitekturnya dijanjikan AWS bakal dibahas lebih dalam pada artikel lanjutan mereka.

Contoh nyata di lapangan: Kasus ringkasan Slack

Untuk melihat bagaimana seluruh primitif ini menyatu, kita bisa kembali ke contoh kasus pemantauan Slack tadi. Karena primitif ini bersifat modular (composable), satu kebutuhan yang sama sebetulnya bisa diwujudkan lewat tiga rancangan arsitektur berbeda:

1. Model Minimalis: Sebuah tugas terjadwal (scheduled trigger) dengan satu baris instruksi polos, membiarkan nalar sang agen menebak sendiri cara membaca dan merangkum obrolan.
2. Model Berbasis Keahlian: Tugas terjadwal yang sama, tetapi dibekali sebuah skill khusus yang memuat aturan pemformatan teks tebal, daftar kanal prioritas, dan contoh ringkasan yang ideal.
3. Model Berbasis Alur Pasti: Tugas terjadwal yang mengeksekusi sebuah workflow deterministik dengan urutan langkah pasti: ambil log percakapan, saring pesan eror teknis, susun teks rangkuman, jalankan validasi sensor data, baru kirimkan ke email manajer.

Ketiga cara di atas sama-sama menghasilkan ringkasan harian di jam yang sama. Yang membedakan hanyalah kontrak keyakinan (confidence contract). Pengguna biasa yang menaruh kepercayaan penuh pada nalar AI cukup memakai cara pertama. Pengguna yang pernah kecewa akibat format teks berantakan bakal memilih cara kedua. Sedangkan tim kepatuhan perbankan yang terikat aturan ketat audit korporasi bakal mewajibkan cara ketiga.

Seiring berjalannya waktu, pembelajaran mesin di latar belakang bakal menyempurnakan tugas tersebut. Tugas yang awalnya cuma bermodal kalimat pendek: "Cek email saya untuk hal mendesak," lama-kelamaan bakal mengumpulkan konteks spesifik dari kebiasaan nyata pengguna: kata kunci kueri pencarian mana yang paling akurat, gaya bahasa laporan yang disukai atasan, hingga alamat email pengirim mana yang wajib diprioritaskan. Pada putaran kesepuluh, hasil ringkasannya bakal berkali-kali lipat lebih tajam dibanding hari pertama, tanpa perlu ada insinyur perangkat lunak yang mengedit kode programnya.

Penerapan praktis buat developer dan tim IT di Indonesia

Buat developer, insinyur AI, dan pengembang produk digital di Indonesia, pelajaran dari Amazon Quick ini ngasih panduan nyata waktu menyusun sistem internal kantor atau produk SaaS berbasis agen:

1. Hindari Pemborosan Entitas Agen: Berhentilah bikin puluhan bot terpisah untuk tugas-tugas kecil. Satukan aktor di balik satu agen utama, lalu kendalikan aksinya lewat penambahan trigger berkala dan pengelolaan pustaka tools yang rapi.
2. Patuhi Regulasi Data dan UU PDP lewat Workflow: Di Indonesia, kepatuhan pemrosesan data identitas dan data finansial menuntut auditabilitas ketat. Jangan serahkan alur transmisi data sensitif ke nalar probabilistik LLM. Gunakan workflow deterministik untuk mengunci batasan kepatuhan, dan manfaatkan tata kelola agen seperti yang dibahas di artikel Okta Bedrock AgentCore Governance.
3. Hemat Biaya Token Operasional: Memuat semua panduan operasional perusahaan ke dalam system prompt utama bikin tagihan komputasi melonjak tajam. Terapkan metode pemuatan bertahap (progressive disclosure) ala skills Quick: biarkan agen cuma membaca judul keahliannya saja di awal, dan baru unduh berkas instruksi lengkapnya saat tugas relevan dipanggil.

Kalau kamu lagi merancang arsitektur agen modular dan butuh fleksibilitas gonta-ganti model bahasa tanpa pusing menulis ulang logika integrasi API, kamu bisa memanfaatkan platform Classai Router. Cukup gunakan satu API key yang kompatibel dengan SDK standar OpenAI dan Anthropic, lalu arahkan base URL ke router lokal kami. Kamu bisa memasangkan model penalaran berat seperti Claude Sonnet 4.6 (Rp2.700 / Rp13.500 per 1M token) untuk agen perencana utama, dan model super cepat hemat biaya seperti gpt-4o-mini (Rp945 / Rp3.750 per 1M token) untuk agen eksekutor alat atomik.

Semua riwayat pemanggilan, latensi, dan biaya token langsung tercatat rapi per transaksi tanpa perlu langganan kartu kredit luar negeri yang ribet. Kalau tim teknismu mau mendalami cara membangun integrasi agen AI yang siap skala industri, kamu juga bisa mengikuti silabus terarah di kelas AI untuk Developer.

Contoh format penulisan panduan skill mandiri

Untuk menyusun modul skill yang rapi dan siap dimuat secara dinamis oleh sistem agenmu, berikut contoh struktur instruksi terarah yang memadukan panduan peran, batasan nalar, dan format keluaran tanpa mengunci urutan kode secara kaku:

Nama Skill: Ringkasan Insiden Server HarianDeskripsi Singkat: Menganalisis log galat sistem dan menyusun ringkasan status operasional teknis. Panduan Peran:Kamu adalah analis keandalan sistem (SRE). Tugasmu mengevaluasi berkas log kejadian kritis dan memilah masalah menjadi ringkasan yang mudah dipahami manajemen. Aturan Evaluasi:1. Kelompokkan galat berdasarkan komponen layanan terkait.2. Tentukan tingkat urgensi: Rendah, Sedang, atau Kritis berdasarkan dampaknya ke pengguna.3. Jangan menebak penyebab masalah jika log tidak memuat jejak galat (stack trace) lengkap; tuliskan sebagai 'Perlu Investigasi Manual'. Format Keluaran:- Ringkasan Eksekutif (maksimal 2 paragraf).- Tabel Insiden: [Nama Layanan | Kode Status | Tingkat Urgensi | Dampak Langsung].- Rekomendasi Mitigasi Prioritas.