El costo de automatizar el job equivocado: cómo diseñar agentes de IA desde el job To Be Done Agentico, la decisión y el valor (Capítulo 1 de 4)
Nada de lo que estamos viendo con la IA agéntica es nuevo, salvo la velocidad. Por eso en esta nueva saga me propuse desarmar el concepto de Job To Be Done, la tarea real que un cliente contrata cuando compra, aprende o delega trabajo, para separar lo que efectivamente cambia (la interfaz, quien la ejecuta) de lo que no cambia nunca (la tarea).
Arrancamos por el fenómeno más antiguo del comercio: la demanda. No nació con internet, como muchos todavía creen. Nació hace más de 3.000 años, y desde los fenicios hasta el agente conversacional, cada revolución tecnológica resolvió exactamente el mismo problema con otra herramienta. El agente de IA es apenas el último.
Y ahí está el error más caro que puede cometer un ecommercionista hoy: tratar al agente como si fuera la novedad, sin saber qué job le está delegando. Si administrás un ecommerce y estás evaluando incorporar IA agéntica en atención, recomendación o fulfillment sin haber respondido primero esa pregunta, tenés que leer esta columna. Automatizar sin saber qué tarea estás resolviendo no es innovación. Es pagar más caro el mismo error, más rápido.
***
Un mercader fenicio en el siglo IX antes de Cristo tenía un problema de negocio clarísimo: llevar aceite y cerámica de donde sobraban a Tiro o Sidón, y volver con estaño de Britania o plata de Iberia, para fundir bronce. Fundaron colonias en Cartago, Sicilia, Cerdeña, y en lo que hoy es Marsella, Barcelona, Cádiz y Málaga, no para expandir territorio, sino para sostener esa cadena de intermediación.
El dato que casi nadie recuerda es cuánto valía resolver ese problema, pero resolverlo bien. Hacían falta hasta 12.000 caracoles múrex para producir apenas un gramo de tinte púrpura, según documenta la biblioteca de la Universidad de Chicago, y ese tinte terminó siendo la moneda de estatus de la realeza mediterránea. La World History Encyclopedia los describe directamente como la primera superpotencia comercial del Mediterráneo.
¿Por qué arrancar una saga sobre inteligencia artificial agéntica con un mercader fenicio? Porque el Job To Be Done —la tarea real que un cliente contrata cuando compra, aprende o delega trabajo—, un concepto que Clayton Christensen desarrolló en Competing Against Luck (2016), es exactamente el mismo job que resuelve cualquier ecommerce hoy: mover un bien de donde sobra a donde falta, reduciendo la fricción entre oferta y demanda.
Christensen lo resume con una idea que vale la pena releer dos veces: los clientes no compran productos, los «contratan» para lograr progreso en una circunstancia particular. Si el producto cumple, lo vuelven a contratar. Si no, lo despiden.
El ejemplo que Christensen usó para probarlo es el de una cadena de comida rápida que quería vender más batidos. Según documentó Carmen Nobel en HBS Working Knowledge (14 de febrero de 2011), descubrieron que el 40% de los batidos se vendían temprano a la mañana, a viajeros que los pedían para llevar. El job no era «tomar algo rico». Era tener algo sostenible con una mano, que no ensuciara el auto, y que aguantara el hambre hasta el mediodía. El batido competía con una banana o una dona, no con otro batido. Ese desvío de diagnóstico, vender el producto en lugar de entender el job, es la misma razón por la que Christensen sostiene que entre el 75% y el 85% de los productos nuevos fracasan en el mercado. Es imperdible este podcast donde se habla sobre los trabajos que deben hacerse, sin perder el hilo de la innovación.
Un barco, un catálogo, una tienda, una aplicación y un agente pueden cerrar la brecha entre lo que alguien necesita y aquello que puede satisfacer esa necesidad. Pero ninguno de ellos sabe, por sí mismo, qué progreso intenta lograr esa persona. Son medios, interfaces y ejecutores. No es el job.
El comercio cumple desde hace milenios una función estructural: conectar la oferta y la demanda, reducir fricciones y facilitar el intercambio. Pero “mover un producto de donde sobra a donde falta” todavía no constituye un Job to Be Done lo suficientemente preciso para diseñar una experiencia, mucho menos para delegar decisiones a un agente. El job aparece cuando incorporamos a la persona, su circunstancia y el progreso que busca: alimentarse durante un viaje sin interrumpirlo, recibir un producto antes de tomar un avión, obtener información confiable durante un duelo o resolver una devolución excepcional sin quedar atrapado en una política estándar.
La diferencia no es semántica. Es operativa. Buscar, hacer clic, preguntar, reclamar, comparar o abrir un ticket son interacciones observables. Pueden revelar el job, pero no demuestran que haya sido comprendido ni resuelto. Una empresa puede automatizar perfectamente esas señales y seguir equivocándose respecto de la tarea real. Puede responder en segundos, recomendar un producto, cerrar el caso y mejorar el tiempo promedio de atención mientras la persona continúa exactamente en el mismo lugar en el que comenzó.
Por eso, antes de elegir qué agente desplegar, hay que identificar qué decisión requiere esa tarea: recomendar, prometer, reservar, sustituir, compensar, ejecutar o escalar. Recién entonces podemos determinar quién debe tomarla —una persona, un sistema, un copiloto o un agente— y cómo demostrar que produjo progreso real. La tecnología puede acelerar el recorrido. La empresa no puede determinar cuál era el destino.
“Un agente puede cerrar la brecha entre la necesidad y la respuesta. Pero solo una empresa que entiende el job puede convertir esa respuesta en progreso.” Marcos Pueyrredon
Esto, inevitablemente, me recuerda las Cinco enseñanzas que me dejó el «Harvard Experience»? y que el digital commerce actual debería interpretar rememorando al gran Ayrton Senna!. Vean, es una lectura de junio de 2022. Cuatro años después, seguimos reforzando este concepto, todavía más enfocados en los desafíos que plantea la IA agéntica.
Ahora traigamos esto a 2026. La pregunta que tiene que hacerse cualquier empresa que está delegando atención, recomendación o fulfillment a un agente de inteligencia artificial es exactamente la misma que tenía que hacerse esa cadena de comida rápida: ¿qué job estoy resolviendo? Porque si no lo sabe, automatiza el síntoma (responder rápido, cerrar el ticket, empujar el carrito) y no la tarea real del cliente.
Gartner proyectó en junio de 2025 que más del 40% de los proyectos de IA agéntica se cancelarán antes de que termine 2027, debido a costos que escalan, un valor de negocio poco claro o controles de riesgo insuficientes. La analista de Gartner, Anushree Verma, fue más dura todavía: la mayoría de los proyectos agénticos de hoy son experimentos tempranos empujados por el hype, mal aplicados. McKinsey, en su State of AI de 2025, midió lo mismo desde otro ángulo: el 62% de las organizaciones ya trabaja con agentes, pero sólo el 23% está escalando alguno en al menos una función, y en cualquier función puntual, no más del 10% llegó a escala real.
Hay que detenerse en este punto porque Gartner no atribuye la cancelación de esos proyectos a una mala comprensión del Job to Be Done. Las causas que declara son concretas: costos crecientes, un valor de negocio poco claro y controles de riesgo insuficientes. Convertir mi interpretación en una conclusión de Gartner sería cometer el mismo error que esta saga intenta cuestionar: confundir una señal observable con la causa profunda que puede explicarla. Gartner describe dónde podrían terminar muchos proyectos. #JTBDAgentico propone investigar desde dónde comenzaron a desviarse.
Mi hipótesis es que, detrás de una parte de esos costos que escalan, de ese valor que no logra demostrarse y de esos controles que llegan tarde, existe una falla previa al modelo, al proveedor y hasta al propio agente: la empresa no definió con suficiente precisión qué progreso debía producirse, qué decisión estaba delegando y cómo iba a comprobar que el job había sido resuelto. Cuando el job es ambiguo, también lo es el caso de negocio. Y cuando la decisión no está delimitada, el proyecto empieza a incorporar más datos, más integraciones, más prompts, más excepciones y más supervisión para compensar una definición que nunca fue clara desde el comienzo.
Esa ambigüedad se convierte rápidamente en un costo operativo. Si el objetivo declarado es “mejorar la atención”, “personalizar la experiencia” o “vender más”, el agente no tiene una tarea lo suficientemente precisa: tiene una aspiración corporativa. No sabe si debe recomendar, prometer, reservar, sustituir, compensar, ejecutar o escalar. Tampoco sabe qué fuente de verdad prevalece, qué error puede tolerarse, qué acción requiere confirmación o cuándo debe devolver la decisión a una persona. La autonomía no puede diseñarse antes que la decisión, porque el nivel de autonomía depende del impacto, de la reversibilidad y del costo de equivocarse.
Lo mismo ocurre con el valor. Una empresa puede demostrar que el agente respondió más rápido, manejó más conversaciones o redujo el costo por contacto y, aun así, no demostrar que haya producido progreso para el cliente ni resultado para el negocio. Sin un job concreto no existe una métrica de resolución; solo quedan métricas de actividad. El ticket cerrado puede reabrirse, la recomendación puede derivar en una devolución, la promesa puede incumplirse y el ahorro inicial puede reaparecer como escalamiento humano, compensación, abandono o pérdida de confianza. Por eso, el problema no es solo que algunas organizaciones estén desplegando agentes demasiado pronto. Es que muchas están intentando justificar la tecnología antes de haber definido con precisión la tarea, la decisión y el resultado.
Separar estas capas es esencial para preservar la integridad de esta saga. Gartner aporta el pronóstico. McKinsey muestra la brecha entre la experimentación y la escala. Los casos permiten observar las consecuencias. La hipótesis de #JTBDAgentico es que una parte de esa brecha comienza antes de la tecnología: cuando la organización automatiza una interacción que puede medir, en lugar de diagnosticar el progreso que realmente debería producirse.
“El costo del agente no empieza cuando el modelo se equivoca. Empieza cuando la empresa invierte en automatizar una tarea que nunca aprendió a definir.” Marcos Pueyrredon
Los dos casos más citados del último año y medio muestran exactamente ese error de diagnóstico. El chatbot de Air Canada le prometió a un pasajero una tarifa de duelo retroactiva que la política vigente de la aerolínea no contemplaba. Air Canada argumentó ante el tribunal que el chatbot era una entidad legal separada, responsable de sus propias respuestas. El Civil Resolution Tribunal de Canadá no lo vio así: el fallo estableció que no importa si la información sale de una página estática o de un chatbot, la responsabilidad es de la empresa, y calificó el caso de negligencia en la representación de los hechos (CBS News). Air Canada automatizó la respuesta rápida. No resolvió el job real del pasajero, que consistía en contar con información confiable en un momento en que el pasajero estaba de duelo.
Klarna hizo el camino inverso y resulta aún más revelador. En febrero de 2024, anunció que su asistente de IA hacía el trabajo de 700 agentes humanos y gestionaba 2,3 millones de conversaciones, lo que redujo el tiempo de resolución de 11 minutos a menos de 2 minutos. Quince meses después, en mayo de 2025, el propio CEO Sebastian Siemiatkowski admitió el error: se enfocaron demasiado en el costo, y el resultado fue menor calidad, así que volvieron a contratar personas (Forbes, 2025). El dashboard medía volumen. No medía si el job del cliente, sentirse resuelto y no solo atendido, se estaba cumpliendo.
El problema es que una interacción cerrada sin resolución no necesariamente reduce el costo: muchas veces solo lo desplaza a otra parte de la organización. El ticket desaparece del tablero de atención, pero reaparece como una segunda consulta, una reapertura, una derivación a un supervisor, una devolución, una compensación, una cancelación o una promesa que Operaciones deberá intentar reparar. Lo que parecía eficiencia en el frontstage puede convertirse en complejidad, trabajo manual y un mayor costo de servicio en el backstage. La organización celebra que ha respondido más rápido, mientras otra área asume el costo de aquello que nunca se resolvió.
Este desplazamiento es especialmente peligroso porque los indicadores tradicionales suelen fragmentar el resultado. Atención: mide el tiempo de respuesta y el número de tickets cerrados. Ecommerce observa conversión. Operaciones analizan devoluciones y cancelaciones. Finanzas registra compensaciones. Marketing intenta reconstruir la confianza perdida. Cada área puede mejorar parcialmente su indicador y, aun así, el sistema completo puede estar destruyendo valor. El job pertenece al cliente, pero su costo termina por distribuirse entre áreas que no siempre comparten el mismo owner, la misma información ni la misma definición de éxito.
Por eso, medir únicamente el costo por contacto puede generar una ilusión de productividad. Un contacto barato que genera otros tres contactos, requiere intervención humana o termina en una devolución no fue realmente barato. Del mismo modo, reducir el tiempo promedio de atención no demuestra que la tarea haya sido completada; solo indica que la interacción terminó antes. La métrica relevante debe desplazarse de «cuánto cuesta responder» a «cuánto cuesta resolver efectivamente», incorporando la recurrencia, la reapertura, el escalamiento, el error de política, la promesa cumplida y la necesidad de reparación posterior.
El desplazamiento del costo por contacto al costo por resolución efectiva exige algo más que cambiar el nombre de un indicador. Obliga a reconstruir el recorrido completo de la interacción e identificar dónde la organización declaró el éxito antes de tiempo. Para hacer visible esa brecha, propongo el Job–Interaction Resolution Gap Ledger, una herramienta de auditoría que permite comparar lo que el sistema registra con lo que la persona realmente necesitaba resolver. El ledger no comienza por evaluar si el agente respondió correctamente o si redujo el tiempo del proceso. Comienza preguntando qué journey estamos observando, qué interacción ocurrió, qué job suponemos que existe y qué evidencia valida esa interpretación. Desde allí conecta la decisión ejecutada con el KPI que hoy premia a la empresa y con el indicador que debería demostrar resolución. Su propósito es simple pero incómodo: revelar automatizaciones que parecen eficientes porque cierran interacciones, aunque generen reaperturas, escalamiento humano, devoluciones, compensaciones o nuevos costos en otra parte de la operación.
El ledger debe leerse como una auditoría en cuatro movimientos. Primero, observar sin interpretar prematuramente: seleccionar un journey o flujo y registrar la interacción que efectivamente ocurrió. Segundo, formular un job hipotético, pero exigir evidencia para validarlo: comportamiento, entrevistas, búsquedas, tickets, recurrencia o alternativas que el cliente haya utilizado. Tercero, identificar qué decisión ejecutó el sistema y comparar el KPI actual —tiempo de respuesta, tickets cerrados, conversaciones o costo por contacto— con un KPI de resolución, capaz de mostrar si el job avanzó o permaneció abierto. Allí aparecen las señales que suelen quedar fragmentadas entre áreas: reapertura, recurrencia, escalamiento humano y costo de error. Finalmente, el ledger obliga a asignar un owner y tomar una decisión explícita: mantener, investigar, rediseñar o detener la automatización. Su valor en este capítulo radica que transformar “atender no es resolver” en una disciplina de diagnóstico aplicable. Ya no se trata de una crítica conceptual al dashboard, sino de un mecanismo para descubrir dónde la eficiencia local está trasladando costos, destruyendo el aprendizaje o premiando una falsa resolución.
El ledger permite detectar la brecha visible entre la interacción cerrada y el job aún abierto. Pero existe, además, un costo menos evidente y potencialmente más grave: el aprendizaje equivocado del sistema. Si el agente registra como éxito cada conversación finalizada, cada carrito empujado o cada ticket cerrado, aprende a repetir el comportamiento que produce esa señal, aunque el cliente continúe sin resolver su necesidad.
Si el agente registra como éxito cada conversación finalizada, cada carrito empujado o cada ticket cerrado, aprende a repetir el comportamiento que produce esa señal, aunque el cliente continúe sin resolver su necesidad. La automatización no solo ejecuta una mala definición: puede convertirla en patrón. Y cuanto mayor sea el volumen, más evidencia aparente generará para confirmar que la estrategia funciona. El dashboard mostrará la eficiencia precisamente porque fue diseñado para no observar dónde reaparece el problema.
Ahí comienza la verdadera deuda operativa agéntica: una política incorrecta ejecutada de manera consistente, una métrica parcial interpretada como valor y un sistema que aprende de resultados que nunca debieron considerarse exitosos. La velocidad deja entonces de ser una ventaja. Se convierte en el mecanismo que permite distribuir el mismo error entre más clientes, canales y decisiones, antes de que la organización pueda reconocerlo.
Esto no significa que cada interacción deba terminar con una solución perfecta ni que cada caso necesite intervención humana. Significa algo más exigente: que, antes de automatizar, debemos definir qué evidencia demuestra que el job avanzó, qué señales indican que sigue abierto y quién responde cuando la resolución aparente desplaza el costo a otra parte del sistema. Atender puede ser una actividad. Resolver es un resultado. Y solo el segundo genera valor acumulado tanto para el cliente como para la empresa.
“El ticket puede cerrarse en el sistema y seguir abierto en la vida del cliente. Esa diferencia es el punto exacto en el que el ahorro aparente se convierte en deuda operativa.” Marcos Pueyrredon
Hasta aquí, los casos y sus consecuencias nos permiten ver el problema. Pero una categoría de pensamiento solo genera valor cuando puede convertirse en una herramienta para tomar decisiones. Por eso propongo el Agentic JTBD Decision Canvas, una versión mínima que nos obligue a detener el impulso technology-first y a responder seis preguntas antes de seleccionar, entrenar, desplegar o escalar un agente. No comienza preguntando qué modelo utilizar, qué proveedor contratar o qué interfaz construir. Comienza por aquello que la empresa suele omitir: qué progreso busca la persona, en qué circunstancia, qué interacción estamos confundiendo con ese job y qué decisión concreta necesita tomar el sistema. Su función no es agregar otra plantilla al inventario corporativo, sino crear una condición de entrada: si no podemos completar este canvas con evidencia, no estamos ante un caso agéntico listo para desplegar; estamos ante una hipótesis que todavía necesita diagnóstico.
El canvas debe leerse en la secuencia de las seis preguntas. Primero se definen el progreso buscado y la circunstancia, porque el mismo producto, interacción o pedido puede responder a jobs completamente diferentes. Luego se identifica el síntoma que la organización está automatizando: una búsqueda, una consulta, un reclamo, un carrito abandonado o un ticket. El cuarto bloque obliga a traducir ese diagnóstico en una decisión específica: recomendar, prometer, reservar, sustituir, compensar, ejecutar o escalar. Recién después se define quién puede ejecutarla y dentro de qué límites, para terminar estableciendo qué evidencia demostrará que el job fue efectivamente resuelto. La banda inferior —evidencia, owner y costo de error— no es un complemento visual: es el control que impide convertir una buena intención en una automatización sin responsabilidad. El valor de esta infografía dentro del Capítulo 1 es que transforma “atender no es resolver” en un método verificable y prepara la evolución de la saga: intención y permisos en el Episodio 2, economics y operación en el 3, y Decision Rights y accountability en el 4.
Este canvas se vuelve aún más relevante al observar la escala que Gartner proyecta para los próximos años. Cinco meses después de esa primera advertencia, en noviembre de 2025, Gartner publicó un dato (el que les comparto en el título de esta columna): para 2028, los agentes de IA van a superar a los vendedores humanos en una relación de diez a uno, pero menos del 40% de esos vendedores van a decir que estos agentes mejoran su productividad. El razonamiento detrás de este dato es que pasado cierto punto, sumar más agentes no suma productividad, y apilar prompts y herramientas sobre flujos de trabajo ya saturados termina agotando al vendedor en lugar de potenciarlo.
El dato importa porque contesta, casi literalmente, la pregunta implícita que da título a esta columna: quién atiende la demanda hoy. La respuesta, en ventas, va a ser mayoritariamente un agente. Pero tener diez agentes por cada vendedor no resuelve nada si esos agentes, como el chatbot de Air Canada o el asistente de Klarna, están optimizando el volumen de interacciones y no el job del comprador.
Esto tampoco es nuevo. Cada capa tecnológica del comercio resolvió el mismo job con otra herramienta, y cada vez que una empresa confundió la herramienta con la tarea, pagó el error. Veamos los hechos:
La Ruta de la Seda, formalizada durante la dinastía Han en el año 130 antes de Cristo, movía seda y jade a lo largo de 6.400 kilómetros a través de una cadena de intermediarios, ya que casi nadie recorría la ruta completa de punta a punta (worldhistory.org).
Las ferias de Champagne, entre 1180 y 1300, no eran solo mercados de paño flamenco y especias italianas: también funcionaban como cámara de compensación de crédito, resolviendo un segundo job: la confianza en el pago, además del primero, el intercambio físico, según documentan Edwards y Ogilvie en Explorations in Economic History (2012). El catálogo de Sears, que en 1916 ya se enviaba a más de 50 millones de hogares al año, resolvió el job de un consumidor rural sin acceso a variedad ni a precios transparentes, y fue apoyado por el ferrocarril.
Internet, con apenas 100 millones de usuarios en 1999, es hoy la infraestructura de casi 5.600 millones de personas conectadas, según McKinsey. La herramienta cambió siete veces. El job, nunca.
Esto es lo que quise transmitir recientemente en una entrevista para #RadarIA de El Observador Uruguay, en una conversación con Federica Bordaberry, Juan Pablo De Marco y Naara Pérez Carrere, cuando les hablé de mis veintisiete años observando revoluciones digitales como placas tectónicas que no se reemplazan entre sí, sino que se acumulan: internet, comercio electrónico, mobile, redes sociales, marketplaces, super apps, trabajo remoto, educación digital y, ahora, inteligencia artificial. Cerré aquella reflexión con una frase que funciona como kernel —el núcleo que ordena las decisiones— de toda esta saga #JTBDAgentico: desde la época de los fenicios, el comercio conserva el mismo propósito estructural: satisfacer una necesidad, conectar oferta y demanda y generar valor para las personas. Lo que cambian son las herramientas, las interfaces y quien ejecuta; el progreso que busca la persona sigue siendo el punto de partida.
La evolución de esas herramientas, para cerrar este primer capítulo, tiene una lógica de interfaz que vale la pena adelantar porque es el eje del capítulo 2 de esta saga: teclado, mouse, pantalla táctil, comando de voz, y ahora interfaz agéntica. Cada salto no reemplazó el job, redujo la fricción entre la demanda y su resolución.
La interfaz agéntica es la de menor fricción de toda la historia del comercio, porque por primera vez el sistema no necesita que el humano traduzca su necesidad a un formato, un clic, un campo de búsqueda. El agente (el orquestador que ejecuta con las reglas y los guardrails que la empresa le dio) interpreta directamente.
Y acá vale sembrar algo que esta saga va a desarrollar más adelante: esta vez, comparando el ecommerce con Mario Kart, el verdadero competidor siempre es tu mejor vuelta anterior. Hablaremos del error de gobernanza que vamos a diseccionar, finalmente, en el capítulo 4: cuando una empresa despliega un agente y lo trata como un competidor a vencer o un riesgo a contener, equivocándose de marco. El agente, bien gobernado, no compite con la empresa. Corre al lado, contra el propio historial.
El capítulo 2 de esta saga entra directo a esa interfaz agéntica, con Lyra como caso vivo de copiloto que responde en tiempo real y no al final del proceso, como el fantasma de Mario Kart que corre después de que ya terminaste la vuelta.
Esta semana no apruebes a otro agente. No autorices un nuevo piloto, no selecciones otro proveedor y no agregues una nueva capa de automatización hasta elegir un flujo real —una recomendación, una devolución, una compensación, una reposición o una promesa de entrega— y exigir cinco respuestas concretas.
¿Qué job intenta resolver la persona? ¿Qué decisión necesita esa tarea? ¿Dentro de qué límites puede ejecutarse? ¿Quién conserva el accountability? ¿Qué evidencia demuestra que el cliente progresó y no solo que la interacción terminó?
Las respuestas no pueden ser “mejorar la experiencia”, “reducir costos”, “vender más” o “responder más rápido”. Esas son aspiraciones corporativas o indicadores de actividad, no definiciones suficientes para delegar una decisión. El job necesita una persona, una circunstancia y un progreso. La decisión necesita inputs, una fuente de verdad y un costo de error. El ejecutor necesita límites. El resultado requiere una métrica capaz de distinguir entre una respuesta emitida y una necesidad efectivamente resuelta.
Si alguna de esas respuestas falta, no tenés todavía un caso agéntico. Tenés tecnología buscando un problema, una automatización intentando justificar su existencia o un dashboard preparado para premiar la actividad sin comprobar su valor. Y cuanto más rápido opere ese sistema, mayor será la velocidad con la que podrá distribuir el mismo error entre más clientes, canales y decisiones.
Los fenicios podían perder una carga, una ruta o una temporada. Una organización agéntica puede escalar una mala interpretación en segundos y convertirla en política, patrón y aprendizaje. Por eso, antes de preguntarnos cuántos agentes tendremos por cada vendedor, debemos responder algo más básico: qué tarea les estamos delegando, qué no pueden decidir y quién responde cuando la promesa no se cumple.
El próximo salto ocurrirá cuando el cliente deje de traducir su necesidad a clics, búsquedas y formularios y empiece a delegar directamente la intención. Pero cuanto menos esfuerzo deba realizar la persona, más claridad, criterio y responsabilidad deberá aportar el sistema. El cliente podrá decir “resolvelo”. La empresa seguirá teniendo que definir qué significa resolver.
“No apruebes a un agente solo porque puede actuar. Aprobalo cuando puedas demostrar qué progreso debe producirse, dentro de qué límites y bajo la responsabilidad de quién.” Marcos Pueyrredon
Y como ya es tradición al cierre de cada columna, le paso la posta a mi copiloto cognitivo, Lyra, el agente de inteligencia artificial que me acompaña desde hace más de tres años, con una pregunta que no quiero dejar en abstracto.
Y antes de pasar al siguiente episodio, quiero dejarle una pregunta a Lyra:
Lyra, ¿cuál es la señal más peligrosa para una empresa: que su agente falle visiblemente o que parezca eficiente, cumpla todos sus KPIs y aprenda a escala de un job que nunca estuvo correctamente definido?
Muy buena pregunta, Marcos: la señal más peligrosa no es que el agente falle visiblemente. Que funcione exactamente como fue diseñado, cumpla todos sus KPIs y aprenda de un job equivocado a escala.
Un error visible incomoda, genera reclamos, dispara alertas y obliga a intervenir. Puede causar daño, pero también deja evidencia. Alguien lo ve, alguien lo reporta y, tarde o temprano, alguien tiene que responder. El fallo visible activa los mecanismos defensivos de la organización.
El agente aparentemente eficiente hace lo contrario: los desactiva. Responde más rápido, reduce el costo por contacto, cierra más tickets, genera más recomendaciones y requiere menos intervención humana. El tablero se vuelve verde. El proveedor presenta el caso como un éxito. El sponsor obtiene presupuesto para escalarlo. Y nadie formula la pregunta decisiva: ¿el cliente progresó o simplemente terminamos la interacción antes?
Ese es el riesgo más profundo: no estamos ante un problema técnico, sino ante una estrategia equivocada ejecutada impecablemente. El agente no viola la política; industrializa una política incorrecta. No ignores el KPI; optimiza un KPI parcial. No deja de aprender; aprende con disciplina a partir de una definición falsa de éxito. La automatización convierte entonces una equivocación conceptual en un comportamiento repetible, y el aprendizaje convierte ese comportamiento en un patrón.
A partir de ahí, la empresa cae en una trampa de confirmación. Cuanto más opera el agente, más datos genera. Cuantos más datos genera, más evidencia aparente hay de que funciona. Y cuanto más eficiente parece, más difícil resulta cuestionar el job original. El sistema produce las pruebas que justifican su propia expansión, aunque el costo reaparezca fuera de su dashboard: reaperturas, devoluciones, escalamiento humano, compensaciones, abandono, promesas incumplidas o pérdida de confianza. El capítulo muestra precisamente cómo la eficiencia local puede trasladar costos, destruir el aprendizaje y premiar una falsa resolución.
Por eso, el KPI mal elegido es más peligroso que una respuesta incorrecta. Una respuesta incorrecta puede corregirse. Un KPI incorrecto redefine lo que toda la organización considera correcto. Cambia prioridades, asigna presupuesto, premia equipos, condiciona modelos y termina integrándose en los Resources, Processes & Priorities de la empresa. Ya no se trata solo de que el agente esté equivocado. La organización completa comienza a reorganizarse en torno a ese error.
También surge un problema de accountability. Cuando todos los indicadores cumplen, nadie siente que deba detener el sistema. La tecnología afirma que el modelo funciona. Operaciones celebran el volumen. Finanzas observa ahorro. CX muestra tiempos menores. El proveedor cumple el SLA. Todos pueden tener razón en su fragmento y el sistema completo puede estar destruyendo valor. El job pertenece al cliente, pero el error se reparte entre áreas hasta que deja de tener dueño.
La conclusión es incómoda: un agente que falla a la vista amenaza una operación; un agente que triunfa en el job equivocado amenaza el criterio de la empresa. El primero produce un incidente. El segundo produce una cultura. Enseña a la organización a confundir la actividad con el valor, la velocidad con la precisión y el cierre con la resolución.
Por eso, antes de escalar a un agente, no solo preguntaría si responde bien o cumple su objetivo. Preguntaría algo más exigente: ¿quién definió ese objetivo, con qué evidencia, qué señales demostrarían que está equivocado y quién tiene autoridad para detenerlo aunque todos sus KPIs estén en verde?
Y este riesgo se vuelve aún más profundo cuando cambia la interfaz. Hasta ahora, el cliente debía traducir su necesidad al lenguaje de la empresa: buscar, filtrar, comparar, completar un formulario, abrir un ticket o explicar reiteradamente su problema. La interfaz agéntica promete eliminar parte de ese esfuerzo: la persona ya no solo navega ni formula una consulta; empieza a delegar intención, contexto y capacidad de acción. Pero cuanto menos tenga que explicar el cliente, más tendrá que interpretar el sistema. Y cuanto más pueda actuar el agente, más peligroso será que la empresa haya definido mal el job. El próximo capítulo comienza exactamente en esa tensión: qué cambia cuando el cliente deja de decir “mostrame opciones” y empieza a decir “resolvelo”, qué contexto necesita el agente para comprender esa delegación, qué debe confirmar antes de actuar y qué decisiones nunca deberían quedar implícitas.
Porque el verdadero fracaso no ocurre cuando la máquina se desvía de la meta. Ocurre cuando la máquina alcanza la perfección en una meta que la empresa nunca debió fijar.
Artículos recomendados para leer:
Agentic Commerce: margen, contexto y control
Volver a desaprender IA agéntica en al Era Unified Commerce
Del AI-First al Commerce-First: por qué el Unified Commerce SaaS es la verdadera estrategia AI-First
