Have you ever watched a movie without knowing much about it or expecting it to be good, and it completely surprised you?
I’m looking for movies like that. What was yours?
Part one was about the courage to get started. This one is about the discipline of not staying in the 95%. Ng gives you the pattern to grow from one agent to a network without losing coherence. Gates forces you to decide that architecture before complexity forces you to decide it badly. Mollick reminds you that trust in an agent isn’t a checkbox you tick once. And MIT, with hard data, confirms what you probably already suspected: the difference between a pilot that impresses in a demo and an agent that actually moves the needle for your business isn’t which platform you picked — it’s whether you redesigned the process, whether you measured the right thing, and whether you had the humility to bring in specialized help before the project became one more anecdote in the statistics.
El 95% de los pilotos de IA generativa no llega a producción. Cinco movimientos concretos para que el tuyo esté en el otro 5%.
Segunda parte de la serie sobre agentes de IA en un landscape SAP
En la primera parte dejamos una receta de seis pasos para arrancar el journey de agentes de IA sobre un landscape SAP: elegir un proceso real, elegir la capa de agentes según tu curva de aprendizaje, diseñar con los cuatro patrones de Ng, gobernar los permisos al estilo Mollick, resolver interoperabilidad al estilo Gates, y escalar a pro-code solo cuando el caso lo exija.
Supongamos que hiciste bien la tarea: el piloto de conciliación de disputas o de aprobación de compras funciona, el dueño de proceso está contento, y ahora la pregunta cambia. Ya no es "¿cómo arranco?" sino "¿cómo hago que esto deje de ser un experimento aislado?". Ahí es exactamente donde la mayoría de los proyectos de IA se rompen.
El informe "The GenAI Divide: State of AI in Business 2025" del MIT NANDA es contundente: el 95% de los pilotos de IA generativa en empresas no logran pasar a producción ni generar retorno medible. Lo interesante no es el número, es el motivo.
95% de los pilotos no llega a producción; el 5% que escala rediseña el proceso, aprende de las correcciones y suele apoyarse en un partner de dominio (MIT NANDA, 2025).
El reporte encuentra que los pilotos que fracasan comparten un patrón: usan herramientas genéricas que lucen bien en una demo pero son frágiles frente a un flujo de trabajo real, no retienen contexto ni aprenden de las correcciones del usuario, y las empresas miden adopción (logins, sesiones de chat) en vez de medir si el proceso de negocio realmente cambió. El 5% que sí escala hace lo contrario: rediseña el flujo de trabajo en vez de superponer el agente sobre el proceso existente, construye una capa de memoria que aprende de cada corrección, y —dato relevante para el mundo SAP— tiene el doble de probabilidad de éxito cuando se apoya en un partner especializado del dominio en vez de construir todo in-house.
Traducido a un landscape ECC o S/4HANA: si tu agente de aprobación de compras "funciona" pero nadie cambió el flujo de aprobación en sí, ni el agente aprende de las excepciones que el comprador corrige a mano cada semana, no tienes un piloto exitoso — tienes una demo cara esperando a ser abandonada.
Los cinco movimientos: métrica, arquitectura, confianza, interoperabilidad y partners.
MOVIMIENTO 1 · MÉTRICA
Cambia la métrica antes de pedir más presupuesto
Si tu tablero mide cuántos usuarios abrieron el agente o cuántas conversaciones tuvo, estás midiendo lo mismo que mide el 95% que fracasa. Mide en cambio el porcentaje de aprobaciones de compra, conciliaciones o tickets que el agente resuelve de punta a punta sin intervención humana, cuánto bajó el tiempo de ciclo del proceso en tu SAP, y qué tan seguido el agente aprende de una corrección para no repetir el mismo error. Esa es la diferencia entre "adopción" y "transformación" que marca el informe del MIT.
MOVIMIENTO 2 · ARQUITECTURA
Decide cuándo pasas de un agente a una red de agentes
Gates lo planteaba como pregunta abierta en su ensayo original: ¿un asistente único o una red de agentes especializados? Con el primer proceso ya en marcha, la respuesta empieza a aparecer sola. Cuando la tarea cruza módulos —una disputa de cobranza que toca FI, SD y gestión de crédito a la vez— un solo prompt gigante se vuelve inmanejable. Ahí aplica el patrón de multi-agent collaboration que Ng describe: un agente orquestador que descompone el caso y delega en agentes especializados por dominio, cada uno con su propio acceso acotado a las tablas y BAPIs que le corresponden. No fragmentes por moda; fragmenta cuando la complejidad del proceso lo exige, y solo entonces.
MOVIMIENTO 3 · CONFIANZA
Sube la autonomía como una escalera, no como un interruptor
Mollick, en su escrito más reciente sobre convivencia con sistemas cada vez más autónomos, es honesto sobre algo incómodo: la relación de confianza con un agente no se resuelve una vez, se "negocia y renegocia" todo el tiempo a medida que la capacidad del sistema cambia. En la práctica, eso significa construir niveles explícitos de autonomía sobre tu proceso SAP en vez de un botón de encendido/apagado: el agente que solo sugiere y un humano ejecuta, el agente que ejecuta acciones reversibles (crear un borrador de pedido) y notifica, y recién en un tercer nivel el agente que contabiliza documentos financieros de forma autónoma dentro de límites estrictos, con auditoría por muestreo. Cada salto de nivel se gana con evidencia del nivel anterior, no con la fecha del roadmap.
Autonomía como escalera: la confianza se negocia nivel por nivel, no con un botón de encendido/apagado.
MOVIMIENTO 4 · INTEROPERABILIDAD
No le prometas a tu directorio una interoperabilidad que la plataforma todavía no tiene
La arquitectura de referencia de SAP para A2A y MCP es honesta al respecto: hoy el Agent Gateway que expone los agentes Joule vía protocolo A2A todavía no está disponible en general (GA), y la comunicación soportada es unidireccional —Joule puede invocar agentes externos ("bring your own agent"), pero la exposición completa hacia afuera todavía está en construcción—. Esto no invalida el consejo de la primera parte de priorizar estándares abiertos; lo que cambia es la secuencia: usa el MCP Gateway del Integration Suite para exponer hoy tus capacidades de SAP como herramientas gobernadas, y planea la malla de agentes bidireccional como una fase siguiente, no como un supuesto de la arquitectura inicial.
MOVIMIENTO 5 · PARTNERS
Compra experiencia de dominio antes que reinventarla
El propio informe del MIT lo cuantifica: las implementaciones con un partner especializado tienen el doble de tasa de éxito que las construidas enteramente puertas adentro. Tiene sentido en un landscape SAP — el riesgo no está en el modelo de lenguaje, está en modelar correctamente cómo una disputa de cobranza, una orden de venta bloqueada o una excepción de crédito se comportan realmente en tus datos maestros de ECC o S/4HANA. Ya sea un partner del ecosistema SAP, el equipo del hyperscaler o un integrador especializado, prioriza a quien ya se equivocó con esos procesos antes que a quien recién está aprendiendo con tu implementación como primer caso.
| EJEMPLO EN EL ECOSISTEMA SAP Onibex, LLC · Workforce 2.0 Onibex es un partner especializado en SAP con recorrido en migraciones ECC a S/4HANA, servicios de AMS y, más recientemente, en agentes de IA en tiempo real sobre eventos (junto a Confluent). Su solución Workforce 2.0 aparece en el directorio de partners de IA de SAP como una propuesta de agentic AI gobernada para S/4HANA — es decir, exactamente el tipo de apuesta que describe este quinto movimiento: partir del conocimiento de dominio que un integrador ya tiene sobre cómo se comportan tus procesos reales, en lugar de construir esa curva de aprendizaje desde cero puertas adentro. Ver la ficha de Onibex, LLC · Workforce 2.0 en SAP.com → |
|---|
La primera parte era sobre el coraje de empezar. Esta es sobre la disciplina de no quedarse en el 95%. Ng te da el patrón para crecer de un agente a una red sin perder coherencia. Gates te obliga a decidir esa arquitectura antes de que la complejidad te obligue a decidirla mal. Mollick te recuerda que la confianza en un agente no es un checkbox que se marca una sola vez. Y el MIT, con datos duros, confirma lo que probablemente ya sospechabas: la diferencia entre un piloto que impresiona en una demo y un agente que de verdad mueve la aguja de tu negocio no está en qué plataforma elegiste, está en si rediseñaste el proceso, si mediste lo correcto, y si tuviste la humildad de traer ayuda especializada antes de que el proyecto se convirtiera en una anécdota más de la estadística.
P: ¿Cómo sé si mi piloto de agentes está listo para escalar o es en realidad una demo cara?
Revisa tres señales, no una: ¿el flujo de trabajo se rediseñó de verdad o el agente solo se superpuso al proceso viejo? ¿Existe una capa de memoria que aprende de las correcciones que el usuario hace cada semana? ¿Mides el porcentaje de casos resueltos de punta a punta, o solo cuántas veces se abrió el chat? Si la respuesta a cualquiera de esas es "no", según el MIT NANDA estás en el 95%, no en el 5%.
P: ¿Qué debo medir en vez de logins o sesiones de chat?
Tres números por proceso: el porcentaje de casos (aprobaciones, conciliaciones, tickets) que el agente resuelve de punta a punta sin intervención humana; la reducción del tiempo de ciclo del proceso dentro de tu ECC o S/4HANA; y la frecuencia con la que el agente incorpora una corrección para no repetir el mismo error. Esos tres indicadores describen transformación de proceso, no adopción de herramienta.
P: ¿Cuándo conviene pasar de un solo agente a una red de agentes especializados?
Cuando la tarea empieza a cruzar módulos —por ejemplo, una disputa de cobranza que toca FI, SD y gestión de crédito a la vez— y un solo prompt se vuelve inmanejable. Ahí conviene un agente orquestador que descompone el caso y delega en agentes especializados, cada uno con acceso acotado a las tablas y BAPIs de su propio dominio. Fragmentar antes de tener esa complejidad solo añade coordinación innecesaria.
P: ¿Cómo subo el nivel de autonomía sin poner en riesgo mis datos financieros?
Construyendo niveles explícitos en vez de un interruptor único: primero un agente que solo sugiere y un humano ejecuta; luego un agente que ejecuta acciones reversibles (como crear un borrador de pedido) y notifica; y solo en un tercer nivel, con evidencia acumulada de los anteriores, un agente que contabiliza documentos financieros de forma autónoma dentro de límites estrictos y con auditoría por muestreo. Cada salto se gana con datos del nivel anterior, no con el calendario del proyecto.
P: ¿Ya puedo conectar Joule con agentes externos vía A2A hoy mismo?
Parcialmente. Según la arquitectura de referencia de SAP, Joule ya puede invocar agentes externos ("bring your own agent"), pero el Agent Gateway que expondría los agentes Joule hacia afuera vía A2A todavía no está disponible en general (GA) — hoy la comunicación soportada es unidireccional. La ruta recomendada mientras tanto es usar el MCP Gateway del Integration Suite para exponer capacidades de SAP como herramientas gobernadas, y tratar la malla de agentes bidireccional como una fase posterior.
P: ¿Por qué el informe del MIT recomienda un partner especializado en vez de construir todo puertas adentro?
Porque el informe encuentra que las implementaciones con un partner especializado en el dominio tienen el doble de tasa de éxito que las construidas enteramente in-house. En un landscape SAP el riesgo mayor no está en el modelo de lenguaje, está en modelar bien cómo se comportan realmente tus datos maestros y tus procesos (una disputa de cobranza, una orden bloqueada, una excepción de crédito). Quien ya se equivocó con esos procesos en otros clientes llega más rápido a una versión que funciona.
P: ¿Qué es Workforce 2.0 de Onibex y cómo encaja en estos cinco movimientos?
Workforce 2.0 es la solución de agentic AI gobernada para S/4HANA de Onibex, un partner del ecosistema SAP con recorrido previo en migraciones ECC a S/4HANA y en agentes de IA en tiempo real. Encaja directamente en el quinto movimiento de este artículo: apoyarse en experiencia de dominio ya probada en vez de reinventarla desde cero. Puedes ver el detalle en su ficha de partner en SAP.com.
MIT NANDA, "The GenAI Divide: State of AI in Business 2025".
Jason Snyder, "MIT Finds 95% Of GenAI Pilots Fail Because Companies Avoid Friction", Forbes.
Andrew Ng, "Agentic Design Patterns Part 5: Multi-Agent Collaboration", The Batch, DeepLearning.AI.
Bill Gates, "AI is about to completely change how you use computers", GatesNotes.
Ethan Mollick, "Co-Existence and the End of Co-Intelligence", One Useful Thing.
SAP, "A2A and MCP for Interoperability", SAP Architecture Center.
SAP Community, "Joule A2A: Connect Code Based Agents into Joule".
SAP, "Onibex, LLC | Workforce 2.0", SAP Partner Directory.
We have S/4HANA on prem as a source and we need the data in Snowflake with low latency, including deletes.
What we have ruled out so far: ODP and RFC based extraction, because of SAP Note 3255746. OData on top of CDS views works but it is pull based, and it gives us no reliable way to capture deletes without reconciling full snapshots.
That leaves SAP's own event mechanisms, BOR, RAP and BTE, which push a notification whenever a business object changes. On paper that solves both the latency and the delete problem.
Has anyone actually landed this in Snowflake? Curious specifically about the landing path, whether you go Kafka connector, Snowpipe Streaming, or Openflow, and how you handle the initial full load and stitch it to the event stream without gaps or duplicates. Also interested in how people are doing the MERGE side, since the events arrive at table level and header and item rows do not always show up in order.
[ Removed by Reddit on account of violating the content policy. ]
