Igår eftermiddag såg en ingenjör i vårt team Anthropic gå igenom deras interna GTM-stack på SaaStr-scenen, tog en skärmdump av sliden och ställde en enda fråga till Zero: vilka av dessa saknar vi? Sex timmar och nitton minuter senare var Snowflake live i produktion för alla Zero-kunder. Det var den 180:e integrationen vi lanserat på ett år, och allt oftare är det inte längre en ingenjör som skriver nästa. Här är ramverket, och den interna skillen ovanpå, som gör det möjligt.
Sanningen ingen berättar om agentplattformar
En LLM är som en hjärna i en burk. På egen hand kan den skriva en dikt om ditt datalager, men den kan inte faktiskt öppna det. Det som förvandlar en chatbot till en agent, det som ditt team faktiskt betalar för, är om agenten kan nå in i de verktyg ni redan använder och göra jobbet där.
Vi kallar den räckvidden för connector-lagret. Efter ett år med Zero tror vi att det är den enskilt viktigaste infrastrukturen i en agentprodukt. Så vi byggde vårt eget. Ännu viktigare, vi byggde ett arbetsflöde kring det som gör att vem som helst i teamet kan skapa en connector.
Varför inte MCP. Varför inte Zapier.
Båda frågades om tidigt. Båda är bra på sitt sätt. Ingen av dem var vad vi behövde.
MCP är ett protokoll, inte en produkt. Lysande för verktygsutvecklare som vill att deras tjänst ska vara nåbar av vilken LLM som helst. Men MCP-servrar, som de används idag, ger modellen en lista med verktyg och litar på att den anropar dem säkert. Det finns inget per-organisations credential-valv, ingen brandvägg för vilka endpoints som får nås, ingen granskningslogg som kopplar ett anrop till en människa som godkänt det. För en produkt där en agent kan röra en kunds produktions-Stripe och en annan kan skriva ett mejl i deras VD:s Gmail, är "lita på modellen" inte en säkerhetsmodell.
Zapier-liknande integrationsplattformar löser ett annat problem: de kopplar deterministiska triggers till deterministiska åtgärder. Agenter fungerar inte så. En agent bestämmer, mitt i tanken, att nästa steg är att fråga Snowflake och sedan skapa ett Linear-ärende. Den behöver en credential, en avgränsad HTTP-klient och en granskningskedja direkt, inte som ett fördefinierat recept.
Så vi byggde det tråkiga: ett register över integrationer där varje post bär autentiseringsmetadata, en miljö-mappning för vilka hemligheter som injiceras i sandlådan, en brandvägg för tillåtna värdar och en liten hanterare för OAuth- eller token-särdrag. Det är infrastrukturen.
Men infrastrukturen är inte den intressanta delen av historien. Det intressanta är vad som hände ovanpå den.
Skillen som gjorde alla till connector-författare
Ett nytt SaaS hamnar i vår integrations-backlog ungefär två gånger om dagen. Vissa kommer från kundönskemål. Vissa från en kollega som märker att Zero inte kan göra något de behöver. Vissa från ett BD-samtal där en prospekts stack innehåller ett verktyg vi inte stött på än.
Om alla dessa måste gå genom en ingenjörs kö, skulle vi lansera en i veckan. Vi lanserar en om dagen.
Anledningen är ett internt verktyg vi kallar connector-authoring skill. Det är en Zero-skill, samma typ vi levererar till kunder, men riktad inåt mot vår egen kodbas. När någon i teamet säger "Jag vill lägga till Notion-kopplingen" guidar Zero dem genom processen:
- Börja från användarscenariot. Vad vill användaren faktiskt göra med verktyget? "Fråga en databas", "skapa en sida", "söka i arbetsytan". Skillen kräver en konkret användarberättelse innan en enda fil rörs. Målet med en connector är att möjliggöra en agentförmåga, inte att täcka ett API heltäckande.
- Identifiera autentiseringsformen. OAuth, API-token eller båda. Skillen vet vad varje form innebär: för OAuth, samtyckesgränssnitt och omdirigering; för API-tokens, per-organisations hemlighetsinjektion och var användaren hämtar token. Författaren väljer formen som passar verktyget; allt nedströms faller ut därifrån.
- Mappa endpoints till scenariot. Inte "täcka hela REST-API:et". Bara de få endpoints som uppfyller användarberättelsen. En connector med tre väl valda endpoints är bättre än en med fyrtio som agenten aldrig använder.
- Skapa de tolv filerna. Registerpost, hanterare, brandväggsmönster, plattformsikon, miljö-mappning, den agentinriktade skillen som lär Zero hur man använder connectorn. Skillen skriver grunden; författaren skriver avsikten.
- Öppna de två PR:erna. En till connector-ramverket, en till skill-biblioteket. Båda granskas av en ingenjör, men granskningen gäller korrekthet, inte att lära författaren hur ramverket fungerar.
Det som tidigare krävde institutionskunskap (vilken autentiseringsform, vilka endpoints, vilka tolv filer i vilka två repos, hur brandväggsmönstret kombineras med ett dynamiskt subdomän) bärs nu av skillen själv. Författaren bidrar med användarförståelse. Skillen bidrar med grunden.
Så här kan en designer, en BD-ansvarig eller en produktchef lansera en connector. De vet vad användaren vill. Skillen vet allt annat.
Fallstudie: Snowflake, igår
Igår gick Anthropic igenom sin interna GTM-stack på SaaStr-scenen: Salesforce som system of record, Clay för enrichment, LeanData för routing, Gong för samtal, Jira för ärenden, Intercom (Fin) för support, Ironclad för avtal, Snowflake som datalager. [länk till föredraget]
En av våra ingenjörer tog en skärmdump av sliden och la in den i Zero med en enda fråga: "vilka av dessa saknar vi en connector för?"
Här är den faktiska tidslinjen som följde. Alla tider PDT.
16:59. Skärmdumpen inkommer. Zero jämför den mot connector-katalogen: 7 av 10 finns redan (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Tre saknas (Clay, LeanData, Snowflake), och Snowflake flaggas som mest värdefull eftersom datalagret är grunden i GTM-stacken. Svar inkommer 17:00.
17:01. Uppföljning: "vilka av dessa kan göras som en api-token-connector?" Zero hämtar autentiseringsdokumentationen: Clay har en personlig API-nyckel, Snowflake har nyligen lanserat Programmatic Access Tokens, LeanData är endast OAuth och Salesforce-bundet. Utslag 17:02: Snowflake först (högst värde, renast auth), sedan Clay.
17:04. Ingenjören säger "kör". Connector-authoring skill tar vid. Vid 17:07 har den avgränsat Clay (enda publika ytan är per-tabell-webhooks, ingen riktig connector att bygga) och bekräftat Snowflakes form: SNOWFLAKE_PAT hemlighet + SNOWFLAKE_ACCOUNT variabel, bearer auth mot Snowflake REST API och SQL API v2, dynamiskt subdomän-brandväggsmönster modellerat efter Zendesk.
17:35. Båda PR:erna öppnas samma minut:
vm0-skills#176: den agentinriktade skillen. Hur man skriver Snowflake SQL, formaterar resultat, försöker igen vid övergående fel.vm0#13356: connectorn själv. Registerpost, PAT-hanterare, brandväggsgenerator, plattformsikon, miljö-mappning plumbing.
18:22. Skill-PR slås ihop.
18:42. Connector-PR slås ihop.
18:52. Release-PR öppnas automatiskt.
23:18. [email protected] och resten av release-tåget rullas ut i produktion. Snowflake är live för varje organisation.
Sex timmar och nitton minuter från "skärmdump av Anthropics stack" till "Zero kan fråga ditt datalager". En ingenjör. En konversation. Ingen överlämning till något "connector-team".
Genomströmningen här beror inte på att ingenjören är snabb. Det beror på att connector-authoring skill bar de delar som tidigare krävde institutionskunskap: vilken autentiseringsform som ska väljas, vilka endpoints som matchar användarscenariot, vilka tolv filer som ska in i vilka två repos, hur brandväggsmönstret kombineras med ett dynamiskt subdomän. Författaren skrev avsikten. Skillen skrev grunden. Produktion gjorde resten.
Det är detta ramverket ger oss. Inte bara hastighet (även om den är verklig), utan vem som kan ta jobbet. Snowflake-författaren råkade vara ingenjör. Han behövde inte vara det.
Varför api-token är förstaklassmedborgare
En fotnot värd att lyfta fram, eftersom det är ett medvetet designval som överraskat många.
De flesta agentplattformar behandlar OAuth som den enda sanna autentiseringen och api-token som en nödlösning för äldre verktyg. Vi gör tvärtom. API-tokens är förstaklassmedborgare i vår connector-modell, med samma samtyckesgränssnitt, samma per-organisations valv, samma granskningskedja, samma brandvägg.
Det finns två skäl.
Det första är att api-token-autentisering har kortare tid till första användning. Snowflake har nyligen lanserat Programmatic Access Tokens just av denna anledning: långlivade, avgränsade, återkallningsbara credentials som inte kräver någon OAuth-process. En användare med en PAT kan vara produktiv i Zero på under en minut. Ett OAuth-flöde, även ett smidigt, tar längre tid och kräver mer av användaren.
Det andra är att OAuth inte alltid finns tillgängligt. Vissa företagsverktyg har helt enkelt inte det, eller så är det låst bakom en Enterprise-licens. Att behandla api-token som jämbördig (inte som nödlösning) gör att vi kan stödja dessa verktyg ordentligt istället för att lämna dem i en "kommer snart"-grav.
Snowflake-connectorn som lanserades igår är api-token. Gmail-connectorn som levererar kunders e-posttrådar är OAuth. Båda går genom samma ramverk, samma skill, samma granskning. Författaren väljer formen som passar verktyget, och ramverket gör båda enkla att bygga.
Vad 180 integrationer faktiskt låser upp
Själva antalet är inte poängen. Poängen är att vid denna täthet slutar agenten vara ett verktyg du kallar på och blir istället en miljö du lever i.
När Zero har connectors till ditt CRM och ditt datalager och din supportinkorg och ditt designverktyg och ditt repo, kan den göra saker ingen enskild integrationsagent kan. Den kan hämta en Snowflake-fråga, korsreferera mot öppna Linear-ärenden och posta en sammanfattning i Slack-kanalen där kundframgångsteamet håller till. Den kan läsa ett Gong-samtal, hitta funktionen prospektet frågade om, kolla om den finns på roadmapen och skriva uppföljningsmejlet – allt i ett svep.
Varje ny connector tillför inte värde linjärt. Den tillför värde kombinatoriskt. Den 180:e connectorn är mer värdefull än den första, eftersom den kombineras med de 179 som kom före.
Det är vad vi satsar på med ramverket. Och satsningen med skillen är att hastigheten i sammansättningen beror på hur många i ditt team som får bidra till högen.
Vad händer härnäst
Vi arbetar på att öppna connector-authoring skill för kunder. Om du kör Zero för ditt team och har ett internt verktyg du behöver integration till (ditt faktureringssystem, ditt datalager, din interna adminpanel), kommer samma arbetsflöde som lanserade Snowflake igår vara det du använder för att lansera din. Samma grund, samma autentiseringsmodell, samma brandvägg, samma granskningskedja. Annan författare.
Om det låter intressant, hör gärna av dig.
