Wczoraj po południu jeden z naszych inżynierów obejrzał prezentację Anthropic o ich wewnętrznym stosie GTM na scenie SaaStr, zrobił zrzut ekranu slajdu i zadał Zero jedno pytanie: których z tych narzędzi nam brakuje? Sześć godzin i dziewiętnaście minut później Snowflake był już dostępny w produkcji dla każdego klienta Zero. Była to 180-ta integracja, którą wdrożyliśmy w ciągu roku, a coraz częściej osobą piszącą kolejną nie jest już inżynier. Oto framework i wewnętrzna umiejętność, która to umożliwia.
Rzecz, o której nikt nie mówi w kontekście platform agentów
LLM to mózg w słoiku. Sam w sobie może napisać wiersz o twoim magazynie danych, ale nie potrafi go otworzyć. To, co zamienia chatbota w agenta, to, za co twój zespół faktycznie płaci, to czy agent potrafi sięgnąć do narzędzi, których już używasz, i wykonać w nich pracę.
Nazywamy to zasięgiem, czyli warstwą konektorów. Po roku budowania Zero wierzymy, że to najważniejszy element infrastruktury w produkcie z agentami. Dlatego zbudowaliśmy własną. Co ważniejsze, stworzyliśmy wokół niej workflow, który pozwala każdemu w zespole tworzyć własne konektory.
Dlaczego nie MCP. Dlaczego nie Zapier.
Oba pytania pojawiły się u nas wcześnie. Oba rozwiązania są dobre w tym, czym są. Żadne nie spełniało naszych potrzeb.
MCP to protokół, nie produkt. Świetny dla twórców narzędzi, którzy chcą, by ich usługa była dostępna dla dowolnego LLM. Ale serwery MCP, jak są dziś wdrażane, przekazują modelowi listę narzędzi i ufają, że wywoła je bezpiecznie. Brakuje sejfu na poświadczenia dla każdej organizacji, firewalla kontrolującego, które endpointy mogą być użyte, czy dziennika audytów wiążącego wywołanie z człowiekiem, który je autoryzował. W produkcie, gdzie jeden agent może dotknąć produkcyjnego Stripe klienta, a inny napisać maila w Gmailu CEO, „zaufaj modelowi” to nie jest model bezpieczeństwa.
Platformy integracyjne w stylu Zapier rozwiązują inny problem: łączą deterministyczne wyzwalacze z deterministycznymi akcjami. Agenci nie działają w ten sposób. Agent decyduje w trakcie działania, że kolejnym krokiem jest zapytanie do Snowflake, a potem utworzenie zgłoszenia w Linear. Potrzebuje poświadczenia, ograniczonego klienta HTTP i ścieżki audytu natychmiast, a nie jako gotowego przepisu.
Zbudowaliśmy więc rzecz nudną: rejestr integracji, gdzie każda pozycja zawiera metadane autoryzacji, mapowanie środowiska określające, które sekrety są wstrzykiwane do sandboxa, firewall dozwolonych hostów i mały handler do obsługi niuansów OAuth lub tokenów. To infrastruktura.
Ale infrastruktura nie jest najciekawszą częścią tej historii. Najciekawsze jest to, co wydarzyło się na niej.
Umiejętność, która zamieniła każdego w autora konektorów
Nowy SaaS trafia do naszego backlogu integracji średnio dwa razy dziennie. Część pochodzi od klientów. Część od członka zespołu, który zauważył, że Zero nie potrafi czegoś, czego potrzebuje. Część z rozmów BD, gdzie w stosie potencjalnego klienta pojawia się narzędzie, którego jeszcze nie znamy.
Gdyby każda z tych integracji musiała przechodzić przez kolejkę inżyniera, wdrażalibyśmy jedną tygodniowo. My wdrażamy jedną dziennie.
Powodem jest narzędzie wewnętrzne, które nazywamy umiejętnością tworzenia konektorów. To umiejętność Zero, w tej samej formie, którą dostarczamy klientom, ale skierowana do naszego własnego kodu. Gdy ktoś z zespołu mówi „chcę dodać konektor Notion”, Zero prowadzi go przez proces:
- Zacznij od scenariusza użytkownika. Co użytkownik faktycznie chce zrobić z tym narzędziem? „Zapytać bazę danych”, „utworzyć stronę”, „przeszukać workspace”. Umiejętność wymaga konkretnej historii użytkownika zanim zostanie dotknięty choćby jeden plik. Celem konektora jest umożliwienie agentowi konkretnej funkcji, nie pełne opakowanie API.
- Określ typ autoryzacji. OAuth, token API lub oba. Umiejętność wie, co oznacza każdy typ: dla OAuth – UI zgody i przekierowania; dla tokenów API – wstrzykiwanie sekretu dla organizacji i skąd użytkownik pobiera token. Autor wybiera typ pasujący do narzędzia; reszta procesu wynika z tego wyboru.
- Zmapuj endpointy do scenariusza. Nie „opakuj całe REST API”. Tylko te kilka endpointów, które realizują historię użytkownika. Konektor z trzema dobrze dobranymi endpointami jest lepszy niż taki z czterdziestoma, z których agent nigdy nie korzysta.
- Wygeneruj dwanaście plików. Wpis do rejestru, handler, wzorzec firewalla, ikona platformy, obsługa mapowania środowiska, umiejętność dla agenta ucząca Zero korzystania z konektora. Umiejętność generuje szkielet; autor pisze intencję.
- Otwórz dwa PR-y. Jeden do frameworka konektorów, drugi do biblioteki umiejętności. Oba są przeglądane przez inżyniera, ale przegląd dotyczy poprawności, nie nauki frameworka przez autora.
To, co kiedyś wymagało wiedzy instytucjonalnej (jaki typ autoryzacji, które endpointy, które dwanaście plików w których dwóch repozytoriach, jak wzorzec firewalla łączy się z dynamiczną subdomeną), teraz niesie sama umiejętność. Autor wnosi empatię użytkownika. Umiejętność dostarcza szkielet.
Tak właśnie designer, osoba z BD czy PM może wdrożyć konektor. Wiedzą, czego chce użytkownik. Umiejętność wie wszystko inne.
Studium przypadku: Snowflake, wczoraj
Wczoraj Anthropic zaprezentował swój wewnętrzny stos GTM na scenie SaaStr: Salesforce jako system główny, Clay do wzbogacania, LeanData do routingu, Gong do rozmów, Jira do zgłoszeń, Intercom (Fin) do wsparcia, Ironclad do umów, Snowflake jako magazyn danych. [link do prezentacji]
Jeden z naszych inżynierów zrobił zrzut ekranu slajdu i wrzucił go do Zero z jednym pytaniem: „których z tych narzędzi brakuje nam jako konektora?”
Oto faktyczna oś czasu. Wszystkie godziny PDT.
16:59. Zrzut ekranu trafia do Zero. Zero porównuje go z katalogiem konektorów: 7 z 10 już istnieje (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Brakuje trzech (Clay, LeanData, Snowflake), a Snowflake jest oznaczony jako najcenniejszy, bo magazyn danych to fundament stosu GTM. Odpowiedź pojawia się o 17:00.
17:01. Dalsze pytanie: „które z nich można zrobić jako konektor api-token?” Zero pobiera dokumentację autoryzacji: Clay ma osobisty klucz API, Snowflake niedawno wprowadził Programmatic Access Tokens, LeanData tylko OAuth i powiązanie z Salesforce. Werdykt o 17:02: najpierw Snowflake (największa wartość, najczystsza autoryzacja), potem Clay.
17:04. Inżynier mówi „start”. Umiejętność tworzenia konektorów podejmuje zadanie. Do 17:07 wyklucza Clay (jedyna publiczna powierzchnia to webhooki per-tabela, brak sensownego konektora do zbudowania) i potwierdza kształt Snowflake: sekret SNOWFLAKE_PAT + zmienna SNOWFLAKE_ACCOUNT, autoryzacja bearer do REST API Snowflake i SQL API v2, wzorzec firewalla z dynamiczną subdomeną wzorowany na Zendesk.
17:35. Oba PR-y otwarte w tej samej minucie:
vm0-skills#176: umiejętność dla agenta. Jak pisać SQL do Snowflake, formatować wyniki, ponawiać przy błędach przejściowych.vm0#13356: sam konektor. Wpis do rejestru, handler PAT, generator firewalla, ikona platformy, obsługa mapowania środowiska.
18:22. PR z umiejętnością scalony.
18:42. PR z konektorem scalony.
18:52. PR wydania otwiera się automatycznie.
23:18. [email protected] i reszta pociągu wydaniowego wdrażają na produkcję. Snowflake dostępny dla każdej organizacji.
Sześć godzin i dziewiętnaście minut od „zrzutu ekranu stosu Anthropic” do „Zero może zapytać twoją hurtownię”. Jeden inżynier. Jedna rozmowa. Zero przekazań do „zespołu konektorów”.
Wydajność nie wynika z szybkości inżyniera. To umiejętność tworzenia konektorów przejęła elementy wymagające wiedzy instytucjonalnej: jaki typ autoryzacji wybrać, które endpointy pasują do scenariusza użytkownika, które dwanaście plików musi trafić do których dwóch repozytoriów, jak wzorzec firewalla łączy się z dynamiczną subdomeną. Autor napisał intencję. Umiejętność napisała szkielet. Produkcja zrobiła resztę.
To właśnie daje framework. Nie tylko szybkość (choć ta jest realna), ale kto może wykonać pracę. Autorem Snowflake był inżynier. Nie musiał nim być.
Dlaczego api-token to pełnoprawny obywatel
Warto o tym wspomnieć, bo to celowy wybór projektowy, który zaskoczył wiele osób.
Większość platform agentów traktuje OAuth jako jedyną słuszną autoryzację, a api-token jako rozwiązanie dla starszych narzędzi. My robimy odwrotnie. Tokeny API są pełnoprawnym elementem naszego modelu konektorów, z tym samym UI zgody, tym samym sejfem dla organizacji, tą samą ścieżką audytu, tym samym egzekwowaniem firewalla.
Są dwa powody.
Po pierwsze, autoryzacja api-token skraca czas do pierwszego użycia. Snowflake niedawno wprowadził Programmatic Access Tokens właśnie z tego powodu: długowieczne, zakresowe, odwoływalne poświadczenia, które nie wymagają tańca OAuth. Użytkownik z PAT może być produktywny w Zero w mniej niż minutę. Nawet czysty flow OAuth trwa dłużej i wymaga więcej od użytkownika.
Po drugie, OAuth nie zawsze jest dostępny. Niektóre narzędzia enterprise po prostu go nie oferują, albo jest dostępny tylko w wersji enterprise. Traktując api-token jako równorzędny (nie zapasowy), możemy obsłużyć te narzędzia właściwie, zamiast zostawiać je w „wkrótce dostępne”.
Konektor Snowflake wdrożony wczoraj to api-token. Konektor Gmail, który pobiera wątki mailowe klientów, to OAuth. Oba przechodzą przez ten sam framework, tę samą umiejętność, ten sam przegląd. Autor wybiera typ pasujący do narzędzia, a framework sprawia, że każdy z nich jest łatwy do zbudowania.
Co faktycznie odblokowuje około 180 integracji
Sama liczba nie jest najważniejsza. Najważniejsze jest to, że przy tej gęstości agent przestaje być narzędziem, które wywołujesz, a staje się środowiskiem, w którym żyjesz.
Gdy Zero ma konektory do twojego CRM i magazynu danych i skrzynki wsparcia i narzędzia projektowego i repozytorium, może robić rzeczy, których nie potrafi żaden agent z pojedynczą integracją. Może pobrać zapytanie Snowflake, porównać je z otwartymi zgłoszeniami Linear i opublikować podsumowanie na kanale Slack, gdzie pracuje zespół customer-success. Może przeczytać rozmowę Gong, znaleźć funkcję, o którą pytał potencjalny klient, sprawdzić, czy jest na roadmapie, i napisać maila follow-up – wszystko w jednym ruchu.
Każdy nowy konektor nie dodaje wartości liniowo. Dodaje ją kombinatorycznie. 180. konektor jest cenniejszy niż pierwszy, bo łączy się z 179 poprzednimi.
To jest założenie frameworka. A założenie umiejętności jest takie, że szybkość kumulacji zależy od tego, ilu ludzi w twoim zespole może dorzucać kolejne elementy.
Co dalej
Pracujemy nad udostępnieniem umiejętności tworzenia konektorów klientom. Jeśli korzystasz z Zero w swoim zespole i potrzebujesz integracji z narzędziem wewnętrznym (systemem billingowym, magazynem danych, własnym panelem administracyjnym), ten sam workflow, który wczoraj wdrożył Snowflake, będzie workflowem, którego użyjesz do wdrożenia własnego. Ten sam szkielet, ten sam model autoryzacji, ten sam firewall, ta sama ścieżka audytu. Inny autor.
Jeśli to cię interesuje, chętnie porozmawiamy.
