I går eftermiddag så en ingeniør på vores team Anthropic gennemgå deres interne GTM-stack på SaaStr-scenen, tog et screenshot af sliden og stillede Zero ét spørgsmål: hvilke af disse mangler vi? Seks timer og nitten minutter senere var Snowflake live i produktion for alle Zero-kunder. Det var den 180.-et-eller-andet integration, vi har lanceret på et år, og i stigende grad er det ikke længere en ingeniør, der skriver den næste. Her er rammeværket og den interne skill ovenpå, der gør det muligt.
Det ingen fortæller dig om agentplatforme
En LLM er en hjerne på glas. Alene kan den skrive et digt om dit datalager, men den kan ikke åbne det. Det, der forvandler en chatbot til en agent, det, dit team faktisk betaler for, er, om agenten kan række ind i de værktøjer, I allerede bruger, og udføre arbejde i dem.
Vi kalder den rækkevidde for connector-laget. Efter et år med at bygge Zero mener vi, det er det vigtigste stykke infrastruktur i et agentprodukt. Så vi byggede vores eget. Endnu vigtigere: vi byggede en arbejdsgang omkring det, så alle på teamet kan forfatte én.
Hvorfor ikke MCP. Hvorfor ikke Zapier.
Begge blev vi spurgt om tidligt. Begge er gode til det, de er. Ingen af dem var det, vi havde brug for.
MCP er en protokol, ikke et produkt. Genialt for værktøjsudviklere, der vil gøre deres service tilgængelig for enhver LLM. Men MCP-servere, som de er implementeret i dag, giver modellen en liste af værktøjer og stoler på, at den kalder dem sikkert. Der er intet per-org credential vault, ingen firewall for hvilke endpoints der må rammes, ingen audit-log der binder et kald til et menneske, der har godkendt det. For et produkt, hvor én agent måske rører en kundes produktions-Stripe og en anden måske skriver en mail i deres CEOs Gmail, er "stol på modellen" ikke en sikkerhedsmodel.
Zapier-lignende integrationsplatforme løser et andet problem: de forbinder deterministiske triggere til deterministiske handlinger. Agenter fungerer ikke sådan. En agent beslutter midt i tanken, at næste skridt er at forespørge Snowflake og derefter oprette en Linear-ticket. Den har brug for et credential, en afgrænset HTTP-klient og et audit-trail med det samme, ikke som en forudbygget opskrift.
Så vi byggede det kedelige: et register over integrationer, hvor hver post bærer auth-metadata, en miljø-mapping af hvilke secrets der injiceres i sandkassen, en firewall over tilladte hosts og en lille handler til OAuth- eller token-quirks. Det er infrastrukturen.
Men infrastrukturen er ikke den interessante del af historien. Det interessante er, hvad der skete ovenpå den.
Skillen der gjorde alle til connector-forfattere
Et nyt SaaS lander i vores integrations-backlog cirka to gange om dagen. Nogle kommer fra kundebehov. Nogle fra en kollega, der opdager, at Zero ikke kan noget, de har brug for. Nogle fra en BD-samtale, hvor en prospects stack indeholder et værktøj, vi ikke har mødt endnu.
Hvis hver eneste af dem skulle igennem en ingeniørs kø, ville vi kun lancere én om ugen. Vi lancerer én om dagen.
Årsagen er et internt værktøj, vi kalder connector-authoring skill. Det er en Zero-skill, samme type som vi leverer til kunder, men rettet indad mod vores egen kodebase. Når nogen på teamet siger "jeg vil tilføje Notion-connectoren", guider Zero dem igennem:
- Start fra brugerscenariet. Hvad vil brugeren faktisk gøre med dette værktøj? "Forespørge en database", "oprette en side", "søge på tværs af workspace". Skillen insisterer på en konkret brugerhistorie, før en eneste fil røres. Målet med en connector er at muliggøre en agentfunktion, ikke at dække et API udtømmende.
- Identificér auth-typen. OAuth, API-token eller begge. Skillen ved, hvad hver type indebærer: for OAuth, consent-UI og redirect-flow; for API-tokens, per-org secret-injektion og hvor brugeren får tokenet. Forfatteren vælger den type, der matcher værktøjet; alt nedstrøms følger derfra.
- Kortlæg endpoints til scenariet. Ikke "dæk hele REST API'et". Kun de få endpoints, der opfylder brugerhistorien. En connector med tre velvalgte endpoints slår én med fyrre, som agenten aldrig bruger.
- Scaffold de tolv filer. Registry-post, handler, firewall-mønster, platform-ikon, env-mapping, den agentvendte skill, der lærer Zero at bruge connectoren. Skillen skriver scaffolding; forfatteren skriver intentionen.
- Åbn de to PR'er. Én til connector-rammeværket, én til skill-biblioteket. Begge bliver gennemgået af en ingeniør, men reviewet handler om korrekthed, ikke om at lære forfatteren rammeværket.
Det, der før krævede institutionsviden (hvilken auth-type, hvilke endpoints, hvilke tolv filer i hvilke to repos, hvordan firewall-mønstret sammensættes med et dynamisk subdomæne), bæres nu af skillen selv. Forfatteren bidrager med brugerforståelsen. Skillen leverer scaffolding.
Sådan ender en designer, en BD-lead eller en PM med at lancere en connector. De ved, hvad brugeren vil. Skillen ved alt andet.
Casen: Snowflake, i går
I går gennemgik Anthropic deres interne GTM-stack på SaaStr-scenen: Salesforce som system of record, Clay til berigelse, LeanData til routing, Gong til opkald, Jira til tickets, Intercom (Fin) til support, Ironclad til kontrakter, Snowflake som datalager. [link til oplægget]
En af vores ingeniører tog et screenshot af sliden og lagde det i Zero med ét spørgsmål: "hvilke af disse mangler vi en connector til?"
Her er den faktiske tidslinje, der fulgte. Alle tidspunkter er PDT.
16:59. Screenshot lander. Zero sammenligner det med connector-kataloget: 7 af 10 findes allerede (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Tre mangler (Clay, LeanData, Snowflake), og Snowflake markeres som mest værdifuld, da et datalager er fundamentet i GTM-stacken. Svar lander kl. 17:00.
17:01. Opfølgning: "hvilke af disse kan laves som en api-token connector?" Zero henter auth-dokumentationen: Clay har en personlig API-nøgle, Snowflake har for nylig lanceret Programmatic Access Tokens, LeanData er kun OAuth og Salesforce-bundet. Konklusion kl. 17:02: Snowflake først (mest værdi, ren auth), derefter Clay.
17:04. Ingeniøren siger "go". Connector-authoring skillen tager over. Ved 17:07 har den scoped Clay fra (den eneste offentlige overflade er per-tabel webhooks, ingen reel connector at bygge) og bekræftet Snowflakes type: SNOWFLAKE_PAT secret + SNOWFLAKE_ACCOUNT-variabel, bearer-auth mod Snowflake REST API og SQL API v2, dynamisk subdomæne-firewall mønster modelleret efter Zendesk.
17:35. Begge PR'er åbnes i samme minut:
vm0-skills#176: den agentvendte skill. Hvordan man skriver Snowflake SQL, formaterer resultater, genprøver ved midlertidige fejl.vm0#13356: selve connectoren. Registry-post, PAT-handler, firewall-generator, platform-ikon, env-mapping.
18:22. Skill-PR flettet.
18:42. Connector-PR flettet.
18:52. Release-PR åbnes automatisk.
23:18. [email protected] og resten af release-train deployes til produktion. Snowflake er live for alle organisationer.
Seks timer og nitten minutter fra "screenshot af Anthropics stack" til "Zero kan forespørge dit datalager." Én ingeniør. Én samtale. Ingen overlevering til et "connector-team".
Gennemløbet her skyldes ikke, at ingeniøren er hurtig. Det skyldes, at connector-authoring skillen bar de dele, der før krævede institutionsviden: hvilken auth-type der skal vælges, hvilke endpoints der matcher brugerscenariet, hvilke tolv filer der skal lande i hvilke to repos, hvordan firewall-mønstret sammensættes med et dynamisk subdomæne. Forfatteren skrev intentionen. Skillen skrev scaffolding. Produktion klarede resten.
Det er det, rammeværket giver os. Ikke bare hastighed (selvom hastigheden er reel), men hvem der kan tage opgaven. Snowflake-forfatteren var tilfældigvis ingeniør. Han behøvede ikke være det.
Hvorfor api-token er en førsteklasses borger
En fodnote værd at fremhæve, fordi det er et bevidst designvalg, der overraskede folk.
De fleste agentplatforme behandler OAuth som den eneste rigtige auth og api-token som en nødløsning for ældre værktøjer. Vi gør det modsatte. API-tokens er en førsteklasses borger i vores connector-model, med samme consent-UI, samme per-org vaulting, samme audit-trail, samme firewall-håndhævelse.
Der er to grunde.
Den første er, at api-token auth har kortere tid til første brug. Snowflake har for nylig lanceret Programmatic Access Tokens netop af denne grund: langtidsholdbare, afgrænsede, tilbagekaldelige credentials, der ikke kræver et OAuth-flow. En bruger med et PAT kan være produktiv i Zero på under et minut. Et OAuth-flow, selv et rent, tager længere tid og kræver mere af brugeren.
Den anden er, at OAuth ikke altid er tilgængelig. Nogle enterprise-værktøjer tilbyder det slet ikke, eller kun bag en enterprise-SKU. At behandle api-token som ligestillet (ikke en nødløsning) betyder, at vi kan understøtte disse værktøjer ordentligt i stedet for at efterlade dem i en "kommer snart"-gravplads.
Snowflake-connectoren, der blev lanceret i går, er api-token. Gmail-connectoren, der leverer kundemailtråde, er OAuth. Begge går gennem samme rammeværk, samme skill, samme review. Forfatteren vælger den type, der matcher værktøjet, og rammeværket gør begge billige at bygge.
Hvad 180-et-eller-andet integrationer faktisk låser op
Tallet i sig selv er ikke pointen. Pointen er, at ved denne tæthed holder agenten op med at være et værktøj, du tilkalder, og bliver et miljø, du lever i.
Når Zero har connectors til dit CRM og dit datalager og din support-indbakke og dit designværktøj og dit repo, kan den gøre ting, ingen enkelt-integrations-agent kan. Den kan hente en Snowflake-forespørgsel, krydsreferere den mod åbne Linear-tickets og poste et resumé i Slack-kanalen, hvor customer-success-teamet holder til. Den kan læse et Gong-opkald, finde den feature, prospecten spurgte til, tjekke om den er på roadmap, og skrive opfølgningsmailen – alt i ét hug.
Hver ny connector tilføjer ikke værdi lineært. Den tilføjer værdi kombinatorisk. Den 180. connector er mere værdifuld end den første, fordi den kan kombineres med de 179, der kom før.
Det er satsningen bag rammeværket. Og satsningen bag skillen er, at hastigheden af sammensætning afhænger af, hvor mange på dit team der må lægge til bunken.
Hvad nu
Vi arbejder på at åbne connector-authoring skillen for kunder. Hvis du kører Zero for dit team og har et internt værktøj, du har brug for en integration til (dit faktureringssystem, dit datalager, dit interne adminpanel), vil den samme arbejdsgang, der lancerede Snowflake i går, være den arbejdsgang, du bruger til at lancere din. Samme scaffolding, samme auth-model, samme firewall, samme audit-trail. En anden forfatter.
Hvis det lyder interessant, vil vi meget gerne tale med dig.
