Los agentes de codificación transformaron la ingeniería en Stripe, pero los no ingenieros, como representantes de ventas, analistas financieros, gestores de cuentas técnicas y otros, se sintieron rezagados por la ola de IA de Claude Code y Codex. Ninguna herramienta existente podía cumplir con los requisitos de seguridad de datos y los flujos de trabajo específicos que Stripe necesitaba: consultar almacenes de datos, investigar cuentas antes de las llamadas de ventas, clasificar incidentes, modelar escenarios de ingresos o preparar revisiones de cumplimiento. Todo eso cambió cuando lanzamos el agente de IA de conocimiento de Stripe.
GIF
En las dos semanas posteriores a nuestro lanzamiento de 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 de GTM (marketing, ventas, gestores de éxito de clientes y gestores de cuentas técnicas). La mayoría de las sesiones de Kai requieren muchos turnos, ya que los usuarios realizan investigaciones profundas, crean artefactos específicos o refinan activos antes de compartirlos interna o externamente. Con Kai, todos en Stripe tienen un agente diseñado específicamente para ayudarles con su trabajo diario.
Por qué creamos una Plataforma de IA de Conocimiento
En las tareas de codificación, el cambio concreto 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 está en el lado opuesto de ese espectro. Tareas como investigar una cuenta o preparar una revisión de cumplimiento requieren herramientas distintas, datos distintos, resultados distintos y definiciones distintas de "terminado".
Antes de Kai, teníamos dos opciones de IA para el trabajo de conocimiento:
- NoCode Agent Builder: 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 comprobamos que la proliferación de estos microagentes era cada vez más difícil de supervisar y mantener.
- Agentes de codificación: Los agentes de codificación eran potentes, pero introducían un conjunto diferente de riesgos. Dado que nuestro objetivo es mejorar la productividad de todo Stripe, algunos usuarios modificaron sus flujos de trabajo y eligieron agentes de codificación. Sin embargo, pronto surgieron problemas de seguridad, junto con una nueva carga de soporte para los equipos de calidad de código que nunca antes habían dado soporte a no ingenieros.
A partir de estas experiencias, nos dimos cuenta de que construir una plataforma de IA de conocimiento requería acertar en tres cosas: escalar la experiencia sin centralizarla, llegar a los usuarios donde trabajan y aplicar salvaguardas que no existen en el código.
Escalar la experiencia sin centralizarla
La variedad de conocimientos necesarios para atender a los usuarios de Stripe es asombrosa. Las personas que saben cómo clasificar una escalación de facturación o modelar un escenario de ingresos no están centralizadas y, desde luego, no están en el equipo que construye la infraestructura de agentes. Están distribuidas en docenas 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 qué es "bueno". Si multiplicamos esto por todos los productos y países en los que opera Stripe, el resultado es asombrosamente complejo. Kai tiene que modelar esa complejidad de forma que sea invisible, para que la tarea simplemente funcione.
El agente tiene que moverse
Dónde aparece el agente importa tanto como lo que sabe. No todo el mundo trabaja en una pestaña del navegador, y menos aún en una terminal. Así que un agente de conocimiento no puede ser un único producto; tiene que ser una plataforma, lo bastante flexible como para integrarse dondequiera que se desarrolle el trabajo.
Por ejemplo, pensemos en 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 sacarlos 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 en una nueva aplicación. Tampoco funcionaría crear un producto de agente separado para cada superficie; sería difícil de mantener, y los usuarios que usan varias herramientas tendrían una experiencia fragmentada. La plataforma tiene que llegar 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 la sintaxis inválida, las pruebas detectan regresiones y git hace que cualquier error sea reversible. El trabajo de conocimiento tiene muy poco soporte para estos mecanismos.
Pensemos en un invariante central en Stripe: "no deberías combinar datos de dos contextos de clientes no relacionados en un mismo análisis". Un usuario puede tener acceso legítimo a ambos contextos de forma independiente, pero nunca pueden aparecer en la misma sesión. La frontera 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 único simplemente no puede codificar todas estas restricciones de forma efectiva. Y pedir a cada equipo de dominio que construya de forma independiente una infraestructura de agentes segura, alojada y de alto rendimiento tampoco escala. Para afrontar este desafío, construimos Kai en tres capas:
- APIs independientes de la superficie que ofrecen múltiples interfaces al mismo agente
- AgentStudio, donde los propietarios de dominio crean y gestionan sus propios agentes de Kai, y
- Entornos de ejecución que proporcionan seguridad en segundos sin que nadie tenga que pensar en la infraestructura.
APIs independientes de la superficie
Kai incluye una aplicación web con criterio propio 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 del mismo.
La mayoría de los empleados de Stripe interactúan con Kai a través de la aplicación web alojada internamente. No hay infraestructura que configurar: está disponible para todos los empleados desde el día 0.
Cualquier herramienta interna también puede integrar Kai, y muchas han decidido hacerlo. Por ejemplo, un empleado que trabaja en nuestra plataforma de business intelligence 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 Kai mediante APIs para llevar experiencias de agentes a todos los flujos de trabajo
AgentStudio
AgentStudio es el plano de control para los propietarios de dominio. Los equipos lo usan para crear, probar y supervisar sus skills, agentes de Kai personalizados y selecciones de herramientas. Un equipo de GTM, por ejemplo, es propietario de un agente de 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 activo, para que los propietarios de dominio puedan ver qué funciona sin tener que preguntar al equipo de plataforma.
Los skills están organizados en áreas de Stripe 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 al producto de Stripe. El trabajo de conocimiento interno opera con los mismos datos sensibles y atiende a los mismos usuarios que nuestros productos externos, por lo que exige el mismo nivel de seguridad y cumplimiento. Compartir el sustrato impone disciplina y crea un círculo virtuoso: las mejoras en el entorno de ejecución benefician simultáneamente a los agentes internos y a los de producto.
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 multiinquilino. Dentro de una sesión, el agente trabaja con un sistema de archivos virtual donde crea y mejora artefactos, mientras que un sandbox seguro de ejecución de código se usa para el análisis y el procesamiento de datos.
Está diseñado para mantener el estado a lo largo de sesiones largas y complejas: una de ellas alcanzó recientemente los 932 turnos. Con las capacidades de gestión profunda de tareas de Kai, una sola conversación puede constar de cientos de turnos y cientos de llamadas a herramientas y al LLM sin agotar el tiempo 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 adecuado. Kai está conectado a más de 1.000 skills y herramientas que abarcan diversos sistemas internos, desde paneles de business intelligence que rastrean 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 un artículo posterior, explicaremos 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 empleados de GTM son nativos de Kai, lo usan 2,7 veces más y los usuarios avanzados generan un 80 % más de valor que los usuarios con poco uso dentro de la misma cohorte. Cuando los ejecutivos de cuenta usan Kai, producen el doble de actividad de ventas, crean un 17 % más de oportunidades, generan un 26 % más de oportunidades de ingresos y cierran un 39 % más de 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 del trabajo administrativo al trabajo generador de ingresos.
En finanzas y operaciones, Kai está ayudando a los empleados de Stripe a analizar datos desordenados, generar resúmenes periódicos y convertir el contexto fragmentado en artefactos utilizables.
En ingeniería, Kai es ahora un lugar natural para hacer preguntas sobre sistemas, investigar para 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 el análisis de datos. Esto convierte a Kai en un punto de apalancamiento único: al incorporar 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.
El feedback directo de los empleados de Stripe respalda estas cifras: dicen sentirse "empoderados para adoptar la IA" y "asombrados por lo que Kai hace con precisión". Pero nuestra anécdota favorita es la de un no ingeniero que salió de una sesión introductoria de Kai y de inmediato colaboró en un resumen que integra Asana, Slack y Jira en un único 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 primeras etapas de este viaje y tenemos mucho más que queremos hacer:
- Mejor gestión del estado: Los agentes de propósito general como Kai generan mucho estado a medida que 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 los traces que involucran un skill, proponer mejoras, probarlas y enviar cambios para que el propietario 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 la gente comparta 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 esa misma sensación de apalancamiento a los trabajadores del conocimiento en toda Stripe. Es interesante porque, aunque hemos mejorado la productividad considerablemente, todavía no conocemos el techo, y estamos emocionados por seguir superando los límites. Si construir sistemas de agentes que impulsen la productividad interna y los agentes externos suena a tu tipo de desafío, estamos contratando.
