Kemarin sore, seorang engineer di tim kami menyaksikan Anthropic memaparkan tumpukan GTM internal mereka di atas panggung SaaStr, menjepret slide-nya, dan mengajukan satu pertanyaan kepada Zero: mana di antara ini yang belum kita punya? Enam jam sembilan belas menit kemudian, Snowflake aktif di produksi untuk setiap pelanggan Zero. Itu adalah integrasi ke-180-an yang kami rilis dalam setahun, dan semakin sering, orang yang menulis integrasi berikutnya sama sekali bukan seorang engineer. Inilah kerangkanya, dan skill internal di atasnya, yang membuat itu mungkin.
Hal yang tak pernah diberitahukan siapa pun tentang platform agen
Sebuah LLM adalah otak dalam toples. Sendirian, ia bisa menuliskan puisi tentang data warehouse Anda, tetapi tidak bisa benar-benar membukanya. Hal yang mengubah sebuah chatbot menjadi agen, hal yang benar-benar dibayar oleh tim Anda, adalah apakah agen itu bisa menjangkau alat yang sudah Anda gunakan dan mengerjakan sesuatu di dalamnya.
Jangkauan itu kami sebut lapisan konektor. Setelah setahun membangun Zero, kami percaya itu adalah satu-satunya bagian infrastruktur terpenting dalam sebuah produk agen. Maka kami membangun milik kami sendiri. Yang lebih penting, kami membangun alur kerja di sekitarnya yang memungkinkan siapa pun di tim menulis satu.
Mengapa bukan MCP. Mengapa bukan Zapier.
Keduanya pernah ditanyakan kepada kami sejak awal. Keduanya baik untuk apa adanya. Tetapi tak satu pun adalah yang kami butuhkan.
MCP adalah protokol, bukan produk. Cemerlang bagi penulis alat yang ingin layanannya dapat dijangkau oleh LLM mana pun. Tetapi server MCP, sebagaimana di-deploy hari ini, menyerahkan kepada model sebuah daftar alat dan memercayainya untuk memanggilnya dengan aman. Tidak ada brankas kredensial per-organisasi, tidak ada firewall atas endpoint mana yang boleh dihubungi, tidak ada audit log yang mengaitkan sebuah panggilan kembali ke manusia yang mengizinkannya. Untuk produk di mana satu agen mungkin menyentuh Stripe produksi pelanggan dan agen lain mungkin menyusun email di Gmail CEO mereka, "percayai modelnya" bukanlah sebuah model keamanan.
Platform integrasi ala Zapier memecahkan masalah yang berbeda: mereka merangkai pemicu deterministik ke aksi deterministik. Agen tidak bekerja seperti itu. Seorang agen memutuskan, di tengah jalan pikirannya, bahwa langkah berikutnya adalah meng-query Snowflake lalu menulis tiket Linear. Ia membutuhkan kredensial, klien HTTP yang berlingkup, dan jejak audit saat itu juga, bukan sebagai resep yang sudah jadi.
Maka kami membangun hal yang membosankan: sebuah registri integrasi di mana setiap entri membawa metadata auth, sebuah pemetaan lingkungan tentang rahasia mana yang disuntikkan ke dalam sandbox, sebuah firewall atas host yang diizinkan, dan sebuah handler kecil untuk keanehan OAuth atau token. Itulah infrastrukturnya.
Tetapi infrastruktur bukanlah bagian menarik dari cerita ini. Bagian menariknya adalah apa yang terjadi di atasnya.
Skill yang mengubah semua orang menjadi penulis konektor
Sebuah SaaS baru masuk ke backlog integrasi kami kira-kira dua kali sehari. Sebagian datang dari permintaan pelanggan. Sebagian dari rekan tim yang menyadari Zero tidak bisa melakukan sesuatu yang mereka butuhkan. Sebagian dari percakapan BD di mana tumpukan teknologi calon pelanggan mencakup sebuah alat yang belum kami kenal.
Jika setiap satu dari itu harus melewati antrean seorang engineer, kami akan merilis satu per minggu. Kami merilis satu per hari.
Alasannya adalah sepotong perkakas internal yang kami sebut skill penulisan konektor. Itu adalah sebuah skill Zero, berbentuk sama dengan yang kami rilis ke pelanggan, tetapi diarahkan ke dalam ke codebase kami sendiri. Ketika siapa pun di tim berkata "saya ingin menambahkan konektor Notion," Zero menuntun mereka melaluinya:
- Mulai dari skenario pengguna. Apa yang sebenarnya ingin dilakukan pengguna dengan alat ini? "Meng-query basis data," "membuat halaman," "mencari di seluruh workspace." Skill ini memaksa adanya cerita pengguna yang konkret sebelum satu file pun disentuh. Tujuan sebuah konektor adalah memungkinkan kemampuan agen, bukan membungkus sebuah API secara tuntas.
- Identifikasi bentuk auth. OAuth, token API, atau keduanya. Skill ini tahu apa yang dituntut oleh setiap bentuk: untuk OAuth, UI persetujuan dan rangkaian redirect; untuk token API, penyuntikan rahasia per-organisasi dan dari mana pengguna memperoleh tokennya. Penulis memilih bentuk yang cocok dengan alatnya; semua yang di hilir mengikuti dari situ.
- Petakan endpoint ke skenario. Bukan "bungkus seluruh REST API." Hanya segelintir endpoint yang memenuhi cerita pengguna. Sebuah konektor dengan tiga endpoint yang dipilih dengan baik mengalahkan satu dengan empat puluh endpoint yang tak pernah dijangkau agen.
- Susun kerangka dua belas file. Entri registri, handler, pola firewall, ikon platform, rangkaian pemetaan env, skill yang menghadap-agen yang mengajari Zero cara menggunakan konektor itu. Skill menulis kerangkanya; penulis menulis maksudnya.
- Buka dua PR. Satu ke kerangka konektor, satu ke pustaka skill. Keduanya ditinjau oleh seorang engineer, tetapi tinjauannya tentang kebenaran, bukan tentang mengajari penulis bagaimana kerangka itu bekerja.
Apa yang dulu membutuhkan pengetahuan institusional (bentuk auth mana, endpoint mana, dua belas file mana di dua repo mana, bagaimana pola firewall berpadu dengan subdomain dinamis) kini dibawa oleh skill itu sendiri. Penulis membawa empati terhadap pengguna. Skill membawa kerangkanya.
Beginilah caranya seorang desainer, seorang pemimpin BD, atau seorang PM akhirnya merilis sebuah konektor. Mereka tahu apa yang diinginkan pengguna. Skill tahu segala sisanya.
Studi kasus: Snowflake, kemarin
Kemarin Anthropic memaparkan tumpukan GTM internal mereka di atas panggung SaaStr: Salesforce sebagai sistem catatan, Clay untuk pengayaan, LeanData untuk routing, Gong untuk panggilan, Jira untuk tiket, Intercom (Fin) untuk dukungan, Ironclad untuk kontrak, Snowflake sebagai data warehouse. [tautan ke pembicaraannya]
Salah satu engineer kami menjepret slide-nya dan menjatuhkannya ke dalam Zero dengan satu pertanyaan: "mana di antara ini yang belum kita punya konektornya?"
Inilah linimasa sebenarnya yang menyusul. Semua waktu PDT.
16:59. Screenshot tiba. Zero membandingkannya dengan katalog konektor: 7 dari 10 sudah ada (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Tiga belum ada (Clay, LeanData, Snowflake), dan Snowflake ditandai sebagai yang paling bernilai, karena data warehouse adalah fondasi dari tumpukan GTM. Balasan tiba pukul 17:00.
17:01. Tindak lanjut: "mana di antara ini yang bisa dibuat sebagai konektor token-api?" Zero menarik dokumen auth: Clay memiliki kunci API personal, Snowflake baru-baru ini merilis Programmatic Access Tokens, LeanData hanya OAuth dan terikat ke Salesforce. Vonis pukul 17:02: Snowflake dulu (nilai tertinggi, auth terbersih), lalu Clay.
17:04. Engineer berkata "mulai." Skill penulisan konektor mengambil alih. Pada pukul 17:07 ia telah mengeluarkan Clay dari lingkup (satu-satunya permukaan publik adalah webhook per-tabel, tidak ada konektor nyata untuk dibangun) dan mengonfirmasi bentuk Snowflake: rahasia SNOWFLAKE_PAT + variabel SNOWFLAKE_ACCOUNT, auth bearer terhadap Snowflake REST API dan SQL API v2, pola firewall subdomain-dinamis yang dimodelkan dari Zendesk.
17:35. Kedua PR dibuka pada menit yang sama:
vm0-skills#176: skill yang menghadap-agen. Cara menulis SQL Snowflake, memformat hasil, mencoba ulang saat ada error sementara.vm0#13356: konektornya sendiri. Entri registri, handler PAT, generator firewall, ikon platform, rangkaian pemetaan env.
18:22. PR skill di-merge.
18:42. PR konektor di-merge.
18:52. PR rilis terbuka otomatis.
23:18. web@v12.369.0 dan sisa rangkaian rilis di-deploy ke produksi. Snowflake aktif untuk setiap organisasi.
Enam jam sembilan belas menit dari "screenshot tumpukan Anthropic" hingga "Zero bisa meng-query warehouse Anda." Satu engineer. Satu percakapan. Nol serah-terima ke sebuah "tim konektor."
Throughput di sini bukan karena engineer-nya cepat. Tetapi karena skill penulisan konektor membawa bagian-bagian yang dulu membutuhkan pengetahuan institusional: bentuk auth mana yang dipilih, endpoint mana yang dipetakan ke skenario pengguna, dua belas file mana yang perlu mendarat di dua repo mana, bagaimana pola firewall berpadu dengan subdomain dinamis. Penulis menulis maksudnya. Skill menulis kerangkanya. Produksi melakukan sisanya.
Inilah yang dibeli kerangka ini untuk kami. Bukan sekadar kecepatan (meski kecepatannya nyata), tetapi siapa yang bisa mengambil pekerjaan itu. Penulis Snowflake kebetulan seorang engineer. Ia tidak harus begitu.
Mengapa token-api adalah warga kelas satu
Sebuah catatan kaki yang layak ditarik keluar, karena ini adalah pilihan desain yang disengaja dan mengejutkan banyak orang.
Sebagian besar platform agen memperlakukan OAuth sebagai Satu-satunya Auth Sejati dan token-api sebagai cadangan untuk alat warisan. Kami melakukan kebalikannya. Token API adalah warga kelas satu dalam model konektor kami, dengan UI persetujuan yang sama, penyimpanan brankas per-organisasi yang sama, jejak audit yang sama, penegakan firewall yang sama.
Ada dua alasan.
Yang pertama adalah bahwa auth token-api memiliki waktu-hingga-pemakaian-pertama yang lebih singkat. Snowflake baru-baru ini merilis Programmatic Access Tokens justru karena alasan ini: kredensial yang berumur panjang, dapat diberi lingkup, dan dapat dicabut, yang tidak membutuhkan tarian OAuth. Seorang pengguna dengan PAT bisa produktif di Zero dalam kurang dari satu menit. Sebuah alur OAuth, bahkan yang bersih sekalipun, butuh waktu lebih lama dan menuntut lebih banyak dari pengguna.
Yang kedua adalah bahwa OAuth tidak selalu tersedia. Beberapa alat perusahaan sama sekali tidak merilisnya, atau merilis yang terkunci di balik SKU perusahaan. Memperlakukan token-api sebagai sejajar (bukan cadangan) berarti kami bisa mendukung alat-alat itu dengan benar alih-alih meninggalkannya di kuburan "segera hadir."
Konektor Snowflake yang dirilis kemarin adalah token-api. Konektor Gmail yang mengirimkan thread email pelanggan adalah OAuth. Keduanya melewati kerangka yang sama, skill yang sama, tinjauan yang sama. Penulis memilih bentuk yang cocok dengan alatnya, dan kerangka membuat keduanya murah untuk dibangun.
Apa yang sebenarnya dibuka oleh 180-an integrasi
Angkanya sendiri bukanlah intinya. Intinya adalah bahwa pada kepadatan ini, agen berhenti menjadi alat yang Anda panggil dan mulai menjadi lingkungan tempat Anda tinggal.
Ketika Zero memiliki konektor ke CRM Anda dan data warehouse Anda dan inbox dukungan Anda dan alat desain Anda dan repo Anda, ia bisa melakukan hal-hal yang tak bisa dilakukan agen integrasi-tunggal. Ia bisa menarik sebuah query Snowflake, menyilangkannya dengan tiket Linear yang terbuka, dan memposting ringkasan di channel Slack tempat tim customer-success berada. Ia bisa membaca panggilan Gong, menemukan fitur yang ditanyakan calon pelanggan, memeriksa apakah itu ada di roadmap, dan menyusun email tindak lanjut, semuanya dalam satu gerakan.
Setiap konektor baru tidak menambahkan nilai secara linear. Ia menambahkan nilai secara kombinatorial. Konektor ke-180 lebih bernilai daripada yang ke-1, karena ia berpadu dengan 179 yang datang sebelumnya.
Itulah taruhan di balik kerangka ini. Dan taruhan di balik skill ini adalah bahwa kecepatan penggandaan bergantung pada berapa banyak orang di tim Anda yang diizinkan untuk menambah ke tumpukan itu.
Apa selanjutnya
Kami sedang berupaya membuka skill penulisan konektor untuk pelanggan. Jika Anda menjalankan Zero untuk tim Anda dan ada alat internal yang Anda butuhkan integrasinya (sistem penagihan Anda, warehouse Anda, panel admin internal khusus Anda), alur kerja yang sama yang merilis Snowflake kemarin akan menjadi alur kerja yang Anda gunakan untuk merilis milik Anda. Kerangka yang sama, model auth yang sama, firewall yang sama, jejak audit yang sama. Penulis yang berbeda.
Jika itu menarik bagi Anda, kami ingin sekali berbincang.
