Eilen iltapäivällä eräs insinöörimme katsoi, kun Anthropic esitteli sisäistä GTM-pinoaan SaaStr-lavalla, otti kuvakaappauksen diasta ja esitti Zerolle yhden kysymyksen: mitkä näistä meiltä puuttuvat? Kuusi tuntia ja yhdeksäntoista minuuttia myöhemmin Snowflake oli tuotannossa jokaiselle Zero-asiakkaalle. Se oli 180. integraatio, jonka olemme julkaisseet vuoden aikana, ja yhä useammin seuraavan kirjoittaja ei ole insinööri lainkaan. Tässä on kehys ja sen päälle rakennettu sisäinen taito, jotka tekevät tämän mahdolliseksi.
Asia, josta agenttialustoilla ei puhuta
LLM on kuin aivot purkissa. Yksinään se voi kirjoittaa sinulle runon tietovarastostasi, mutta ei oikeasti pääse siihen käsiksi. Se, mikä muuttaa chatbotin agentiksi – se, mistä tiimisi oikeasti maksaa – on, voiko agentti käyttää jo käyttämiäsi työkaluja ja tehdä töitä niiden sisällä.
Kutsumme tätä kykyä liitinkerrokseksi. Vuoden Zero-kehityksen jälkeen uskomme, että se on agenttituotteen tärkein infrastruktuuriosa. Siksi rakensimme oman. Vielä tärkeämpää, rakensimme sen ympärille työnkulun, jonka avulla kuka tahansa tiimissä voi tehdä liittimen.
Miksi ei MCP. Miksi ei Zapier.
Molempia kysyttiin meiltä alussa. Molemmat ovat hyviä omassa tarkoituksessaan. Kumpikaan ei ollut sitä, mitä tarvitsimme.
MCP on protokolla, ei tuote. Loistava työkalujen tekijöille, jotka haluavat palvelunsa kaikkien LLM-mallien ulottuville. Mutta MCP-palvelimet, kuten niitä nykyään käytetään, antavat mallille listan työkaluja ja luottavat siihen, että niitä käytetään turvallisesti. Ei organisaatiokohtaista tunnusvarastoa, ei palomuuria päätepisteille, ei audit-lokia, joka yhdistää kutsun valtuutettuun käyttäjään. Tuotteessa, jossa yksi agentti voi käyttää asiakkaan tuotanto-Stripeä ja toinen luonnostella sähköpostia toimitusjohtajan Gmailissa, "luota malliin" ei ole tietoturvamalli.
Zapier-tyyliset integraatioalustat ratkaisevat eri ongelman: ne yhdistävät deterministiset laukaisijat deterministisiin toimintoihin. Agentit eivät toimi näin. Agentti päättää kesken prosessin, että seuraava askel on kysellä Snowflakea ja sitten luoda Linear-tiketti. Se tarvitsee tunnuksen, rajatun HTTP-asiakkaan ja audit-jäljen heti, ei valmiina reseptinä.
Joten rakensimme tylsän ratkaisun: integraatiorekisterin, jossa jokaisella merkinnällä on tunnistautumistiedot, ympäristökartoitus siitä, mitkä salaisuudet ruiskutetaan hiekkalaatikkoon, sallittujen isäntien palomuuri ja pieni käsittelijä OAuth- tai token-erikoisuuksille. Tämä on infrastruktuuri.
Mutta infrastruktuuri ei ole tarinan kiinnostavin osa. Kiinnostavaa on se, mitä sen päälle tapahtui.
Taito, joka teki kaikista liittimen tekijöitä
Uusi SaaS päätyy integraatiojonoomme noin kahdesti päivässä. Osa tulee asiakastoiveista. Osa siitä, että tiimiläinen huomaa, ettei Zero osaa jotain tarpeellista. Osa BD-keskustelusta, jossa prospektin pinossa on meille tuntematon työkalu.
Jos jokainen näistä menisi insinöörin jonoon, julkaisisimme yhden viikossa. Nyt julkaistaan yksi päivässä.
Syy on sisäinen työkalu, jota kutsumme liittimen kirjoitustaidoksi. Se on Zero-taito, samanlainen kuin asiakkaille toimitettava, mutta suunnattu omaan koodipohjaamme. Kun kuka tahansa tiimissä sanoo "Haluan lisätä Notion-liittimen", Zero ohjaa prosessin läpi:
- Aloita käyttäjän skenaariosta. Mitä käyttäjä oikeasti haluaa tehdä tällä työkalulla? "Kysellä tietokantaa", "luoda sivu", "etsiä koko työtilasta." Taito vaatii konkreettisen käyttäjätarinan ennen kuin yhtäkään tiedostoa kosketaan. Liittimen tavoite on mahdollistaa agentin kyvykkyys, ei kääriä API:ta kattavasti.
- Tunnista tunnistautumismuoto. OAuth, API-token tai molemmat. Taito tietää, mitä kukin muoto vaatii: OAuthille suostumus-UI ja uudelleenohjaus, API-tokeneille organisaatiokohtainen salaisuuden ruiskutus ja mistä käyttäjä saa tokenin. Tekijä valitsee työkalulle sopivan muodon; kaikki muu seuraa siitä.
- Kartta päätepisteet skenaarioon. Ei "kääri koko REST APIa". Vain ne muutamat päätepisteet, jotka täyttävät käyttäjätarinan. Kolmella hyvin valitulla päätepisteellä varustettu liitin on parempi kuin neljäkymmentä, joita agentti ei koskaan käytä.
- Luo kaksitoista tiedostoa. Rekisterimerkintä, käsittelijä, palomuurikuvio, alustan ikoni, ympäristökartoitus, agentille suunnattu taito, joka opettaa Zerolle liittimen käytön. Taito kirjoittaa rungon; tekijä kirjoittaa tarkoituksen.
- Avaa kaksi PR:ää. Yksi liitinkerrokseen, yksi taitokirjastoon. Molemmat tarkistaa insinööri, mutta tarkistus koskee oikeellisuutta, ei kehyksen opettamista tekijälle.
Se, mikä ennen vaati hiljaista tietoa (mikä tunnistautumismuoto, mitkä päätepisteet, mitkä kaksitoista tiedostoa missä kahdessa repossa, miten palomuurikuvio yhdistyy dynaamiseen aliverkkotunnukseen), on nyt taidon sisällä. Tekijä tuo käyttäjäymmärryksen. Taito tuo rungon.
Näin suunnittelija, BD-vastaava tai PM päätyy julkaisemaan liittimen. He tietävät, mitä käyttäjä haluaa. Taito tietää kaiken muun.
Case: Snowflake, eilen
Eilen Anthropic esitteli sisäistä GTM-pinoaan SaaStr-lavalla: Salesforce järjestelmänä, Clay rikastukseen, LeanData reititykseen, Gong puheluihin, Jira tiketteihin, Intercom (Fin) tukeen, Ironclad sopimuksiin, Snowflake tietovarastona. [linkki esitykseen]
Yksi insinööreistämme otti kuvakaappauksen diasta ja syötti sen Zeroon yhdellä kysymyksellä: "mistä näistä meiltä puuttuu liitin?"
Tässä todellinen aikajana. Kaikki ajat PDT.
16:59. Kuvakaappaus saapuu. Zero vertaa sitä liitinkatalogiin: 7 / 10 on jo olemassa (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Kolme puuttuu (Clay, LeanData, Snowflake), ja Snowflake merkitään arvokkaimmaksi, koska tietovarasto on GTM-pinon perusta. Vastaus saapuu 17:00.
17:01. Jatkokysymys: "mitkä näistä voi tehdä api-token-liittimenä?" Zero hakee tunnistautumisohjeet: Claylla on henkilökohtainen API-avain, Snowflake julkaisi hiljattain ohjelmalliset käyttöoikeustokenit, LeanData on vain OAuth ja Salesforce-riippuvainen. Tuomio 17:02: Snowflake ensin (arvokkain, selkein tunnistautuminen), sitten Clay.
17:04. Insinööri sanoo "aloita". Liittimen kirjoitustaito ottaa työn. 17:07 mennessä se on rajannut Clayn pois (ainoa julkinen rajapinta on taulukohtaiset webhookit, ei oikeaa liitintä rakennettavaksi) ja vahvistanut Snowflaken muodon: SNOWFLAKE_PAT salaisuus + SNOWFLAKE_ACCOUNT muuttuja, bearer-tunnistautuminen Snowflaken REST APIin ja SQL API v2:een, dynaaminen aliverkkotunnus -palomuurikuvio Zendeskin malliin.
17:35. Molemmat PR:t auki saman minuutin aikana:
vm0-skills#176: agentille suunnattu taito. Miten kirjoittaa Snowflake SQL:ää, muotoilla tulokset, yrittää uudelleen tilapäisissä virheissä.vm0#13356: itse liitin. Rekisterimerkintä, PAT-käsittelijä, palomuurigeneraattori, alustan ikoni, ympäristökartoitus.
18:22. Taitoon liittyvä PR yhdistetty.
18:42. Liitin-PR yhdistetty.
18:52. Julkaisu-PR avautuu automaattisesti.
23:18. [email protected] ja muu julkaisujuna siirtyy tuotantoon. Snowflake on käytössä kaikilla organisaatioilla.
Kuusi tuntia ja yhdeksäntoista minuuttia "Anthropicin pinon kuvakaappauksesta" siihen, että "Zero voi kysellä tietovarastoasi". Yksi insinööri. Yksi keskustelu. Ei yhtään siirtoa "liitintiimille".
Tässä läpimenossa ei ole kyse insinöörin nopeudesta. Kyse on siitä, että liittimen kirjoitustaito kantoi osat, jotka ennen vaativat hiljaista tietoa: mikä tunnistautumismuoto valitaan, mitkä päätepisteet vastaavat käyttäjän skenaariota, mitkä kaksitoista tiedostoa pitää lisätä kahteen repositorioon, miten palomuurikuvio yhdistyy dynaamiseen aliverkkotunnukseen. Tekijä kirjoitti tarkoituksen. Taito kirjoitti rungon. Tuotanto hoiti loput.
Tämän kehyksen arvo ei ole vain nopeus (vaikka se on todellinen), vaan kuka voi tehdä työn. Snowflaken tekijä sattui olemaan insinööri. Hänen ei olisi tarvinnut olla.
Miksi api-token on ensiluokkainen vaihtoehto
Tämä ansaitsee oman huomionsa, koska kyseessä on tietoinen suunnitteluratkaisu, joka yllätti monet.
Useimmat agenttialustat pitävät OAuthia ainoana oikeana tunnistautumisena ja api-tokenia vanhojen työkalujen vararatkaisuna. Me teemme päinvastoin. API-tokenit ovat ensiluokkaisia liitinmallissamme: sama suostumus-UI, sama organisaatiokohtainen varastointi, sama audit-jälki, sama palomuurivalvonta.
Syitä on kaksi.
Ensimmäinen on, että api-token-tunnistautumisella pääsee nopeammin alkuun. Snowflake julkaisi ohjelmalliset käyttöoikeustokenit juuri tästä syystä: pitkäikäiset, rajattavat, peruttavat tunnukset, jotka eivät vaadi OAuth-tanssia. Käyttäjä, jolla on PAT, voi olla tuottava Zerossa alle minuutissa. OAuth-prosessi, vaikka olisi sujuva, kestää pidempään ja vaatii käyttäjältä enemmän.
Toinen on, että OAuth ei aina ole saatavilla. Jotkin yritystyökalut eivät tarjoa sitä lainkaan, tai se on vain enterprise-tason SKU:ssa. Kun api-token on tasavertainen (ei vararatkaisu), voimme tukea näitä työkaluja kunnolla sen sijaan, että ne jäisivät "tulossa pian" -hautausmaalle.
Eilen julkaistu Snowflake-liitin käyttää api-tokenia. Gmail-liitin, joka hakee asiakassähköpostit, käyttää OAuthia. Molemmat kulkevat saman kehyksen, saman taidon, saman tarkistuksen läpi. Tekijä valitsee työkalulle sopivan muodon, ja kehys tekee kummastakin helpon rakentaa.
Mitä yli 180 integraatiota oikeasti mahdollistaa
Luku itsessään ei ole tärkeä. Tärkeää on, että tällä tiheydellä agentti ei ole enää työkalu, vaan ympäristö, jossa elät.
Kun Zerolla on liittimet CRM:ään ja tietovarastoon ja tukisähköpostiin ja suunnittelutyökaluun ja repoosi, se voi tehdä asioita, joihin yksittäinen agentti ei pysty. Se voi hakea Snowflake-kyselyn, verrata sitä avoimiin Linear-tiketteihin ja postata yhteenvedon Slack-kanavalle, jossa asiakastiimi työskentelee. Se voi lukea Gong-puhelun, löytää ominaisuuden, josta prospekti kysyi, tarkistaa onko se tiekartalla ja luonnostella jatkosähköpostin – kaikki yhdellä kertaa.
Jokainen uusi liitin ei lisää arvoa lineaarisesti. Se lisää arvoa yhdistelmällisesti. 180. liitin on arvokkaampi kuin ensimmäinen, koska se yhdistyy kaikkiin 179 aiempiin.
Tämä on kehyksen perusajatus. Ja taidon perusajatus on, että yhteenlasketun arvon kasvunopeus riippuu siitä, kuinka moni tiimissäsi saa lisätä pinoon.
Mitä seuraavaksi
Työstämme liittimen kirjoitustaidon avaamista asiakkaille. Jos käytät Zeroa tiimissäsi ja tarvitset integraation sisäiseen työkaluun (laskutusjärjestelmä, tietovarasto, oma hallintapaneeli), sama työnkulku, jolla Snowflake julkaistiin eilen, on se, jolla julkaiset omasi. Sama runko, sama tunnistautumismalli, sama palomuuri, sama audit-jälki. Eri tekijä.
Jos tämä kiinnostaa, ota yhteyttä.
