Gestern Nachmittag sah ein Engineer in unserem Team zu, wie Anthropic auf der SaaStr-Bühne ihren internen GTM-Stack vorstellte, machte einen Screenshot der Folie und stellte Zero eine einzige Frage: welche davon fehlen uns? Sechs Stunden und neunzehn Minuten später war Snowflake produktiv für jeden Zero-Kunden verfügbar. Es war die rund 180. Integration, die wir in einem Jahr ausgeliefert haben, und zunehmend ist die Person, die die nächste schreibt, gar kein Engineer mehr. Hier ist das Framework und der interne Skill darauf, der das möglich macht.
Was niemand über Agenten-Plattformen erzählt
Ein LLM ist ein Gehirn im Glas. Allein kann es dir ein Gedicht über dein Data Warehouse schreiben, aber es kann es nicht tatsächlich öffnen. Was einen Chatbot in einen Agenten verwandelt, das wofür dein Team eigentlich bezahlt, ist die Frage, ob der Agent in die Tools greifen kann, die du bereits nutzt, und dort Arbeit erledigen kann.
Wir nennen diese Reichweite den Connector-Layer. Nach einem Jahr Zero-Entwicklung sind wir überzeugt: Es ist das wichtigste Infrastrukturstück in einem Agenten-Produkt. Also haben wir unseren eigenen gebaut. Wichtiger noch: Wir haben einen Workflow drumherum gebaut, der es jedem im Team erlaubt, einen zu schreiben.
Warum nicht MCP. Warum nicht Zapier.
Beide wurden uns früh vorgeschlagen. Beide sind gut für das, was sie sind. Keines ist das, was wir brauchten.
MCP ist ein Protokoll, kein Produkt. Brillant für Tool-Autoren, die ihren Dienst für jedes LLM erreichbar machen wollen. Aber MCP-Server, wie sie heute deployt werden, übergeben dem Modell eine Liste von Tools und vertrauen darauf, dass es sie sicher aufruft. Es gibt keinen Per-Org-Credential-Vault, keine Firewall für die zulässigen Endpoints, kein Audit-Log, das einen Call zu einem Menschen zurückverfolgt, der ihn autorisiert hat. Für ein Produkt, bei dem ein Agent das Produktiv-Stripe eines Kunden berührt und ein anderer eine E-Mail im Gmail-Konto des CEO entwirft, ist „dem Modell vertrauen" kein Sicherheitsmodell.
Zapier-artige Integrationsplattformen lösen ein anderes Problem: Sie verdrahten deterministische Trigger zu deterministischen Aktionen. So arbeiten Agenten nicht. Ein Agent entscheidet mitten im Denken, dass der nächste Schritt ist, Snowflake abzufragen und dann ein Linear-Ticket zu schreiben. Er braucht einen Credential, einen gescopten HTTP-Client und einen Audit-Trail, und zwar sofort, nicht als vorgefertigtes Rezept.
Also haben wir das Langweilige gebaut: eine Registry von Integrationen, in der jeder Eintrag Auth-Metadaten trägt, ein Environment-Mapping, welche Secrets in die Sandbox injiziert werden, eine Firewall der erlaubten Hosts und einen kleinen Handler für OAuth- oder Token-Eigenheiten. Das ist die Infrastruktur.
Aber Infrastruktur ist nicht der interessante Teil der Geschichte. Der interessante Teil ist, was darauf passierte.
Der Skill, der alle zu Connector-Autoren machte
Etwa zweimal am Tag landet ein neues SaaS-Tool in unserem Integration-Backlog. Manche kommen aus Kundenanfragen. Manche, weil ein Teammitglied bemerkt, dass Zero etwas nicht kann, was es braucht. Manche aus einem BD-Gespräch, bei dem der Stack eines Prospects ein Tool enthält, das wir noch nicht kennen.
Wenn jede dieser Anfragen durch die Queue eines Engineers gehen müsste, würden wir eine pro Woche ausliefern. Wir liefern eine pro Tag.
Der Grund ist ein internes Tooling, das wir den Connector-Authoring-Skill nennen. Es ist ein Zero-Skill, in derselben Form, die wir an Kunden ausliefern, aber nach innen auf unsere eigene Codebase gerichtet. Wenn jemand im Team sagt „Ich will den Notion-Connector hinzufügen", führt Zero ihn Schritt für Schritt durch:
- Vom User-Szenario starten. Was will der User mit diesem Tool tatsächlich tun? „Eine Datenbank abfragen", „eine Seite erstellen", „den Workspace durchsuchen". Der Skill besteht auf einer konkreten User Story, bevor eine einzige Datei angefasst wird. Das Ziel eines Connectors ist, eine Agenten-Fähigkeit zu ermöglichen, nicht eine API erschöpfend zu wrappen.
- Die Auth-Form identifizieren. OAuth, API-Token oder beides. Der Skill weiß, was jede Form bedeutet: für OAuth die Consent-UI und Redirect-Plumbing; für API-Token die Per-Org-Secret-Injection und wo der User das Token bekommt. Der Autor wählt die Form, die zum Tool passt; alles weitere ergibt sich daraus.
- Endpoints dem Szenario zuordnen. Nicht „die ganze REST-API wrappen". Nur die Handvoll Endpoints, die die User Story erfüllen. Ein Connector mit drei gut gewählten Endpoints schlägt einen mit vierzig, die der Agent nie aufruft.
- Die zwölf Dateien scaffolden. Registry-Eintrag, Handler, Firewall-Pattern, Plattform-Icon, Env-Mapping-Plumbing, der Agent-seitige Skill, der Zero beibringt, den Connector zu nutzen. Der Skill schreibt das Scaffold; der Autor schreibt die Intent.
- Die zwei PRs öffnen. Einen ins Connector-Framework, einen in die Skill-Bibliothek. Beide werden von einem Engineer reviewt, aber das Review geht um Korrektheit, nicht darum, dem Autor zu erklären, wie das Framework funktioniert.
Was früher institutionelles Wissen erforderte (welche Auth-Form, welche Endpoints, welche zwölf Dateien in welchen zwei Repos, wie das Firewall-Pattern mit einer dynamischen Subdomain komponiert) trägt jetzt der Skill selbst. Der Autor bringt das User-Empathie mit. Der Skill bringt das Scaffolding.
So endet es damit, dass ein Designer, ein BD-Lead oder ein PM einen Connector ausliefert. Sie wissen, was der User will. Der Skill weiß den Rest.
Die Case Study: Snowflake, gestern
Gestern ging Anthropic auf der SaaStr-Bühne ihren internen GTM-Stack durch: Salesforce als System of Record, Clay für Enrichment, LeanData für Routing, Gong für Calls, Jira für Tickets, Intercom (Fin) für Support, Ironclad für Verträge, Snowflake als Data Warehouse. [Link zum Vortrag]
Einer unserer Engineers machte einen Screenshot der Folie und gab ihn Zero mit einer einzigen Frage: „welche davon fehlen uns als Connector?"
Hier ist die tatsächliche Timeline, die folgte. Alle Zeiten in PDT.
16:59. Der Screenshot kommt an. Zero vergleicht ihn mit dem Connector-Katalog: 7 der 10 existieren bereits (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Drei fehlen (Clay, LeanData, Snowflake), und Snowflake wird als das wertvollste markiert, da ein Data Warehouse das Fundament des GTM-Stacks ist. Antwort kommt um 17:00.
17:01. Follow-up: „welche davon lassen sich als API-Token-Connector machen?" Zero zieht die Auth-Docs: Clay hat einen persönlichen API-Key, Snowflake hat kürzlich Programmatic Access Tokens ausgeliefert, LeanData ist nur OAuth und an Salesforce gebunden. Urteil um 17:02: Snowflake zuerst (höchster Wert, sauberste Auth), dann Clay.
17:04. Der Engineer sagt „los". Der Connector-Authoring-Skill nimmt es auf. Bis 17:07 hat er Clay aus dem Scope genommen (die einzige öffentliche Oberfläche sind per-Tabelle-Webhooks, kein echter Connector zu bauen) und Snowflakes Form bestätigt: SNOWFLAKE_PAT-Secret + SNOWFLAKE_ACCOUNT-Variable, Bearer-Auth gegen die Snowflake REST API und SQL API v2, dynamisches Subdomain-Firewall-Pattern nach Vorbild von Zendesk.
17:35. Beide PRs werden in derselben Minute geöffnet:
vm0-skills#176: der Agent-seitige Skill. Wie man Snowflake-SQL schreibt, Ergebnisse formatiert, bei transienten Fehlern retried.vm0#13356: der Connector selbst. Registry-Eintrag, PAT-Handler, Firewall-Generator, Plattform-Icon, Env-Mapping-Plumbing.
18:22. Skill-PR gemergt.
18:42. Connector-PR gemergt.
18:52. Release-PR öffnet automatisch.
23:18. web@v12.369.0 und der Rest des Release-Trains werden in Produktion deployt. Snowflake ist für jede Org live.
Sechs Stunden und neunzehn Minuten vom „Screenshot von Anthropics Stack" zu „Zero kann dein Warehouse abfragen". Ein Engineer. Eine Konversation. Null Übergaben an ein „Connector-Team".
Der Durchsatz hier kommt nicht daher, dass der Engineer schnell ist. Er kommt daher, dass der Connector-Authoring-Skill die Teile übernommen hat, die früher institutionelles Wissen erforderten: welche Auth-Form, welche Endpoints zum User-Szenario passen, welche zwölf Dateien in welchen zwei Repos landen müssen, wie das Firewall-Pattern mit einer dynamischen Subdomain komponiert. Der Autor schrieb die Intent. Der Skill schrieb das Scaffolding. Die Production hat den Rest erledigt.
Das ist es, was das Framework uns einkauft. Nicht nur Geschwindigkeit (obwohl die Geschwindigkeit real ist), sondern wer die Arbeit übernehmen kann. Der Snowflake-Autor war zufällig ein Engineer. Er hätte keiner sein müssen.
Warum API-Token ein First-Class Citizen ist
Eine Fußnote, die es wert ist, herausgezogen zu werden, weil sie eine bewusste Design-Entscheidung ist, die Leute überrascht hat.
Die meisten Agenten-Plattformen behandeln OAuth als die One True Auth und API-Token als Fallback für Legacy-Tools. Wir machen das Gegenteil. API-Tokens sind ein First-Class Citizen in unserem Connector-Modell, mit derselben Consent-UI, demselben Per-Org-Vaulting, demselben Audit-Trail, derselben Firewall-Enforcement.
Es gibt zwei Gründe.
Der erste ist, dass API-Token-Auth eine kürzere Time-to-First-Use hat. Snowflake hat kürzlich Programmatic Access Tokens genau aus diesem Grund ausgeliefert: langlebige, scopebare, widerrufbare Credentials, die keinen OAuth-Tanz erfordern. Ein User mit einem PAT kann in Zero in unter einer Minute produktiv sein. Ein OAuth-Flow, selbst ein sauberer, dauert länger und fordert mehr vom User.
Der zweite ist, dass OAuth nicht immer verfügbar ist. Manche Enterprise-Tools liefern es einfach nicht, oder liefern es nur hinter einer Enterprise-SKU. API-Token als Peer (nicht als Fallback) zu behandeln, heißt, dass wir solche Tools richtig unterstützen können, statt sie in einem „Coming Soon"-Friedhof zu lassen.
Der Snowflake-Connector, der gestern ausgeliefert wurde, ist API-Token. Der Gmail-Connector, der Kunden-E-Mail-Threads ausliefert, ist OAuth. Beide gehen durch dasselbe Framework, denselben Skill, dasselbe Review. Der Autor wählt die Form, die zum Tool passt, und das Framework macht beide günstig in der Umsetzung.
Was 180-something Integrationen tatsächlich freischalten
Die Zahl selbst ist nicht der Punkt. Der Punkt ist, dass bei dieser Dichte der Agent aufhört, ein Tool zu sein, das man herbeiruft, und beginnt, eine Umgebung zu sein, in der man lebt.
Wenn Zero Connectors zu deinem CRM und deinem Data Warehouse und deinem Support-Inbox und deinem Design-Tool und deinem Repo hat, kann es Dinge tun, die kein Single-Integration-Agent kann. Es kann eine Snowflake-Query ziehen, sie gegen offene Linear-Tickets querreferenzieren und eine Summary im Slack-Channel posten, in dem das Customer-Success-Team lebt. Es kann einen Gong-Call lesen, das Feature finden, nach dem der Prospect gefragt hat, prüfen, ob es in der Roadmap ist, und die Follow-up-E-Mail entwerfen, alles in einem Zug.
Jeder neue Connector fügt nicht linear Wert hinzu. Er fügt kombinatorisch Wert hinzu. Der 180. Connector ist wertvoller als der erste, weil er mit den 179 davor komponiert.
Das ist die Wette hinter dem Framework. Und die Wette hinter dem Skill ist, dass die Geschwindigkeit des Compoundings davon abhängt, wie viele Leute im Team auf den Stapel legen dürfen.
Was als Nächstes kommt
Wir arbeiten daran, den Connector-Authoring-Skill für Kunden zu öffnen. Wenn du Zero für dein Team einsetzt und es ein internes Tool gibt, zu dem du eine Integration brauchst (dein Billing-System, dein Warehouse, dein eigenes internes Admin-Panel), wird derselbe Workflow, der gestern Snowflake ausgeliefert hat, der Workflow sein, mit dem du deinen ausliefern wirst. Dasselbe Scaffolding, dasselbe Auth-Modell, dieselbe Firewall, derselbe Audit-Trail. Anderer Autor.
Wenn dich das interessiert, würden wir gerne mit dir sprechen.
