IA agéntica en producción: qué han cambiado de verdad cuatro grandes empresas

Coyol, Costa Rica. Las 3:57 de la madrugada. En el centro de distribución no hay ningún planificador de turno, pero un sistema acaba de comparar la velocidad real de venta de una referencia de verdura fresca con la demanda prevista para las próximas cuarenta y ocho horas en cada tienda de la zona, ha simulado el coste de transporte, la vida útil restante del producto y el margen de cada alternativa, y ha emitido una orden de traslado. Nadie la ha aprobado. Cuando el primer encargado llegue a las siete, el camión ya habrá salido.

La misma noche, en otra parte del mundo, un agente de software abre una rama en un repositorio, migra ciento treinta clases de un patrón antiguo a otro, ejecuta el compilador, falla, lee el error, se corrige, vuelve a compilar, pasa los tests, somete su propio cambio al juicio de un segundo modelo que comprueba si se ha salido del encargo, lanza la integración continua en una máquina que no es la suya y, solo cuando todo está en verde, abre una pull request para que la revise una persona. Esa persona llegará por la mañana y encontrará el trabajo hecho.

Ninguna de las dos escenas es una demostración de laboratorio ni un piloto de innovación. Son procesos de negocio en producción, con volumen, con métricas y con dueño. Y el dato que mejor resume lo que está pasando no es ninguna proyección de consultora: aproximadamente la mitad de todos los cambios de código que se integran hoy en Spotify no los ha escrito un ingeniero, sino la plataforma de automatización de la propia compañía.

La diferencia entre una empresa que presume de IA y una que ha transformado un proceso con IA no está en el modelo que usa. Está en si alguien ha dejado de hacer algo.

Este análisis recorre cuatro casos documentados en profundidad —Spotify, Uber, PepsiCo y Walmart— que tienen muy poco en común: uno mantiene código, otro capta clientes, otro diseña fábricas y otro mueve palés de fruta. Son cuatro industrias distintas, cuatro pilas tecnológicas distintas y cuatro grados de autonomía distintos. Y sin embargo, cuando se desmontan pieza a pieza, los cuatro repiten el mismo puñado de decisiones de diseño. Al final del artículo están reunidas en siete lecciones que se pueden aplicar sin tener el presupuesto de ninguna de las cuatro.

---

No es un copiloto: qué cambia cuando el proceso corre solo

La palabra «agente» se ha gastado en menos de dos años. Conviene fijarla con precisión antes de mirar los casos, porque de esa definición depende que las cifras de este artículo signifiquen algo o no signifiquen nada.

Un copiloto funciona de forma síncrona: usted escribe, él sugiere; usted pregunta, él responde. El trabajo sigue siendo suyo y el ritmo también. Un copiloto acelera a la persona, pero no cambia el proceso: si usted se va de vacaciones, el proceso se para.

Un agente, en el sentido en que lo usan las cuatro empresas de este artículo, opera de forma asíncrona y desatendida sobre un objetivo de alto nivel. Recibe un estado final deseado —no una secuencia de pasos—, decide por sí mismo qué pasos dar, usa herramientas reales sobre sistemas reales, evalúa el resultado de sus propias acciones, corrige lo que ha salido mal y persiste en el intento durante minutos, horas o semanas. Si usted se va de vacaciones, el proceso sigue.

Esa distinción no es filosófica: es operativa y tiene cuatro escalones bien diferenciados. Walmart los tiene formalizados internamente y sirven perfectamente para situar a las otras tres.

1. Nivel 1 — Predictivo. Un modelo estadístico calcula un pronóstico y produce un informe o un cuadro de mando. La persona lo interpreta, decide y ejecuta. Es lo que casi todas las empresas llaman «tener IA».
2. Nivel 2 — Consultivo. Un asistente conversacional sintetiza información dispersa y responde preguntas en lenguaje natural. Ahorra tiempo de búsqueda, pero la ejecución sigue siendo íntegramente humana.
3. Nivel 3 — Copiloto agéntico. El agente ejecuta la tarea completa de varios pasos y presenta el resultado terminado, pero una persona tiene que aprobarlo antes de que surta efecto. Aquí está el grueso de lo que hoy funciona bien en producción.
4. Nivel 4 — Bucle cerrado. El agente detecta la anomalía, evalúa alternativas, decide y ejecuta directamente sobre el sistema transaccional o sobre el mundo físico, sin validación previa. El humano entra después y solo por excepción.

Aquí está la primera idea que conviene retener, porque contradice la intuición del mercado: ninguna de estas cuatro empresas intenta llegar al nivel 4 en todo. Eligen el escalón proceso a proceso, y el criterio no es la madurez tecnológica. Es el coste de equivocarse y la facilidad para deshacer el error.

Un cambio de código mal hecho lo caza un compilador, lo caza un test, lo caza un revisor y, si aún así pasa, se revierte con un comando. Un plan de medios equivocado se corrige antes de firmarlo. Una compra de maquinaria mal dimensionada, en cambio, son dos millones de euros de acero instalados en una nave durante quince años: ahí nadie cierra el bucle. Y un palé de lechugas enviado a la tienda equivocada cuesta unos cientos de euros y se arregla mañana: ahí sí se cierra, y se cierra a las cuatro de la mañana.

Spotify: el mantenimiento del código dejó de ser trabajo humano

El problema: el 30% que nadie terminaba nunca

Spotify tiene más de 751 millones de usuarios activos mensuales y miles de microservicios repartidos entre cientos de equipos. Su problema estructural no era la velocidad a la que escribía código nuevo, sino la velocidad a la que envejecía el que ya tenía: el código de producción crecía siete veces más rápido que la plantilla de ingeniería. Una investigación interna puso números al síntoma: los desarrolladores dedicaban de media menos de 52 minutos al día a escribir código nuevo. El resto de la jornada se iba en reuniones, alineación y mantenimiento mecánico.

Para atacarlo, la compañía llevaba años usando Fleet Management (internamente, Fleetshift): un orquestador que aplica transformaciones de código masivas sobre miles de repositorios mediante trabajos en contenedores. El motor de esas transformaciones eran scripts deterministas que manipulaban el árbol de sintaxis abstracta del programa o, en el peor de los casos, expresiones regulares. Funcionaba, pero con tres límites que cualquiera que haya gestionado una migración reconocerá:

• La explosión de complejidad imperativa. Para subir una versión en un pom.xml de Maven, un script de veinte líneas basta. Para cubrir las variantes de estilo de cientos de equipos, no. El actualizador automático de dependencias de Maven de Spotify superó las 20.000 líneas de código imperativo, y la práctica totalidad de ese volumen existía solo para tratar casos de esquina.
• El problema de la larga cola. Los scripts migraban con soltura el 70% de la flota en menos de una semana. El 30% restante —estructuras heterogéneas, patrones no estandarizados, particularidades arquitectónicas— se quedaba atascado indefinidamente. Los equipos propietarios «declaraban victoria al 70%» y seguían con lo suyo.
• El desgaste humano. Resolver ese 30% exigía coordinar con docenas de equipos, modificar archivos línea a línea, ejecutar pruebas en local y abrir cientos de pull requests a mano. Una migración de API se dilataba meses o años, y mientras tanto la diversidad del código base —y con ella la deuda técnica— aumentaba.

Fíjese en el detalle, porque es el patrón que se repetirá en los otros tres casos: el problema nunca estuvo en el 70% fácil. Estuvo en el 30% que requiere juicio, y ese 30% es exactamente el trabajo que un script determinista no puede hacer y que ninguna persona quiere hacer.

La solución: un agente con tres herramientas y dos jueces

Spotify construyó Honk, un agente de codificación autónomo que se ejecuta en segundo plano sobre Claude Code y el Claude Agent SDK, dentro de contenedores aislados de Kubernetes. La mecánica completa cabe en cinco pasos.

1. El objetivo entra en lenguaje natural. Un desarrollador o un líder de migración define el estado final deseado desde una de tres superficies: el plugin de Fleetshift dentro de Backstage, una mención en Slack —lo que permite lanzar cambios desde el móvil, de camino al trabajo— o un evento automático de GitHub Enterprise. No se describe una secuencia de pasos, se describe el destino: «Migrar la clase de datos de AutoValue a Java Records preservando la compatibilidad con Jackson».

2. El contexto se inyecta, no se busca. Aquí está la decisión de diseño más contraintuitiva de todo el caso. En lugar de dar al agente acceso ilimitado a herramientas para que investigue por su cuenta, Spotify hace lo contrario: le restringe deliberadamente la capacidad y le entrega un prompt estático exhaustivo. La frase que lo justifica es del propio equipo:

Cuantas más herramientas tienes, más dimensiones de imprevisibilidad introduces.

Ese prompt lleva tres ingredientes que merece la pena copiar tal cual: tablas de mapeo explícitas (qué patrón antiguo se sustituye exactamente por qué patrón nuevo), reglas de exclusión tajantes —las directivas DO NOT MIGRATE, que marcan qué archivos o métodos no debe tocar porque requieren juicio humano— y ejemplos concretos de código antes y después.

3. Tres herramientas, ni una más. Honk solo puede interactuar con el mundo a través de tres herramientas expuestas vía Model Context Protocol (MCP):

Herramienta	Qué hace	Qué le impide hacer
Verify Tool	Invoca de forma determinista compiladores, linters y ejecutores de pruebas del proyecto (Maven, Yarn, Bazel)	El agente no conoce los detalles internos del sistema de build; solo recibe el resultado y los logs resumidos
Git Tool	Crear ramas, hacer commits con formato estandarizado y generar diffs	Bloquea comandos destructivos y cualquier push sin validación previa
Bash Tool	Terminal con lista blanca de comandos, con ripgrep como pieza central para localizar patrones	Sin acceso libre al sistema operativo ni a la red externa

4. La validación ocurre en dos niveles, y ninguno es el agente. Honk trabaja en un bucle cerrado de hasta diez turnos por sesión y tres reintentos completos. La calidad se asegura con dos filtros independientes:

• Nivel 1, verificadores deterministas. Detectan el tipo de proyecto y ejecutan la compilación. Cuando un fallo de Maven escupe miles de líneas de log, no se le devuelven al agente —eso agotaría su ventana de contexto y lo despistaría—: un filtro por expresiones regulares o un segundo modelo de extracción reducen el vertido al mensaje de error exacto.
• Nivel 2, el LLM como juez. Un modelo secundario compara el git diff final con el prompt original y busca dos cosas: que el agente no se haya salido del encargo (scope creep) y que no haya tomado atajos inaceptables, como comentar las pruebas unitarias que fallaban o degradar la versión del lenguaje para que compile. Ese juez veta aproximadamente el 25% de las sesiones. Y el dato realmente interesante: ante un veto, el agente se corrige solo la mitad de las veces.

5. Quien piensa no es quien compila. Honk no ejecuta la integración continua definitiva dentro de su propio contenedor. Evitar eso resuelve de golpe un problema de seguridad —no hace falta conceder privilegios elevados ni ejecutar Docker dentro de Docker— y otro de fidelidad: empuja la rama a GitHub Enterprise y un servicio de verificación independiente dispara la CI en la infraestructura nativa que corresponda, incluidos servidores macOS para las compilaciones de iOS. Solo cuando el resultado está completamente en verde se abre formalmente la pull request para revisión humana.

Xirp: el problema que aparece cuando todo el mundo tiene agentes

Cuando cientos de ingenieros empezaron a lanzar agentes a la vez, apareció una fragmentación nueva que nadie había previsto: el contexto operativo se quedaba atrapado en configuraciones locales, terminales individuales y bibliotecas privadas de prompts. Un agente gastaba tokens redescubriendo lo que otro agente, en otra sesión, ya había resuelto media hora antes.

La respuesta fue Xirp, una aplicación de escritorio para macOS usada internamente por más de 1.300 ingenieros en más de 36.000 sesiones, que funciona a la vez como consola de control multiagente y como memoria institucional. Tres rasgos la definen:

• Neutralidad de proveedor. Permite ejecutar Claude Code, Gemini CLI, OpenAI Codex o modelos open-source auto-hospedados, y cambiar de modelo a mitad de proyecto sin perder el hilo conceptual. La estrategia agéntica de Spotify no está atada a un proveedor.
• Aislamiento por git worktree. Cada sesión corre en su propio árbol de trabajo independiente. Esto permite que un solo desarrollador supervise más de 50 sesiones agénticas en paralelo sobre el mismo repositorio sin que los agentes colisionen entre sí.
• Sincronización bidireccional con el catálogo. Al arrancar, Xirp inyecta automáticamente el contexto de arquitectura, propiedad y dependencias desde Backstage. Al terminar, la transcripción de la sesión se convierte en documentación viva en ese mismo catálogo. El aprendizaje de una sesión deja de morir con ella.

Los resultados

Métrica	Resultado	Contexto
Tiempo en migraciones complejas	Entre un 60% y un 90% menos	Medido en migraciones como AutoValue a Java Records o actualizaciones de Scio, frente al desarrollo manual
Pull requests integradas	Más de 1.500 acumuladas	Completamente integradas en la rama principal de producción
Ritmo mensual	Más de 650 al mes	Pull requests agénticas integradas de forma sostenida
Velocidad de escalado	De 3 meses a 10 días	Tiempo necesario para acumular 1.000 pull requests integradas
Caso de datos	10 semanas de ingeniería ahorradas	Migración de unos 1.800 pipelines de datos con 240 pull requests automáticas exitosas
Peso sobre el total	Cerca del 50% de las PR	Aproximadamente la mitad de todos los cambios integrados vienen de la plataforma automatizada
Adopción	Más del 99% semanal	El 94% de los ingenieros declara mayor productividad; la frecuencia de PR sube un 76%

Un matiz importante para no sobrevender el caso: la migración masiva sigue exigiendo iteración y no todo se resuelve al primer intento. Lo que ha cambiado no es que el trabajo desaparezca, sino quién lo hace y a qué coste marginal. Y hay un efecto de segundo orden que Spotify reconoce abiertamente: con una base de código muy estandarizada —el Java BOM está al 96% de cumplimiento—, los prompts se simplifican, el agente acierta más, la revisión humana es más rápida y eso permite estandarizar todavía más. Es un ciclo virtuoso, y también una advertencia: quien no tenga esa estandarización previa no obtendrá estos números.

Spotify Ads AI: de veinte campos de formulario a tres frases

El segundo caso de Spotify no tiene nada que ver con ingeniería, y por eso es tan útil: demuestra que el patrón se traslada a un proceso puramente comercial.

El negocio publicitario de Spotify se vende por tres canales —directo, autoservicio y programático— que compartían backend pero no reglas. La lógica de tarificación, el cálculo de disponibilidad de inventario y la asignación presupuestaria estaban implementadas de forma distinta en Ads Manager, en Salesforce, en Slack y en herramientas internas. Las consecuencias:

• Un proceso manual lento. Construir un plan de medios exigía rellenar a mano más de 20 campos técnicos obligatorios repartidos en varias consolas. De 15 a 30 minutos por propuesta.
• Decisiones por intuición. Las recomendaciones de audiencia, el reparto de presupuesto y la elección de formato salían del criterio del operador y de tablas estáticas, sin consultar el rendimiento real de las miles de campañas anteriores.
• Divergencia de reglas. La misma regla comercial existía en varias versiones en distintas herramientas, con el consiguiente derroche de inventario.

La respuesta fue Ads AI: una capa de decisión conversacional construida sobre el Google Agent Development Kit y Vertex AI, con comunicación gRPC de baja latencia y el histórico de rendimiento en PostgreSQL con caché en memoria. La pieza clave del diseño es que no se construyó un agente, sino seis, cada uno con una responsabilidad estrecha y verificable.

Agente	Responsabilidad concreta
1. Router	Triaje inicial. Analiza el mensaje y determina qué variables ya están presentes y cuáles faltan, para no invocar modelos caros innecesariamente
2. Objetivo	Traduce intenciones abstractas («aumentar el reconocimiento de mi marca de calzado») a objetivos técnicos normalizados y categoriza la industria
3. Audiencia	Extrae edad, género, ubicaciones geográficas y segmentos de interés dentro de la taxonomía oficial de Spotify
4. Presupuesto	Normaliza formatos heterogéneos («5k», «5.000 USD», «10.000 €») a microunidades monetarias estandarizadas
5. Calendario	Convierte expresiones temporales relativas («durante las próximas tres semanas») en fechas absolutas de calendario y servidor
6. Planificador de medios	Núcleo de optimización. Recibe los datos ya validados y genera la distribución recomendada

La descomposición tiene dos ventajas que se pasan por alto con facilidad: permite ejecutar en paralelo lo que es paralelizable, y permite localizar el fallo. Cuando un plan sale mal, se sabe qué agente lo estropeó. Con un único agente monolítico, no.

El anclaje que impide las alucinaciones

El planificador de medios no puede inventar disponibilidad ni tarifas, por diseño. Está obligado a consultar los sistemas transaccionales reales mediante llamadas a funciones declaradas con esquema explícito:

• search_geo_targets valida qué ubicaciones geográficas están realmente disponibles.
• search_ad_categories consulta las categorías publicitarias autorizadas.
• get_historical_performance extrae métricas reales de conversión, CPM y entrega de campañas similares anteriores.

Sobre esa base, el agente aplica heurísticas explícitas: reducir CPM, CPC y CPI respecto a las medianas históricas, buscar un ritmo de entrega cercano al 100% y diversificar formatos. Y hay un detalle de diseño comercial que merece un párrafo propio, porque es el tipo de regla que suele quedarse en la cabeza de un comercial veterano y aquí está codificada:

Presupuesto consolidado	Propuestas generadas	Lógica comercial
Menos de 1.000 €	1	Propuesta única optimizada de entrada
De 1.000 a 5.000 €	2	Opciones de alcance frente a frecuencia
De 5.000 a 15.000 €	3	Estrategias multiformato equilibradas
15.000 € o más	4 o 5	Planes corporativos avanzados diversificados

El resultado: de 15–30 minutos a 5–10 segundos por propuesta, con una latencia agéntica neta de tres a cinco segundos gracias a la ejecución en paralelo. Y una reducción de la fricción de entrada que importa más que el tiempo: de más de veinte campos obligatorios a uno o tres mensajes en lenguaje natural. El anunciante ya no necesita saber cómo se llaman los campos del sistema de Spotify para pedir una propuesta.

Uber: el embudo comercial que trabaja mientras nadie mira

Treinta personas para doce mil oportunidades al mes

Uber for Business da servicio a más de 300.000 organizaciones. Se diseñó como un portal de autoservicio para que las empresas se dieran de alta solas, y sobre el papel funcionaba. En la práctica, la configuración inicial —validar un método de pago corporativo, definir centros de coste, activar políticas de movilidad— generaba dudas que el portal no resolvía.

El resultado era una fuga sistemática, y las cifras del «antes» son de las más demoledoras de este artículo:

• Un equipo global de solo 30 especialistas de onboarding frente a un flujo de más de 12.000 leads al mes. El seguimiento sistemático era físicamente imposible.
• El 10% de los leads cualificados por marketing nunca llegaba a asignarse a un comercial. Dinero de captación ya gastado, tirado por un cuello de botella administrativo.
• Solo el 40% de los contactos se atendía dentro del plazo comprometido de 24 horas. El tiempo medio real superaba con frecuencia los dos o tres días hábiles.
• El ciclo medio de venta se estiraba hasta los 78 días hábiles y la tasa de cierre se estancaba en el 32%.
• Cuando por fin alguien llamaba, no sabía en qué punto exacto se había detenido el registro. Llamaba a ciegas.

En paralelo, la división de publicidad tenía otro atasco. Las solicitudes de propuesta (RFP) son la vía principal de captación de clientes estratégicos —constituyen el 42% de las oportunidades en Estados Unidos y Canadá y más del 25% de los acuerdos globales de gran consumo—, y llegaban como documentos no estructurados de más de veinte páginas en PDF, presentaciones o hilos de correo. Cada una consumía unos 30 minutos netos de trabajo administrativo: leerla, extraer presupuestos, fechas y audiencias, transcribir campo a campo al CRM, montar el plan de medios en una hoja de cálculo aparte y, al cerrar la campaña, volver a rastrear los archivos originales para el informe final.

El agente que persigue un objetivo, no una pregunta

El nuevo flujo de Uber for Business opera de forma ininterrumpida sobre Salesforce Agentforce, y su rasgo definitorio es que nadie lo invoca. No espera una consulta: persigue un objetivo de negocio.

1. Detección autónoma. El agente vigila en tiempo real el embudo de registro. Cuando un prospecto se detiene en un paso concreto —la validación de la tarjeta, la estructura de departamentos, la activación de la cuenta—, detecta el evento de abandono de inmediato, sin que nadie se lo pida.
2. Contacto personalizado y multilingüe. Redacta y envía un correo adaptado al punto exacto del bloqueo, a la industria del prospecto y a su comportamiento previo, con soporte nativo en cinco idiomas además del inglés. Todo el intercambio queda registrado de forma transparente en el CRM.
3. Respuestas ancladas en conocimiento aprobado. Para responder dudas técnicas, el agente opera bajo una arquitectura de recuperación aumentada (RAG) estrictamente limitada a una base de unas 300 fuentes internas aprobadas: manuales de producto, guías de cumplimiento, políticas de facturación y ventas. Si el usuario no responde en 24 horas, programa un seguimiento contextualizado.
4. Y aquí el agente se detiene. Cuando toca decidir a qué comercial va ese lead, la inteligencia artificial deja de decidir.

Ese cuarto punto es la pieza más importante del caso de Uber, y es la que casi nadie copia.

Lo probabilístico y lo determinista, separados por diseño

Un modelo de lenguaje es probabilístico por naturaleza. Las reglas de asignación comercial —territorios, jerarquías de cuenta, listas de supresión, acuerdos de nivel de servicio— tienen que ser estrictamente deterministas: no puede pasar que un cliente que ya tiene un ejecutivo asignado sea contactado por otro porque el modelo «creyó» que era una cuenta nueva.

Uber resolvió esa tensión no pidiéndole al modelo que fuera más fiable, sino sacándole esa responsabilidad de las manos. Integró Agentforce con LeanData, una capa de orquestación determinista que ejecuta cuatro cosas sobre el CRM:

• Coincidencia difusa. Compara el lead contra las jerarquías de cuentas existentes sobre seis campos del CRM, con una precisión superior al 95%, para evitar que un cliente actual acabe en la cartera de un comercial de cuentas nuevas.
• Verificación de listas de supresión. Antes de enrutar, comprueba si la empresa ya es cliente activo o tiene una oportunidad abierta. Si hay propietario, el contacto va a él y no entra en el reparto rotatorio.
• Agendado inmediato. El motor BookIt ofrece al cliente un enlace dinámico que ya conoce la zona horaria del comprador, la disponibilidad real del calendario del especialista y los territorios asignados. La reunión se confirma dentro de la propia conversación, sin intercambio de correos.
• Vigilancia del plazo. Si el especialista humano no hace el seguimiento acordado dentro de una ventana de 8 horas hábiles, unos nodos de contención detectan el incumplimiento, alertan al responsable de operaciones de ingresos y reasignan automáticamente la reunión.

Por encima de ambas capas hay una tercera que merece atención propia, porque es la que permite escalar sin que la organización se rompa: la gobernanza centralizada. Un GenAI Gateway —un microservicio en Go que canaliza más de 16 millones de consultas al mes— actúa como punto único de entrada a cualquier modelo de lenguaje e incorpora un redactor automático de información personal identificable, que anonimiza los datos sensibles en la capa de infraestructura antes de enviarlos a modelos de terceros y los restaura al recibir la respuesta. Un segundo gateway, esta vez de MCP, gobierna el acceso de los agentes a herramientas y sistemas internos sin exponer credenciales.

Las licitaciones: seis semanas de la idea a producción

En publicidad, Uber desplegó junto a Accenture y los servicios profesionales de Salesforce un agente de ingesta de RFP construido y puesto en producción en seis semanas. El flujo es deliberadamente sencillo:

1. El comercial sube el documento —PDF, presentación o correo— al registro de la cuenta en Salesforce. Eso dispara un webhook hacia una función serverless conectada con servicios de procesamiento de lenguaje natural en la nube, que extrae el texto depurado y lo escribe en un campo estructurado de la oportunidad.
2. Desde el chat, el comercial escribe «resume esta RFP» o «crea una oportunidad para este cliente». El agente analiza el contenido, extrae presupuestos, fechas de inicio y fin, audiencias objetivo y KPIs, y rellena solo los campos financieros y temporales.
3. A partir de los objetivos del anunciante y de un árbol de decisión ajustado por equipo de ventas, genera un borrador de plan de medios con productos sugeridos, cotizaciones y partidas de facturación, refinable desde el propio chat sin cambiar de pantalla.
4. Al cerrar la campaña, recupera automáticamente los criterios almacenados de la RFP original para compilar el informe de cierre. La búsqueda retrospectiva de archivos desaparece del proceso.

Los resultados

Métrica	Antes	Después
Cobertura de leads entrantes	Fragmentada, limitada a 30 personas	Cercana al 100% de unos 12.000 leads al mes
Leads cualificados sin asignar	10%	Menos del 1%
Cumplimiento de plazo	40% en una ventana de 24 h	85% en una ventana de 8 h
Duración del ciclo de venta	78 días hábiles	25 días
Tasa de cierre	32%	49%
Conversión del embudo global	Línea base del portal	+83%
Conversión de campañas por correo	Tasa orgánica	+60% (verificado a las dos semanas del lanzamiento)
Capacidad total de contacto	Limitada al horario del equipo	+28%
Coste de adquisición	Base asociada al tiempo manual	−23%
Tiempo por licitación (publicidad)	30 minutos netos	5 minutos (−83%)

Merece la pena detenerse en una cifra que se lee rápido y dice mucho: la tasa de cierre pasó del 32% al 49%. Un agente que escribe correos no cierra tratos. Lo que subió el cierre no fue la elocuencia del modelo, sino que el comercial dejó de dedicar el 83% de su tiempo administrativo a transcribir campos y empezó a dedicarlo a negociar. El efecto sobre los ingresos es indirecto, y por eso es sólido.

PepsiCo, Siemens y NVIDIA: probar la fábrica antes de construirla

Medio segundo de retraso y una nave sobredimensionada

Este caso es el más físico de los cuatro y por eso ilustra mejor un límite que conviene tener claro: hay decisiones que no se pueden deshacer.

Históricamente, rediseñar o ampliar una planta de alimentación y bebidas se hacía con planos 2D y modelos CAD 3D estáticos. Esos modelos son representaciones geométricas: enseñan dónde está cada máquina, pero no tienen comportamiento dinámico, ni fricción, ni inercia, ni lógica de automatización. En una línea de embotellado de alta velocidad, donde las máquinas trabajan estrechamente acopladas, esa carencia es demoledora. El ejemplo canónico:

Un microretraso de 0,5 segundos en el ciclo de una tapadora genera una onda de acumulación hacia atrás que detiene la llenadora y desequilibra las encajadoras aguas abajo.

Como esa interacción transitoria no se podía calcular en la fase de diseño, los ingenieros hacían lo único razonable: sobredimensionar. Mesas de acumulación masivas, metros de más de cinta transportadora, acumuladores comprados «por si acaso». Puro seguro pagado en CAPEX.

Y había un segundo coste, mayor. Las colisiones mecánicas, los cuellos de botella y los fallos del código de los autómatas programables no aparecían hasta la puesta en marcha física. Depurar en vivo, sobre equipamiento ya instalado, es un proceso tenso y caro: un error no detectado podía costar entre 50.000 y 500.000 dólares por cada día de retraso de la obra. Construir una planta nueva desde cero, por su parte, son de dos a tres años. Con esos números, la estrategia se reorienta sola hacia extraer la capacidad oculta de los activos que ya se tienen.

Agentes que actúan como codiseñadores

PepsiCo anunció en el CES de 2026, junto a Siemens y NVIDIA, un acuerdo plurianual para convertir el enfoque virtual-first en su estándar de planificación de ingeniería. La arquitectura resultante tiene tres capas:

• Percepción física. Sistemas de visión artificial sobre las líneas de empaque detectan en tiempo real desviaciones de etiqueta, alineación de envases, estabilidad estructural de palés con referencias mixtas y microatascos.
• Gemelo fotorrealista. El Digital Twin Composer de Siemens unifica la información de ciclo de vida del producto alojada en el PLM con datos geométricos y dinámicos, y NVIDIA Omniverse aporta el motor de física. Cada elemento —botellas, cajas, palés, brazos robóticos, vehículos autónomos— lleva masa, inercia, fricción de superficie y rigidez reales.
• IA industrial y control. La telemetría de sensores, autómatas y sistemas de ejecución de fabricación alimenta continuamente el modelo virtual, que se recalibra con datos empíricos en lugar de quedarse congelado el día que se entregó.

Sobre esa base, los agentes de IA actúan como codiseñadores: en lugar de que un ingeniero dibuje a mano diez o veinte alternativas de planta, los agentes exploran de forma autónoma miles de iteraciones espaciales en minutos, evaluando paso de materiales, zonas de congestión y ergonomía, y proponiendo distribuciones que maximizan el volumen en el espacio existente. El método está formalizado en siete fases:

Fase	Qué ocurre
1. Captura y modelado 3D cinemático	Escaneo por nubes de puntos e ingesta de CAD para convertir la instalación real en una réplica con precisión milimétrica y propiedades cinemáticas
2. Ingesta de telemetría	Conexión con autómatas, historiadores SCADA, MES/ERP y sensores para establecer una línea base de rendimiento real
3. Simulación acelerada por agentes	Ejecución masiva de escenarios: velocidades de cinta, capacidad de amortiguamiento, rutas de montacargas, patrones de empaque
4. Aislamiento de cuellos de botella	Algoritmos que separan la restricción primaria real de las paradas secundarias y predicen adónde migrará el cuello si se altera la velocidad de llenado
5. Puesta en marcha virtual	El código real de los autómatas y los programas robóticos se conectan al gemelo en bucle cerrado; se depuran errores lógicos, condiciones de carrera y secuencias de seguridad
6. Validación con personas y congelación del diseño	Los ingenieros evalúan ergonomía, flexibilidad, seguridad y rentabilidad antes de autorizar el design freeze
7. Despliegue físico y realimentación	Instalación con código ya probado; la telemetría en vivo sigue calibrando el gemelo frente al desgaste mecánico real

Hay un cuarto elemento que no aparece en el gemelo digital pero completa el retrato: en la extrusión de aperitivos, un proceso extremadamente sensible a la humedad, la temperatura ambiental y el desgaste de las boquillas, PepsiCo entrenó un agente por aprendizaje por refuerzo profundo sobre un simulador de red neuronal construido con datos históricos reales de la planta. Los ingenieros programaron en el simulador las reglas de calidad y los límites de seguridad, y dejaron que el agente aprendiera sin riesgo de dañar maquinaria ni generar mermas. El «cerebro» resultante lee hoy los datos de calidad a la salida del extrusor y ejecuta ajustes continuos de velocidad de corte, inyección de agua y alimentación de harina directamente sobre los autómatas. Ahí sí hay bucle cerrado: porque el error se corrige en el siguiente segundo.

Los resultados

Indicador	Resultado	Dónde
Throughput de fabricación	+20% de capacidad	Planta de bebidas Gatorade (EE. UU.), en solo 3 meses de despliegue y sin añadir espacio físico
Eficiencia logística	+15%	Uno de los almacenes más antiguos y complejos de la compañía, sin mover una sola máquina
Presupuesto de inversión	Entre un 10% y un 15% menos	Al eliminar el sobredimensionamiento de acumuladores y cintas
Errores de diseño detectados	Hasta el 90%	Interferencias geométricas, colisiones de brazos robóticos y fallos de ruteo, en fase virtual previa a la obra
Validación del control	Cercana al 100%	Código de autómatas, comunicación industrial e interfaces, antes del arranque físico
Tiempo de puesta en marcha	Entre un 40% y un 75% menos	Al trasladar la depuración al espacio virtual
Ciclo de ingeniería y diseño	De meses a días	Fase de planificación de planta

Un detalle de gestión que vale por todo el caso. Para el primer piloto, PepsiCo eligió a propósito uno de sus almacenes más antiguos y complicados, con pasillos estrechos y restricciones estructurales. La razón, en palabras de Athina Kanioura, directora de estrategia y transformación de la compañía:

Si podemos entregar resultados financieros significativos en un almacén con este nivel de complejidad, demuestra cuánta oportunidad existe en toda la organización.

Athina Kanioura, PepsiCo

Es exactamente lo contrario de lo que hace la mayoría de las empresas, que elige el piloto más fácil para garantizar un resultado presentable. Elegir el caso difícil convierte el piloto en una prueba de la tesis, no en una demostración de la herramienta.

Walmart: el inventario que se cura solo

Catorce días de latencia en un negocio de productos frescos

Walmart atiende a más de 240 millones de clientes semanales en más de 10.500 tiendas, con millones de referencias. En el modelo tradicional, la gestión de existencias funcionaba en cinco etapas rigurosamente secuenciales y todas ellas lentas:

1. Detección mediante auditorías físicas periódicas, escaneo manual de códigos de barras y análisis semanal de hojas de cálculo. El problema se veía cuando ya estaba en el estante.
2. Análisis por planificadores humanos sobre promedios históricos estáticos, sin capacidad de incorporar el clima, un pico cultural repentino o un atasco portuario.
3. Decisión de traslado a través de reuniones de coordinación, validaciones presupuestarias y correos cruzados entre gerentes de tienda y responsables de centro de distribución.
4. Planificación logística con asignación manual de rutas y programación telefónica de camiones.
5. Ejecución con órdenes de preparación generadas a mano. Entre tres y diez días desde que se identificaba el problema hasta que se ejecutaba el movimiento; de cinco a catorce desde que se producía el desequilibrio hasta que la mercancía de reemplazo llegaba al estante.

En productos frescos, esa latencia no es una ineficiencia: es merma. Y arrastraba las consecuencias clásicas: efecto látigo, inventario de seguridad defensivo en cada nodo, capital de trabajo inmovilizado, liquidaciones forzosas, roturas de stock recurrentes de entre el 20% y el 25% y una precisión de previsión de demanda de apenas el 55%–65%. A lo que se sumaba un agujero silencioso: el 20% del gasto de cola con proveedores no estratégicos se quedaba sin negociar simplemente porque los compradores no tenían tiempo.

El bucle que se cierra antes del amanecer

El sistema Self-Healing Inventory —inventario de autorrecuperación— está diseñado como un organismo digital autorregulable: detecta desviaciones en el flujo de mercancías y las corrige mediante reasignación proactiva y redireccionamiento físico. Se apoya en cuatro capas:

• Element, la plataforma propietaria de aprendizaje automático sobre Kubernetes, con arquitectura con estado que rastrea la memoria a corto y largo plazo de los agentes.
• WIBEY, la capa de invocación agéntica, que traduce intenciones en acciones orquestadas usando protocolos abiertos: MCP para el descubrimiento y el acceso a contexto, y A2A para la delegación encadenada de tareas entre agentes especializados.
• Enterprise Inventory, un libro mayor unificado que consolida en tiempo real las existencias de tiendas, centros de distribución y canal digital, conectado con el sistema de fulfillment global y el ERP.
• Sensores IoT y RFID desplegados en alianza con Wiliot, que permiten el rastreo continuo de temperatura, ubicación y masa de más de 90 millones de palés a finales de 2026.

Con esa base, el bucle se cierra en cinco pasos y sin intervención previa de nadie:

1. Ingesta multivariable en tiempo real: registros de punto de venta, búsquedas en el comercio electrónico, tendencias detectadas en redes sociales, previsión meteorológica local, congestión portuaria y viaria, y lecturas RFID de palés.
2. Detección de anomalías: se compara la velocidad real de venta contra la demanda prevista local por referencia y tienda. No hace falta que nadie cuente cajas.
3. Evaluación en el gemelo digital de la red —modelos virtuales de más de 1.700 tiendas y centros—, sopesando coste de transporte, vida útil restante del producto y margen por tienda.
4. Decisión y emisión de órdenes «clic cero»: el sistema emite autónomamente la transferencia entre nodos o el desvío de un camión en tránsito. Si un camión iba a la tienda A, que tiene exceso, se redirige a la tienda B, que tiene demanda.
5. Orquestación física antes del amanecer: a las 3:57 en Coyol (Costa Rica), a las 4:12 en Calgary, a las 5:01 en Ciudad de México, los sistemas de almacén automatizado preparan y despachan para que la mercancía optimizada salga antes de que abran las tiendas.

Cuatro superagentes y un negociador incansable

Para evitar la proliferación caótica de herramientas aisladas —lo que internamente llaman agent sprawl—, Walmart no creó decenas de asistentes: consolidó todo en cuatro superagentes, cada uno con un público claro.

• Sparky, para el cliente. Integrado en la aplicación móvil, supera la búsqueda por palabras clave con consultas contextuales por evento («planifica una fiesta temática»), recetas o imágenes. Incorpora recompra autónoma de productos de consumo habitual y eleva el valor medio del pedido un 35% en usuarios activos.
• Marty, para socios y anunciantes. Punto de entrada único para proveedores y marcas: automatiza el alta de catálogos, la gestión de pedidos y la optimización de campañas patrocinadas.
• Wally, para el comercial de compras. Diagnostica la causa raíz de las discrepancias de inventario cruzando ventas, clima y retrasos de proveedores, y reconfigura pedidos de forma proactiva antes de que las estanterías se vacíen.
• El agente de asociados y desarrolladores, para dentro. Centraliza desde la programación de turnos de más de un millón y medio de empleados —que baja de 90 a 30 minutos por responsable— hasta la orquestación de código para ingenieros.

Hay un quinto caso que merece mención aparte porque es probablemente el más replicable para una empresa mediana: la negociación autónoma con proveedores de bienes no destinados a la venta —carritos, transporte, mantenimiento—, el llamado gasto de cola. Un bot agéntico de la plataforma Pactum AI, probado inicialmente en Walmart Canadá con 89 proveedores y 5 compradores, negocia condiciones por chat de forma simultánea con miles de contrapartes.

Variable	Resultado
Tasa de cierre de acuerdos	Entre el 64% y el 68%, frente a un objetivo inicial del 20%
Duración del ciclo	11 días de media por negociación, con hasta 2.000 negociaciones simultáneas
Ahorro financiero	1,5% de media sobre el gasto negociado
Condiciones de pago	Extensión media de 35 días adicionales
Satisfacción del proveedor	4,2 sobre 5, valorando la eliminación de correos y la equidad del proceso

Fíjese en la última fila, porque es contraintuitiva: los proveedores prefieren negociar con el bot. No porque sea más blando, sino porque responde siempre, no hace esperar tres semanas a una respuesta y aplica el mismo criterio a todos. Un proveedor pequeño que antes no conseguía ni una reunión ahora negocia en once días.

Los resultados, y de dónde salen los 55 millones

La cifra más citada del caso Walmart —más de 55 millones de dólares ahorrados— circula a menudo sin contexto, y sin contexto no sirve para nada. Conviene acotarla:

• Alcance geográfico. Corresponde específicamente a las operaciones de la Zona Metropolitana de la Ciudad de México, una de las áreas urbanas más densas del mundo, donde el espacio de trastienda es mínimo y el coste de oportunidad de tener inventario parado es altísimo.
• Mecanismo concreto. Reducción de mermas en perecederos. El sistema actuó como alerta temprana: identificó sobrestock en bodegas locales antes de su fecha de caducidad y lo redirigió automáticamente a tiendas cercanas con alta velocidad de venta, evitando el desecho y la liquidación forzosa de precio.
• Periodo. Fase inicial de despliegue, consolidada entre mediados de 2024 y el ejercicio fiscal 2025, y utilizada después como caso base para la expansión a Costa Rica, Canadá y Estados Unidos.

Indicador	Resultado
Ahorro por merma de inventario	Más de 55 millones de dólares (Ciudad de México, perecederos)
Rotura de stock	Reducción de entre el 20% y el 25%
Precisión de previsión de demanda	Del 55%–65% al 85%–92%
Ventas frente a inventario	Ventas +5,0% con inventario +2,6%: crecer al doble de ritmo que el stock
Velocidad de tendencia a producto	De meses a 6 semanas
Planificación de turnos	De 90 a 30 minutos por responsable
Ruteo logístico	30 millones de millas reducidas

La fila que más dice de la salud del negocio no es la del ahorro, sino la penúltima comparación: ventas creciendo un 5,0% con el inventario creciendo solo un 2,6%. Eso es eficiencia de capital, y es el tipo de resultado que un piloto de innovación nunca produce.

Una advertencia necesaria para no leer mal el caso: aunque Walmart opera en nivel 4 en flujos rutinarios, la red no funciona sin control humano. El modelo se llama internamente autonomía dentro de límites definidos: los ingenieros y responsables de categoría definen las reglas de negocio, los límites de precio y las políticas de riesgo, y cuando un evento supera los umbrales de confianza —una disrupción climática severa, un desbalance de precios anómalo—, el sistema apela a la intervención humana. La autonomía no es ausencia de gobierno: es gobierno expresado por adelantado.

Los cuatro casos, lado a lado

Puestos en paralelo, los contrastes son más informativos que las coincidencias.

Dimensión	Spotify	Uber	PepsiCo	Walmart
Proceso transformado	Mantenimiento y migración de código; planificación de medios	Captación y alta de clientes; ingesta de licitaciones	Diseño de planta y puesta en marcha de automatización	Reposición de inventario y compras de cola
Qué hace el agente	Edita, compila, prueba y se autocorrige durante diez turnos	Detecta el abandono, escribe, responde y agenda	Simula miles de configuraciones y aísla restricciones	Detecta, simula, decide y ejecuta el traslado físico
Dónde entra la persona	Aprueba cada pull request antes del merge	Negocia y cierra; audita el plan de medios	Congela el diseño antes de comprometer capital	Fija límites por adelantado; interviene por excepción
Nivel de autonomía	3 (copiloto agéntico con guardián humano)	3 en la venta, 4 en el contacto y el enrutado	3 (codiseño con congelación humana)	4 en flujos rutinarios de bajo riesgo
Por qué ese nivel	Un cambio malo llega a producción y afecta a millones	Un correo se rectifica; un contrato no	Una máquina mal comprada dura quince años	Un palé mal enviado cuesta cientos de euros
El verificador	Compilador, tests, LLM juez y CI en plataforma nativa	Motor determinista de reglas y jerarquía de cuentas	Motor de física y autómata emulado en bucle cerrado	Gemelo digital de la red y libro mayor unificado
Resultado insignia	650+ PR integradas al mes; 1.000 PR cada 10 días	Ciclo de 78 a 25 días; cierre del 32% al 49%	+20% de throughput en 3 meses sin obra nueva	+55 M$ de merma evitada; 20–25% menos roturas

Nótese una asimetría reveladora: la empresa más tecnológica de las cuatro es la que menos autonomía concede. Spotify, que construye agentes sobre su propia plataforma y tiene a más del 99% de sus ingenieros usándolos cada semana, no deja que ninguno integre una sola línea de código sin firma humana. Walmart, una cadena de supermercados, sí deja que un algoritmo desvíe camiones de madrugada. La diferencia no es la sofisticación de nadie: es que un camión se puede volver a desviar y un despliegue defectuoso a 751 millones de usuarios, no tanto.

Siete lecciones comunes

Estas son las decisiones que repiten los cuatro casos. Cada una viene acompañada de la prueba en al menos dos de ellos, porque una coincidencia en un solo caso no es una lección: es una anécdota.

1. La infraestructura primero, la IA después

Ninguno de estos resultados se explica por el modelo de lenguaje. Se explican por lo que había debajo, construido durante años y por otras razones.

Spotify tenía Backstage —el catálogo de software que mapea qué componente existe, quién es su equipo propietario, cuáles son sus dependencias ascendentes y descendentes— antes de tener agentes. Sin ese mapa, un agente operaría a ciegas. Walmart construyó Enterprise Inventory, un libro mayor único de existencias que unifica tiendas, almacenes y comercio electrónico, antes de liberar agentes autónomos sobre él. PepsiCo tenía su PLM y sus modelos CAD. Uber ancló su agente en unas 300 fuentes de conocimiento curadas y las conectó con sus bases transaccionales.

No se puede automatizar con seguridad lo que no se entiende.

La versión operativa de esta lección es incómoda: la IA agéntica sobre datos fragmentados no produce autonomía, produce caos más rápido. Si su empresa no sabe hoy, con una consulta, cuánto stock tiene y dónde, o quién es el dueño de cada servicio, el problema que tiene no es de inteligencia artificial.

2. Restringir deliberadamente, no maximizar capacidades

Es la lección más contraintuitiva y la que más se incumple. El instinto de todo equipo técnico es dar al agente todas las herramientas posibles «por si acaso». Los cuatro casos hacen lo contrario.

Honk tiene exactamente tres herramientas, con la de Bash sometida a lista blanca. Spotify decidió además no dejar que el agente buscara esquemas en la web, sino inyectarle un prompt estático exhaustivo, porque cada herramienta nueva es una dimensión nueva de imprevisibilidad. El planificador de medios de Ads AI no puede inventar tarifas: está obligado por diseño a llamar a tres funciones concretas contra los sistemas reales. Walmart consolidó decenas de microagentes en cuatro superagentes precisamente para evitar la dispersión.

Traducción práctica: la fiabilidad de un agente sube cuando se estrecha su mundo. Menos herramientas y más contexto es mejor que más herramientas y menos contexto.

3. Separar el razonamiento probabilístico de la ejecución determinista

Un modelo de lenguaje es excelente interpretando lenguaje ambiguo y pésimo garantizando que una regla se cumpla siempre. Los cuatro casos trazan una frontera explícita entre esas dos cosas.

En Uber, Agentforce conversa y comprende; LeanData aplica territorio, jerarquía de cuentas y plazos, y no improvisa nunca. En Spotify, el agente propone el cambio pero quien dictamina si compila es un compilador, no una opinión. En PepsiCo, quien decide si la secuencia de seguridad es correcta es un autómata emulado ejecutando el código real. En Walmart, la decisión agéntica se traduce en una orden en el ERP mediante una integración limpia por API; la aritmética del inventario no la hace el modelo.

El error simétrico y frecuente es pedirle al modelo que gestione directamente la lógica de enrutamiento, precios o cumplimiento. Funciona en la demostración y falla en el percentil 99.

4. El verificador no puede ser el propio agente

Esta es, en mi lectura, la pieza que convierte una demostración en un sistema de producción. Un agente que evalúa su propio trabajo hereda sus propios sesgos: el bucle se cierra sobre sí mismo y deriva.

Spotify pone cuatro filtros independientes entre el agente y producción: compilación y tests deterministas, un segundo modelo que juzga el diff frente al encargo original, integración continua ejecutada en una plataforma nativa distinta y, al final, un revisor humano. El dato de que ese juez veta el 25% de las sesiones no es un signo de fracaso del agente: es la prueba de que el filtro hace falta. Sin él, uno de cada cuatro cambios llegaría a revisión con alcance desviado o con tests comentados.

PepsiCo hace lo mismo en el mundo físico: el verificador es un motor de física con masas, inercias y coeficientes de fricción reales, que dice que dos brazos robóticos colisionan aunque el diseño parezca correcto en pantalla. Walmart simula la decisión en el gemelo digital de la red antes de emitir la orden. Uber comprueba contra la jerarquía de cuentas real antes de enrutar.

Si no puede nombrar quién verifica a su agente, no tiene un sistema agéntico: tiene una demostración.

5. Empezar por la cola larga, no por el proceso estrella

Los cuatro eligieron como primer campo de batalla trabajo de alta fricción y bajo prestigio: tareas costosas en agregado, que nadie reclamaba y que llevaban años sin resolverse.

• Spotify fue a por el 30% residual de las migraciones, el que los scripts no podían y los equipos abandonaban.
• Uber fue a por los leads abandonados que ningún comercial iba a llamar nunca, no a por las cuentas estratégicas.
• Walmart fue a por el 20% del gasto de cola sin negociar y por la merma de perecederos en una ciudad concreta.
• PepsiCo eligió a propósito su almacén más viejo y complicado.

Hay dos razones y ambas importan. La primera es política: nadie defiende un territorio que nadie quería. La segunda es de riesgo: son procesos donde el listón de comparación es bajísimo —el resultado actual es «no se hace»— y donde un error rara vez es catastrófico. Se valida la tecnología y se consigue retorno antes de tocar lo crítico.

6. El nivel de autonomía se elige por el coste del error, no por la madurez técnica

Ya se ha visto en la comparativa, pero conviene enunciarlo como regla porque es directamente aplicable: para cada proceso, pregúntese cuánto cuesta un error y cuánto cuesta deshacerlo. Esas dos respuestas determinan el escalón, y no hay que subir más.

Un error barato y reversible —desviar un camión, enviar un correo de más— admite bucle cerrado. Un error caro e irreversible —comprar maquinaria, publicar código a millones de usuarios, firmar un contrato estratégico— exige una firma humana, por muy bueno que sea el modelo. Y el corolario, que rara vez se dice: subir de nivel no es un logro. Es una decisión de riesgo que hay que poder justificar.

7. Preparar el siguiente cuello de botella antes de crearlo

Es la lección que casi nadie anticipa y que merece su propia sección, porque es lo que separa una transformación sostenible de una que se atasca a los seis meses.

La ironía de la automatización: el cuello de botella se mueve, no desaparece

En 1983, la investigadora Lisanne Bainbridge publicó un artículo sobre sistemas automatizados titulado Ironies of Automation. Su tesis: cuanto más se automatiza un proceso, más críticas y más difíciles se vuelven las tareas que quedan en manos humanas. Spotify cita ese trabajo por su nombre para describir exactamente lo que le pasó.

Al pasar de tardar tres meses a tardar diez días en acumular mil pull requests, el cuello de botella de la compañía se desplazó de la escritura de código a la revisión de código. La frecuencia de pull requests que había que revisar subió un 76%. El trabajo no se evaporó: cambió de sitio y de naturaleza, y pasó a un tipo de tarea —revisar cambios que uno no ha escrito, en repositorios que quizá no conoce— que es más cansada y más difícil de escalar que escribir.

Las tres respuestas de Spotify son tan instructivas como el problema, y se pueden trasladar a cualquier proceso donde un agente produzca más de lo que un humano puede validar:

1. Bandeja de entrada priorizada. Herramientas centralizadas que consolidan las solicitudes de revisión ordenadas por impacto, antigüedad y dominio técnico del revisor. Si el agente multiplica el volumen, la cola necesita criterio, no orden de llegada.
2. Aprobación delegada al líder de la migración. Quien impulsa una estandarización puede aprobar las pull requests agénticas de esa migración sin necesidad de que cada propietario de servicio intervenga de forma síncrona. Se cambia el modelo de gobierno, no solo la herramienta.
3. Criterios de fusión automática segura. Se identifican categorías de cambio de bajo riesgo —documentación, actualización de manifiestos con tests en verde— que pueden integrarse sin humano en el bucle. Es decir: se sube selectivamente al nivel 4 solo donde el coste del error lo permite.

La misma dinámica aparece en los otros casos, aunque con menos dramatismo. En Uber, el cuello pasó de «no hay quien atienda los leads» a «hay que auditar y refinar planes de medios generados por máquina». En Walmart, de contar cajas a definir y mantener las reglas de negocio, los límites de coste y las políticas de riesgo que gobiernan al sistema. En PepsiCo, de verificar interferencias geométricas a evaluar compensaciones de capital y criterios de ergonomía.

Formulada como pregunta para su propio comité de dirección: si mañana este proceso produjera diez veces más output, ¿quién lo revisaría, con qué criterio y en cuánto tiempo? Si no hay respuesta, el proyecto no está listo, por mucho que el agente funcione.

Por dónde empezar: noventa días

Ninguna de estas cuatro empresas empezó con un programa corporativo de IA. Empezaron con un proceso concreto que dolía. Este es el camino más corto entre leer este artículo y tener algo funcionando.

Días 1 a 30: elegir bien y medir el punto de partida

• Elija un proceso de alta fricción y bajo prestigio. Reglas de cribado: se repite muchas veces, nadie lo defiende como territorio propio, un error es barato y reversible, y hoy existe un porcentaje que sencillamente «no se hace». Ese hueco es su 30% residual.
• Mida hoy tres números. Tiempo medio por unidad de trabajo, coste asociado y tasa de error o de abandono. Sin línea base no habrá forma de defender el resultado dentro de seis meses, y todo el mundo discutirá la cifra.
• Escriba las reglas que el agente nunca debe romper. El equivalente a las directivas DO NOT MIGRATE de Spotify. Es un ejercicio de una tarde y es la parte que más previene desastres.
• Compruebe si existe la fuente única de verdad. Si el dato que el agente necesita está en cuatro sistemas que no coinciden, el primer proyecto no es el agente: es unificar ese dato.

Días 31 a 60: construir el bucle, no la demostración

• Dele tres herramientas, no treinta. Y una de ellas debe ser la que verifica el trabajo hecho, no la que lo hace.
• Ponga un verificador que no sea el agente. Puede ser un test automatizado, una consulta contra el sistema transaccional, un motor de reglas o un segundo modelo que juzgue el resultado frente al encargo original. Lo que no puede ser es el mismo agente diciendo que lo ha hecho bien.
• Deje la aprobación final en manos de una persona con nombre. No de un comité, no de «el equipo»: una persona que responde de ese proceso y que puede decir que no.
• Instrumente el bucle desde el primer día. Cuántas veces se reintenta, cuántas veces lo veta el verificador, cuántas se corrige solo. Sin esos tres contadores no sabrá si el sistema mejora o solo produce más.

Días 61 a 90: abrir el cuello de botella que usted mismo ha creado

• Mida cuánto trabajo llega ahora a revisión y cuánto tarda en salir. Si el tiempo de espera en revisión ha crecido más que lo que ha bajado el tiempo de ejecución, no ha ganado nada: ha movido el problema.
• Defina qué categorías pueden aprobarse solas. Igual que Spotify con la documentación y los manifiestos con tests en verde: liste los casos de bajo riesgo y súbalos a bucle cerrado, de uno en uno y con métricas.
• Decida conscientemente si sube o baja de nivel. Bajar también es una respuesta legítima: si el verificador veta demasiado, el problema está en el encargo, no en el modelo.
• Redacte la regla de gobierno. Quién puede cambiar los límites del agente, con qué aprobación, y qué eventos disparan una revisión humana obligatoria. Es lo que Walmart llama autonomía dentro de límites definidos, y conviene tenerlo escrito antes de necesitarlo.

Conclusión: lo que separa estos casos de los pilotos que no llegan

Hay una tentación comprensible al leer estas cifras: pensar que la diferencia entre Spotify y una empresa normal es el presupuesto, el talento o el acceso a modelos punteros. La evidencia de los cuatro casos apunta en otra dirección.

Lo que separa un proceso transformado de un piloto que no llega a ninguna parte no es el modelo. Es que alguien se sentó a hacer cuatro cosas nada glamurosas: describir un proceso con precisión suficiente para que una máquina lo entienda, unificar el dato del que depende, decidir quién verifica el trabajo y aceptar que el trabajo humano va a cambiar de sitio. Las cuatro empresas hicieron exactamente eso, y ninguna de las cuatro empezó por el modelo.

Si tiene que quedarse con tres frases de todo el artículo, que sean estas:

• La infraestructura decide el techo. Backstage, Enterprise Inventory, el gemelo digital y las 300 fuentes curadas se construyeron antes y por otras razones. El agente solo cobró el rendimiento de esa inversión.
• La restricción produce fiabilidad. Tres herramientas, reglas de exclusión explícitas y llamadas obligatorias a sistemas reales rinden más que un agente con acceso libre y buenas intenciones.
• El verificador es el producto. El compilador, el juez, el motor de física, el gemelo digital y el motor de reglas son lo que convierte una demostración impresionante en un proceso que se puede dejar corriendo de noche.

Y si va a hacer una sola cosa después de leer esto, haga esta: identifique en su empresa el proceso que hoy solo se completa «al 70%» —ese donde todos saben que queda un resto que nunca se termina— y pregúntese quién podría verificar automáticamente ese 30% si alguien lo hiciera. Esa respuesta, y no la elección de proveedor, es el principio de todo lo demás.

Nota sobre datos y fuentes

Las cifras de este artículo proceden de estudios de caso técnicos elaborados a partir de fuentes corporativas y de sus socios tecnológicos: publicaciones de ingeniería y presentaciones en conferencias del sector en el caso de Spotify; historias de cliente de Salesforce y LeanData, el blog de ingeniería de Uber y material de Accenture en el caso de Uber; el comunicado conjunto de PepsiCo, Siemens y NVIDIA del CES 2026, los blogs de Siemens y la cobertura especializada posterior en el caso de PepsiCo; y registros corporativos de Walmart Global Tech junto a material de Pactum AI y prensa de cadena de suministro en el caso de Walmart.

Conviene leerlas con la cautela que merece su origen. Son métricas mayoritariamente autorreportadas, publicadas por empresas y proveedores con un interés comercial evidente en que el resultado luzca bien, y en varios casos corresponden a pilotos o a despliegues acotados geográficamente —los 55 millones de Walmart son de un área metropolitana concreta, el +20% de throughput de PepsiCo es de una planta— y no a la totalidad de la operación. Las líneas base del «antes» también las eligen las propias compañías.

Son hechos verificables las arquitecturas descritas, los componentes tecnológicos, las secuencias de proceso y las cifras publicadas. Es interpretación propia de Transformalix la lectura de los cuatro niveles de autonomía aplicada a los cuatro casos, la tesis de que el escalón se elige por el coste y la reversibilidad del error, la síntesis de las siete lecciones y todo el contenido del plan de noventa días.

---

En Transformalix, ayudamos a empresas a llevar la IA agéntica del piloto al proceso: identificar qué procesos son candidatos reales, ordenar el dato del que dependen, diseñar el bucle de verificación y decidir qué nivel de autonomía admite cada decisión. Si quieres saber cuál de tus procesos está listo para dejar de ejecutarse a mano, hablemos.