Como a Stripe construiu o próprio cérebro de IA da empresa, o agente Kai

A pergunta que abre praticamente todo projeto de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → corporativa hoje é a mais chata possível: construir ou comprar? A Stripe respondeu construir, e o resultado é o Kai, agente interno usado por mais de 10 mil funcionários toda semana. Em episódio do podcast How I AI, de Claire Vo, Sharadh Krishnamurthy, engineering manager↳Liderança técnica5 conteúdosLiderança técnica: a arte de inspirar desenvolvedores e gerar transformações 🚀Gestão Dev & TI · mai 2024Full Cycle lança pós-graduação que capacita devs para cargos de liderança técnicaDev (Back & Front) · mar 2024De Dev a Tech Leader: caminhos para se tornar um Tech Leader excepcionalGestão Dev & TI · ago 2024Ver tudo em Gestão Dev & TI → da Stripe, abriu a caixa: o que pesou na decisão, como a governança foi desenhada e o que quase derrubou sistemas de produção no caminho.

O ângulo que interessa para quem constrói infra não é o hype do agente. É que a Stripe tratou IA interna como um problema de plataforma, não de ferramenta. E boa parte da resposta já estava construída antes de o Kai existir.

Por que construir em vez de comprar

A decisão de fazer do zero costuma soar como orgulho de engenharia (o clássico "not invented here"). No relato de Sharadh, o que virou a chave foi contexto. Um agente comprado sabe usar ferramentas genéricas; ele não sabe o que é um "pagamento em disputa" no vocabulário interno da Stripe, quais tabelas contêm dado sensível, ou quem tem permissão para consultar o quê. Esse contexto corporativo é justamente o que não vem na caixa.

O ponto central da entrevista, e o que mais vale para um time técnico brasileiro, é este: a infraestrutura que a Stripe já tinha construído para desenvolvedores humanos acabou sendo exatamente o que os agentes precisavam. Camada de dados consultável com controle de acesso, sandbox seguro, catálogo de ferramentas com permissões. Nada disso foi criado para IA. Foi criado para gente, e o agente entrou como só mais um consumidor dessas APIs internas.

A leitura que fica: se a sua empresa já investiu em developer experience decente (data layer governado, ambientes isolados, identidade e permissão bem resolvidas), você está mais perto de um agente corporativo seguro do que imagina. Se não investiu, comprar um agente pronto não resolve, porque o buraco está embaixo dele.

Projetos como camada de governança, não pasta

O detalhe de design mais interessante é o conceito de "projects". Na maioria das ferramentas, um projeto é uma pasta: uma forma de organizar conversas. Na Stripe, projeto é um mecanismo de governança. Ele define o escopo de dados, ferramentas e permissões a que o agente tem acesso dentro daquele contexto de trabalho.

É uma inversão importante. Em vez de dar ao agente acesso irrestrito e torcer para que ele se comporte, o projeto funciona como uma fronteira: dentro dele, o Kai só enxerga o que aquele contexto autoriza. Isso muda o modelo mental de segurança de "filtrar a saída do modelo" para "restringir o que ele pode alcançar em primeiro lugar". Para quem lida com dado sensível (e pagamentos são o caso extremo), essa é a diferença entre um piloto e algo que roda em produção.

O Kai também carrega, por padrão, contexto sobre o próprio usuário: quem você é, seu time, seu histórico. Sharadh faz questão de separar o que o agente sabe por default do que o funcionário controla e pode desligar, um reconhecimento de que contexto útil e vigilância são a mesma tecnologia com governança diferente.

A camada de dados: Trino e consulta segura em escala

Para os agentes consultarem dados sem virar risco, a Stripe apoiou-se em uma camada de dados estruturada. A entrevista cita o Trino (o engine de query distribuída, ex-PrestoSQL) entre as ferramentas de referência. A ideia é que o agente não fale direto com bancos de produção, e sim com uma camada de consulta que já carrega as regras de acesso.

Isso resolve dois problemas de uma vez. O óbvio é segurança: o agente não consegue ler o que não deveria. O menos óbvio é carga: um agente que dispara queries pesadas sem noção de custo pode degradar um sistema que atende pagamentos reais. Sharadh menciona explicitamente load shedding (descarte de carga sob pressão) e o episódio em que agentes quase derrubaram sistemas de produção, o que empurrou o time a tratar o agente como um cliente de infra que precisa de rate limiting e circuit breakers como qualquer outro serviço.

A leitura que fica desse trecho da conversa: agentes que rodam com autonomia precisam de identidade própria e limites de carga, ou eventualmente encostam num sistema crítico.

Aqui entra o conceito de identidade agêntica (agentic identity): o agente age em nome de alguém, mas precisa de uma identidade rastreável para que se saiba o que ele fez, com que permissão, e para cortar acesso se sair do controle. É o mesmo princípio de service account, aplicado a algo que toma decisões.

Skills: quando qualquer um empacota um workflow

A parte mais escalável do Kai é a plataforma de skills. Uma skill é um workflow empacotado: um funcionário descreve um processo repetitivo (gerar um relatório, montar um dashboard, checar um status) e transforma isso em algo reutilizável por toda a empresa. Segundo a entrevista, a Stripe chegou a cerca de 2.000 skills.

Esse número traz o problema real de qualquer marketplace interno: qualidade. Duas mil skills criadas por gente de todos os níveis técnicos incluem, inevitavelmente, muita coisa quebrada, redundante ou perigosa. A resposta da Stripe combina evals (avaliações automatizadas da qualidade da skill) e telemetria para saber quais são de fato usadas e quais funcionam. Sem isso, a plataforma de skills vira um cemitério de automações que ninguém confia.

Para um time menor no Brasil, a lição não é "tenha 2.000 skills". É que o problema de escala não é criar automações, é curá-las. No momento em que qualquer pessoa pode empacotar um workflow, você precisa de um mecanismo de avaliação contínua, ou a plataforma perde credibilidade na primeira skill que dá resultado errado.

O que dá pra levar (e o que não)

O caminho da Stripe é sedutor, mas caro. Construir do zero só faz sentido quando três condições se somam: você tem contexto corporativo que nenhuma ferramenta de mercado captura, já tem infra de dados e permissão madura para reaproveitar, e tem escala (10 mil pessoas) que justifica o investimento. Faltando qualquer um dos três, comprar e integrar tende a ser mais racional.

O que é transferível independentemente de tamanho:

• Governança na entrada, não na saída. Restrinja o que o agente pode alcançar (o modelo de "projects"), em vez de tentar filtrar tudo que ele produz.
• Trate o agente como cliente de infra. Identidade própria, rate limiting, load shedding. Ele vai encostar em produção, então planeje para isso antes.
• Reaproveite a camada de dados governada. Se o agente consulta dados via uma engine com controle de acesso (Trino ou equivalente), você ganha segurança e controle de carga de brinde.
• Curadoria de skills é infra, não faxina. Evals e telemetria desde o começo, senão a plataforma apodrece.

A pergunta boa para levar ao próprio produto: se um agente autônomo tivesse as mesmas permissões que meu desenvolvedor médio, o que ele conseguiria derrubar? A resposta define o quanto de governança você precisa construir antes de soltar qualquer IA em produção.

O episódio completo, com demo ao vivo do Kai montando um dashboard, está disponível no YouTube, Spotify e Apple Podcasts pela newsletter da Lenny.

Fonte: Lenny's Newsletter