Los agentes de codificación transformaron la ingeniería en Stripe, pero los no ingenieros, como representantes de ventas, analistas financieros, gerentes técnicos de cuentas y otros, se sintieron rezagados ante la ola de IA de Claude Code y Codex. Ninguna herramienta existente podía manejar los requisitos de seguridad de datos y los flujos de trabajo específicos que Stripe necesitaba: consultar almacenes de datos, investigar cuentas antes de llamadas de ventas, priorizar incidentes, modelar escenarios de ingresos o preparar revisiones de cumplimiento. Todo eso cambió cuando lanzamos el agente de IA de conocimiento de Stripe.
GIF
A las dos semanas de nuestro lanzamiento en abril, la mayor parte de Stripe ya usaba la Plataforma de IA de Conocimiento de Stripe, también conocida como Kai. Hoy, el 83% son usuarios activos semanales, incluidos casi todos los equipos de GTM (marketing, ventas, gerentes de éxito del cliente y gerentes técnicos de cuentas). La mayoría de las sesiones de Kai requieren muchos turnos, ya que los usuarios hacen investigación profunda, crean artefactos específicos o refinan recursos antes de compartirlos interna o externamente. Con Kai, todos en Stripe tienen un agente creado específicamente para ayudarles en su trabajo diario.
Por qué creamos una Plataforma de IA de Conocimiento
Para las tareas de codificación, el cambio específico varía, pero el flujo de trabajo y las herramientas necesarias para realizar la tarea se mantienen más o menos iguales. Editas archivos, ejecutas pruebas, haces commit. Los lenguajes de programación varían, pero la forma del trabajo es bastante uniforme, por eso una arquitectura de agente único funciona bien. El trabajo de conocimiento es el lado opuesto de ese espectro. Tareas como investigar una cuenta o preparar una revisión de cumplimiento requieren diferentes herramientas, diferentes datos, diferentes resultados y diferentes definiciones de "terminado".
Antes de Kai, teníamos dos opciones de IA para el trabajo de conocimiento:
- Constructor de Agentes NoCode: Cualquiera podía crear e implementar agentes específicos para flujos de trabajo que pudieran usar herramientas. Se construyeron más de 4,000 agentes con este sistema. Sin embargo, rápidamente notamos que los equipos escribían prompts conceptualmente similares pero con niveles de calidad variables, y la proliferación de estos micro-agentes se volvió cada vez más difícil de monitorear y mantener.
- Agentes de codificación: Los agentes de codificación eran poderosos, pero introdujeron un conjunto diferente de riesgos. Dado que nuestro objetivo es habilitar una mayor productividad para toda Stripe, algunos usuarios alteraron sus flujos de trabajo y eligieron agentes de codificación. Sin embargo, pronto surgieron preocupaciones de seguridad, junto con una nueva carga de soporte para los equipos de calidad de código que nunca habían dado soporte a no ingenieros antes.
A partir de estas experiencias, nos dimos cuenta de que construir una plataforma de IA de conocimiento requería hacer bien tres cosas: escalar la experiencia sin centralizarla, encontrar a los usuarios dondequiera que trabajen y aplicar salvaguardas que no existen en el código.
Escalar la experiencia sin centralizarla
El nivel de experiencia necesario para atender a los usuarios de Stripe es asombroso. Las personas que saben cómo priorizar una escalación de facturación o modelar un escenario de ingresos no están centralizadas y ciertamente no están en el equipo que construye la infraestructura de agentes. Están distribuidas en decenas de dominios especializados (GTM, Finanzas, Marketing, Legal, Ciencia de Datos y más), cada uno con sus propias herramientas, fuentes de datos, flujos de trabajo y criterio sobre cómo se ve algo "bien". Multiplica esto por todos los productos y países en los que Stripe opera, y el resultado es asombrosamente complejo. Kai tiene que modelar esa complejidad de una manera que la haga invisible, para que la tarea simplemente funcione.
El agente tiene que moverse
El lugar donde el agente aparece importa tanto como lo que sabe. No todos trabajan en una pestaña del navegador, y muchos menos en una terminal. Por eso, un agente de conocimiento no puede ser solo un producto único; tiene que ser una plataforma, lo suficientemente flexible como para integrarse dondequiera que ocurra el trabajo.
Por ejemplo, considera una aplicación interna que nuestro equipo de Finanzas usa para modelar cambios complejos en el presupuesto operativo de Stripe: el agente necesita leer el contexto, investigar documentos relacionados, proponer cambios válidos y resumir las diferencias, todo sin sacar a los usuarios de la aplicación.
Construir un producto de agente independiente no funcionaría. Obligaría a los usuarios a salir de sus flujos de trabajo naturales y entrar a una nueva aplicación. Tampoco funcionaría construir un producto de agente separado para cada superficie; sería difícil de mantener, y los usuarios que utilizan múltiples herramientas tendrían una experiencia fragmentada. La plataforma tiene que encontrar al usuario donde está.
Construir salvaguardas desde cero
Los agentes de codificación operan en un entorno con décadas de salvaguardas rápidas y verificables: los compiladores rechazan sintaxis inválida, las pruebas detectan regresiones y git hace que cada error sea reversible. El trabajo de conocimiento tiene muy poco soporte para estos mecanismos.
Considera un invariante central en Stripe: "no deberías combinar datos de dos contextos de clientes no relacionados en un solo análisis". Un usuario puede tener acceso legítimo a ambos contextos de forma independiente, pero nunca pueden aparecer en la misma sesión. El límite de aislamiento no es "¿a qué puede acceder esta persona según su token de autorización?", sino "¿qué debería poder ver esta tarea dado este contexto?" La plataforma tiene que hacer cumplir estas salvaguardas implícitas en las que los usuarios confían.
Cómo construimos Kai
Un agente monolítico simplemente no puede codificar todas estas restricciones de manera efectiva. Y pedirle a cada equipo de dominio que construya de forma independiente una infraestructura de agentes segura, alojada y de alto rendimiento tampoco escala. Para gestionar este desafío, construimos Kai en tres capas:
- APIs independientes de la superficie que ofrecen múltiples interfaces hacia el mismo agente
- AgentStudio donde los dueños de dominio construyen y gobiernan sus propios agentes Kai, y
- Entornos de ejecución que brindan seguridad en segundos sin que nadie tenga que pensar en la infraestructura.
APIs independientes de la superficie
Kai incluye una aplicación web con un enfoque definido y una integración con Slack, pero la primitiva principal es la API subyacente que impulsa a ambas. El agente es un servicio, no una aplicación, y las superficies son simplemente vistas personalizadas de ese servicio.
La mayoría de los Stripes interactúan con Kai a través de la aplicación web alojada internamente. No hay infraestructura que configurar: está disponible para cada empleado desde el Día 0.
Cualquier herramienta interna también puede integrar a Kai, y muchas han optado por hacerlo. Por ejemplo, un empleado que trabaja en nuestra plataforma de inteligencia de negocios puede hacerle una pregunta a Kai desde su aplicación existente, porque nuestras extensiones de Chrome exponen las capacidades de Kai dentro de herramientas de terceros basadas en web.
Las aplicaciones personalizadas integran a Kai mediante APIs para llevar experiencias agénticas a todos los flujos de trabajo
AgentStudio
AgentStudio es el plano de control para los dueños de dominio. Los equipos lo usan para construir, probar y monitorear sus skills, agentes Kai personalizados y selecciones de herramientas. Un equipo de GTM, por ejemplo, es dueño de un agente Kai ajustado a sus flujos de trabajo. Carga sus skills por defecto, se conecta a sus fuentes de datos y presenta los resultados en el formato que sus usuarios esperan. AgentStudio muestra datos de uso y señales de calidad junto a cada recurso, para que los dueños de dominio puedan ver qué está funcionando sin tener que preguntarle al equipo de la plataforma.
Los skills están organizados en áreas de toda Stripe que son gestionadas por expertos de dominio
El entorno de ejecución
Esta es la capa que hace realidad las promesas de la plataforma. Las primitivas centrales, incluidos el harness del agente, el sandbox, la orquestación de flujos de trabajo y el marco de control de acceso, se comparten deliberadamente con los agentes orientados a productos de Stripe. El trabajo de conocimiento interno opera sobre los mismos datos sensibles y atiende a los mismos usuarios que nuestros productos externos, por lo que requiere el mismo estándar de seguridad y cumplimiento. Compartir el sustrato impone disciplina y crea un efecto volante: las mejoras al entorno de ejecución benefician simultáneamente a los agentes internos y a los de productos.
El harness del agente, construido con deepagents de LangChain, se ejecuta en Kubernetes con un sandbox seguro por sesión y un sistema de archivos virtual multi-tenant. Dentro de una sesión, el agente trabaja con un sistema de archivos virtual donde crea e itera sobre artefactos, mientras que un sandbox seguro de ejecución de código se usa para análisis y procesamiento de datos.
Está diseñado para mantener el estado a lo largo de sesiones largas y complejas; una de ellas llegó recientemente a 932 turnos. Con las capacidades de gestión profunda de tareas de Kai, una sola conversación puede consistir en cientos de turnos y cientos de llamadas a herramientas y al LLM sin agotar el tiempo de espera ni sobrecargar la ventana de contexto. Esto importa porque el trabajo de conocimiento rara vez es una sola pregunta. Es un razonamiento iterativo que se construye sobre sí mismo, y la sesión tiene que mantener ese estado sin degradarse.
Los comportamientos de los usuarios están cambiando, y las sesiones se usan cada vez más para la colaboración profunda de múltiples turnos
Una de las partes más interesantes del harness es cómo elige el skill correcto para usar. Kai está conectado a más de 1,000 skills y herramientas que abarcan varios sistemas internos, desde paneles de inteligencia de negocios que dan seguimiento a métricas clave, hasta herramientas de gestión de proyectos que organizan la ejecución interna, y servicios de terceros como Zoom y Google Workspace. Cualquiera puede hacerle una pregunta y confiar en que cargará el contexto correcto y usará las herramientas adecuadas para hacer el trabajo. Los agentes de codificación tienen una ventaja natural aquí: las carpetas en las que trabajan proporcionan una organización natural para los skills y el contexto. En una publicación de seguimiento, profundizaremos en cómo resolvimos esto sin esa estructura preexistente, utilizando un enfoque híbrido de RAG/LLM, entre otras técnicas.
Impacto
Los resultados han sido sorprendentes. Los nuevos contratados en GTM son nativos de Kai, lo usan 2.7 veces más, y los usuarios avanzados cierran 80% más valor que los usuarios de bajo uso dentro de la misma cohorte. Cuando los ejecutivos de cuenta usan Kai, producen 2 veces más actividad de ventas, crean 17% más oportunidades, generan 26% más oportunidades de ingresos y cierran 39% más acuerdos, en comparación con los mismos vendedores en las semanas en que no lo usan. En conjunto, Kai ha ayudado a trasladar 25,000 horas al año de trabajo administrativo a trabajo generador de ingresos.
En finanzas y operaciones, Kai está ayudando a los Stripes a analizar datos desordenados, generar resúmenes periódicos y convertir contexto fragmentado en artefactos utilizables.
En ingeniería, Kai ahora es un lugar natural para hacer preguntas sobre sistemas, investigar solicitudes de ejecución, analizar logs, redactar planes e invocar agentes y skills más especializados.
Y en toda Stripe, más de 5,000 sesiones diarias se centran en análisis de datos. Esto convierte a Kai en un punto de apalancamiento único: al conectar el contexto correcto sobre la calidad de los datos y nuestra capa de analítica, podemos garantizar respuestas correctas por defecto para la mayoría de las preguntas.
Los comentarios directos de los Stripes respaldan estos agregados: reportan sentirse "empoderados para adoptar la IA" y "asombrados por lo que Kai hace con total precisión". Pero nuestra anécdota favorita es la de un no ingeniero que salió de una sesión introductoria de Kai e inmediatamente colaboró en un resumen que integra Asana, Slack y Jira en un solo proceso automatizado.
Todavía no hemos ganado
En Stripe, una de nuestras frases favoritas es "todavía no hemos ganado", y eso aplica perfectamente a Kai. Estamos en las etapas más tempranas de este viaje y tenemos mucho más que queremos hacer:
- Mejor gestión de estado: Los agentes de propósito general como Kai generan mucho estado mientras hacen llamadas iterativas a herramientas, descargan documentos grandes y más. Estamos ajustando continuamente tanto el contexto "activo" que se envía al LLM como el contexto "extendido" que reside en almacenes de estado como S3 o el sistema de archivos virtual.
- Reflexión y automejora: Estamos trabajando en un ciclo de mejora de calidad que permite a Kai reflexionar sobre trazas que involucran un skill, proponer mejoras, probarlas y enviar cambios para que el dueño del skill los revise.
- Mejores primitivas de colaboración: Los usuarios generan mucho contexto en sus sesiones de Kai que actualmente está "bloqueado", pero así no es como se hace el trabajo. Queremos permitir que las personas compartan lo que Kai muestra entre sesiones, y que varias personas (¡y agentes!) colaboren en los mismos artefactos.
Los agentes de codificación hicieron que la IA se sintiera concreta primero para los ingenieros de software. Kai ha ayudado a llevar ese mismo sentido de apalancamiento a los trabajadores del conocimiento en toda Stripe. Es interesante porque, aunque hemos mejorado considerablemente la productividad, todavía no conocemos el techo, y estamos emocionados de seguir empujando los límites aquí. Si construir sistemas agénticos que impulsen la productividad interna y los agentes externos suena como tu tipo de desafío, estamos contratando.
