I går ettermiddag så en ingeniør på teamet vårt Anthropic gå gjennom deres interne GTM-stack på SaaStr-scenen, tok skjermbilde av lysbildet, og stilte Zero ett spørsmål: hvilke av disse mangler vi? Seks timer og nitten minutter senere var Snowflake live i produksjon for alle Zero-kunder. Det var den 180-et eller annet integrasjonen vi har lansert på ett år, og stadig oftere er det ikke en ingeniør som skriver den neste. Her er rammeverket, og den interne ferdigheten oppå det, som gjør dette mulig.
Det ingen forteller deg om agentplattformer
En LLM er en hjerne på glass. Alene kan den skrive et dikt om datavarehuset ditt, men den kan ikke faktisk åpne det. Det som gjør en chatbot til en agent, det teamet ditt faktisk betaler for, er om agenten kan nå inn i verktøyene dere allerede bruker og gjøre arbeid i dem.
Vi kaller den rekkevidden koblingslaget. Etter ett år med å bygge Zero, mener vi det er den viktigste delen av infrastrukturen i et agentprodukt. Så vi bygde vårt eget. Enda viktigere, vi bygde en arbeidsflyt rundt det som lar hvem som helst på teamet lage en kobling.
Hvorfor ikke MCP. Hvorfor ikke Zapier.
Begge ble spurt om tidlig. Begge er gode til sitt bruk. Ingen av dem var det vi trengte.
MCP er et protokoll, ikke et produkt. Strålende for verktøyleverandører som vil at tjenesten deres skal være tilgjengelig for enhver LLM. Men MCP-servere, slik de er i dag, gir modellen en liste med verktøy og stoler på at den kaller dem trygt. Det finnes ikke et per-organisasjon kredentialhvelv, ingen brannmur for hvilke endepunkter som kan nås, ingen revisjonslogg som knytter et kall til et menneske som godkjente det. For et produkt der én agent kan berøre en kundes produksjons-Stripe og en annen kan skrive et utkast til e-post i CEOens Gmail, er «stol på modellen» ikke en sikkerhetsmodell.
Zapier-lignende integrasjonsplattformer løser et annet problem: de kobler deterministiske triggere til deterministiske handlinger. Agenter fungerer ikke slik. En agent bestemmer, midt i tankerekken, at neste steg er å spørre Snowflake og så opprette en Linear-sak. Den trenger et kredential, en avgrenset HTTP-klient og et revisjonsspor med én gang, ikke som en forhåndsdefinert oppskrift.
Så vi bygde det kjedelige: et register over integrasjoner der hver oppføring har autentiseringsmetadata, et miljøkart over hvilke hemmeligheter som injiseres i sandkassen, en brannmur for tillatte verter, og en liten håndterer for OAuth- eller token-særheter. Det er infrastrukturen.
Men infrastrukturen er ikke den interessante delen av historien. Det interessante er hva som skjedde oppå den.
Ferdigheten som gjorde alle til koblingsforfattere
En ny SaaS havner på integrasjons-backlogen vår omtrent to ganger om dagen. Noen kommer fra kundebehov. Noen fra en kollega som ser at Zero ikke kan noe de trenger. Noen fra en BD-samtale der en potensiell kunde har et verktøy vi ikke har møtt ennå.
Hvis alle disse måtte gjennom en ingeniørs kø, ville vi lansert én i uka. Vi lanserer én om dagen.
Årsaken er et internt verktøy vi kaller koblingsforfatter-ferdigheten. Det er en Zero-ferdighet, samme struktur vi leverer til kunder, men rettet innover mot vår egen kodebase. Når noen på teamet sier «jeg vil legge til Notion-koblingen», guider Zero dem gjennom:
- Start fra brukerscenarioet. Hva vil brukeren faktisk gjøre med dette verktøyet? «Spørre en database», «opprette en side», «søke i arbeidsområdet». Ferdigheten krever en konkret brukerhistorie før en eneste fil berøres. Målet med en kobling er å muliggjøre en agentfunksjon, ikke å pakke inn et API fullstendig.
- Identifiser autentiseringsformen. OAuth, API-token, eller begge. Ferdigheten vet hva hver form innebærer: for OAuth, samtykkegrensesnitt og omdirigering; for API-tokens, per-organisasjon hemmelighetsinjeksjon og hvor brukeren får tokenet. Forfatteren velger formen som passer verktøyet; alt annet følger derfra.
- Kartlegg endepunkter til scenarioet. Ikke «pakk inn hele REST-API-et». Bare de få endepunktene som dekker brukerhistorien. En kobling med tre velvalgte endepunkter er bedre enn én med førti som agenten aldri bruker.
- Sett opp de tolv filene. Registeroppføring, håndterer, brannmurmønster, plattformikon, miljøkart, agentrettet ferdighet som lærer Zero å bruke koblingen. Ferdigheten skriver rammeverket; forfatteren skriver hensikten.
- Åpne de to PR-ene. Én til koblingsrammeverket, én til ferdighetsbiblioteket. Begge blir gjennomgått av en ingeniør, men gjennomgangen handler om korrekthet, ikke om å lære forfatteren hvordan rammeverket fungerer.
Det som før krevde institusjonskunnskap (hvilken autentiseringsform, hvilke endepunkter, hvilke tolv filer i hvilke to repoer, hvordan brannmurmønsteret fungerer med et dynamisk subdomene) bæres nå av selve ferdigheten. Forfatteren bringer brukerforståelsen. Ferdigheten gir grunnstrukturen.
Slik kan en designer, en BD-leder eller en PM ende opp med å lansere en kobling. De vet hva brukeren vil. Ferdigheten vet alt annet.
Casestudie: Snowflake, i går
I går gikk Anthropic gjennom sin interne GTM-stack på SaaStr-scenen: Salesforce som system of record, Clay for berikelse, LeanData for ruting, Gong for samtaler, Jira for saker, Intercom (Fin) for support, Ironclad for kontrakter, Snowflake som datavarehus. [lenke til foredraget]
En av våre ingeniører tok skjermbilde av lysbildet og la det inn i Zero med ett spørsmål: «hvilke av disse mangler vi en kobling til?»
Her er den faktiske tidslinjen som fulgte. Alle klokkeslett er PDT.
16:59. Skjermbildet mottas. Zero sammenligner det med koblingskatalogen: 7 av 10 finnes allerede (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Tre mangler (Clay, LeanData, Snowflake), og Snowflake markeres som mest verdifull, siden datavarehuset er grunnmuren i GTM-stacken. Svar sendes kl. 17:00.
17:01. Oppfølging: «hvilke av disse kan lages som en api-token-kobling?» Zero henter autentiseringsdokumentasjonen: Clay har en personlig API-nøkkel, Snowflake har nylig lansert Programmatic Access Tokens, LeanData er kun OAuth og Salesforce-avhengig. Konklusjon kl. 17:02: Snowflake først (høyest verdi, renest autentisering), deretter Clay.
17:04. Ingeniøren sier «kjør». Koblingsforfatter-ferdigheten tar over. Innen 17:07 er Clay utelatt (den eneste offentlige flaten er per-tabell-webhooks, ingen reell kobling å bygge) og Snowflakes form bekreftet: SNOWFLAKE_PAT hemmelighet + SNOWFLAKE_ACCOUNT variabel, bearer-autentisering mot Snowflake REST API og SQL API v2, dynamisk subdomene-brannmurmønster modellert etter Zendesk.
17:35. Begge PR-er åpnes i samme minutt:
vm0-skills#176: den agentrettede ferdigheten. Hvordan skrive Snowflake SQL, formatere resultater, prøve på nytt ved forbigående feil.vm0#13356: selve koblingen. Registeroppføring, PAT-håndterer, brannmurgenerator, plattformikon, miljøkart.
18:22. Ferdighets-PR flettet.
18:42. Koblings-PR flettet.
18:52. Release-PR åpnes automatisk.
23:18. [email protected] og resten av release-toget rulles ut i produksjon. Snowflake er live for alle organisasjoner.
Seks timer og nitten minutter fra «skjermbilde av Anthropics stack» til «Zero kan spørre datavarehuset ditt». Én ingeniør. Én samtale. Ingen overlevering til et «koblingsteam».
Gjennomstrømningen her skyldes ikke at ingeniøren er rask. Det er fordi koblingsforfatter-ferdigheten bar delene som tidligere krevde institusjonskunnskap: hvilken autentiseringsform som skal velges, hvilke endepunkter som dekker brukerscenarioet, hvilke tolv filer som skal inn i hvilke to repoer, hvordan brannmurmønsteret fungerer med et dynamisk subdomene. Forfatteren skrev hensikten. Ferdigheten skrev rammeverket. Produksjonen gjorde resten.
Dette er hva rammeverket gir oss. Ikke bare fart (selv om farten er reell), men hvem som kan gjøre jobben. Snowflake-forfatteren var tilfeldigvis en ingeniør. Han måtte ikke være det.
Hvorfor api-token er en førsteklasses borger
En fotnote verdt å trekke frem, fordi det er et bevisst designvalg som overrasket mange.
De fleste agentplattformer behandler OAuth som den eneste sanne autentiseringen og api-token som en nødløsning for eldre verktøy. Vi gjør det motsatte. API-tokens er en førsteklasses borger i vårt koblingsmodell, med samme samtykkegrensesnitt, samme per-organisasjon hvelv, samme revisjonsspor, samme brannmur.
Det er to grunner.
Den første er at api-token-autentisering gir kortere tid til første bruk. Snowflake har nylig lansert Programmatic Access Tokens nettopp av denne grunn: langlivede, avgrensbare, tilbakekallbare nøkler som ikke krever en OAuth-prosess. En bruker med en PAT kan være produktiv i Zero på under ett minutt. En OAuth-prosess, selv en enkel en, tar lengre tid og krever mer av brukeren.
Den andre er at OAuth ikke alltid er tilgjengelig. Noen bedriftsverktøy tilbyr det rett og slett ikke, eller tilbyr det kun bak en Enterprise-SKU. Å behandle api-token som likestilt (ikke som nødløsning) gjør at vi kan støtte disse verktøyene skikkelig i stedet for å la dem havne i en «kommer snart»-gravplass.
Snowflake-koblingen som ble lansert i går er api-token. Gmail-koblingen som leverer kundens e-posttråder er OAuth. Begge går gjennom samme rammeverk, samme ferdighet, samme gjennomgang. Forfatteren velger formen som passer verktøyet, og rammeverket gjør det like enkelt å bygge begge.
Hva 180-et eller annet integrasjoner faktisk åpner opp
Tallet i seg selv er ikke poenget. Poenget er at med denne tettheten slutter agenten å være et verktøy du tilkaller og blir et miljø du lever i.
Når Zero har koblinger til CRM-en din og datavarehuset og support-innboksen og designverktøyet og repoet ditt, kan den gjøre ting ingen enkeltintegrasjonsagent kan. Den kan hente en Snowflake-spørring, kryssjekke den mot åpne Linear-saker, og poste et sammendrag i Slack-kanalen der kundesuksessteamet holder til. Den kan lese en Gong-samtale, finne funksjonen prospektet spurte om, sjekke om den er på veikartet, og skrive oppfølgingse-posten – alt i ett steg.
Hver ny kobling gir ikke verdi lineært. Den gir verdi kombinatorisk. Den 180. koblingen er mer verdifull enn den første, fordi den kan kombineres med de 179 som kom før.
Det er dette rammeverket satser på. Og ferdigheten satser på at farten på sammensetningen avhenger av hvor mange på teamet som får lov til å bidra.
Hva skjer videre
Vi jobber med å åpne koblingsforfatter-ferdigheten for kunder. Hvis du kjører Zero for teamet ditt og har et internt verktøy du trenger integrasjon til (faktureringssystem, datavarehus, eget adminpanel), vil samme arbeidsflyt som lanserte Snowflake i går være arbeidsflyten du bruker for å lansere din. Samme rammeverk, samme autentiseringsmodell, samme brannmur, samme revisjonsspor. Annen forfatter.
Hvis det er interessant for deg, ta gjerne kontakt.
