Gistermiddag keek een engineer uit ons team naar hoe Anthropic hun interne GTM-stack presenteerde op het SaaStr-podium, maakte een screenshot van de slide en stelde Zero één vraag: welke hiervan missen wij? Zes uur en negentien minuten later stond Snowflake live in productie voor elke Zero-klant. Het was de 180-en-nog-watste integratie die we in een jaar hebben uitgebracht, en steeds vaker is degene die de volgende schrijft geen engineer meer. Hier is het framework, en de interne vaardigheid erbovenop, die dat mogelijk maakt.
Wat niemand je vertelt over agentplatforms
Een LLM is een brein in een pot. Op zichzelf kan het een gedicht schrijven over je datawarehouse, maar het kan het niet daadwerkelijk openen. Wat een chatbot in een agent verandert, waar je team daadwerkelijk voor betaalt, is of de agent toegang heeft tot de tools die je al gebruikt en daar werk in kan doen.
Wij noemen die toegang de connectorlaag. Na een jaar bouwen aan Zero geloven we dat dit het belangrijkste onderdeel van de infrastructuur in een agentproduct is. Dus hebben we onze eigen gebouwd. Belangrijker nog: we hebben er een workflow omheen gebouwd waarmee iedereen in het team er een kan maken.
Waarom geen MCP. Waarom geen Zapier.
Beide werden ons vroeg gevraagd. Beide zijn goed in wat ze doen. Geen van beide is wat wij nodig hadden.
MCP is een protocol, geen product. Briljant voor toolmakers die willen dat hun dienst bereikbaar is door elke LLM. Maar MCP-servers, zoals ze nu worden ingezet, geven het model een lijst tools en vertrouwen erop dat het deze veilig aanroept. Er is geen per-organisatie credential vault, geen firewall op welke endpoints benaderd mogen worden, geen auditlog die een call koppelt aan de mens die deze heeft geautoriseerd. Voor een product waarbij de ene agent de productie-Stripe van een klant kan aanraken en een andere een e-mail kan opstellen in de Gmail van hun CEO, is "vertrouw het model" geen beveiligingsmodel.
Zapier-achtige integratieplatforms lossen een ander probleem op: ze koppelen deterministische triggers aan deterministische acties. Agents werken niet zo. Een agent besluit halverwege dat de volgende stap is om Snowflake te bevragen en daarna een Linear-ticket aan te maken. Het heeft direct een credential, een gescope HTTP-client en een audittrail nodig, niet als vooraf gebouwde recept.
Dus bouwden we het saaie: een register van integraties waarbij elke vermelding authenticatie-metadata bevat, een omgevingsmapping van welke geheimen in de sandbox worden geïnjecteerd, een firewall van toegestane hosts en een kleine handler voor OAuth- of token-eigenaardigheden. Dat is de infrastructuur.
Maar infrastructuur is niet het interessante deel van het verhaal. Het interessante is wat er bovenop gebeurde.
De vaardigheid die iedereen tot connectorauteur maakte
Ongeveer twee keer per dag komt er een nieuwe SaaS op onze integratie-backlog. Sommige komen van klantverzoeken. Sommige doordat een collega merkt dat Zero iets niet kan wat ze nodig hebben. Sommige uit een BD-gesprek waarin de stack van een prospect een tool bevat die we nog niet kennen.
Als elk van die verzoeken door de queue van een engineer moest, zouden we er één per week uitbrengen. Nu brengen we er één per dag uit.
De reden is een stuk intern gereedschap dat we de connector-authoring skill noemen. Het is een Zero-vaardigheid, hetzelfde type dat we aan klanten leveren, maar dan gericht op onze eigen codebase. Wanneer iemand in het team zegt "Ik wil de Notion-connector toevoegen," begeleidt Zero hen stap voor stap:
- Begin bij het gebruikersscenario. Wat wil de gebruiker daadwerkelijk doen met deze tool? "Een database bevragen," "een pagina aanmaken," "zoeken in de workspace." De vaardigheid staat op een concreet gebruikersverhaal voordat er een bestand wordt aangeraakt. Het doel van een connector is een agentvaardigheid mogelijk maken, niet een API volledig afdekken.
- Bepaal de auth-vorm. OAuth, API-token, of beide. De vaardigheid weet wat elke vorm inhoudt: voor OAuth de toestemmings-UI en redirect-plumbing; voor API-tokens de per-organisatie geheime injectie en waar de gebruiker de token vandaan haalt. De auteur kiest de vorm die bij de tool past; alles daarna volgt automatisch.
- Koppel endpoints aan het scenario. Niet "de hele REST API afdekken." Alleen de paar endpoints die het gebruikersverhaal ondersteunen. Een connector met drie goed gekozen endpoints is beter dan één met veertig die de agent nooit gebruikt.
- Scaffold de twaalf bestanden. Registry entry, handler, firewall-patroon, platformicoon, env-mapping, de agentgerichte vaardigheid die Zero leert hoe de connector te gebruiken. De vaardigheid schrijft de scaffold; de auteur schrijft de intentie.
- Open de twee PR's. Eén naar het connector-framework, één naar de skill-library. Beide worden door een engineer gereviewd, maar de review gaat over juistheid, niet over uitleggen hoe het framework werkt.
Wat vroeger institutionele kennis vereiste (welke auth-vorm, welke endpoints, welke twaalf bestanden in welke twee repos, hoe het firewall-patroon samenwerkt met een dynamisch subdomein) wordt nu gedragen door de vaardigheid zelf. De auteur brengt gebruikersinzicht. De vaardigheid brengt de scaffolding.
Zo kan een designer, een BD-lead of een PM een connector uitbrengen. Zij weten wat de gebruiker wil. De vaardigheid weet de rest.
De casus: Snowflake, gisteren
Gisteren liep Anthropic hun interne GTM-stack door op het SaaStr-podium: Salesforce als systeem van record, Clay voor verrijking, LeanData voor routering, Gong voor gesprekken, Jira voor tickets, Intercom (Fin) voor support, Ironclad voor contracten, Snowflake als datawarehouse. [link naar de talk]
Een van onze engineers maakte een screenshot van de slide en plaatste die in Zero met één vraag: "voor welke hiervan missen we een connector?"
Hier is de daadwerkelijke tijdlijn die volgde. Alle tijden PDT.
16:59. De screenshot komt binnen. Zero vergelijkt deze met de connectorcatalogus: 7 van de 10 bestaan al (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Drie ontbreken (Clay, LeanData, Snowflake), en Snowflake wordt als meest waardevol gemarkeerd, omdat een datawarehouse de basis is van de GTM-stack. Antwoord volgt om 17:00.
17:01. Vervolg: "welke hiervan kunnen als api-token connector?" Zero haalt de auth-documentatie op: Clay heeft een persoonlijke API-key, Snowflake heeft recent Programmatic Access Tokens uitgebracht, LeanData is alleen OAuth en Salesforce-gebonden. Oordeel om 17:02: eerst Snowflake (meeste waarde, schoonste auth), dan Clay.
17:04. De engineer zegt "go." De connector-authoring skill pakt het op. Tegen 17:07 is Clay uitgesloten (het enige publieke oppervlak is per-tabel webhooks, geen echte connector te bouwen) en is Snowflake's vorm bevestigd: SNOWFLAKE_PAT secret + SNOWFLAKE_ACCOUNT variabele, bearer-auth tegen de Snowflake REST API en SQL API v2, dynamisch subdomein-firewallpatroon gemodelleerd naar Zendesk.
17:35. Beide PR's openen in dezelfde minuut:
vm0-skills#176: de agentgerichte vaardigheid. Hoe Snowflake SQL te schrijven, resultaten te formatteren, opnieuw proberen bij tijdelijke fouten.vm0#13356: de connector zelf. Registry entry, PAT-handler, firewallgenerator, platformicoon, env-mapping.
18:22. Skill-PR gemerged.
18:42. Connector-PR gemerged.
18:52. Release-PR opent automatisch.
23:18. [email protected] en de rest van de release-trein worden uitgerold naar productie. Snowflake is live voor elke organisatie.
Zes uur en negentien minuten van "screenshot van Anthropics stack" tot "Zero kan je warehouse bevragen." Eén engineer. Eén gesprek. Geen overdracht naar een "connector-team."
De doorvoersnelheid hier komt niet doordat de engineer snel is. Het komt doordat de connector-authoring skill de delen droeg die vroeger institutionele kennis vereisten: welke auth-vorm te kiezen, welke endpoints bij het gebruikersscenario horen, welke twaalf bestanden in welke twee repos moeten landen, hoe het firewallpatroon samenwerkt met een dynamisch subdomein. De auteur schreef de intentie. De vaardigheid schreef de scaffolding. Productie deed de rest.
Dit is wat het framework ons oplevert. Niet alleen snelheid (hoewel die echt is), maar wie het werk kan doen. De Snowflake-auteur was toevallig een engineer. Dat had niet gehoeven.
Waarom api-token een volwaardige optie is
Een voetnoot die het vermelden waard is, omdat het een bewuste ontwerpkeuze is die mensen verraste.
De meeste agentplatforms behandelen OAuth als de enige echte auth en api-token als een fallback voor legacy-tools. Wij doen het tegenovergestelde. API-tokens zijn een volwaardige optie in ons connectormodel, met dezelfde toestemmings-UI, dezelfde per-organisatie vaulting, dezelfde audittrail, dezelfde firewallhandhaving.
Daar zijn twee redenen voor.
De eerste is dat api-token-auth een kortere time-to-first-use heeft. Snowflake heeft onlangs Programmatic Access Tokens uitgebracht om precies deze reden: langlevende, scopebare, intrekbare credentials die geen OAuth-dans vereisen. Een gebruiker met een PAT kan binnen een minuut productief zijn in Zero. Een OAuth-flow, zelfs een schone, duurt langer en vraagt meer van de gebruiker.
De tweede is dat OAuth niet altijd beschikbaar is. Sommige enterprise-tools leveren er simpelweg geen, of alleen achter een enterprise-SKU. Door api-token als gelijkwaardig (niet als fallback) te behandelen, kunnen we die tools goed ondersteunen in plaats van ze in een "binnenkort beschikbaar"-graf te laten.
De Snowflake-connector die gisteren verscheen is api-token. De Gmail-connector die klant-e-mailthreads verwerkt is OAuth. Beide gaan door hetzelfde framework, dezelfde vaardigheid, dezelfde review. De auteur kiest de vorm die bij de tool past, en het framework maakt beide goedkoop om te bouwen.
Wat 180-en-nog-wat integraties daadwerkelijk mogelijk maken
Het getal zelf is niet het punt. Het punt is dat bij deze dichtheid de agent ophoudt een tool te zijn die je oproept en een omgeving wordt waarin je leeft.
Wanneer Zero connectors heeft naar je CRM en je datawarehouse en je support-inbox en je designtool en je repo, kan het dingen doen die geen enkele single-integratie-agent kan. Het kan een Snowflake-query uitvoeren, deze vergelijken met open Linear-tickets en een samenvatting posten in het Slack-kanaal waar het customer-success-team zit. Het kan een Gong-gesprek lezen, de feature vinden waar de prospect naar vroeg, checken of die op de roadmap staat en de follow-up mail opstellen, allemaal in één beweging.
Elke nieuwe connector voegt niet lineair waarde toe. Het voegt waarde combinatorisch toe. De 180e connector is waardevoller dan de 1e, omdat hij samengaat met de 179 die eraan voorafgingen.
Dat is de inzet achter het framework. En de inzet achter de vaardigheid is dat de snelheid van cumulatie afhangt van hoeveel mensen in je team mogen bijdragen.
Wat volgt
We werken eraan om de connector-authoring skill open te stellen voor klanten. Als je Zero voor je team gebruikt en er is een interne tool waarvoor je een integratie nodig hebt (je facturatiesysteem, je warehouse, je interne adminpanel), dan zal dezelfde workflow die gisteren Snowflake opleverde ook de workflow zijn waarmee jij die van jou bouwt. Zelfde scaffolding, zelfde auth-model, zelfde firewall, zelfde audittrail. Andere auteur.
Als dat je aanspreekt, spreken we je graag.
