Dün öğleden sonra, ekibimizden bir mühendis Anthropic'in SaaStr sahnesinde kendi iç GTM yığınını anlatmasını izledi, slaytı ekran görüntüsü aldı ve Zero'ya tek bir soru sordu: bunlardan hangisi bizde yok? Altı saat on dokuz dakika sonra, Snowflake tüm Zero müşterileri için üretimde canlıydı. Bu, bir yıl içinde gönderdiğimiz 180-inci entegrasyondu ve giderek, bir sonrakini yazan kişi artık bir mühendis bile değil. Bunu mümkün kılan çerçeve ve üzerine inşa ettiğimiz iç yetenek işte burada.
Ajan platformları hakkında kimsenin size söylemediği şey
Bir LLM, kavanozda bir beyin gibidir. Tek başına, veri ambarınız hakkında size bir şiir yazabilir, ama onu gerçekten açamaz. Bir sohbet robotunu ajana dönüştüren şey, ekibinizin aslında para ödediği şey, ajanın zaten kullandığınız araçlara erişip iş yapabilmesidir.
Biz bu erişime bağlayıcı katmanı diyoruz. Zero'yu bir yıl boyunca geliştirirken, bunun bir ajan ürünündeki en önemli altyapı parçası olduğuna inandık. Bu yüzden kendi altyapımızı kurduk. Daha da önemlisi, ekipteki herkesin bir bağlayıcı yazabilmesini sağlayan bir iş akışı geliştirdik.
Neden MCP değil. Neden Zapier değil.
İkisi de bize başta soruldu. İkisi de kendi alanında iyi. Hiçbiri ihtiyacımız olan değildi.
MCP bir protokoldür, ürün değil. Hizmetini herhangi bir LLM tarafından erişilebilir kılmak isteyen araç yazarları için harika. Ancak bugün dağıtılan MCP sunucuları, modele bir araç listesi verir ve bunları güvenli şekilde çağıracağına güvenir. Kurum başına kimlik bilgisi kasası yok, hangi uç noktaların erişilebileceğine dair güvenlik duvarı yok, bir çağrıyı yetkilendiren kişiye bağlayan denetim kaydı yok. Bir ajanın bir müşterinin üretim Stripe'ına dokunabileceği, bir diğerinin CEO'nun Gmail'inde e-posta taslağı hazırlayabileceği bir üründe, "modele güven" bir güvenlik modeli değildir.
Zapier tarzı entegrasyon platformları ise farklı bir sorunu çözer: belirli tetikleyicileri belirli eylemlere bağlarlar. Ajanlar böyle çalışmaz. Bir ajan, düşüncesinin ortasında, bir sonraki adımın Snowflake sorgulamak ve ardından bir Linear bileti oluşturmak olduğuna karar verir. Hemen bir kimlik bilgisine, kapsamlı bir HTTP istemcisine ve bir denetim kaydına ihtiyaç duyar, önceden hazırlanmış bir tarif olarak değil.
Bu yüzden sıkıcı olanı yaptık: Her girdinin kimlik doğrulama meta verisi taşıdığı, hangi sırların sandbox'a enjekte edileceğinin ortam eşlemesinin olduğu, izin verilen ana makinelerin güvenlik duvarının bulunduğu ve OAuth veya token ile ilgili küçük bir işleyicinin olduğu bir entegrasyon kaydı oluşturduk. İşte altyapı bu.
Ama hikayenin ilginç kısmı altyapı değil. İlginç olan, üzerinde olanlar.
Herkesi bağlayıcı yazarı yapan yetenek
Entegrasyon bekleme listemize her gün ortalama iki yeni SaaS ekleniyor. Bazıları müşteri taleplerinden geliyor. Bazıları bir ekip arkadaşının Zero'nun ihtiyacı olan bir şeyi yapamadığını fark etmesinden. Bazıları ise bir BD görüşmesinde, potansiyel bir müşterinin yığınında henüz tanımadığımız bir aracın olmasından.
Eğer bunların hepsi bir mühendisin sırasından geçmek zorunda olsaydı, haftada bir gönderirdik. Şimdi günde bir gönderiyoruz.
Bunun nedeni, bağlayıcı yazma yeteneği adını verdiğimiz bir iç araç. Bu, müşterilere gönderdiğimizle aynı biçimde bir Zero yeteneği, ama kendi kod tabanımıza yönelik. Ekipten biri "Notion bağlayıcısını eklemek istiyorum" dediğinde, Zero onu adım adım yönlendiriyor:
- Kullanıcı senaryosundan başla. Kullanıcı bu araçla gerçekten ne yapmak istiyor? "Bir veritabanı sorgula", "bir sayfa oluştur", "çalışma alanında arama yap". Yetenek, tek bir dosya bile dokunulmadan önce somut bir kullanıcı hikayesi ister. Bir bağlayıcının amacı, bir ajan yeteneği kazandırmaktır, API'yi tamamen sarmak değil.
- Kimlik doğrulama biçimini belirle. OAuth, API token veya her ikisi. Yetenek, her biçimin ne gerektirdiğini bilir: OAuth için onay arayüzü ve yönlendirme işlemleri; API token için kurum başına gizli anahtar enjeksiyonu ve kullanıcının token'ı nereden alacağı. Yazar, araca uygun biçimi seçer; gerisi otomatik ilerler.
- Uç noktaları senaryoya eşle. "Tüm REST API'yi sarmak" değil. Sadece kullanıcı hikayesini karşılayan birkaç uç nokta. Üç iyi seçilmiş uç noktalı bir bağlayıcı, ajanın asla kullanmayacağı kırk uç noktalı bir bağlayıcıdan daha iyidir.
- On iki dosyayı iskeletle. Kayıt girişi, işleyici, güvenlik duvarı deseni, platform simgesi, ortam eşlemesi işlemleri, Zero'ya bağlayıcıyı nasıl kullanacağını öğreten ajan-yüzlü yetenek. Yetenek iskeleti yazar; yazar amacı yazar.
- İki PR aç. Biri bağlayıcı çerçevesine, biri yetenek kütüphanesine. İkisi de bir mühendis tarafından incelenir, ancak inceleme doğruluk içindir, yazara çerçevenin nasıl çalıştığını öğretmek için değil.
Eskiden kurumsal bilgi gerektiren şeyler (hangi kimlik doğrulama biçimi, hangi uç noktalar, hangi iki depoda hangi on iki dosya, güvenlik duvarı deseninin dinamik alt alan adıyla nasıl birleştiği) artık yeteneğin kendisinde taşınıyor. Yazar kullanıcı empatisini getirir. Yetenek iskeleti getirir.
Bir tasarımcı, bir BD lideri veya bir ürün yöneticisi böylece bir bağlayıcı gönderebilir. Kullanıcının ne istediğini bilirler. Yetenek geri kalan her şeyi bilir.
Vaka çalışması: Snowflake, dün
Dün Anthropic, SaaStr sahnesinde kendi iç GTM yığınını anlattı: Salesforce kayıt sistemi, Clay zenginleştirme, LeanData yönlendirme, Gong aramalar, Jira biletler, Intercom (Fin) destek, Ironclad sözleşmeler, Snowflake veri ambarı. [konuşmaya bağlantı]
Mühendislerimizden biri slaytı ekran görüntüsü aldı ve Zero'ya tek bir soruyla bıraktı: "bunlardan hangisi için bağlayıcımız eksik?"
İşte ardından gelen gerçek zaman çizelgesi. Tüm saatler PDT.
16:59. Ekran görüntüsü geldi. Zero bunu bağlayıcı kataloğuyla karşılaştırır: 10 taneden 7'si zaten mevcut (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Üçü eksik (Clay, LeanData, Snowflake) ve Snowflake en değerli olarak işaretleniyor, çünkü veri ambarı GTM yığınının temelidir. Yanıt 17:00'te gelir.
17:01. Takip: "bunlardan hangisi api-token bağlayıcı olarak yapılabilir?" Zero kimlik doğrulama belgelerini çeker: Clay kişisel API anahtarına sahip, Snowflake kısa süre önce Programmatic Access Tokens çıkardı, LeanData yalnızca OAuth ve Salesforce'a bağlı. Karar 17:02'de: Önce Snowflake (en yüksek değer, en temiz kimlik doğrulama), sonra Clay.
17:04. Mühendis "başlat" diyor. Bağlayıcı yazma yeteneği devreye giriyor. 17:07'da Clay kapsam dışı bırakıldı (tek halka açık yüzey tablo başına webhook, gerçek bir bağlayıcı yok) ve Snowflake'in biçimi doğrulandı: SNOWFLAKE_PAT gizli + SNOWFLAKE_ACCOUNT değişken, Snowflake REST API ve SQL API v2'ye karşı bearer kimlik doğrulama, Zendesk'e göre modellenmiş dinamik alt alan adı güvenlik duvarı deseni.
17:35. Her iki PR aynı dakikada açılır:
vm0-skills#176: ajan-yüzlü yetenek. Snowflake SQL nasıl yazılır, sonuçlar nasıl biçimlendirilir, geçici hatalarda tekrar deneme.vm0#13356: bağlayıcının kendisi. Kayıt girişi, PAT işleyici, güvenlik duvarı oluşturucu, platform simgesi, ortam eşlemesi işlemleri.
18:22. Yetenek PR'ı birleştirildi.
18:42. Bağlayıcı PR'ı birleştirildi.
18:52. Sürüm PR'ı otomatik açılır.
23:18. [email protected] ve sürüm treninin geri kalanı üretime dağıtılır. Snowflake tüm organizasyonlar için canlıdır.
Altı saat on dokuz dakika içinde "Anthropic'in yığınının ekran görüntüsü"nden "Zero ambarınızı sorgulayabilir"e. Bir mühendis. Bir konuşma. "Bağlayıcı ekibi"ne sıfır devir.
Buradaki verimlilik mühendisin hızlı olmasından değil. Bağlayıcı yazma yeteneği, eskiden kurumsal bilgi gerektiren kısımları taşıdığı için: hangi kimlik doğrulama biçimi seçilecek, hangi uç noktalar kullanıcı senaryosuna eşlenir, hangi on iki dosya hangi iki depoya inecek, güvenlik duvarı deseni dinamik alt alan adıyla nasıl birleşir. Yazar niyeti yazdı. Yetenek iskeleti yazdı. Üretim gerisini halletti.
İşte çerçevenin bize kazandırdığı bu. Sadece hız değil (hız gerçek), aynı zamanda bu işi kimin yapabileceği. Snowflake yazarı bir mühendisti. Olmak zorunda değildi.
Neden api-token birinci sınıf vatandaş
Çıkarmaya değer bir dipnot, çünkü bu kasıtlı bir tasarım tercihi ve insanları şaşırttı.
Çoğu ajan platformu OAuth'u tek doğru kimlik doğrulama, api-token'ı ise eski araçlar için yedek olarak görür. Biz tam tersini yapıyoruz. API token'lar bağlayıcı modelimizde birinci sınıf vatandaş; aynı onay arayüzü, aynı kurum başına kasalama, aynı denetim kaydı, aynı güvenlik duvarı uygulaması.
Bunun iki nedeni var.
Birincisi, api-token kimlik doğrulamanın ilk kullanıma geçiş süresi daha kısadır. Snowflake, tam da bu nedenle kısa süre önce Programmatic Access Tokens çıkardı: uzun ömürlü, kapsamlanabilir, iptal edilebilir kimlik bilgileri, OAuth dansı gerektirmez. PAT sahibi bir kullanıcı, Zero'da bir dakikadan kısa sürede üretken olabilir. Temiz bir OAuth akışı bile daha uzun sürer ve kullanıcıdan daha fazlasını ister.
İkincisi, OAuth her zaman mevcut değildir. Bazı kurumsal araçlar hiç OAuth sunmaz veya sadece kurumsal SKU ile sunar. Api-token'ı eşit (yedek değil) olarak ele almak, bu araçları düzgün şekilde destekleyebileceğimiz anlamına gelir, onları "yakında" mezarlığında bırakmak yerine.
Dün gönderilen Snowflake bağlayıcısı api-token. Müşteri e-posta dizilerini gönderen Gmail bağlayıcısı OAuth. İkisi de aynı çerçeveden, aynı yetenekten, aynı incelemeden geçiyor. Yazar araca uygun biçimi seçer, çerçeve ise her ikisini de ucuza inşa etmeyi sağlar.
180-inci entegrasyonlar gerçekte neyi açığa çıkarıyor
Sayının kendisi önemli değil. Önemli olan, bu yoğunlukta ajanın çağırdığınız bir araç olmaktan çıkıp yaşadığınız bir ortam haline gelmesidir.
Zero, CRM'inize ve veri ambarınıza ve destek kutunuza ve tasarım aracınıza ve deponuza bağlandığında, tek entegrasyonlu bir ajanın yapamayacağı şeyleri yapabilir. Bir Snowflake sorgusu çekebilir, bunu açık Linear biletleriyle çapraz referanslayabilir ve müşteri başarı ekibinin yaşadığı Slack kanalına özet gönderebilir. Bir Gong görüşmesini okuyabilir, potansiyel müşterinin sorduğu özelliği bulabilir, yol haritasında olup olmadığını kontrol edebilir ve takip e-postasını tek hamlede taslak haline getirebilir.
Her yeni bağlayıcı değeri doğrusal olarak artırmaz. Kombinatoryal olarak artırır. 180. bağlayıcı, ondan önce gelen 179 ile birleştiği için 1.'den daha değerlidir.
Çerçevenin arkasındaki iddia bu. Yetenek arkasındaki iddia ise bileşik hızın, ekibinizde kaç kişinin yığına katkıda bulunmasına izin verdiğinize bağlı olmasıdır.
Sırada ne var
Bağlayıcı yazma yeteneğini müşterilere açmak için çalışıyoruz. Ekibiniz için Zero'yu kullanıyorsanız ve entegrasyon ihtiyacınız olan bir iç aracınız varsa (faturalandırma sisteminiz, ambarınız, özel iç yönetim paneliniz), dün Snowflake'i gönderen aynı iş akışı, kendi bağlayıcınızı göndereceğiniz iş akışı olacak. Aynı iskelet, aynı kimlik doğrulama modeli, aynı güvenlik duvarı, aynı denetim kaydı. Farklı yazar.
Eğer bu ilginizi çekiyorsa, sizinle konuşmak isteriz.
