Ambient Agents di Amazon Bedrock: AI yang Gerak Sendiri Lewat Event

Apa itu ambient agents dan kenapa beda dari chatbot biasa?

Agent berbasis chat jalan dengan pola User → Prompt → Agent → Response → User. Kamu buka aplikasi, ngetik, nunggu jawaban. Cocok buat pertanyaan sekali jalan, tapi nggak cocok kalau yang perlu direspons itu kejadian di infrastruktur — file ke-upload, data di database berubah, ada alert sistem.

Ambient agent (konsep yang juga udah dibahas LangChain) pakai pola beda: Event → Signal → Agent → [interaksi manusia kalau perlu] → Action. Agent-nya dengerin stream event dan bisa nanganin banyak event sekaligus secara paralel, tanpa harus dipicu pesan manusia. Tapi penting dicatat, agent ini nggak sepenuhnya otonom — desainnya sengaja bikin agent berhenti buat interaksi manusia di momen-momen tertentu, biar risikonya lebih kecil pas dipakai di produksi.

Pipeline otomatis kayak AWS Step Functions bisa ngatur workflow tapi nggak bisa nalar kalau ada hal ambigu atau nanya klarifikasi. Chatbot bisa nalar tapi butuh orang yang mulai percakapan duluan. Ambient agent ini posisinya pas di tengah — nalar jalan, tapi tetap nunggu sinyal dari sistem buat mulai kerja.

Gimana sinyal event berubah jadi job yang dikerjain agent?

AWS nyebut konfigurasi yang nyambungin sumber event ke agent sebagai "ambient signal". Begitu event-nya kejadian, platform otomatis bikin job buat agent itu. Yang nentuin agent langsung jalan atau nunggu dulu cuma satu setting: autoExecute.

Kalau autoExecute: false (ini default-nya), job bakal mendarat di halaman Jobs dengan status idle, nunggu manusia review dan jalanin manual. Ini alur yang aman kalau sinyalnya bisa ke-trigger dari input yang nggak pasti, atau kalau agent-nya punya tool yang berisiko gede. Kalau autoExecute: true, job langsung masuk queue worker dan agent jalan sendiri — manusia cuma diajak masuk kalau agent itu sendiri yang manggil tool ask_human.

Sumber event yang udah siap pakai di reference implementation ada dua: upload file ke Amazon S3, dan scheduled event (jalan di jadwal cron). Webhook API dan perubahan database (lewat DynamoDB streams atau Amazon RDS) baru sebatas extension point — kamu perlu nulis Lambda handler baru sendiri buat itu.

Data signal-nya disimpan di DynamoDB dengan field kayak signalType, bucketName, prefix, suffix, dan triggerCount. Satu detail teknis yang menarik: partition key GSI DynamoDB nggak bisa nested di dalam map attribute, jadi configuration.bucketName yang kamu isi lewat API otomatis di-mirror ke field bucketName di level atas biar index-nya bisa nemuin signal yang cocok setiap ada event S3 baru.

Human-in-the-loop: satu tool ask_human buat semua skenario

Bagian paling menarik dari desain ini, menurut kami, adalah kesederhanaannya. Semua interaksi manusia — mau itu agent cuma lapor hasil, nanya klarifikasi, minta approval buat suatu tindakan, atau ngasih tahu ada error — lewat satu tool yang sama: ask_human. Responnya dibungkus dalam satu "envelope" yang isinya status (completed, interrupted, atau error) plus field yang sesuai (result, question, atau error).

Begini pola-pola yang muncul dari penggunaan tool ini di lapangan:

Semua pola di atas sebenarnya cuma konvensi gimana agent nulis pertanyaannya — di level platform cuma ada satu code path dan satu envelope. Begitu agent balikin status interrupted, job otomatis masuk tab Interrupted di halaman Jobs dengan tanda peringatan, jadi nggak perlu ada queue review terpisah yang harus dipantau manual.

Arsitektur di balik layar: dari S3 sampai AgentCore Runtime

Seluruh platform ini serverless, disusun dari komponen AWS yang kemungkinan udah familiar buat tim yang udah pakai AWS: Amazon S3 buat trigger event, Amazon SQS buat decouple antara permintaan API dan panggilan agent, tiga Lambda function (Signal Processor, Job Execution, Scheduler), Amazon Bedrock AgentCore Runtime buat jalanin agent di container terisolasi, dan Amazon DynamoDB buat nyimpen semua state.

Frontend-nya React dan Cloudscape Design, disajikan dari S3 lewat CloudFront, dengan lima tab navigasi: Workflows, Chat, Agents, Jobs, dan halaman detail yang nunjukin semua interaksi pending. Jadi satu tempat buat user ngecek semua yang lagi dikerjain agent-nya, nggak perlu mantau banyak jendela chat atau email bolak-balik.

Dari job masuk sampai agent kerja: peran AgentCore Runtime dan DynamoDB

Job Execution Lambda function punya dua jalur masuk. Jalur API langsung enqueue pesan ke SQS dan balikin status 202 Accepted — jadi frontend nggak perlu nunggu model selesai kerja. Jalur SQS worker inilah yang beneran jalanin kerjaan: dia load riwayat percakapan, gabungin jawaban manusia (kalau ada) ke prompt lanjutan, panggil AgentCore Runtime, lalu tulis hasilnya balik ke DynamoDB.

Agent-nya sendiri dibangun pakai langchain.agents.create_agent yang dikompilasi jadi LangGraph — tool-calling agent dengan tool kalkulator, pembaca file S3, dan ask_human. Default model yang dipakai reference implementation ini adalah Anthropic Claude Sonnet 4.5 di Amazon Bedrock, karena cocok buat tool calling bertahap dan reasoning context panjang yang dibutuhin alur human-in-the-loop. Ganti ke Claude Haiku, Amazon Nova, atau model tool-calling lain yang ada di Bedrock cuma butuh ubah satu baris model_id di config.

DynamoDB jadi "sistem pencatatan" buat semuanya — registry agent, status job, riwayat percakapan (dengan TTL 30 hari), dan definisi signal. Penulisan riwayat percakapan pakai UpdateItem + list_append secara atomik, jadi dua proses yang nulis bareng ke session yang sama nggak bakal saling tabrak.

Cara nyobain reference implementation ini sendiri

AWS ngerilis kode lengkapnya di reference implementation GitHub. Kalau kamu developer dan mau nyobain, ini langkah intinya berdasarkan prasyarat yang disebutin:

1. Siapkan akun AWS dengan izin bikin IAM role, Lambda, DynamoDB, S3, SQS, API Gateway, CloudFront, Cognito, ECR, dan Bedrock AgentCore runtime.
2. Pastikan AWS CLI udah terkonfigurasi dengan Region default us-east-1, dan AWS CDK v2 udah di-bootstrap.
3. Nyalain Docker lokal — container agent-nya dibangun dan di-push ke ECR waktu deploy.
4. Sediakan Python 3.11+ buat backend dan build agent, plus Node.js 18+ buat frontend React.
5. Aktifkan akses ke model Anthropic Claude Sonnet 4.5 di Bedrock lewat panduan Manage access to Amazon Bedrock foundation models — ketersediaan model beda-beda tiap Region.
6. Deploy agent-nya pakai script ./deploy_agent.sh dari folder agent, yang bakal build container, push ke ECR, dan register ke Bedrock AgentCore Runtime.

Kalau kamu cuma mau ngerasain dulu gimana rasanya desain prompt system buat agent yang nanya manusia di tengah jalan, sebelum ribet setup AWS, kamu bisa eksperimen konsepnya pakai model kayak claude-sonnet-4.5 (Rp160 / Rp800 per 1 juta token input/output) lewat Classai Router — cukup ganti base URL, SDK Anthropic atau OpenAI yang udah kamu pakai nggak perlu diubah.

Kamu adalah asisten AI yang analisis dokumen invoice yang baru di-upload.Tugasmu: baca isi file, tentuin kategori beban (Hardware/Services/Software).Kalau dokumennya punya lebih dari satu kategori beban dan kamu nggak yakinmana yang harus difokuskan, PANGGIL tool ask_human dengan pertanyaan spesifiksebelum lanjut analisis. Jangan nebak kategori sendiri.

Buat yang pengin paham dulu konsep dasar API AI sebelum nyemplung ke setup AWS yang lumayan banyak komponennya, bisa baca Apa itu API AI? Panduan Lengkap untuk Pemula. Kalau topik agent AI dan Bedrock AgentCore ini bikin kamu penasaran lebih jauh, kami juga pernah bahas Claude AI yang kini bisa web search lewat AWS Bedrock AgentCore.

Dampak buat developer dan bisnis di Indonesia

Buat tim developer di Indonesia yang udah pakai AWS buat infrastruktur, pola ini kemungkinan kerasa familiar — S3 event notification, EventBridge, Lambda trigger, DynamoDB streams udah lama jadi bagian dari stack banyak startup lokal. Yang baru di sini adalah cara nyambungin semua itu ke agent yang bisa nalar, bukan cuma ngejalanin pipeline kaku.

Buat tim yang ngurusin dokumen dalam volume banyak — finance yang proses invoice, legal yang review kontrak, atau operasional yang pantau alert sistem — pola autoExecute: false ini kemungkinan jadi pilihan aman buat mulai. Agent-nya jalan, tapi manusia tetap review sebelum ada tindakan diambil, jadi risiko kesalahan nggak langsung berdampak ke sistem produksi. Soal keamanan data, karena semua proses jalan di infrastruktur AWS milik perusahaan sendiri (bukan nitip data ke layanan luar), ini jadi pertimbangan yang relevan buat perusahaan yang perlu patuh UU PDP.

Kalau kamu kerja di tim kecil atau UMKM yang mau mulai eksperimen agent tanpa langsung bangun infrastruktur AWS selengkap ini, artikel kami soal reliabilitas agen AI di database bisa jadi bacaan lanjutan yang relevan buat ngerti risiko-risiko serupa di level yang lebih sederhana.

Batasan yang perlu diperhatiin sebelum pakai di produksi

Reference implementation ini bukan produk siap pakai plug-and-play — ini blueprint yang masih butuh kerja tambahan buat kasus pakai spesifik kamu. Webhook API dan trigger database cuma "extension point", kamu perlu nulis handler Lambda sendiri. Setiap turn agent juga dibatasin sama timeout Lambda 15 menit, dan max_iterations: 10 ngatur berapa kali agent boleh gantian panggil tool sebelum berhenti.

Secara keseluruhan, pola ambient agent ini menurut kami nunjukin arah yang lebih matang buat deploy AI agent di produksi — nggak full otonom yang berisiko, tapi juga nggak sekadar chatbot yang nunggu perintah. Buat developer Indonesia yang udah mulai eksplor agentic AI, pola event-driven plus human-in-the-loop kayak ini kemungkinan jadi standar yang makin umum ke depannya.