Pada 31 Maret 2026, laporan publik menyebutkan bahwa rilis npm Claude Code tanpa sengaja menyertakan source map yang mengekspos sejumlah besar kode sumber TypeScript internal. Ars Technica, Zscaler, dan media lainnya melaporkan sekitar 512.000 hingga 513.000 baris kode di sekitar 1.900 file TypeScript. Anthropic menyatakan bahwa paparan tersebut merupakan masalah pengemasan rilis dan tidak melibatkan data pelanggan yang sensitif maupun kredensial.
Sebagian besar liputan awal berfokus pada temuan yang paling mencolok — sistem memori, mode tersembunyi, fitur yang belum dirilis, dan nama-nama internal. Pelajaran yang lebih bertahan lama justru lebih sunyi. Analisis publik terhadap kode yang terekspos menunjukkan betapa besar rekayasa yang dibutuhkan agen coding kelas produksi di sekitar model: izin akses, telemetri, analitik, pelacakan sesi, eksekusi tool, integrasi IDE, integrasi MCP, tugas latar belakang, dan orkestrasi multi-agen.
Hal ini menunjukkan lahirnya sebuah disiplin baru: Agent Behavior Analysis (ABA). Tujuannya adalah mengubah setiap interaksi, panggilan model, panggilan tool, penantian persetujuan, status terblokir, relasi sesi, dan peristiwa tata kelola menjadi telemetri yang dapat dikueri, dikorelasikan, dan ditinjau.
Agen Produksi Bukan Sekadar Pembungkus Model
Claude Code sering dikenal sebagai asisten coding berbasis CLI. Analisis publik terhadap kode sumber yang bocor menggambarkan runtime yang jauh lebih besar di baliknya: lapisan izin, lapisan memori, pekerjaan latar belakang, jembatan IDE, jalur MCP, dan orkestrasi multi-agen di sekitar model.
Rincian jumlah baris kode yang pasti sebaiknya diperlakukan sebagai analisis berbasis kode sumber, bukan dokumentasi arsitektur resmi. Meski begitu, arahnya jelas: hanya sebagian kecil dari agen produksi yang berupa pemanggilan model secara langsung. Sisanya adalah rekayasa runtime.
Bagi tim enterprise, hal ini penting karena risiko operasional tidak terbatas pada respons model — risiko itu ada di sistem yang mengelilinginya:
- Tool mana yang dipanggil agen?
- Batas izin mana yang berlaku?
- Apakah manusia menyetujui tindakan tersebut?
- Apakah agen terblokir menunggu input pengguna?
- Apakah sub-agen mewarisi konteks yang benar?
- Sesi atau sesi induk mana yang memiliki tindakan ini?
- Data apa yang masuk ke trace, dan apa yang disamarkan?
Ini adalah pertanyaan observability, tetapi bukan pertanyaan APM biasa.
Apa Saja Tiga Lapisan Observability Agen?
Analisis publik berbasis kode sumber menggambarkan tiga lapisan observability yang terpisah pada Claude Code. Pembedaan ini tetap berlaku bahkan bagi tim yang membangun runtime agennya sendiri dari nol.
| Lapisan | Menjawab | Contoh |
|---|---|---|
| Event analitik produk | Perilaku apa yang terlihat oleh pengguna? | Awal alur OAuth, instalasi plugin, melanjutkan sesi |
| Telemetri standar | Bagaimana performa infrastruktur? | Jumlah request, latensi, tingkat error, status exporter (OTel, Prometheus, OTLP) |
| Pelacakan agen tingkat sesi | Bagaimana satu interaksi pengguna berlangsung di dalam runtime? | Interaksi, request LLM, panggilan tool, tool terblokir menunggu persetujuan, eksekusi tool, eksekusi hook |
Analitik produk sebaiknya tidak dicampur dengan trace runtime. Event produk dan span eksekusi model dapat terjadi dalam sesi yang sama, tetapi keduanya menjawab pertanyaan yang berbeda.
Pelacakan tingkat sesi adalah lapisan yang dibangun untuk investigasi khusus agen. Unit dasarnya adalah interaksi pengguna, bukan sekadar request HTTP. Satu giliran dapat mencakup penanganan prompt, beberapa panggilan model, beberapa panggilan tool, penantian persetujuan, hook, dan logika resume. Tanpa root span tingkat interaksi, investigasi berubah menjadi tumpukan event yang tidak saling terhubung.
Mengapa Kunci Korelasi Lebih Penting daripada Menambah Log
Sistem agen sulit diinvestigasi karena tindakan yang sama dapat muncul dalam berbagai bentuk. Sebuah agen bisa berupa:
- sub-agen lokal
- anggota tim dalam swarm
- proses mandiri
- worker yang dikelola framework
- asisten coding di dalam IDE
- peserta alur kerja yang dipanggil melalui MCP
Untuk memahaminya, dibutuhkan kunci korelasi yang stabil:
user.idsession.idorganization.idagentIdparentSessionIdagentTypeteamName
Identifier ini memungkinkan backend membangun graf relasi minimal — sesi mana yang aktif, agen mana yang melakukan tindakan, sesi induk mana yang memilikinya, serta tim atau workspace mana yang menaunginya. Di sinilah Agent Behavior Analysis dimulai. Tim tidak dapat menyelidiki deadlock multi-agen, lonjakan biaya, atau insiden penyalahgunaan tool jika setiap event datang sebagai baris log datar.
Span Semantik Mengungguli Pengukuran Waktu Tingkat Fungsi
Pelacakan tradisional dimulai dari fungsi, request, dan panggilan database. Pelacakan agen membutuhkan taksonomi tingkat yang lebih tinggi:
agent.interactionagent.llm_requestagent.toolagent.tool.blocked_on_useragent.tool.executionagent.hook
Span blocked_on_user layak mendapat perhatian khusus. Dalam sistem agen, waktu bukan hanya waktu mesin — penantian persetujuan, konfirmasi manual, giliran yang terinterupsi, dan keputusan manusia adalah bagian dari jalur runtime.
Memisahkan waktu tersebut memungkinkan tim menjawab pertanyaan yang lebih tajam:
- Apakah giliran lambat karena modelnya lambat?
- Apakah eksekusi tool yang lambat?
- Apakah agen menunggu persetujuan pengguna?
- Apakah tool berisiko tinggi sering ditolak?
- Apakah sub-agen macet karena tidak memiliki izin?
Itulah nilai inti Agent Behavior Analysis. Ia tidak hanya menunjukkan API mana yang dipanggil — ia menunjukkan bagaimana perilaku agen berlangsung, di mana ia berhenti, dan batas mana yang membentuk apa yang terjadi selanjutnya.
Taksonomi adalah Tata Kelola
Observability agen menghasilkan data berdimensi tinggi, semi-terstruktur, dan berkardinalitas tinggi. Jika setiap prompt, nama tool, nama server, path file, pesan pengguna, dan variabel internal disimpan tanpa disiplin, platform akan menjadi mahal, bising, dan berisiko.
Taksonomi yang baik adalah mekanisme tata kelola. Analisis publik berbasis kode sumber Claude Code menyoroti pola-pola yang penting bagi sistem enterprise:
- Metadata harus dibatasi berdasarkan tipe
- String sensitif harus memerlukan penanganan eksplisit
- Field payload privat harus dihapus sebelum fanout ke pihak eksternal
- Nama server dan tool MCP buatan pengguna mungkin perlu dinormalisasi
- Teks prompt, konten tool, dan parameter tool harus dikendalikan oleh sakelar eksplisit
- Identifier berkardinalitas tinggi harus dikelola secara sengaja
Ini bukan sekadar masalah pemodelan data — ini sekaligus soal privasi, biaya, stabilitas backend, dan peninjauan insiden.
Yang Diambil TrueWatch dari Pola Ini
Arah desain di atas sejalan dengan pendekatan TrueWatch terhadap observability agen AI.
Data fleksibel, tanpa bentuk agen yang baku. Identitas agen tidak tetap — sebuah tim dapat menjalankan OpenClaw, Claude Code, Codex, agen internal, asisten yang terhubung via MCP, atau alur kerja khusus produk, masing-masing menghasilkan field yang berbeda. TrueWatch dibangun untuk menerima data observability yang heterogen dan membuatnya dapat dikueri tanpa memaksa setiap tim memakai skema kaku yang sama sejak hari pertama, karena field berguna berikutnya mungkin sessionId, parentSessionId, skillName, teamName, approvalState, atau sesuatu yang belum dibutuhkan tim.
Pengumpulan dan pemrosesan tetap terpisah. DataKit mengumpulkan telemetri di lingkungan target; pemrosesan pipeline mem-parsing, menyaring, memperkaya, dan menyamarkan data sebelum mencapai platform. Ini mencerminkan pelajaran dari analisis Claude Code: tata kelola harus dimulai di dekat titik pengumpulan, bukan setelah data tersebar ke setiap sink.
DQL memberi operator satu bidang kueri. Perilaku agen melintasi berbagai tipe data — satu investigasi mungkin membutuhkan span trace, metrik token, log, event, catatan persetujuan, dan data layanan. DQL menghubungkan panggilan tool, trace ID, lonjakan token, log error, dan dependensi layanan tanpa memaksa siapa pun berpindah-pindah antar sistem yang tidak terkait.
Kardinalitas tinggi perlu dihormati. Session ID, trace ID, agent ID, nama tool, versi model, varian prompt, dan identifier workspace dapat membengkak dengan cepat. TrueWatch memperlakukan kardinalitas sebagai masalah arsitektural, bukan catatan kaki — sehingga tim dapat mempertahankan detail yang berguna tanpa membuat backend observability menjadi insiden berikutnya.
Empat Skenario Enterprise untuk Agent Behavior Analysis
1. Atribusi Biaya Token
Sebuah agen layanan pelanggan masuk ke produksi. Pada akhir bulan, pengeluaran API model jauh lebih tinggi dari perkiraan. Log aplikasi menunjukkan total penggunaan, tetapi tidak dapat menjawab pertanyaan sebenarnya: skill, versi prompt, model, atau pola sesi mana yang mendorong lonjakan tersebut?
Dengan Agent Behavior Analysis, tim dapat mengelompokkan penggunaan token berdasarkan aplikasi, model, skill, sesi, tool, atau versi prompt. Penyebabnya sering kali hal kecil — skill riwayat pesanan baru yang membawa terlalu banyak konteks di setiap giliran. Perbaikannya biasanya mudah. Visibilitasnya yang sulit.
2. Penggunaan Tool Berisiko dan Penghentian Darurat
Sebuah agen operasional memiliki izin untuk menjalankan tugas pemeliharaan database. Sebuah kondisi batas salah, dan agen mulai mencoba kelas operasi SQL yang berbahaya.
Grafik CPU dan memori mungkin tampak normal. Span agen menunjukkan perilaku sebenarnya: panggilan berulang ke tool berisiko tinggi, database target, kelas perintah, sesi, dan konteks izin. Dengan kebijakan alert yang tepat, platform dapat memberi tahu pemilik, membuka insiden, atau mencabut kredensial melalui alur kerja yang terkelola — dan tinjauan pascainsiden dapat mengikuti trace alih-alih merekonstruksi cerita dari log yang tersebar.
3. Deadlock Multi-Agen
Sebuah tim menjalankan swarm dengan agen kebutuhan, agen coding, dan agen pengujian. Alur kerja macet — agen kebutuhan mengira pekerjaan sudah diserahkan, sementara agen pengujian terus menunggu output kode yang tak kunjung datang.
Kunci korelasi seperti parentSessionId dan agentId memungkinkan platform menghubungkan tindakan-tindakan tersebut menjadi sebuah topologi. Tim mungkin menemukan bahwa agen coding terblokir menunggu persetujuan pengguna saat panggilan tool git_commit dan gagal melaporkan status itu ke atas. Tanpa analisis perilaku, ini tampak seperti kesunyian. Dengan pelacakan sesi, deadlock memiliki lokasi.
4. Audit Kepatuhan dan Deteksi Izin Berlebih
Sebuah tim layanan keuangan memperkenalkan agen pelaporan yang seharusnya hanya mengakses dataset yang telah disamarkan. Auditor membutuhkan bukti bahwa agen tidak pernah mengkueri data pelanggan mentah.
Agent Behavior Analysis dapat mencatat server MCP, tool, dataset, dan cakupan izin yang digunakan pada setiap langkah. Upaya memanggil server yang tidak disetujui atau sumber data mentah dapat dicatat, diblokir, dan ditinjau — bukan sekadar pemantauan, melainkan bagian dari permukaan kendali kepatuhan.
FAQ
Q: Apa itu Agent Behavior Analysis? A: Agent Behavior Analysis (ABA) adalah praktik mengubah setiap interaksi agen — panggilan model, panggilan tool, penantian persetujuan, status terblokir, dan relasi sesi — menjadi telemetri yang dapat dikueri, dikorelasikan, dan ditinjau, alih-alih memperlakukan aktivitas agen sebagai log datar.
Q: Apa sebenarnya yang terekspos dalam kebocoran kode sumber Claude Code? A: Menurut laporan publik, masalah pengemasan pada rilis npm Claude Code mengekspos source map yang mencakup sekitar 512.000–513.000 baris di sekitar 1.900 file TypeScript. Anthropic menyatakan tidak ada data pelanggan sensitif atau kredensial yang terekspos.
Q: Mengapa APM standar tidak cukup untuk agen AI? A: APM standar melacak request, latensi, dan kesehatan infrastruktur. Sistem agen membutuhkan lapisan tingkat sesi yang memodelkan semantik bisnis — panggilan tool, penantian persetujuan, eksekusi hook — yang berpusat pada satu interaksi pengguna, bukan sekadar request HTTP.
Q: Apa itu kunci korelasi dalam observability agen? A: Kunci korelasi adalah identifier stabil — seperti sessionId, agentId, parentSessionId, dan teamName — yang memungkinkan platform observability merekonstruksi agen mana yang melakukan apa, di dalam sesi mana, serta sesi induk atau tim mana yang menaunginya.
Q: Bagaimana TrueWatch menangani data agen berkardinalitas tinggi? A: TrueWatch memperlakukan kardinalitas sebagai persoalan arsitektural, bukan hal yang dipikirkan belakangan, sehingga tim dapat mempertahankan session ID, trace ID, agent ID, dan varian prompt pada tingkat detail yang dibutuhkan untuk investigasi tanpa mengganggu stabilitas backend.
Setiap Agen Produksi Membutuhkan Analisis Perilaku
Insiden source map Claude Code adalah kesalahan pengemasan, bukan pelanggaran data pelanggan, menurut pernyataan publik Anthropic. Pelajaran yang lebih luas dari insiden ini adalah tentang rekayasa runtime agen.
Agen kelas produksi membutuhkan observability yang dibangun ke dalam desainnya. Analitik produk, telemetri standar, pelacakan tingkat sesi, span semantik, kunci korelasi, kontrol privasi, manajemen kardinalitas tinggi, dan pembersihan kegagalan bukanlah pemanis — semuanya adalah infrastruktur.
Claude Code sebagian besar mengamati runtime-nya sendiri. Observability enterprise memiliki tugas yang lebih berat: mengamati berbagai jenis agen — agen white-box, agen framework, agen internal tertutup, dan tool yang terhubung via MCP — sambil menjaga data tetap dapat dikueri, dikorelasikan, dan terkelola.
Itulah arah observability Toby AI Agents: membuat setiap interaksi, panggilan tool, panggilan model, penantian persetujuan, status terblokir, dan relasi sesi cukup terlihat bagi tim untuk melakukan debug, audit, dan operasi.