Claude Managed Agents vs Claude Agent SDK

Minggu lalu saya membuka tiga tab sekaligus: dokumentasi Managed Agents, quickstart Agent SDK, dan referensi Messages API. Saya mencoba menentukan jalur mana yang harus digunakan untuk pipeline pemrosesan dokumen secara asinkron. Empat puluh menit berlalu, saya menyadari kebingungannya bukan soal fitur. Melainkan tentang siapa yang memiliki runtime.

Itulah inti dari keputusan ini. Bukan mana yang “lebih baik.” Melainkan batas infrastruktur mana yang masuk akal untuk apa yang sedang Anda bangun saat ini. Artikel ini mendokumentasikan bagaimana dua jalur tersebut dibandingkan — dan mengapa ada opsi ketiga yang dilewatkan oleh sebagian besar artikel perbandingan.

Dua Jalur Menuju Agen Berbasis Claude

Agent SDK: Anda mengelola loop, Anda mengurus runtime

Claude Agent SDK — yang sebelumnya bernama Claude Code SDK — memberikan Anda alat, loop agen, dan manajemen konteks yang sama yang menggerakkan Claude Code, dikemas sebagai library Python atau TypeScript. Anda menginstalnya, menjalankannya di infrastruktur Anda sendiri, dan menangani penskalaan, sandboxing, serta orkestrasi secara mandiri.

SDK ini menyertakan Claude Code CLI secara otomatis. Agen Anda mendapatkan akses ke operasi file, perintah bash, penelusuran web, eksekusi kode — seluruh toolset Claude Code — langsung tersedia. Anda menentukan alat mana yang diizinkan, mengatur mode izin, dan mengimplementasikan alat kustom sebagai server MCP in-process.

Yang Anda dapatkan: kendali penuh atas lingkungan eksekusi. Yang juga Anda dapatkan: tanggung jawab untuk menjaga lingkungan tersebut tetap berjalan, aman, dan dapat dipantau.

Managed Agents: Anthropic mengelola harness, Anda mendefinisikan tugas

Claude Managed Agents, diluncurkan dalam public beta pada 8 April 2026, membalik model kepemilikan. Anda menentukan agen — model, system prompt, alat, server MCP, guardrail — dan Anthropic yang menjalankannya. Harness menangani eksekusi alat, sandboxing, persistensi sesi, kompaksi konteks, prompt caching, dan pemulihan dari crash.

Tim engineering Anthropic menyebutnya sebagai “meta-harness” — dirancang untuk mengakomodasi harness di masa depan seiring model berkembang daripada mengodifikasikan asumsi tetap tentang apa yang bisa atau tidak bisa dilakukan Claude. Jika container mengalami crash, sesi tetap bertahan. Container baru melanjutkan dari log sesi.

Anda mengonfigurasi, Anthropic mengoperasikan.

Tidak ada yang secara universal lebih baik

Tumpang tindih kemampuannya sangat tinggi. Keduanya memberikan Claude akses ke eksekusi kode, manipulasi file, bash, penelusuran web, dan integrasi MCP. Perbedaannya bersifat operasional: siapa yang menyediakan lingkungan, siapa yang menangani kegagalan, siapa yang menskalakan container. Ini adalah keputusan infrastruktur, bukan keputusan fitur.

Perbandingan Inti

Satu hal yang perlu dicatat soal penagihan: Agent SDK tidak memperkenalkan biaya runtime sesi. Namun menyebutnya “lebih murah” tanpa kualifikasi adalah menyesatkan. Runtime yang Anda host sendiri memiliki biaya nyata — server, orkestrasi container, pemantauan, respons insiden, jam kerja engineer untuk memelihara semuanya. Struktur biayanya berbeda, bukan sekadar lebih murah atau mahal.

Kapan Memilih Managed Agents

Tugas berjangka panjang atau asinkron di mana persistensi sesi penting

Jika agen Anda berjalan selama 30 menit hingga beberapa jam — memproses dokumen, melakukan riset, menjalankan alur kerja multi-langkah — Anda membutuhkan status sesi yang bertahan dari pemutusan koneksi dan kegagalan container. Managed Agents menyimpan seluruh riwayat event di sisi server dan membuatnya dapat diambil melalui API. Membangun ketahanan yang setara sendiri itu bisa dilakukan. Tapi itu juga membutuhkan beberapa minggu rekayasa yang bukan produk inti Anda.

Tim tanpa kapasitas infrastruktur untuk membangun sandbox yang aman

Sandboxing berkelas produksi — isolasi, manajemen kredensial, izin terbatas, pelacakan eksekusi — benar-benar sulit. Sebagian besar tim meremehkannya. Jika tim Anda tidak memiliki kapasitas DevOps untuk membangun dan memelihara lingkungan eksekusi agen yang aman, Managed Agents menghapus seluruh area tersebut dari roadmap Anda.

Prototipe cepat ke produksi: hari, bukan bulan

Headline Anthropic adalah “capai produksi 10x lebih cepat.” Saya belum memverifikasi angka tersebut di cukup banyak skenario untuk mendukungnya. Namun arahnya akurat: kesenjangan antara “agen berfungsi dalam pengujian lokal” dan “agen berjalan andal di produksi” itu besar, dan Managed Agents mempersempitnya. Rakuten dilaporkan men-deploy agen spesialis dalam waktu kurang dari seminggu masing-masing.

Ketika kompaksi dan caching bawaan lebih penting dari kontrol kustom

Managed Agents menangani prompt caching dan kompaksi konteks secara otomatis. Jika Anda telah membangun manajemen konteks sendiri untuk agen berjangka panjang, Anda tahu betapa banyak percobaan dan kesalahan yang terlibat. Pendekatan bawaan tidak akan optimal untuk setiap beban kerja. Untuk sebagian besar, itu sudah cukup baik — dan tersedia sejak hari pertama.

Kapan Memilih Agent SDK

Logika orkestrasi kustom yang tidak diekspos Managed Agents

SDK memberikan Anda hooks, alat kustom sebagai server MCP in-process, callback izin yang granular, dan kendali penuh atas loop agen. Jika agen Anda membutuhkan strategi retry kustom, perutean alat kondisional, atau modifikasi prompt dinamis di tengah sesi — logika yang tidak diekspos oleh permukaan konfigurasi Managed Agents — Anda membutuhkan SDK.

Integrasi alat khusus atau lingkungan eksekusi kustom

Jika agen Anda perlu berjalan di dalam lingkungan tertentu — akses ke GPU, driver database tertentu, library proprietary — SDK memungkinkan Anda mengontrol lingkungan eksekusi sepenuhnya. Managed Agents memberikan Anda container cloud dengan paket yang sudah terinstal. Itu cukup untuk sebagian besar kasus. Tidak untuk semua.

Persyaratan on-premise atau private cloud

Managed Agents berjalan secara eksklusif di infrastruktur Anthropic. Tidak ada opsi on-prem, tidak ada deployment ke cloud Anda sendiri. Bagi organisasi dengan persyaratan kedaulatan data yang ketat atau batasan regulasi yang melarang pengiriman data ke infrastruktur pihak ketiga, SDK adalah satu-satunya jalur. Ini adalah batasan keras, bukan preferensi.

Struktur biaya pada skala besar

Biaya $0,08/jam-sesi tidak signifikan untuk sebagian besar beban kerja — agen 24/7 menghabiskan sekitar $58/bulan dalam biaya runtime sebelum token. Namun untuk armada besar agen berjangka panjang yang berjalan bersamaan, biaya sesi terakumulasi. Armada 500 agen yang berjalan bersamaan menghasilkan overhead sesi $40/jam saja.

Agent SDK tidak memiliki surcharge per-sesi ini. Biaya Anda adalah token ditambah apapun yang dijalankan infrastruktur Anda. Pada volume tinggi, memiliki runtime sendiri bisa lebih murah secara marginal — tetapi hanya jika Anda sudah menyerap biaya tetap membangun dan memeliharanya.

Opsi Ketiga: Messages API

Ketika baik SDK maupun Managed Agents tidak diperlukan

Ini adalah opsi yang dilewatkan oleh sebagian besar artikel perbandingan, dan ini adalah jawaban yang tepat lebih sering dari yang orang pikirkan.

Messages API memberikan Anda akses langsung ke model. Anda mengirim prompt, mendapatkan respons. Tidak ada harness, tidak ada loop agen, tidak ada managed runtime. Anda membangun semuanya sendiri — termasuk loop eksekusi alat, jika Anda membutuhkannya.

Pola penggunaan alat sederhana yang tidak memerlukan framework agen penuh

Jika kasus penggunaan Anda adalah: panggil Claude, opsional biarkan menggunakan satu atau dua alat, kembalikan hasil — Anda sama sekali tidak memerlukan framework agen. Messages API dengan penggunaan alat menangani ini dengan bersih. Menambahkan Agent SDK atau Managed Agents memperkenalkan kompleksitas yang tidak sepadan dalam pola request-response yang sederhana.

SDK Python dan TypeScript Anthropic mendukung penggunaan alat secara native. Anda mengimplementasikan loop alat sendiri — sebuah while loop yang memeriksa stop_reason, mengeksekusi alat, mengirimkan hasil kembali. Untuk banyak beban kerja produksi, itu sudah cukup.

Saya pernah melihat tim meraih framework agen padahal loop alat 20 baris sudah cukup. Periksa apakah tugas Anda benar-benar memerlukan otonomi atau persistensi sesi sebelum memilih abstraksi yang lebih berat.

Pertimbangan Migrasi

Mulai di Managed Agents, pindah ke SDK: apa yang berubah

Logika agen — system prompt, definisi alat, struktur tugas — berpindah secara langsung. Yang tidak: persistensi sesi, sandboxing, manajemen konteks, dan pemulihan crash. Anda harus membangun semua itu.

Berpindah dari Managed Agents ke SDK berarti berpindah dari “Anthropic mengoperasikan” ke “Anda mengoperasikan.” Kemampuannya setara. Beban operasional sepenuhnya beralih ke tim Anda.

Mulai di SDK, pindah ke Managed Agents: apa yang berubah

Lebih mudah dalam beberapa hal, lebih sulit dalam hal lain. Logika inti agen berpindah. Alat kustom yang diimplementasikan sebagai server MCP in-process mungkin perlu diekspos ulang sebagai server MCP remote. Hooks kustom dan callback izin perlu dipetakan ke model konfigurasi Managed Agents.

Keuntungannya: Anda berhenti memelihara runtime. Biayanya: Anda kehilangan kontrol granular atas lingkungan eksekusi. Apakah trade-off itu berhasil bergantung pada seberapa banyak infrastruktur kustom Anda yang benar-benar diperlukan versus diwarisi dari keputusan prototyping awal.

Tidak ada panduan migrasi resmi antara keduanya per April 2026. Rencanakan untuk pengujian integrasi, bukan sekadar porting kode.

FAQ

Bisakah saya menggunakan keduanya dalam produk yang sama?

Ya. SDK dan Managed Agents melayani kebutuhan operasional yang berbeda. Pola umum: Agent SDK untuk interaksi yang berhadapan dengan pengguna dan sensitif terhadap latensi di mana Anda membutuhkan kendali penuh; Managed Agents untuk tugas latar belakang dan asinkron di mana persistensi sesi dan operasi tanpa campur tangan lebih penting. Keduanya berbagi model Claude yang sama dan struktur harga untuk biaya token.

Apakah Managed Agents mengunci saya ke infrastruktur Anthropic?

Ya. Runtime ini dibuat khusus untuk Claude. Ini tidak akan menjalankan GPT, Gemini, atau model open-source. Logika agen Anda — prompt, definisi alat, struktur tugas — bersifat portabel. Format runtime dan sesi tidak. SDK memberikan lebih banyak fleksibilitas untuk mengabstraksikan lapisan model, meskipun juga spesifik untuk Claude.

Mana yang lebih baik menangani error dan retry?

Managed Agents memiliki pemulihan crash bawaan — log sesi tetap bertahan, container baru melanjutkan dari tempat container sebelumnya gagal. Dengan SDK, Anda membangun penanganan error sendiri. Jika Anda sudah pernah melakukan ini sebelumnya dan memiliki pola yang baik, penanganan error SDK bisa lebih tepat disesuaikan dengan kebutuhan Anda. Jika belum, default Managed Agents adalah titik awal yang kuat.

Bisakah saya memigrasikan agen SDK yang sudah ada ke Managed Agents?

Logika agen inti berpindah. System prompt, definisi alat, dan struktur tugas kompatibel. Yang memerlukan pengerjaan ulang: hooks kustom, server MCP in-process (mungkin memerlukan padanan remote), logika izin kustom, dan apapun yang bergantung pada lingkungan eksekusi spesifik Anda. Belum ada tooling migrasi resmi.

Mana yang lebih hemat biaya pada volume tinggi?

Bergantung pada apa yang Anda hitung. Managed Agents menambahkan $0,08/jam-sesi di atas token. SDK tidak menambahkan surcharge per-sesi — tetapi runtime yang Anda host sendiri memiliki baris biayanya sendiri: server, orkestrasi, pemantauan, pemeliharaan engineering. Pada volume rendah hingga sedang, Managed Agents biasanya lebih murah dalam total cost of ownership. Pada volume sangat tinggi dengan banyak sesi berjangka panjang yang berjalan bersamaan, perhitungan bisa berbalik — tetapi hanya jika Anda sudah berinvestasi dalam infrastruktur tersebut.

Itulah perbandingannya. Pohon keputusan: butuh kendali infrastruktur atau tidak dapat mengirim data di luar premises → SDK. Ingin melewati infrastruktur → Managed Agents. Tidak membutuhkan loop agen sama sekali → Messages API.

Jalankan pilot pada keduanya jika Anda tidak yakin. Biaya perpindahan lebih rendah pada tahap prototipe daripada setelah Anda berkomitmen pada arsitektur deployment.

Lanjut minggu depan — masih menguji pola multi-agen di Managed Agents.

Postingan sebelumnya: