Arrancamos por el fen\u00f3meno m\u00e1s antiguo del comercio: la demanda. No naci\u00f3 con internet, como muchos todav\u00eda creen. Naci\u00f3 hace m\u00e1s de 3.000 a\u00f1os, y desde los fenicios hasta el agente conversacional, cada revoluci\u00f3n tecnol\u00f3gica resolvi\u00f3 exactamente el mismo problema con otra herramienta. El agente de IA es apenas el \u00faltimo.<\/span><\/p>\n Y ah\u00ed est\u00e1 el error m\u00e1s caro que puede cometer un ecommercionista hoy: tratar al agente como si fuera la novedad, sin saber qu\u00e9 job le est\u00e1 delegando. Si administr\u00e1s un ecommerce y est\u00e1s evaluando incorporar IA ag\u00e9ntica en atenci\u00f3n, recomendaci\u00f3n o fulfillment sin haber respondido primero esa pregunta, ten\u00e9s que leer esta columna. Automatizar sin saber qu\u00e9 tarea est\u00e1s resolviendo no es innovaci\u00f3n. Es pagar m\u00e1s caro el mismo error, m\u00e1s r\u00e1pido.<\/span><\/p>\n ***<\/span><\/p>\n <\/p>\n Un mercader fenicio en el siglo IX antes de Cristo ten\u00eda un problema de negocio clar\u00edsimo: llevar aceite y cer\u00e1mica de donde sobraban a Tiro o Sid\u00f3n, y volver con esta\u00f1o de Britania o plata de Iberia, para fundir bronce. Fundaron colonias en Cartago, Sicilia, Cerde\u00f1a, y en lo que hoy es Marsella, Barcelona, C\u00e1diz y M\u00e1laga, no para expandir territorio, sino para sostener esa cadena de intermediaci\u00f3n.\u00a0<\/span><\/p>\n <\/p>\n El dato que casi nadie recuerda es cu\u00e1nto val\u00eda resolver ese problema, pero resolverlo bien. Hac\u00edan falta hasta 12.000 caracoles m\u00farex para producir apenas un gramo de tinte p\u00farpura, seg\u00fan documenta la <\/span>biblioteca de la Universidad de Chicago<\/span><\/a>, y ese tinte termin\u00f3 siendo la moneda de estatus de la realeza mediterr\u00e1nea. La <\/span>World History Encyclopedia<\/span><\/a> los describe directamente como la primera superpotencia comercial del Mediterr\u00e1neo.<\/span><\/p>\n <\/p>\n \u00bfPor qu\u00e9 arrancar una saga sobre inteligencia artificial ag\u00e9ntica con un mercader fenicio? Porque el <\/span>Job To Be Done<\/span><\/i> \u2014la tarea real que un cliente contrata cuando compra, aprende o delega trabajo\u2014, un concepto que Clayton Christensen desarroll\u00f3 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\u00f3n entre oferta y demanda.\u00a0<\/span><\/p>\n <\/p>\n Christensen lo resume con una idea que vale la pena releer dos veces: los clientes no compran productos, los \u00abcontratan\u00bb para lograr progreso en una circunstancia particular. Si el producto cumple, lo vuelven a contratar. Si no, lo despiden.<\/span><\/p>\n El ejemplo que Christensen us\u00f3 para probarlo es el de una cadena de comida r\u00e1pida que quer\u00eda vender m\u00e1s batidos. Seg\u00fan document\u00f3 <\/span>Carmen Nobel en HBS Working Knowledge<\/span><\/a> (14 de febrero de 2011), descubrieron que el 40% de los batidos se vend\u00edan temprano a la ma\u00f1ana, a viajeros que los ped\u00edan para llevar. El job no era \u00abtomar algo rico\u00bb. Era tener algo sostenible con una mano, que no ensuciara el auto, y que aguantara el hambre hasta el mediod\u00eda. El batido compet\u00eda con una banana o una dona, no con otro batido. Ese desv\u00edo de diagn\u00f3stico, vender el producto en lugar de entender el job, es la misma raz\u00f3n por la que Christensen sostiene que <\/span>entre el 75% y el 85% de los productos nuevos fracasan en el mercado. <\/b>Es imperdible este podcast donde se habla sobre<\/span> los trabajos que deben hacerse, sin perder el hilo de la innovaci\u00f3n<\/span><\/a>.<\/b><\/p>\n Un barco, un cat\u00e1logo, una tienda, una aplicaci\u00f3n y un agente pueden <\/span>cerrar la brecha entre lo que alguien necesita y aquello que puede satisfacer esa necesidad<\/b>. Pero ninguno de ellos sabe, por s\u00ed mismo, <\/span>qu\u00e9 progreso intenta lograr esa persona<\/b>. Son medios, interfaces y ejecutores. <\/span>No es el job.<\/b><\/p>\n El comercio cumple desde hace milenios una funci\u00f3n estructural:\u00a0conectar la oferta y la demanda, reducir fricciones y facilitar el intercambio<\/strong>.\u00a0Pero \u201cmover un producto de donde sobra a donde falta\u201d todav\u00eda no constituye un <\/span>Job to Be Done lo suficientemente preciso<\/b> para dise\u00f1ar una experiencia, mucho menos para delegar decisiones a un agente. El job aparece cuando incorporamos <\/span>a la persona, su circunstancia y el progreso que busca<\/b>: alimentarse durante un viaje sin interrumpirlo, recibir un producto antes de tomar un avi\u00f3n, obtener informaci\u00f3n confiable durante un duelo o resolver una devoluci\u00f3n excepcional sin quedar atrapado en una pol\u00edtica est\u00e1ndar.<\/span><\/p>\n La diferencia no es sem\u00e1ntica. Es operativa.<\/b> Buscar, hacer clic, preguntar, reclamar, comparar o abrir un ticket son <\/span>interacciones observables<\/b>. Pueden revelar el job, pero <\/span>no demuestran que haya sido comprendido ni resuelto<\/b>. Una empresa puede automatizar perfectamente esas se\u00f1ales y seguir equivoc\u00e1ndose respecto de la tarea real. Puede responder en segundos, recomendar un producto, cerrar el caso y mejorar el tiempo promedio de atenci\u00f3n mientras <\/span>la persona contin\u00faa exactamente en el mismo lugar en el que comenz\u00f3<\/b>.<\/span><\/p>\n Por eso, antes de elegir qu\u00e9 agente desplegar, hay que identificar <\/span>qu\u00e9 decisi\u00f3n requiere esa tarea<\/b>: recomendar, prometer, reservar, sustituir, compensar, ejecutar o escalar. Reci\u00e9n entonces podemos determinar <\/span>qui\u00e9n debe tomarla \u2014una persona, un sistema, un copiloto o un agente\u2014<\/b> y c\u00f3mo demostrar que produjo progreso real. <\/span>La tecnolog\u00eda puede acelerar el recorrido. La empresa no puede determinar cu\u00e1l era el destino.<\/b><\/p>\n \u201cUn 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.\u201d <\/b>Marcos Pueyrredon<\/span><\/p><\/blockquote>\n Esto, inevitablemente, me recuerda las <\/span>Cinco ense\u00f1anzas que me dej\u00f3 el \u00abHarvard Experience\u00bb? y que el digital commerce actual deber\u00eda interpretar rememorando al gran Ayrton Senna!<\/span><\/a>. Vean, es una lectura de junio de 2022. Cuatro a\u00f1os despu\u00e9s, seguimos reforzando este concepto, todav\u00eda m\u00e1s enfocados en los desaf\u00edos que plantea la IA ag\u00e9ntica.<\/span><\/p>\n Ahora traigamos esto a 2026. La pregunta que tiene que hacerse cualquier empresa que est\u00e1 delegando atenci\u00f3n, recomendaci\u00f3n o fulfillment a un agente de inteligencia artificial es exactamente la misma que ten\u00eda que hacerse esa cadena de comida r\u00e1pida: <\/span>\u00bfqu\u00e9 job estoy resolviendo?<\/i><\/b> Porque si no lo sabe, automatiza el s\u00edntoma (responder r\u00e1pido, cerrar el ticket, empujar el carrito) y no la tarea real del cliente.\u00a0<\/span><\/p>\n Gartner proyect\u00f3 en junio de 2025 que\u00a0m\u00e1s del 40% de los proyectos de IA ag\u00e9ntica se cancelar\u00e1n antes de que termine 2027<\/a>, debido a costos que escalan, un valor de negocio poco claro o controles de riesgo insuficientes.\u00a0La analista de Gartner, Anushree Verma, fue m\u00e1s dura todav\u00eda: l<\/span>a mayor\u00eda de los proyectos ag\u00e9nticos de hoy son experimentos tempranos empujados por el hype, mal aplicados<\/b>. McKinsey, en su <\/span>State of AI de 2025<\/span><\/a>, midi\u00f3 lo mismo desde otro \u00e1ngulo: el 62% de las organizaciones ya trabaja con agentes, pero s\u00f3lo el 23% est\u00e1 escalando alguno en al menos una funci\u00f3n, y en cualquier funci\u00f3n puntual, no m\u00e1s del 10% lleg\u00f3 a escala real. Hay que detenerse en este punto porque <\/span>Gartner no atribuye la cancelaci\u00f3n de esos proyectos a una mala comprensi\u00f3n del Job to Be Done<\/b>. Las causas que declara son concretas: <\/span>costos crecientes, un valor de negocio poco claro y controles de riesgo insuficientes<\/b>. Convertir mi interpretaci\u00f3n en una conclusi\u00f3n de Gartner ser\u00eda cometer el mismo error que esta saga intenta cuestionar: confundir una se\u00f1al observable con la causa profunda que puede explicarla. Gartner describe d\u00f3nde podr\u00edan terminar muchos proyectos. <\/span>#JTBDAgentico propone investigar desde d\u00f3nde comenzaron a desviarse.<\/b><\/p>\n Mi hip\u00f3tesis es que, detr\u00e1s 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: <\/span>la empresa<\/b> no defini\u00f3 con suficiente precisi\u00f3n<\/b> qu\u00e9 progreso deb\u00eda producirse, qu\u00e9 decisi\u00f3n estaba delegando y c\u00f3mo iba a comprobar<\/b> que el job hab\u00eda sido resuelto<\/b>. Cuando el job es ambiguo, tambi\u00e9n lo es el caso de negocio. Y cuando la decisi\u00f3n no est\u00e1 delimitada, el proyecto empieza a incorporar m\u00e1s datos, m\u00e1s integraciones, m\u00e1s prompts, m\u00e1s excepciones y m\u00e1s supervisi\u00f3n para compensar una definici\u00f3n que nunca fue clara desde el comienzo.<\/span><\/p>\n Esa ambig\u00fcedad se convierte r\u00e1pidamente en un costo operativo. Si el objetivo declarado es \u201cmejorar la atenci\u00f3n\u201d, \u201cpersonalizar la experiencia\u201d o \u201cvender m\u00e1s\u201d, el agente no tiene una tarea lo suficientemente precisa: tiene una aspiraci\u00f3n corporativa. No sabe si debe recomendar, prometer, reservar, sustituir, compensar, ejecutar o escalar. Tampoco sabe qu\u00e9 fuente de verdad prevalece, qu\u00e9 error puede tolerarse, qu\u00e9 acci\u00f3n requiere confirmaci\u00f3n o cu\u00e1ndo debe devolver la decisi\u00f3n a una persona. <\/span>La<\/b> autonom\u00eda no puede dise\u00f1arse<\/b> antes que la decisi\u00f3n<\/b>, porque el nivel de autonom\u00eda depende del impacto, de la reversibilidad y del costo de equivocarse.<\/span><\/p>\n Lo mismo ocurre con el valor. Una empresa puede demostrar que el agente respondi\u00f3 m\u00e1s r\u00e1pido, manej\u00f3 m\u00e1s conversaciones o redujo el costo por contacto y, aun as\u00ed, no demostrar que haya producido progreso para el cliente ni resultado para el negocio. <\/span>Sin un job concreto no existe una m\u00e9trica de resoluci\u00f3n; solo quedan m\u00e9tricas de actividad.<\/b> El ticket cerrado puede reabrirse, la recomendaci\u00f3n puede derivar en una devoluci\u00f3n, la promesa puede incumplirse y el ahorro inicial puede reaparecer como escalamiento humano, compensaci\u00f3n, abandono o p\u00e9rdida de confianza. Por eso, el problema no es solo que algunas organizaciones est\u00e9n desplegando agentes demasiado pronto. Es que muchas est\u00e1n intentando justificar la tecnolog\u00eda antes de haber definido con precisi\u00f3n la tarea, la decisi\u00f3n y el resultado.<\/span><\/p>\n Separar estas capas es esencial para preservar la integridad de esta saga. <\/span>Gartner aporta el pron\u00f3stico. McKinsey muestra la brecha entre la experimentaci\u00f3n y la escala. Los casos permiten observar las consecuencias. La hip\u00f3tesis de #JTBDAgentico es que una parte de esa brecha comienza antes de la tecnolog\u00eda: cuando la organizaci\u00f3n automatiza una interacci\u00f3n que puede medir, en lugar de diagnosticar el progreso que realmente deber\u00eda producirse.<\/b><\/p>\n \u201cEl costo del agente no empieza cuando el modelo se equivoca. Empieza cuando la empresa invierte en automatizar una tarea que nunca aprendi\u00f3 a definir.\u201d <\/b>Marcos Pueyrredon<\/span><\/p><\/blockquote>\n Los dos casos m\u00e1s citados del \u00faltimo a\u00f1o y medio muestran exactamente ese error de diagn\u00f3stico. El chatbot de Air Canada le prometi\u00f3 a un pasajero una tarifa de duelo retroactiva que la pol\u00edtica vigente de la aerol\u00ednea no contemplaba. Air Canada argument\u00f3 ante el tribunal que el chatbot era una entidad legal separada, responsable de sus propias respuestas. El Civil Resolution Tribunal de Canad\u00e1 no lo vio as\u00ed: el fallo estableci\u00f3 que no importa si la informaci\u00f3n sale de una p\u00e1gina est\u00e1tica o de un chatbot, la responsabilidad es de la empresa, y calific\u00f3 el caso de negligencia en la representaci\u00f3n de los hechos (<\/span>CBS News<\/span><\/a>).\u00a0 Air Canada automatiz\u00f3 la respuesta r\u00e1pida. No resolvi\u00f3 el job real del pasajero, que consist\u00eda en contar con informaci\u00f3n confiable en un momento en que el pasajero estaba de duelo.<\/span><\/p>\n Klarna hizo el camino inverso y resulta a\u00fan m\u00e1s revelador. En febrero de 2024, anunci\u00f3 que su asistente de IA hac\u00eda el trabajo de 700 agentes humanos y gestionaba 2,3 millones de conversaciones, lo que redujo el tiempo de resoluci\u00f3n de 11 minutos a menos de 2 minutos. Quince meses despu\u00e9s, en mayo de 2025, el propio CEO Sebastian Siemiatkowski admiti\u00f3 el error: se enfocaron demasiado en el costo, y el resultado fue menor calidad, as\u00ed que volvieron a contratar personas (<\/span>Forbes, 2025<\/span><\/a>). El dashboard med\u00eda volumen. No med\u00eda si el job del cliente, sentirse resuelto y no solo atendido, se estaba cumpliendo.<\/span><\/p>\n El problema es que <\/span>una interacci\u00f3n cerrada sin resoluci\u00f3n no necesariamente reduce el costo: muchas veces solo lo desplaza a otra parte de la organizaci\u00f3n<\/b>. El ticket desaparece del tablero de atenci\u00f3n, pero reaparece como una segunda consulta, una reapertura, una derivaci\u00f3n a un supervisor, una devoluci\u00f3n, una compensaci\u00f3n, una cancelaci\u00f3n o una promesa que Operaciones deber\u00e1 intentar reparar. Lo que parec\u00eda eficiencia en el frontstage puede convertirse en complejidad, trabajo manual y un mayor costo de servicio en el backstage. <\/span>La organizaci\u00f3n celebra que ha respondido m\u00e1s r\u00e1pido, mientras otra \u00e1rea asume el costo de aquello que nunca se resolvi\u00f3.<\/b><\/p>\n Este desplazamiento es especialmente peligroso porque los indicadores tradicionales suelen fragmentar el resultado. Atenci\u00f3n: mide el tiempo de respuesta y el n\u00famero de tickets cerrados. Ecommerce observa conversi\u00f3n. Operaciones analizan devoluciones y cancelaciones. Finanzas registra compensaciones. Marketing intenta reconstruir la confianza perdida. Cada \u00e1rea puede mejorar parcialmente su indicador y, aun as\u00ed, <\/span>el sistema completo puede estar destruyendo valor<\/b>. El job pertenece al cliente, pero su costo termina por distribuirse entre \u00e1reas que no siempre comparten el mismo owner, la misma informaci\u00f3n ni la misma definici\u00f3n de \u00e9xito.<\/span><\/p>\n Por eso, medir \u00fanicamente el <\/span>costo por contacto<\/b> puede generar una ilusi\u00f3n de productividad. Un contacto barato que genera otros tres contactos, requiere intervenci\u00f3n humana o termina en una devoluci\u00f3n no fue realmente barato. Del mismo modo, reducir el tiempo promedio de atenci\u00f3n no demuestra que la tarea haya sido completada; solo indica que la interacci\u00f3n termin\u00f3 antes. <\/span>La m\u00e9trica relevante debe desplazarse de \u00abcu\u00e1nto<\/b> cuesta responder\u00bb a \u00abcu\u00e1nto cuesta resolver efectivamente\u00bb<\/b>, incorporando la recurrencia, la reapertura, el escalamiento, el error de pol\u00edtica, la promesa cumplida y la necesidad de reparaci\u00f3n posterior.<\/span><\/p>\n El desplazamiento del <\/span>costo por contacto<\/b> al costo por resoluci\u00f3n efectiva<\/b> exige algo m\u00e1s que cambiar el nombre de un indicador. Obliga a reconstruir el recorrido completo de la interacci\u00f3n e identificar d\u00f3nde la organizaci\u00f3n declar\u00f3 el \u00e9xito antes de tiempo. Para hacer visible esa brecha, propongo el <\/span>Job\u2013Interaction Resolution Gap Ledger<\/b>, una herramienta de auditor\u00eda 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\u00f3 correctamente o si redujo el tiempo del proceso. Comienza preguntando <\/span>qu\u00e9 journey estamos observando, qu\u00e9 interacci\u00f3n ocurri\u00f3, qu\u00e9 job suponemos que existe y qu\u00e9 evidencia valida esa interpretaci\u00f3n<\/b>. Desde all\u00ed conecta la decisi\u00f3n ejecutada con el KPI que hoy premia a la empresa y con el indicador que deber\u00eda demostrar resoluci\u00f3n. Su prop\u00f3sito es simple pero inc\u00f3modo: revelar automatizaciones que parecen eficientes porque cierran interacciones, aunque generen reaperturas, escalamiento humano, devoluciones, compensaciones o nuevos costos en otra parte de la operaci\u00f3n.<\/span><\/p>\n El ledger debe leerse como una auditor\u00eda en cuatro movimientos. Primero, <\/span>observar sin interpretar prematuramente<\/b>: seleccionar un journey o flujo y registrar la interacci\u00f3n que efectivamente ocurri\u00f3. Segundo, formular un <\/span>job hipot\u00e9tico<\/b>, pero exigir evidencia para validarlo: comportamiento, entrevistas, b\u00fasquedas, tickets, recurrencia o alternativas que el cliente haya utilizado. Tercero, identificar qu\u00e9 decisi\u00f3n ejecut\u00f3 el sistema y comparar el <\/span>KPI actual<\/b> \u2014tiempo de respuesta, tickets cerrados, conversaciones o costo por contacto\u2014 con un <\/span>KPI de resoluci\u00f3n<\/b>, capaz de mostrar si el job avanz\u00f3 o permaneci\u00f3 abierto. All\u00ed aparecen las se\u00f1ales que suelen quedar fragmentadas entre \u00e1reas: reapertura, recurrencia, escalamiento humano y costo de error. Finalmente, el ledger obliga a asignar un owner y tomar una decisi\u00f3n expl\u00edcita: <\/span>mantener, investigar, redise\u00f1ar o detener<\/b> la automatizaci\u00f3n. Su valor en este cap\u00edtulo radica que transformar \u201catender no es resolver\u201d en una disciplina de diagn\u00f3stico aplicable. Ya no se trata de una cr\u00edtica conceptual al dashboard, sino de un mecanismo para descubrir d\u00f3nde la eficiencia local est\u00e1 trasladando costos, destruyendo el aprendizaje o premiando una falsa resoluci\u00f3n.<\/span><\/p>\n El ledger permite detectar la brecha visible entre la interacci\u00f3n cerrada y el job a\u00fan abierto. Pero existe, adem\u00e1s, un costo menos evidente y potencialmente m\u00e1s grave: el aprendizaje equivocado del sistema.<\/b> Si el agente registra como \u00e9xito cada conversaci\u00f3n finalizada, cada carrito empujado o cada ticket cerrado, aprende a repetir el comportamiento que produce esa se\u00f1al, aunque el cliente contin\u00fae sin resolver su necesidad.<\/span><\/p>\n Si el agente registra como \u00e9xito cada conversaci\u00f3n finalizada, cada carrito empujado o cada ticket cerrado, aprende a repetir el comportamiento que produce esa se\u00f1al, aunque el cliente contin\u00fae sin resolver su necesidad. La automatizaci\u00f3n no solo ejecuta una mala definici\u00f3n: puede convertirla en patr\u00f3n. Y cuanto mayor sea el volumen, m\u00e1s evidencia aparente generar\u00e1 para confirmar que la estrategia funciona. El dashboard mostrar\u00e1 la eficiencia precisamente porque fue dise\u00f1ado para no observar d\u00f3nde reaparece el problema.<\/span><\/p>\n Ah\u00ed comienza la verdadera deuda operativa ag\u00e9ntica: <\/span>una pol\u00edtica incorrecta ejecutada de manera consistente, una m\u00e9trica parcial interpretada como valor y un sistema que aprende de resultados que nunca debieron considerarse exitosos<\/b>. La velocidad deja entonces de ser una ventaja. Se convierte en el mecanismo que permite distribuir el mismo error entre m\u00e1s clientes, canales y decisiones, antes de que la organizaci\u00f3n pueda reconocerlo.<\/span><\/p>\n Esto no significa que cada interacci\u00f3n deba terminar con una soluci\u00f3n perfecta ni que cada caso necesite intervenci\u00f3n humana. Significa algo m\u00e1s exigente: que, antes de automatizar, debemos definir <\/span>qu\u00e9 evidencia demuestra que el job<\/b> avanz\u00f3, qu\u00e9 se\u00f1ales indican que<\/b> sigue abierto y qui\u00e9n responde cuando la resoluci\u00f3n aparente desplaza el costo a<\/b> otra parte del sistema<\/b>. Atender puede ser una actividad. Resolver es un resultado. Y solo el segundo genera valor acumulado tanto para el cliente como para la empresa.<\/span><\/p>\n \u201cEl 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.\u201d <\/b>Marcos Pueyrredon<\/span><\/p><\/blockquote>\n Hasta aqu\u00ed, los casos y sus consecuencias nos permiten ver el problema. Pero <\/span>una categor\u00eda de pensamiento solo genera valor cuando puede convertirse en una herramienta para tomar decisiones<\/b>. Por eso propongo el <\/span>Agentic JTBD Decision<\/b> Canvas<\/b>, una versi\u00f3n m\u00ednima 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\u00e9 modelo utilizar, qu\u00e9 proveedor contratar o qu\u00e9 interfaz construir. Comienza por aquello que la empresa suele omitir: <\/span>qu\u00e9 progreso busca la persona, en qu\u00e9 circunstancia, qu\u00e9 interacci\u00f3n estamos confundiendo con ese job y qu\u00e9 decisi\u00f3n concreta necesita tomar el sistema<\/b>. Su funci\u00f3n no es agregar otra plantilla al inventario corporativo, sino crear una condici\u00f3n de entrada: si no podemos completar este canvas con evidencia, no estamos ante un caso ag\u00e9ntico listo para desplegar; estamos ante una hip\u00f3tesis que todav\u00eda necesita diagn\u00f3stico.<\/span><\/p>\n El canvas debe leerse en la secuencia de las seis preguntas. Primero se definen <\/span>el progreso buscado y la circunstancia<\/b>, porque el mismo producto, interacci\u00f3n o pedido puede responder a jobs completamente diferentes. Luego se identifica <\/span>el s\u00edntoma que la organizaci\u00f3n est\u00e1 automatizando<\/b>: una b\u00fasqueda, una consulta, un reclamo, un carrito abandonado o un ticket. El cuarto bloque obliga a traducir ese diagn\u00f3stico en una decisi\u00f3n espec\u00edfica: recomendar, prometer, reservar, sustituir, compensar, ejecutar o escalar. Reci\u00e9n despu\u00e9s se define <\/span>qui\u00e9n puede ejecutarla y dentro de qu\u00e9 l\u00edmites<\/b>, para terminar estableciendo qu\u00e9 evidencia demostrar\u00e1 que el job fue efectivamente resuelto. La banda inferior \u2014evidencia, owner y costo de error\u2014 no es un complemento visual: es el control que impide convertir una buena intenci\u00f3n en una automatizaci\u00f3n sin responsabilidad. <\/span>El valor de esta infograf\u00eda dentro del Cap\u00edtulo 1 es que transforma \u201catender no es resolver\u201d en un m\u00e9todo verificable<\/b> y prepara la evoluci\u00f3n de la saga: intenci\u00f3n y permisos en el Episodio 2, economics y operaci\u00f3n en el 3, y Decision Rights y accountability en el 4.<\/span><\/p>\n Este canvas se vuelve a\u00fan m\u00e1s relevante al observar la escala que Gartner proyecta para los pr\u00f3ximos a\u00f1os. Cinco meses despu\u00e9s de esa primera advertencia, en noviembre de 2025, <\/span>Gartner <\/span><\/a>public\u00f3 un dato (el que les comparto en el t\u00edtulo de esta columna): <\/span>para 2028,<\/b> los agentes de IA van a superar a los vendedores humanos en una relaci\u00f3n de diez a uno, pero menos del 40% de esos vendedores van a decir que estos agentes<\/b> mejoran su productividad<\/b>. El razonamiento detr\u00e1s de este dato es que pasado cierto punto, sumar m\u00e1s agentes no suma productividad, y apilar prompts y herramientas sobre flujos de trabajo ya saturados termina agotando al vendedor en lugar de potenciarlo.\u00a0<\/span><\/p>\n El dato importa porque contesta, casi literalmente, la pregunta impl\u00edcita que da t\u00edtulo a esta columna: <\/span>qui\u00e9n atiende la demanda hoy.<\/b> 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\u00e1n optimizando el volumen de interacciones y no el job del comprador.<\/span><\/p>\n
\n<\/span><\/p>\n![\"Challenge](\"https:\/\/pueyrredonline.com\/blog\/wp-content\/uploads\/2026\/07\/Captura-de-pantalla-2026-07-12-a-las-12.08.41-p.m-1024x861.png\")
<\/p>\n![\"Job\u2013Interaction](\"https:\/\/pueyrredonline.com\/blog\/wp-content\/uploads\/2026\/07\/Captura-de-pantalla-2026-07-12-a-las-12.10.29-p.m-1024x1251.png\")
<\/p>\n![\"Agentic](\"https:\/\/pueyrredonline.com\/blog\/wp-content\/uploads\/2026\/07\/Captura-de-pantalla-2026-07-12-a-las-12.11.52-p.m-1024x1259.png\")
<\/p>\n