Ontem à tarde, um engenheiro da nossa equipe assistiu à Anthropic apresentar sua stack interna de GTM no palco do SaaStr, tirou um print do slide e fez ao Zero uma única pergunta: quais destes estão faltando para a gente? Seis horas e dezenove minutos depois, o Snowflake estava no ar em produção para todos os clientes do Zero. Foi a 180ª e tantas integração que entregamos em um ano e, cada vez mais, quem escreve a próxima não é um engenheiro. Aqui está o framework, e a skill interna por cima dele, que tornam isso possível.
O que ninguém te conta sobre plataformas de agentes
Um LLM é um cérebro num pote. Sozinho, ele pode escrever um poema sobre o seu data warehouse, mas não consegue de fato abri-lo. O que transforma um chatbot em um agente, aquilo pelo que a sua equipe realmente paga, é se o agente consegue alcançar as ferramentas que você já usa e fazer trabalho nelas.
Chamamos esse alcance de camada de conectores. Depois de um ano construindo o Zero, acreditamos que ela é a peça de infraestrutura mais importante de um produto de agentes. Então construímos a nossa. Mais importante: construímos um fluxo de trabalho em torno dela que permite que qualquer pessoa da equipe escreva uma.
Por que não MCP. Por que não Zapier.
Os dois nos foram sugeridos cedo. Ambos são bons no que são. Nenhum dos dois era o que precisávamos.
O MCP é um protocolo, não um produto. Genial para autores de ferramentas que querem que seu serviço seja alcançável por qualquer LLM. Mas os servidores MCP, como implantados hoje, entregam ao modelo uma lista de ferramentas e confiam que ele as chame com segurança. Não há cofre de credenciais por organização, nem firewall sobre quais endpoints podem ser acessados, nem log de auditoria que ligue uma chamada de volta a um humano que a autorizou. Para um produto em que um agente pode tocar o Stripe de produção de um cliente e outro pode redigir um e-mail no Gmail do CEO dele, "confie no modelo" não é um modelo de segurança.
As plataformas de integração no estilo Zapier resolvem um problema diferente: elas conectam gatilhos determinísticos a ações determinísticas. Agentes não funcionam assim. Um agente decide, no meio do raciocínio, que o próximo passo é consultar o Snowflake e depois criar um ticket no Linear. Ele precisa de uma credencial, de um cliente HTTP com escopo e de uma trilha de auditoria agora, não como uma receita pré-montada.
Então construímos a coisa sem graça: um registro de integrações em que cada entrada carrega metadados de autenticação, um mapeamento de ambiente sobre quais segredos são injetados no sandbox, um firewall de hosts permitidos e um pequeno handler para as peculiaridades de OAuth ou tokens. Essa é a infraestrutura.
Mas a infraestrutura não é a parte interessante da história. A parte interessante é o que aconteceu por cima dela.
A skill que transformou todo mundo em autor de conectores
Um novo SaaS cai no nosso backlog de integrações cerca de duas vezes por dia. Alguns vêm de pedidos de clientes. Outros, de alguém da equipe notando que o Zero não consegue fazer algo de que precisa. Outros, de uma conversa de BD em que a stack de um prospect inclui uma ferramenta que ainda não conhecíamos.
Se cada um deles tivesse que passar pela fila de um engenheiro, entregaríamos um por semana. Entregamos um por dia.
A razão é uma ferramenta interna que chamamos de skill de autoria de conectores. É uma skill do Zero, do mesmo formato que entregamos aos clientes, mas voltada para dentro, para a nossa própria base de código. Quando alguém da equipe diz "quero adicionar o conector do Notion", o Zero o conduz pelo processo:
- Comece pelo cenário do usuário. O que o usuário de fato quer fazer com essa ferramenta? "Consultar um banco de dados", "criar uma página", "buscar em todo o workspace". A skill insiste em uma história de usuário concreta antes de tocar em um único arquivo. O objetivo de um conector é habilitar uma capacidade do agente, não embrulhar exaustivamente uma API.
- Identifique o formato de autenticação. OAuth, token de API ou ambos. A skill sabe o que cada formato implica: para OAuth, a UI de consentimento e a fiação de redirecionamento; para tokens de API, a injeção de segredo por organização e onde o usuário obtém o token. O autor escolhe o formato que combina com a ferramenta; tudo a jusante decorre disso.
- Mapeie os endpoints para o cenário. Não "embrulhe a API REST inteira". Apenas o punhado de endpoints que satisfazem a história do usuário. Um conector com três endpoints bem escolhidos vale mais do que um com quarenta que o agente nunca usa.
- Monte a estrutura dos doze arquivos. Entrada no registro, handler, padrão de firewall, ícone da plataforma, fiação de mapeamento de ambiente, a skill voltada ao agente que ensina o Zero a usar o conector. A skill escreve a estrutura; o autor escreve a intenção.
- Abra os dois PRs. Um para o framework de conectores, outro para a biblioteca de skills. Ambos são revisados por um engenheiro, mas a revisão é sobre correção, não sobre ensinar ao autor como o framework funciona.
O que antes exigia conhecimento institucional (qual formato de autenticação, quais endpoints, quais doze arquivos em quais dois repositórios, como o padrão de firewall se compõe com um subdomínio dinâmico) agora é carregado pela própria skill. O autor traz a empatia com o usuário. A skill traz a estrutura.
É assim que um designer, um líder de BD ou um PM acaba entregando um conector. Eles sabem o que o usuário quer. A skill sabe todo o resto.
O estudo de caso: Snowflake, ontem
Ontem a Anthropic apresentou sua stack interna de GTM no palco do SaaStr: Salesforce como sistema de registro, Clay para enriquecimento, LeanData para roteamento, Gong para chamadas, Jira para tickets, Intercom (Fin) para suporte, Ironclad para contratos, Snowflake como data warehouse. [link para a palestra]
Um dos nossos engenheiros tirou um print do slide e o jogou no Zero com uma única pergunta: "para quais destes estamos sem conector?"
Aqui está a linha do tempo real do que se seguiu. Todos os horários em PDT.
16:59. O print chega. O Zero o compara com o catálogo de conectores: 7 dos 10 já existem (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Três estão faltando (Clay, LeanData, Snowflake), e o Snowflake é sinalizado como o mais valioso, já que um data warehouse é a base da stack de GTM. A resposta chega às 17:00.
17:01. Acompanhamento: "quais destes dá para fazer como conector de token de API?" O Zero busca a documentação de autenticação: a Clay tem uma chave de API pessoal, o Snowflake lançou recentemente os Programmatic Access Tokens, a LeanData é só OAuth e atrelada ao Salesforce. Veredito às 17:02: Snowflake primeiro (maior valor, autenticação mais limpa), depois Clay.
17:04. O engenheiro diz "vai". A skill de autoria de conectores assume. Às 17:07 ela já descartou a Clay (a única superfície pública são webhooks por tabela, não há conector real a construir) e confirmou o formato do Snowflake: segredo SNOWFLAKE_PAT + variável SNOWFLAKE_ACCOUNT, autenticação bearer contra a Snowflake REST API e a SQL API v2, padrão de firewall de subdomínio dinâmico modelado no Zendesk.
17:35. Os dois PRs abertos no mesmo minuto:
vm0-skills#176: a skill voltada ao agente. Como escrever SQL do Snowflake, formatar resultados, repetir em erros transitórios.vm0#13356: o conector em si. Entrada no registro, handler de PAT, gerador de firewall, ícone da plataforma, fiação de mapeamento de ambiente.
18:22. PR da skill com merge.
18:42. PR do conector com merge.
18:52. O PR de release abre automaticamente.
23:18. O web@v12.369.0 e o resto do trem de release vão para produção. O Snowflake está no ar para todas as organizações.
Seis horas e dezenove minutos do "print da stack da Anthropic" ao "o Zero consegue consultar seu warehouse". Um engenheiro. Uma conversa. Zero repasses para um "time de conectores".
A vazão aqui não vem de o engenheiro ser rápido. Vem de a skill de autoria de conectores ter carregado as partes que antes exigiam conhecimento institucional: qual formato de autenticação escolher, quais endpoints mapeiam para o cenário do usuário, quais doze arquivos precisam cair em quais dois repositórios, como o padrão de firewall se compõe com um subdomínio dinâmico. O autor escreveu a intenção. A skill escreveu a estrutura. A produção fez o resto.
É isso que o framework nos compra. Não só velocidade (embora a velocidade seja real), mas quem pode assumir o trabalho. O autor do Snowflake por acaso era um engenheiro. Ele não precisava ser.
Por que o token de API é cidadão de primeira classe
Uma nota de rodapé que vale destacar, porque é uma escolha de design deliberada que surpreendeu as pessoas.
A maioria das plataformas de agentes trata o OAuth como a Única Autenticação Verdadeira e o token de API como um plano B para ferramentas legadas. Nós fazemos o oposto. Os tokens de API são cidadãos de primeira classe no nosso modelo de conectores, com a mesma UI de consentimento, o mesmo cofre por organização, a mesma trilha de auditoria, a mesma aplicação de firewall.
Há duas razões.
A primeira é que a autenticação por token de API tem um tempo até o primeiro uso mais curto. O Snowflake lançou recentemente os Programmatic Access Tokens exatamente por isso: credenciais de vida longa, com escopo e revogáveis, que não exigem a dança do OAuth. Um usuário com um PAT pode ser produtivo no Zero em menos de um minuto. Um fluxo de OAuth, mesmo um limpo, leva mais tempo e exige mais do usuário.
A segunda é que o OAuth nem sempre está disponível. Algumas ferramentas corporativas simplesmente não oferecem um, ou oferecem um que fica atrás de um SKU corporativo. Tratar o token de API como par (e não como plano B) significa que podemos dar suporte adequado a essas ferramentas em vez de deixá-las num cemitério de "em breve".
O conector do Snowflake que entrou no ar ontem usa token de API. O conector do Gmail que traz as threads de e-mail dos clientes usa OAuth. Os dois passam pelo mesmo framework, a mesma skill, a mesma revisão. O autor escolhe o formato que combina com a ferramenta, e o framework torna qualquer um dos dois barato de construir.
O que 180 e tantas integrações de fato destravam
O número em si não é o ponto. O ponto é que nessa densidade, o agente deixa de ser uma ferramenta que você invoca e passa a ser um ambiente em que você vive.
Quando o Zero tem conectores para o seu CRM e o seu data warehouse e a sua caixa de suporte e a sua ferramenta de design e o seu repositório, ele consegue fazer coisas que nenhum agente de integração única consegue. Ele pode puxar uma consulta do Snowflake, cruzá-la com tickets abertos no Linear e postar um resumo no canal do Slack onde vive o time de customer success. Ele pode ler uma chamada do Gong, encontrar o recurso sobre o qual o prospect perguntou, verificar se está no roadmap e redigir o e-mail de acompanhamento, tudo num só movimento.
Cada novo conector não agrega valor linearmente. Ele agrega valor de forma combinatória. O 180º conector vale mais do que o 1º, porque ele se compõe com os 179 que vieram antes.
Essa é a aposta por trás do framework. E a aposta por trás da skill é que a velocidade do efeito composto depende de quantas pessoas da sua equipe têm permissão para somar à pilha.
O que vem a seguir
Estamos trabalhando para abrir a skill de autoria de conectores aos clientes. Se você roda o Zero para a sua equipe e há uma ferramenta interna para a qual precisa de uma integração (seu sistema de cobrança, seu warehouse, seu painel administrativo interno customizado), o mesmo fluxo de trabalho que entregou o Snowflake ontem será o que você usará para entregar o seu. Mesma estrutura, mesmo modelo de autenticação, mesmo firewall, mesma trilha de auditoria. Autor diferente.
Se isso te interessa, adoraríamos conversar.
