Postman Agent Mode Bedrock: Rahasia AI Skala 40 Juta Developer

Apa Itu Postman Agent Mode dan Kenapa Butuh Bedrock?

Agent Mode adalah cara kerja baru di Postman yang sifatnya AI-native. Fitur ini dirancang buat nemenin developer ngerjain siklus hidup API secara utuh, mulai dari testing, bikin dokumentasi, nemuin endpoint, sampai implementasi kode. Masalahnya, Postman udah berkembang selama 11 tahun. Selama ini, user terbiasa nyari info lewat antarmuka visual—klik sidebar, buka tab baru, terus utak-atik parameter request.

AI agent nggak mikir kayak mata manusia yang ngeliat layar monitor. Agent butuh penalaran langsung di atas data mentah. Waktu tim Postman pertama kali ngebangun fitur ini, mereka sadar kalau arsitektur lama mereka penuh asumsi tampilan UI yang bikin pusing model AI.

Buat menopang beban kerja global yang lalu lintasnya sering melonjak tiba-tiba (bursty traffic), Postman memilih Amazon Bedrock. Bedrock ngasih akses terkelola ke berbagai model fondasi terdepan tanpa bikin Postman repot ngurus server GPU sendiri. Fleksibilitas ini bikin tim engineer bisa gonta-ganti model Claude, ngatur lokasi pemrosesan data, dan nekan biaya tanpa bongkar pasang kode backend dari nol.

Selain urusan komputasi, Postman juga nggak mau kecolongan soal keamanan data. Agent Mode mewajibkan persetujuan manual (human approval) sebelum menjalankan aksi yang ngubah state aplikasi, kayak ngirim request berbahaya atau ngedit collection. Buat urusan privasi, mereka masang Amazon Bedrock Guardrails buat nge-redact data pribadi (PII) sebelum teksnya nyampe ke LLM.

Masalah Tool Sprawl: Kenapa Kebanyakan Tool Bikin Agent Ngaco?

Di awal pengembangan, tim Postman bikin banyak tool kecil yang sangat spesifik (atomic tools). Misalnya, ada satu tool cuma buat ngebuka request, satu tool buat ngubah satu kolom header, dan tool lain buat narik metadata. Awalnya cara ini kerasa aman dan gampang dikontrol pas uji coba kecil-kecilan.

Tapi pas masuk skenario nyata, pendekatannya malah bikin runyam. Pertama, alur kerja jadi lelet banget karena agent harus bolak-balik manggil model buat tiap langkah sepele. User yang ngeliat prosesnya jadi gregetan sendiri karena hal yang mereka anggap satu tarikan nafas malah dieksekusi pelan-pelan.

Kedua, tim Postman nemuin batas kritis: begitu jumlah tool yang dilihat model nembus angka 40, tingkat error pemilihan tool langsung melonjak drastis. Agent mulai halusinasi manggil tool yang nggak ada, salah ngisi argumen, atau milih tool yang namanya mirip tapi fungsinya keliru. Model AI yang lebih pintar emang bisa ngurangin masalah ini, tapi nggak bener-bener ngilangin error-nya.

Solusinya? Postman membatasi eksposur tool secara dinamis lewat arsitektur sub-agent dan vector database.

Dari total lebih dari 170 tools yang ada di katalog Postman, root agent bakal ngecek kebutuhan user ke vector database berisi embedding tools. Dari situ, sistem cuma nyaring sekitar 15 tools yang paling nyambung sama tugas tersebut, lalu menyerahkannya ke sub-agent yang terisolasi. Model AI nggak pernah ngeliat 170 tools sekaligus, jadi risiko salah pilih tool bisa ditekan habis-habisan.

Masalah lain yang diberesin adalah keterikatan tool sama tab visual. Dulu, agent harus ngebuka tab request di layar cuma buat ngebaca isinya. Sekarang, lewat fitur kayak Native Git, Postman memisahkan aksi agent dari tampilan layar, sehingga agent bisa nembak request di background tanpa perlu buka tab baru sama sekali.

Jurus Schema-Based Read: Ganti Puluhan Tool Pakai Query Langsung

Salah satu terobosan paling keren di Postman Agent Mode ada di bagian pembacaan data analitik API Catalog. Fitur ini nyimpen data terstruktur yang banyak banget, kayak uptime service, log hasil pengujian, dan latensi endpoint dari berbagai layanan.

Alih-alih bikin puluhan tool terpisah kayak getServiceUptime, getEndpointLatency, atau getTestFailures, tim engineer Postman milih jalan lain. Mereka ngasih skema tabel ClickHouse langsung ke agent dan ngizinin si AI nulis query SQL sendiri.

Contoh query analitik kompleks yang di-generate sama agent Postman kelihatan kayak gini:

SELECT toString(service_id) AS service_id,
countMerge(total_events_state) AS total_requests,
countMerge(error_events_state) AS total_errors,
round(countMerge(error_events_state) * 100.0
/ countMerge(total_events_state), 4) AS error_rate_pct,
avgMerge(avg_latency_state) AS avg_latency_ms,
quantileMerge(0.95)(p95_latency_state) AS p95_latency_ms
FROM http_events_summary_1d
WHERE service_id IN ('...list of service IDs')
AND bucket_1d >= today() - 7
GROUP BY service_id
HAVING p95_latency_ms < 100
AND total_requests > 0
ORDER BY error_rate_pct DESC;

Dengan pola ini, tugas engineer bergeser dari sibuk bikin puluhan tool baru jadi merapikan pemodelan data di database. Begitu skemanya rapi dan jelas, agent bisa nanganin variasi pertanyaan analitik yang jauh lebih luas tanpa butuh tambahan kode tool baru sama sekali.

Mengatasi Masalah Konteks: Data UI Bukan Konteks yang Bagus

Awalnya Postman ngira kekurangan tool adalah penghambat utama performa agent. Ternyata mereka salah tebak. Masalah paling sering yang bikin agent gagal justru konteks yang hilang atau nggak lengkap.

Konteks di sini artinya pemahaman agent soal posisi user di aplikasi, entitas mana yang lagi aktif, dan status data sebelumnya. Kalau konteksnya salah, tool sekeren apa pun bakal ngasilin output yang ngawur.

Postman membagi asupan konteks jadi dua jalur utama:

1. Broad, shallow background context: Info umum yang diambil otomatis dari lingkungan kerja user, lalu diperkecil ukurannya (minified) biar hemat token.
2. Deep, focused selected context: Objek spesifik yang sengaja dipilih sama user. Bagian ini diproses lewat handler khusus per tipe entitas buat membuang bagian yang nggak penting dan menyisakan intinya aja.

Tim Postman menegaskan pelajaran penting: jangan pernah langsung ngirim data serialization UI (seperti format JSON buat rendering komponen) ke prompt model AI. Data rendering itu dibikin buat kebutuhan visual browser, bukan buat penalaran logika. Makanya, handler khusus sangat dibutuhin buat merangkum spesifikasi OpenAPI, payload JSON besar, atau deskripsi panjang biar nggak bikin context window kepenuhan.

Selain konteks dinamis, Postman juga menyematkan RAG (Retrieval Augmented Generation) dari dokumentasi Postman Learning Center. Kalau user lagi ngebahas mock server, sistem otomatis nyuntik artikel panduan mock server ke dalam prompt biar agent paham aturan main fitur tersebut tanpa bikin prompt bawaan jadi gemuk.

4 Fitur Amazon Bedrock yang Dipakai Postman Agent Mode

Semua proses orkestrasi di atas ujung-ujungnya bermuara ke satu titik: pemanggilan inferensi foundation model. Postman mengandalkan empat pilar utama di Amazon Bedrock buat ngejalanin jutaan request per hari:

1. Fleksibilitas Model Keluarga Claude

Lewat satu interface API di Bedrock, Postman bebas milih model Claude yang paling pas buat tiap jenis task. Interaksi cepat yang butuh latensi rendah bisa dilempar ke model yang lebih ringan, sementara logika berat diserahkan ke model penalaran tinggi. Begitu Anthropic ngeluarin model baru yang didukung Bedrock, tim Postman cukup ngubah konfigurasi string ID tanpa nulis ulang integrasi sistem.

2. Cross-Region Inference Buat Nanganin Lonjakan Traffic

Lalu lintas developer itu sangat dinamis dan sering melonjak tajam di jam-jam tertentu. Mengalokasikan server statis di satu region AWS jelas bakal boros biaya. Postman memanfaatkan fitur cross-Region inference di Bedrock.

Ada dua profil yang mereka pakai:

• Geographic inference profiles: Membatasi rute inferensi cuma di wilayah tertentu, misalnya khusus kawasan Amerika Serikat atau Uni Eropa saja, demi memenuhi regulasi kepatuhan data.
• Global inference profiles: Membuka rute ke semua region AWS yang didukung di seluruh dunia saat traffic lagi meledak dan tugasnya nggak terikat aturan batas wilayah geografi.

Contoh pemanggilan inferensi dengan profil wilayah di Bedrock Converse API:

# Skema pemanggilan Converse API dengan inference profile
response = bedrock_runtime.converse(
    modelId="<geographic-inference-profile-id-or-arn>",
    messages=messages,
    system=system_blocks,
)

3. Jaminan Privasi Data Enterprise

Buat pelanggan korporat, lokasi pemrosesan data adalah hal non-negosiatif. Bedrock mengenkripsi data saat transit dan istirahat (at rest), serta memastikan prompt nggak dipakai buat ngelatih model AWS. Postman juga mengaktifkan opsi retensi nol dengan parameter data_retention_mode: none pada model yang mendukung, jadi nggak ada rekam jejak data sensitif API yang tertinggal di server inferensi.

4. Hemat Biaya Lewat Multi-Tier Prompt Caching

Karena agent AI selalu ngirim ulang instruksi sistem, daftar tool inti, dan riwayat percakapan di setiap giliran (turn), biaya input token bisa membengkak cepat banget kalau semuanya dihitung ulang dari awal. Postman ngakalin ini pakai prompt caching dua tingkat di Amazon Bedrock.

// Skema checkpoint cache di content blocks Bedrock Converse
{"cachePoint": {"type": "default", "ttl": "1h"}}  // Core statis (instruksi & tools dasar)
{"cachePoint": {"type": "default", "ttl": "5m"}}  // Layer variabel (sesi interaktif)

Bagian instruksi inti sistem dan definisi tool dasar dipasangi Time-to-Live (TTL) selama 1 jam. Sementara itu, konteks percakapan yang gampang berubah dikasih TTL 5 menit yang bakal otomatis diperpanjang tiap ada cache hit. Pendekatan berjenjang ini bikin biaya baca cache jauh lebih murah dibanding harus bayar token input utuh berulang kali.

Cara Menerapkan Prinsip Agent Postman di Proyek AI Kamu

Kalau kamu pengin niru pola arsitektur Postman Agent Mode di aplikasi internal atau produk SaaS buatanmu sendiri, ada beberapa langkah praktis yang bisa langsung kamu terapin:

1. Audit dan Pangkas Daftar Tool: Jangan jejelin semua endpoint API ke dalam prompt model. Kalau jumlah fungsimu udah nembus 30 atau 40, bikin sistem router awal pakai vector database buat milih 10–15 tool paling relevan sebelum diserahkan ke agent eksekutor.
2. Beralih ke Schema-Based Query: Kalau aplikasimu punya banyak data pelaporan atau metrik, jangan bikin endpoint API terpisah buat tiap filter. Sediakan satu tool eksekusi query (misalnya database SQL analitik atau ClickHouse) dan biarkan agent menyusun sintaksnya sendiri berdasar skema tabel yang kamu sediakan.
3. Bangun Context Handler Khusus: Hindari ngirim mentah-mentah objek JSON tampilan frontend ke prompt. Buat converter sederhana yang tugasnya meringkas data cuma jadi field-field yang esensial buat penalaran AI.
4. Manfaatkan Prompt Caching: Identifikasi teks prompt yang sifatnya statis (instruksi sistem, panduan persona, dan skema JSON tool). Pasang checkpoint caching biar latensi turn-nya makin gesit dan tagihan API bulananmu nggak jebol.

Buat developer yang pengin ngetes flow prompt bertingkat atau orkestrasi agent sebelum nyemplung ke infrastruktur cloud yang rumit, kamu bisa nyobain template prompt routing sederhana kayak gini:

Kamu adalah Orchestrator Agent. Tugasmu adalah memilih tools yang tepat untuk sub-agent berdasarkan permintaan user. Konteks Aktif:- User sedang berada di modul: [API Testing / Analytics / Documentation]- Entitas terpilih: [Nama Endpoint / Koleksi] Daftar Kategori Tools:1. Execution Tools (GET, POST, trigger test runner)2. Analytics Tools (ClickHouse SQL query engine)3. Docs Tools (Markdown generator, OpenAPI parser) Aturan:- Jangan berikan lebih dari 5 tools spesifik sekaligus ke sub-agent.- Jika user menanyakan tren performa atau agregasi data, pilih Analytics Tools berbasis skema SQL daripada tools pencarian satuan.- Minta konfirmasi user jika perintah berpotensi mengubah data production. Permintaan user: [Tulis instruksi di sini]

Hubungannya Buat Developer dan Tech Stack di Indonesia

Arsitektur yang dibangun Postman dan AWS ngasih sinyal kuat buat industri teknologi di Indonesia. Selama ini, banyak software house dan tim produk digital lokal terjebak di fase bikin chatbot demo sederhana. Begitu fitur AI mau disambungin ke sistem core banking, ERP manufaktur, atau platform e-commerce yang udah berusia belasan tahun, proyeknya sering mogok di tengah jalan.

Pola yang dipakai Postman membuktikan bahwa modernisasi sistem lawas buat AI bukan berarti harus nulis ulang seluruh aplikasi dari nol. Kuncinya ada di pembuatan lapisan abstraksi konteks yang bersih dan pemisahan logika eksekusi dari tampilan visual UI. Selain itu, kepatuhan data residensi dan perlindungan data pribadi (PII) yang diterapkan Postman lewat guardrails sejalan banget sama kewajiban kepatuhan UU Pelindungan Data Pribadi (UU PDP) di Indonesia.

Buat developer lokal yang mau ngebangun arsitektur serupa tapi butuh fleksibilitas multi-model yang praktis, kamu bisa memanfaatkan platform orkestrasi model AI. Misalnya, kalau kamu butuh nyobain performa keluarga model Anthropic Claude untuk sub-agent atau task penalaran berat, kamu bisa langsung mengaksesnya lewat Classai Router. Di Classai Router, kamu bisa nyobain model seperti Claude Sonnet 4.6 seharga Rp2.400 / Rp11.850 per 1 juta token, Claude Haiku 5.5 seharga Rp180 / Rp840 per 1 juta token, atau Claude Sonnet 5.5 seharga Rp6.750 / Rp33.750 per 1 juta token dengan satu API key yang kompatibel dengan SDK standar. Kalau kamu pengin memperdalam skill rekayasa AI agent dari dasar sampai siap produksi, kamu juga bisa gabung di kelas AI untuk Developer berbahasa Indonesia.

Kamu juga bisa baca ulasan kami tentang arsitektur model hemat di artikel Claude Haiku 5.5 Rilis di AWS Bedrock atau eksplorasi pengamanan data di Keamanan RAG Amazon Bedrock Real-Time buat melengkapi wawasan arsitektur AI-mu.