Včera odpoledne jeden z našich inženýrů sledoval na SaaStr pódiu prezentaci Anthropic o jejich interním GTM stacku, udělal screenshot slidu a položil Zero jedinou otázku: které z těchto nám chybí? O šest hodin a devatenáct minut později byl Snowflake nasazen v produkci pro všechny zákazníky Zero. Byla to 180-tá integrace, kterou jsme za rok spustili, a čím dál častěji už další nepíše inženýr. Tady je rámec a interní skill, který to umožňuje.
Co vám o agentních platformách nikdo neřekne
LLM je mozek ve sklenici. Sám o sobě vám napíše báseň o vašem datovém skladu, ale nedokáže ho skutečně otevřít. To, co z chatbota dělá agenta, za co váš tým skutečně platí, je, jestli agent dokáže sáhnout do nástrojů, které už používáte, a vykonat v nich práci.
Tomuto dosahu říkáme vrstva konektorů. Po roce vývoje Zero věříme, že je to nejdůležitější část infrastruktury v agentním produktu. Proto jsme si ji postavili sami. Ještě důležitější ale je, že jsme kolem ní vytvořili workflow, které umožňuje komukoliv v týmu stát se autorem konektoru.
Proč ne MCP. Proč ne Zapier.
Obě otázky jsme dostali brzy. Obě řešení jsou dobrá pro svůj účel. Ani jedno ale nebylo to, co jsme potřebovali.
MCP je protokol, ne produkt. Skvělý pro autory nástrojů, kteří chtějí, aby jejich služba byla dosažitelná jakýmkoliv LLM. Ale MCP servery, jak jsou dnes nasazeny, předají modelu seznam nástrojů a věří, že je zavolá bezpečně. Není zde trezor přihlašovacích údajů pro každou organizaci, žádný firewall na povolené endpointy, žádný audit log, který by volání svázal s člověkem, jenž ho autorizoval. Pro produkt, kde jeden agent může zasahovat do produkčního Stripe zákazníka a jiný psát e-mail v Gmailu CEO, "věřit modelu" není bezpečnostní model.
Platformy typu Zapier řeší jiný problém: propojují deterministické spouštěče s deterministickými akcemi. Agenti takto nefungují. Agent se v průběhu rozhodování rozhodne, že dalším krokem je dotaz na Snowflake a pak vytvoření ticketu v Linear. Potřebuje přihlašovací údaje, omezeného HTTP klienta a auditní stopu hned, ne jako předpřipravený recept.
Tak jsme postavili tu nudnou věc: registr integrací, kde každý záznam nese metadata pro autentizaci, mapování prostředí, které tajemství se vkládají do sandboxu, firewall povolených hostitelů a malý handler pro zvláštnosti OAuth nebo tokenů. To je infrastruktura.
Ale infrastruktura není to zajímavé. Zajímavé je, co se stalo nad ní.
Skill, který z každého udělal autora konektoru
Nové SaaS se v našem backlogu integrací objeví zhruba dvakrát denně. Některé přicházejí od zákazníků. Některé od kolegů, kteří si všimli, že Zero něco neumí. Některé z BD rozhovorů, kde má potenciální zákazník ve stacku nástroj, který ještě neznáme.
Kdyby každý z nich musel projít frontou inženýra, vydali bychom jednu týdně. My vydáváme jednu denně.
Důvodem je interní nástroj, který nazýváme skill pro tvorbu konektorů. Je to Zero skill, stejný typ, jaký dodáváme zákazníkům, ale zaměřený dovnitř na naši vlastní codebase. Když kdokoliv v týmu řekne "chci přidat Notion konektor", Zero ho tím provede:
- Začněte od uživatelského scénáře. Co vlastně uživatel chce s tímto nástrojem dělat? "Dotazovat databázi," "vytvořit stránku," "prohledat workspace." Skill trvá na konkrétním uživatelském příběhu dřív, než se dotkne jediného souboru. Cílem konektoru je umožnit schopnost agenta, ne kompletně obalit API.
- Určete typ autentizace. OAuth, API token nebo obojí. Skill ví, co každý typ znamená: pro OAuth UI souhlasu a přesměrování; pro API tokeny vkládání tajemství pro každou organizaci a kde uživatel token získá. Autor vybere typ, který odpovídá nástroji; vše ostatní se odvíjí odtud.
- Namapujte endpointy na scénář. Ne "obalit celé REST API." Jen několik endpointů, které naplní uživatelský příběh. Konektor se třemi dobře zvolenými endpointy je lepší než ten se čtyřiceti, které agent nikdy nepoužije.
- Vytvořte dvanáct souborů. Záznam v registru, handler, firewall pattern, ikona platformy, napojení na proměnné prostředí, skill pro agenta, který učí Zero, jak konektor používat. Skill vytvoří kostru; autor napíše záměr.
- Otevřete dva PR. Jeden do frameworku konektorů, druhý do knihovny skillů. Oba zkontroluje inženýr, ale kontrola je o správnosti, ne o tom, jak framework funguje.
Co dříve vyžadovalo institucionální znalost (jaký typ autentizace, které endpointy, kterých dvanáct souborů ve kterých dvou repozitářích, jak firewall pattern skloubit s dynamickou subdoménou), nyní nese samotný skill. Autor přináší empatii k uživateli. Skill přináší kostru.
Takto designer, BD lead nebo PM nakonec vydá konektor. Vědí, co uživatel chce. Skill ví vše ostatní.
Případová studie: Snowflake, včera
Včera Anthropic prezentoval svůj interní GTM stack na SaaStr: Salesforce jako systém záznamu, Clay pro obohacení, LeanData pro směrování, Gong pro hovory, Jira pro tickety, Intercom (Fin) pro podporu, Ironclad pro smlouvy, Snowflake jako datový sklad. [odkaz na přednášku]
Jeden z našich inženýrů udělal screenshot slidu a vložil ho do Zero s jedinou otázkou: "na které z těchto nám chybí konektor?"
Tady je skutečná časová osa. Všechny časy PDT.
16:59. Screenshot dorazí. Zero ho porovná s katalogem konektorů: 7 z 10 už existuje (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Tři chybí (Clay, LeanData, Snowflake) a Snowflake je označen jako nejhodnotnější, protože datový sklad je základem GTM stacku. Odpověď dorazí v 17:00.
17:01. Následuje: "které z těchto lze udělat jako api-token konektor?" Zero vytáhne dokumentaci k autentizaci: Clay má osobní API klíč, Snowflake nedávno zavedl Programmatic Access Tokens, LeanData je pouze OAuth a navázaný na Salesforce. Verdikt v 17:02: nejdřív Snowflake (nejvyšší hodnota, nejčistší autentizace), pak Clay.
17:04. Inženýr říká "jdeme na to." Skill pro tvorbu konektoru to převezme. Do 17:07 vyřadí Clay (jediné veřejné rozhraní jsou webhooky na tabulku, skutečný konektor nejde postavit) a potvrdí tvar Snowflake: SNOWFLAKE_PAT tajemství + SNOWFLAKE_ACCOUNT proměnná, bearer autentizace vůči Snowflake REST API a SQL API v2, firewall pattern s dynamickou subdoménou podle Zendesk.
17:35. Oba PR otevřeny ve stejnou minutu:
vm0-skills#176: skill pro agenta. Jak psát Snowflake SQL, formátovat výsledky, opakovat při dočasných chybách.vm0#13356: samotný konektor. Záznam v registru, handler pro PAT, generátor firewallu, ikona platformy, napojení na proměnné prostředí.
18:22. Skill PR sloučen.
18:42. Konektor PR sloučen.
18:52. Release PR se automaticky otevře.
23:18. [email protected] a zbytek release vlaku nasazen do produkce. Snowflake je dostupný pro každou organizaci.
Šest hodin a devatenáct minut od "screenshotu stacku Anthropic" po "Zero umí dotazovat váš sklad". Jeden inženýr. Jeden rozhovor. Žádné předávání "týmu konektorů".
Tato rychlost není díky tomu, že je inženýr rychlý. Je to proto, že skill pro tvorbu konektoru nesl části, které dříve vyžadovaly institucionální znalost: jaký typ autentizace zvolit, které endpointy odpovídají scénáři, které dvanáct souborů musí být ve kterých dvou repozitářích, jak firewall pattern skloubit s dynamickou subdoménou. Autor napsal záměr. Skill napsal kostru. Produkce udělala zbytek.
Tohle nám framework přináší. Nejen rychlost (i když ta je skutečná), ale kdo může práci udělat. Autor Snowflake byl náhodou inženýr. Nemusel být.
Proč je api-token rovnocenný občan
Poznámka na okraj, protože je to záměrné rozhodnutí, které některé překvapilo.
Většina agentních platforem považuje OAuth za jedinou správnou autentizaci a api-token za zálohu pro starší nástroje. My to děláme naopak. API tokeny jsou v našem modelu konektorů rovnocenné, se stejným UI souhlasu, stejným trezorem pro každou organizaci, stejnou auditní stopou, stejným vynucením firewallu.
Důvody jsou dva.
První je, že api-token autentizace má kratší čas do prvního použití. Snowflake nedávno zavedl Programmatic Access Tokens právě z tohoto důvodu: dlouhodobé, omezitelné, odvolatelné přihlašovací údaje, které nevyžadují OAuth proces. Uživatel s PAT může být v Zero produktivní za méně než minutu. OAuth flow, i když je čistý, trvá déle a od uživatele vyžaduje víc.
Druhý je, že OAuth není vždy dostupný. Některé podnikové nástroje ho prostě nenabízí, nebo je dostupný jen v enterprise verzi. Když je api-token rovnocenný (ne záložní), můžeme tyto nástroje podporovat správně, místo abychom je nechali v "již brzy" hrobě.
Snowflake konektor, který včera vznikl, je api-token. Gmail konektor, který zpracovává zákaznické e-maily, je OAuth. Oba procházejí stejným frameworkem, stejným skillem, stejnou kontrolou. Autor zvolí typ, který odpovídá nástroji, a framework umožní snadnou tvorbu obou.
Co 180-tá integrace skutečně odemyká
Samotné číslo není podstatné. Podstatné je, že při této hustotě přestává být agent nástrojem, který si vyvoláte, a stává se prostředím, ve kterém žijete.
Když má Zero konektory na vaše CRM i datový sklad i podporu i designový nástroj i repozitář, dokáže věci, které žádný agent s jednou integrací neumí. Umí stáhnout dotaz ze Snowflake, porovnat ho s otevřenými tickety v Linear a poslat shrnutí do Slack kanálu, kde sídlí tým zákaznického úspěchu. Umí přečíst hovor z Gongu, najít požadovanou funkci, ověřit, zda je v roadmapě, a připravit follow-up e-mail, vše najednou.
Každý nový konektor nepřidává hodnotu lineárně. Přidává ji kombinatoricky. 180. konektor je cennější než první, protože se skládá s těmi 179 předchozími.
To je sázka frameworku. A sázka skillu je, že rychlost skládání závisí na tom, kolik lidí ve vašem týmu může přidávat další.
Co bude dál
Pracujeme na zpřístupnění skillu pro tvorbu konektorů zákazníkům. Pokud používáte Zero ve svém týmu a potřebujete integraci na interní nástroj (fakturační systém, sklad, vlastní admin panel), stejný workflow, který včera vytvořil Snowflake, bude workflow, kterým vytvoříte svůj. Stejná kostra, stejný model autentizace, stejný firewall, stejná auditní stopa. Jiný autor.
Pokud vás to zajímá, ozvěte se nám.
