El 7 de julio de 2026, Praveen Neppalli, director de tecnología de Uber, publicó en X algo que rara vez se ve: el método operativo exacto, paso a paso, detrás de cómo una empresa de ese tamaño está llevando la IA agéntica más allá de ingeniería. Lo llaman Agentic Pods, y en dos meses ya corrieron 16 de ellos en 16 funciones de negocio distintas, con resultados que se pueden verificar en el mismo hilo.

No es una publicación de relaciones públicas con números vagos. Es el CTO de una empresa pública explicando, con una secuencia de diez días concreta, cómo estructuran el trabajo de emparejar IA con una función de negocio que no es ingeniería. Y lo que describe se parece, punto por punto, al discovery de dos meses que corremos en AI Maestro.

Lo que es un Agentic Pod, en detalle

Según el propio Neppalli, Uber ya tenía adopción masiva de IA en ingeniería: 99% de sus ingenieros usan herramientas de IA, más del 70% de los pull requests vienen de agentes locales o en la nube, y sus ingenieros construyeron más de 2,500 skills de agentes a lo largo del ciclo de vida del desarrollo de software. La pregunta que se hicieron después fue distinta: ¿cómo se lleva eso más allá de ingeniería? Finanzas, legal, operaciones, marketing, soporte al cliente, RRHH, procurement.

La respuesta fue formar cerca de 30 Agentic Pods: parejas de uno de sus ingenieros más expertos en IA con un experto de dominio de la función de negocio en cuestión. A cada pod le dieron exactamente diez días, con una secuencia fija que no varía: días 1 y 2, el ingeniero hace sombra al experto, observa cada paso, documenta el flujo de trabajo y hace preguntas. Día 3, priorizan oportunidades según escala, repetición, impacto de negocio y disponibilidad de datos. Días 4 y 5, construyen un agente funcional junto a la persona que hace el trabajo, no para ella. Días 6 a 9, validan con varias personas más que hacen el mismo trabajo, para confirmar que generaliza y que de verdad mejora el resultado. Día 10, lo lanzan.

Los resultados y la frase que importa más

En dos meses, Uber corrió 16 Agentic Pods en 16 funciones distintas. Algunos números concretos del propio hilo: la asignación de capital en 150 ciudades pasó de 15 horas a 30 minutos. Los reportes de ritmo financiero pasaron de 2 días a 10 minutos. El control de calidad de contenido web de marketing pasó de 2 semanas a 50 minutos. La creación de flujos de soporte pasó de 9,000 flujos manuales a autoservicio.

Pero la ganancia de productividad no fue lo que más sorprendió al propio Neppalli. Lo que él destaca es la velocidad con la que ingenieros ajenos a un dominio encontraron oportunidades que estaban a la vista de todos y nadie había visto. Y una frase que resume el patrón completo: “el flujo de trabajo se vuelve la unidad de automatización, no la tarea individual.” Los mayores resultados no vinieron de automatizar una tarea suelta, vinieron de rediseñar el flujo completo alrededor del agente: eliminar traspasos, quitar aprobaciones innecesarias, reemplazar herramientas heredadas.

Por qué la mayoría de las empresas no puede simplemente copiar esto

Acá está la parte que casi nadie menciona cuando comparte este hilo. El método de Uber funciona porque Uber tiene algo que la mayoría de las empresas medianas en Centroamérica no tiene: cerca de 30 ingenieros con dominio técnico profundo de IA disponibles para prestarlos diez días completos a un área que no es la suya. Ese es un banco de talento interno que se construyó durante meses de inversión previa en adopción de IA dentro de ingeniería.

Si tu empresa no tiene ese banco interno, la secuencia de diez días de Uber no se traduce automáticamente en resultados. Necesitas a alguien con ese mismo perfil, capaz de sentarse con el experto de negocio, documentar el flujo real (no el diagrama de proceso que nadie sigue), y construir el agente junto a la persona que hace el trabajo. Eso es exactamente lo que resolvemos como socio externo en el discovery de AI Maestro: el mismo patrón de pareo, sombra, priorización y construcción que describe Neppalli, pero corrido por alguien de afuera cuando la empresa no tiene el banco interno de ingenieros que Uber sí tiene. Ya escribimos antes sobre la brecha de utilización de IA del 95%: la herramienta está disponible, lo que falta es exactamente este tipo de proceso estructurado para encontrar dónde aplicarla.

La lección más importante que dejó Neppalli no fue un número de productividad. Fue esta: las mejores oportunidades de IA casi nunca son visibles desde afuera de la función donde ocurren. Las descubres sentándote junto a la persona que hace el trabajo, entendiendo cada punto de fricción, y construyendo con ella, no para ella. Uber tiene el banco de ingenieros para hacer eso 16 veces en dos meses. La mayoría de las empresas necesita a alguien más para hacerlo una vez, bien hecho.