Os agentes de codificação transformaram a engenharia na Stripe, mas quem não é engenheiro — como representantes de vendas, analistas de finanças, gerentes técnicos de contas e outros — ficou para trás na onda de IA de Claude Code e Codex. Nenhuma ferramenta existente conseguia lidar com os requisitos de segurança de dados e os fluxos de trabalho específicos que a Stripe precisava: consultar data warehouses, pesquisar contas antes de chamadas de vendas, fazer triagem de incidentes, modelar cenários de receita ou preparar revisões de compliance. Tudo isso mudou quando lançamos o agente de IA de conhecimento da Stripe.
GIF
Em duas semanas após o lançamento em abril, a maior parte da Stripe já estava usando a Plataforma de IA de Conhecimento da Stripe, também conhecida como Kai. Hoje, 83% são usuários ativos semanais, incluindo quase todo o GTM (marketing, vendas, gerentes de sucesso do cliente e gerentes técnicos de contas). A maioria das sessões do Kai exige muitas interações, com usuários fazendo pesquisas aprofundadas, criando artefatos específicos ou refinando materiais antes de compartilhar interna ou externamente. Com o Kai, todos na Stripe têm um agente criado especificamente para ajudar no trabalho do dia a dia.
Por que criamos uma Plataforma de IA de Conhecimento
Em tarefas de codificação, a mudança específica varia, mas o fluxo de trabalho e as ferramentas necessárias para executar a tarefa permanecem praticamente os mesmos. Você edita arquivos, executa testes e faz commit. As linguagens de programação variam, mas o formato do trabalho é bastante uniforme, e é por isso que uma arquitetura de agente único funciona bem. O trabalho de conhecimento é o lado oposto desse espectro. Tarefas como pesquisar uma conta ou preparar uma revisão de compliance exigem ferramentas diferentes, dados diferentes, resultados diferentes e definições diferentes de "pronto".
Antes do Kai, tínhamos duas opções de IA para trabalho de conhecimento:
- NoCode Agent Builder: Qualquer pessoa podia criar e implantar agentes específicos para fluxos de trabalho, capazes de usar ferramentas. Mais de 4.000 agentes foram criados usando esse sistema. No entanto, logo percebemos que os times estavam escrevendo prompts conceitualmente semelhantes, mas com níveis variados de qualidade, e a proliferação desses microagentes ficou cada vez mais difícil de monitorar e manter.
- Agentes de codificação: Os agentes de codificação eram poderosos, mas introduziam um conjunto diferente de riscos. Como nosso objetivo é permitir maior produtividade para toda a Stripe, alguns usuários alteraram seus fluxos de trabalho e optaram por agentes de codificação. No entanto, preocupações com segurança surgiram rapidamente, junto com um novo fardo de suporte para os times de qualidade de código, que nunca tinham dado suporte a não engenheiros antes.
Com essas experiências, percebemos que construir uma plataforma de IA de conhecimento exigia acertar três coisas: escalar o conhecimento especializado sem centralizá-lo, atender os usuários onde quer que trabalhem e impor guardrails que não existem no código.
Escalar o conhecimento especializado sem centralizá-lo
A amplitude do conhecimento especializado necessário para atender os usuários da Stripe é impressionante. As pessoas que sabem fazer triagem de uma escalada de cobrança ou modelar um cenário de receita não estão centralizadas e certamente não estão no time que constrói a infraestrutura de agentes. Elas estão distribuídas em dezenas de domínios especializados — GTM, Finanças, Marketing, Jurídico, Ciência de Dados e outros — cada um com suas próprias ferramentas, fontes de dados, fluxos de trabalho e critérios sobre o que é "bom". Multiplique isso por todos os produtos e países em que a Stripe opera, e o resultado é surpreendentemente complexo. O Kai precisa modelar essa complexidade de uma forma que a torne invisível, para que a tarefa simplesmente funcione.
O agente precisa circular
Onde o agente aparece importa tanto quanto o que ele sabe. Nem todo mundo trabalha em uma aba do navegador, e menos ainda em um terminal. Então, um agente de conhecimento não pode ser apenas um produto único; ele precisa ser uma plataforma, flexível o suficiente para se integrar onde quer que o trabalho aconteça.
Por exemplo, considere um aplicativo interno que o time de Finanças usa para modelar mudanças complexas no orçamento operacional da Stripe: o agente precisa ler o contexto, pesquisar documentos relacionados, propor mudanças válidas e resumir as diferenças, tudo sem tirá-los do aplicativo.
Construir um agente como produto independente não funcionaria. Em vez disso, ele forçaria os usuários a sair de seus fluxos de trabalho naturais e entrar em um novo aplicativo. Construir um produto de agente separado para cada superfície também não funcionaria; seria difícil de manter, e os usuários que usam várias ferramentas teriam uma experiência fragmentada. A plataforma precisa encontrar o usuário onde ele está.
Construindo guardrails do zero
Agentes de codificação operam em um ambiente com décadas de guardrails rápidos e verificáveis: compiladores rejeitam sintaxe inválida, testes detectam regressões e o git torna todo erro reversível. O trabalho de conhecimento tem muito pouco suporte para esses mecanismos.
Considere um invariante central na Stripe: "você não deve combinar dados de dois contextos de clientes não relacionados em uma única análise". Um usuário pode ter acesso legítimo a ambos os contextos de forma independente, mas eles nunca podem aparecer na mesma sessão. A fronteira de isolamento não é "o que essa pessoa pode acessar com base no seu token de autorização?", mas sim "o que essa tarefa deve ter permissão para visualizar dado esse contexto?" A plataforma precisa impor esses guardrails implícitos nos quais os usuários confiam.
Como construímos o Kai
Um agente monolítico único simplesmente não consegue codificar todas essas restrições de forma eficaz. E pedir que cada time de domínio construa de forma independente uma infraestrutura de agentes segura, hospedada e com bom desempenho também não escala. Para lidar com esse desafio, construímos o Kai em três camadas:
- APIs agnósticas de superfície que oferecem múltiplas interfaces para o mesmo agente
- AgentStudio, onde os responsáveis pelos domínios criam e gerenciam seus próprios agentes Kai, e
- Ambientes de execução para entregar segurança em segundos, sem que ninguém precise pensar em infraestrutura.
APIs agnósticas de superfície
O Kai acompanha um aplicativo web opinativo e uma integração com o Slack, mas a principal primitiva é a API subjacente que alimenta ambos. O agente é um serviço, não um aplicativo, e as superfícies são simplesmente visualizações personalizadas dele.
A maioria das pessoas da Stripe interage com o Kai por meio do aplicativo web hospedado internamente. Não há infraestrutura para configurar — está disponível para todos os funcionários desde o Dia 0.
Qualquer ferramenta interna também pode incorporar o Kai, e muitas optaram por fazer isso. Por exemplo, um funcionário que trabalha em nossa plataforma de business intelligence pode fazer uma pergunta ao Kai de dentro do aplicativo existente, porque nossas extensões do Chrome exibem as capacidades do Kai dentro de ferramentas de terceiros baseadas na web.
Aplicativos personalizados incorporam o Kai por meio de APIs para levar experiências com agentes a todos os fluxos de trabalho
AgentStudio
O AgentStudio é o plano de controle para os responsáveis pelos domínios. Os times o usam para criar, testar e monitorar suas skills, agentes Kai personalizados e seleções de ferramentas. Um time de GTM, por exemplo, é dono de um agente Kai ajustado para seus fluxos de trabalho. Ele carrega as skills deles por padrão, conecta-se às fontes de dados e apresenta os resultados no formato que seus usuários esperam. O AgentStudio exibe dados de uso e sinais de qualidade ao lado de cada ativo, para que os responsáveis pelos domínios vejam o que está funcionando sem precisar perguntar ao time da plataforma.
As skills são organizadas em áreas em toda a Stripe, gerenciadas por especialistas de domínio
O ambiente de execução
Esta é a camada que torna reais as promessas da plataforma. As primitivas principais, incluindo o harness do agente, sandbox, orquestração de fluxos de trabalho e a estrutura de controle de acesso, são deliberadamente compartilhadas com os agentes voltados para produtos da Stripe. O trabalho de conhecimento interno opera com os mesmos dados sensíveis e atende aos mesmos usuários que nossos produtos externos, por isso exige o mesmo nível de segurança e conformidade. Compartilhar a base exige disciplina e cria um ciclo virtuoso: melhorias no ambiente de execução beneficiam simultaneamente os agentes internos e os agentes de produto.
O harness do agente, construído com deepagents da LangChain, roda em Kubernetes com um sandbox seguro por sessão e um sistema de arquivos virtual multi-tenant. Em uma sessão, o agente trabalha com um sistema de arquivos virtual onde cria e itera sobre artefatos, enquanto um sandbox seguro de execução de código é usado para análises e processamento de dados.
Ele foi projetado para manter o estado em sessões longas e complexas — uma delas chegou recentemente a 932 interações. Com os recursos avançados de gerenciamento de tarefas do Kai, uma única conversa pode consistir em centenas de interações e centenas de chamadas de ferramentas e de LLM sem expirar ou sobrecarregar a janela de contexto. Isso é importante porque o trabalho de conhecimento raramente é uma única pergunta. É um raciocínio iterativo que se constrói sobre si mesmo, e a sessão precisa manter esse estado sem se degradar.
Os comportamentos dos usuários estão mudando, e as sessões são cada vez mais usadas para colaboração profunda com múltiplas interações
Uma das partes mais interessantes do harness é como ele escolhe a skill correta para usar. O Kai está conectado a mais de 1.000 skills e ferramentas que abrangem diversos sistemas internos — de painéis de business intelligence que acompanham métricas-chave a ferramentas de gerenciamento de projetos que organizam a execução interna e serviços de terceiros como Zoom e Google Workspace. Qualquer pessoa pode fazer uma pergunta e confiar que ele carregará o contexto certo e usará as ferramentas certas para concluir o trabalho. Agentes de codificação têm uma vantagem natural aqui: as pastas em que trabalham fornecem uma organização natural para skills e contexto. Em um post futuro, vamos detalhar como resolvemos isso sem essa estrutura preexistente, utilizando uma abordagem híbrida de RAG/LLM, entre outras técnicas.
Impacto
Os resultados têm sido impressionantes. Novos contratados no GTM já são nativos do Kai, usando-o 2,7x mais, e os usuários avançados fecham 80% mais valor do que os usuários de baixo uso na mesma coorte. Quando executivos de contas usam o Kai, eles produzem 2x mais atividade de vendas, criam 17% mais oportunidades, geram 26% mais oportunidades de receita e fecham 39% mais negócios em comparação com os mesmos vendedores nas semanas em que não o usam. No total, o Kai ajudou a realocar 25.000 horas por ano de trabalho administrativo para trabalho gerador de receita.
Em finanças e operações, o Kai está ajudando os funcionários da Stripe a analisar dados não estruturados, gerar resumos recorrentes e transformar contextos fragmentados em artefatos utilizáveis.
Em engenharia, o Kai agora é um lugar natural para fazer perguntas sobre sistemas, pesquisar para solicitações de execução (run requests), analisar logs, elaborar planos e acionar agentes e skills mais especializados.
E em toda a Stripe, mais de 5.000 sessões por dia são centradas em análise de dados. Isso torna o Kai um ponto de alavancagem único: ao fornecer o contexto certo sobre a qualidade dos dados e nossa camada de análise, podemos garantir respostas corretas por padrão para a maioria das perguntas.
O feedback direto dos funcionários da Stripe reforça esses resultados: eles relatam se sentir "capacitados para adotar a IA" e "impressionados com o que o Kai faz com tanta precisão". Mas nossa anedota favorita é a de um não engenheiro que saiu de uma sessão introdutória do Kai e imediatamente colaborou em um resumo que reúne Asana, Slack e Jira em um único processo automatizado.
Ainda não vencemos
Na Stripe, um dos nossos bordões favoritos é "ainda não vencemos", e isso se aplica bem ao Kai. Estamos nos estágios iniciais dessa jornada e temos muito mais que queremos fazer:
- Melhor gerenciamento de estado: Agentes de propósito geral como o Kai geram muito estado enquanto fazem chamadas iterativas de ferramentas, baixam documentos grandes e muito mais. Estamos continuamente ajustando tanto o contexto "ativo" enviado ao LLM quanto o contexto "estendido" armazenado em repositórios de estado como S3 ou o sistema de arquivos virtual.
- Reflexão e autoaperfeiçoamento: Estamos trabalhando em um ciclo de melhoria de qualidade que permite ao Kai refletir sobre traces envolvendo uma skill, propor melhorias, testá-las e enviar as mudanças para o responsável pela skill revisar.
- Melhores primitivas de colaboração: Os usuários geram muito contexto em suas sessões do Kai que atualmente fica "preso", mas não é assim que o trabalho é feito. Queremos permitir que as pessoas compartilhem o que o Kai apresenta entre sessões e que várias pessoas (e agentes!) colaborem nos mesmos artefatos.
Os agentes de codificação tornaram a IA algo concreto primeiro para engenheiros de software. O Kai ajudou a trazer esse mesmo senso de alavancagem para os trabalhadores do conhecimento em toda a Stripe. É interessante porque, embora tenhamos melhorado consideravelmente a produtividade, ainda não sabemos o teto — e estamos animados para continuar expandindo os limites. Se construir sistemas com agentes que impulsionam a produtividade interna e os agentes externos parece o seu tipo de desafio, estamos contratando.
