Ieri pomeriggio, un ingegnere del nostro team ha guardato Anthropic illustrare il proprio stack GTM interno sul palco di SaaStr, ha fatto uno screenshot della slide e ha posto a Zero una sola domanda: quali di questi ci mancano? Sei ore e diciannove minuti dopo, Snowflake era live in produzione per ogni cliente Zero. Era la centottantesima e passa integrazione che spediamo in un anno e, sempre più spesso, chi scrive quella successiva non è affatto un ingegnere. Ecco il framework, e la skill interna che ci gira sopra, che rende tutto questo possibile.
Quello che nessuno ti dice sulle piattaforme di agenti
Un LLM è un cervello in un barattolo. Da solo, può scriverti una poesia sul tuo data warehouse, ma non può aprirlo davvero. Ciò che trasforma un chatbot in un agente, ciò per cui il tuo team paga davvero, è la capacità dell'agente di mettere mano agli strumenti che già usi e fare lavoro al loro interno.
Chiamiamo questa capacità di raggiungere gli strumenti il connector layer. Dopo un anno passato a costruire Zero, crediamo sia il singolo pezzo di infrastruttura più importante in un prodotto basato su agenti. Così ce lo siamo costruiti da soli. Ancora più importante: ci abbiamo costruito attorno un flusso di lavoro che consente a chiunque nel team di scriverne uno.
Perché non MCP. Perché non Zapier.
All'inizio ci hanno chiesto di entrambi. Entrambi sono validi per quello che sono. Nessuno dei due era ciò che ci serviva.
MCP è un protocollo, non un prodotto. Geniale per chi sviluppa strumenti e vuole che il proprio servizio sia raggiungibile da qualsiasi LLM. Ma i server MCP, così come vengono distribuiti oggi, consegnano al modello un elenco di strumenti e si fidano che li chiami in modo sicuro. Non c'è una cassaforte di credenziali per ogni organizzazione, nessun firewall su quali endpoint possono essere raggiunti, nessun log di audit che colleghi una chiamata alla persona che l'ha autorizzata. Per un prodotto in cui un agente potrebbe toccare lo Stripe in produzione di un cliente e un altro potrebbe redigere un'email nella Gmail del suo CEO, "fidarsi del modello" non è un modello di sicurezza.
Le piattaforme di integrazione in stile Zapier risolvono un problema diverso: collegano trigger deterministici ad azioni deterministiche. Gli agenti non funzionano così. Un agente decide, nel mezzo di un ragionamento, che il passo successivo è interrogare Snowflake e poi scrivere un ticket Linear. Ha bisogno di una credenziale, di un client HTTP con uno scope definito e di una traccia di audit subito, non come una ricetta preconfezionata.
Così abbiamo costruito la cosa noiosa: un registro di integrazioni in cui ogni voce porta con sé i metadati di autenticazione, una mappatura ambientale di quali segreti vengono iniettati nella sandbox, un firewall di host consentiti e un piccolo handler per le particolarità di OAuth o dei token. Questa è l'infrastruttura.
Ma l'infrastruttura non è la parte interessante della storia. La parte interessante è ciò che è successo sopra di essa.
La skill che ha trasformato tutti in autori di connettori
Un nuovo SaaS finisce nel nostro backlog di integrazioni grosso modo due volte al giorno. Alcuni arrivano da richieste dei clienti. Alcuni da un membro del team che si accorge che Zero non riesce a fare qualcosa di cui ha bisogno. Alcuni da una conversazione di BD in cui lo stack di un potenziale cliente include uno strumento che non abbiamo ancora incontrato.
Se ognuno di questi dovesse passare per la coda di un ingegnere, ne spediremmo uno a settimana. Noi ne spediamo uno al giorno.
Il motivo è uno strumento interno che chiamiamo connector-authoring skill. È una skill di Zero, della stessa forma di quelle che spediamo ai clienti, ma rivolta verso l'interno, alla nostra stessa base di codice. Quando qualcuno nel team dice "voglio aggiungere il connettore Notion", Zero lo guida passo dopo passo:
- Parti dallo scenario utente. Cosa vuole davvero fare l'utente con questo strumento? "Interrogare un database", "creare una pagina", "cercare in tutto il workspace". La skill pretende una user story concreta prima ancora di toccare un singolo file. L'obiettivo di un connettore è abilitare una capacità dell'agente, non avvolgere in modo esaustivo un'API.
- Identifica la forma di autenticazione. OAuth, token API, o entrambi. La skill sa cosa comporta ciascuna forma: per OAuth, l'interfaccia di consenso e il cablaggio del redirect; per i token API, l'iniezione del segreto per ogni organizzazione e dove l'utente ottiene il token. L'autore sceglie la forma adatta allo strumento; tutto il resto a valle ne consegue.
- Mappa gli endpoint sullo scenario. Non "avvolgere l'intera API REST". Solo la manciata di endpoint che soddisfano la user story. Un connettore con tre endpoint ben scelti batte uno con quaranta che l'agente non usa mai.
- Genera lo scaffold dei dodici file. Voce nel registro, handler, pattern del firewall, icona della piattaforma, cablaggio della mappatura ambientale, la skill rivolta all'agente che insegna a Zero come usare il connettore. La skill scrive lo scaffold; l'autore scrive l'intento.
- Apri le due PR. Una verso il framework dei connettori, una verso la libreria delle skill. Entrambe vengono revisionate da un ingegnere, ma la revisione riguarda la correttezza, non l'insegnare all'autore come funziona il framework.
Quella che un tempo richiedeva conoscenza istituzionale (quale forma di autenticazione, quali endpoint, quali dodici file in quali due repository, come il pattern del firewall si compone con un sottodominio dinamico) è ora portata dalla skill stessa. L'autore porta l'empatia verso l'utente. La skill porta lo scaffolding.
È così che un designer, un responsabile di BD o un PM finiscono per spedire un connettore. Loro sanno cosa vuole l'utente. La skill sa tutto il resto.
Il caso studio: Snowflake, ieri
Ieri Anthropic ha illustrato il proprio stack GTM interno sul palco di SaaStr: Salesforce come system of record, Clay per l'arricchimento, LeanData per il routing, Gong per le chiamate, Jira per i ticket, Intercom (Fin) per il supporto, Ironclad per i contratti, Snowflake come data warehouse. [link al talk]
Uno dei nostri ingegneri ha fatto uno screenshot della slide e l'ha lasciato cadere in Zero con una sola domanda: "per quali di questi ci manca un connettore?"
Ecco la cronologia reale che ne è seguita. Tutti gli orari sono in PDT.
16:59. Arriva lo screenshot. Zero lo confronta con il catalogo dei connettori: 7 dei 10 esistono già (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Tre mancano (Clay, LeanData, Snowflake), e Snowflake viene segnalato come il più prezioso, dato che un data warehouse è la base dello stack GTM. La risposta arriva alle 17:00.
17:01. Domanda di follow-up: "quali di questi si possono fare come connettore api-token?" Zero recupera la documentazione di autenticazione: Clay ha una chiave API personale, Snowflake ha rilasciato di recente i Programmatic Access Token, LeanData è solo OAuth e legato a Salesforce. Verdetto alle 17:02: prima Snowflake (valore più alto, autenticazione più pulita), poi Clay.
17:04. L'ingegnere dà il "via". La connector-authoring skill se ne occupa. Entro le 17:07 ha escluso Clay (l'unica superficie pubblica sono i webhook per tabella, nessun vero connettore da costruire) e confermato la forma di Snowflake: segreto SNOWFLAKE_PAT + variabile SNOWFLAKE_ACCOUNT, autenticazione bearer verso la Snowflake REST API e la SQL API v2, pattern di firewall a sottodominio dinamico modellato su Zendesk.
17:35. Entrambe le PR aperte nello stesso minuto:
vm0-skills#176: la skill rivolta all'agente. Come scrivere SQL per Snowflake, formattare i risultati, ritentare in caso di errori transitori.vm0#13356: il connettore vero e proprio. Voce nel registro, handler PAT, generatore di firewall, icona della piattaforma, cablaggio della mappatura ambientale.
18:22. PR della skill merge.
18:42. PR del connettore merge.
18:52. La PR di release si apre automaticamente.
23:18. web@v12.369.0 e il resto del treno di release vengono distribuiti in produzione. Snowflake è live per ogni organizzazione.
Sei ore e diciannove minuti da "screenshot dello stack di Anthropic" a "Zero può interrogare il tuo warehouse". Un ingegnere. Una conversazione. Zero passaggi di consegne a un "team connettori".
Il throughput qui non dipende dalla velocità dell'ingegnere. Dipende dal fatto che la connector-authoring skill si è fatta carico delle parti che un tempo richiedevano conoscenza istituzionale: quale forma di autenticazione scegliere, quali endpoint mappare sullo scenario utente, quali dodici file devono atterrare in quali due repository, come il pattern del firewall si compone con un sottodominio dinamico. L'autore ha scritto l'intento. La skill ha scritto lo scaffolding. La produzione ha fatto il resto.
È questo che ci compra il framework. Non solo velocità (anche se la velocità è reale), ma chi può prendersi il lavoro. L'autore di Snowflake si dava il caso fosse un ingegnere. Non doveva esserlo per forza.
Perché api-token è un cittadino di prima classe
Una nota a margine che vale la pena estrarre, perché è una scelta di design deliberata che ha sorpreso le persone.
La maggior parte delle piattaforme di agenti tratta OAuth come l'Unica Vera Autenticazione e l'api-token come ripiego per gli strumenti legacy. Noi facciamo l'opposto. I token API sono cittadini di prima classe nel nostro modello di connettori, con la stessa interfaccia di consenso, lo stesso vaulting per organizzazione, la stessa traccia di audit, lo stesso enforcement del firewall.
Ci sono due ragioni.
La prima è che l'autenticazione api-token ha un tempo al primo utilizzo più breve. Snowflake ha rilasciato di recente i Programmatic Access Token proprio per questo motivo: credenziali a lunga durata, con scope definibile, revocabili, che non richiedono il balletto di OAuth. Un utente con un PAT può essere produttivo in Zero in meno di un minuto. Un flusso OAuth, anche pulito, richiede più tempo e chiede di più all'utente.
La seconda è che OAuth non è sempre disponibile. Alcuni strumenti enterprise semplicemente non ne offrono uno, oppure ne offrono uno chiuso dietro una SKU enterprise. Trattare l'api-token come un pari (non come ripiego) significa che possiamo supportare quegli strumenti come si deve, invece di lasciarli nel cimitero del "presto disponibile".
Il connettore Snowflake spedito ieri è api-token. Il connettore Gmail che porta i thread di email dei clienti è OAuth. Entrambi passano per lo stesso framework, la stessa skill, la stessa revisione. L'autore sceglie la forma adatta allo strumento, e il framework rende economica la costruzione di entrambe.
Cosa sblocca davvero avere centottanta e passa integrazioni
Il numero in sé non è il punto. Il punto è che a questa densità, l'agente smette di essere uno strumento che invochi e inizia a essere un ambiente in cui vivi.
Quando Zero ha connettori al tuo CRM e al tuo data warehouse e alla tua casella di supporto e al tuo strumento di design e al tuo repository, può fare cose che nessun agente con una sola integrazione può fare. Può estrarre una query Snowflake, incrociarla con i ticket Linear aperti e pubblicare un riepilogo nel canale Slack in cui vive il team di customer success. Può leggere una chiamata Gong, individuare la funzionalità chiesta dal potenziale cliente, verificare se è nella roadmap e redigere l'email di follow-up, tutto in un'unica mossa.
Ogni nuovo connettore non aggiunge valore in modo lineare. Lo aggiunge in modo combinatorio. Il 180° connettore è più prezioso del 1°, perché si compone con i 179 che lo hanno preceduto.
Questa è la scommessa dietro il framework. E la scommessa dietro la skill è che la velocità della crescita composta dipende da quante persone nel tuo team sono autorizzate ad aggiungere qualcosa alla pila.
Cosa viene dopo
Stiamo lavorando per aprire la connector-authoring skill ai clienti. Se gestisci Zero per il tuo team e c'è uno strumento interno a cui ti serve un'integrazione (il tuo sistema di fatturazione, il tuo warehouse, il tuo pannello di amministrazione interno personalizzato), lo stesso flusso di lavoro che ieri ha spedito Snowflake sarà il flusso che userai per spedire il tuo. Stesso scaffolding, stesso modello di autenticazione, stesso firewall, stessa traccia di audit. Autore diverso.
Se la cosa ti interessa, ci farebbe piacere parlarne.
