9 min de lectura
La promesa comercial que llega al comprador de IA es sencilla. Con las herramientas disponibles hoy, cualquiera puede construir un agente autónomo que automatice un flujo de trabajo complejo. Es una promesa que tiene una mitad verdadera. El acceso a la construcción se democratizó de una manera que hace tres años parecía lejana. Los frameworks, los modelos de lenguaje, las plataformas de orquestación y las interfaces visuales permiten que un equipo pequeño o una sola persona ensamble en pocas horas algo que ejecuta tareas encadenadas, consulta sistemas externos y devuelve resultados plausibles.
La otra mitad es la que casi nunca llega al pitch. Gartner le puso nombre al fenómeno hace poco con el término "agent washing". En una revisión reciente del mercado, la firma estimó que de los miles de vendors que ofrecen agentes autónomos apenas unos 130 construyen lo que efectivamente cumple con la definición. El resto empaqueta chatbots, flujos predefinidos o integraciones livianas bajo el mismo nombre comercial. La proyección que acompaña ese diagnóstico es más incómoda. Gartner anticipa que más del 40% de los proyectos agénticos en curso se cancelarán antes de 2027.
Esa brecha entre lo que se promete y lo que llega a producción no se cierra con más acceso. Se cierra con criterio técnico, que es lo que no se democratiza al mismo ritmo que la herramienta.
Lo que sí se abarató
Construir un prototipo de agente autónomo hoy requiere, en términos operativos, muy poco. Un modelo de lenguaje accesible por API, una capa de orquestación que encadena llamadas, un par de herramientas conectadas (correo, calendario, un CRM, una base de documentos) y una interfaz que permita verlo funcionar. En una tarde se puede llegar a algo que recibe una instrucción en lenguaje natural, planifica tres o cuatro pasos, consulta datos, redacta una respuesta y envía un correo. Esa demo es honesta, en el sentido limitado de que efectivamente ejecuta el flujo.
Lo que la demo no muestra es la distancia entre esa ejecución exitosa y la ejecución confiable en volumen, con datos reales, en una organización que ya tiene procesos y sistemas que ese agente debe respetar. En la demo todo converge: la instrucción es clara, el estado del sistema es predecible, las herramientas responden como se espera y el usuario está mirando. En producción, cualquiera de esas condiciones puede caerse en cualquier momento y nadie estará mirando cuando pase.
Esta facilidad de arranque es real y es valiosa. Permite que una empresa que antes no podía siquiera prototipar una idea ahora la tenga funcionando en una semana. El problema es que esa misma facilidad genera una expectativa plana. Si construir el agente fue sencillo, llevarlo a producción debería ser una continuación natural del mismo esfuerzo. Esa expectativa es la que después produce el 40% de cancelaciones.
La primera brecha es de arquitectura
La arquitectura de un agente va más allá del diagrama de qué componentes tiene. Es el conjunto de decisiones sobre qué puede hacer, qué no puede hacer, qué información puede ver, cuándo tiene que detenerse y qué debe entregarle a una persona. Esas decisiones no las sugiere el framework. Las toma quien diseña el sistema, con criterio técnico que viene de haber visto fallar sistemas parecidos antes.
Un ejemplo simple y concreto. Un agente que atiende consultas comerciales sobre contratos tiene que decidir, en cada turno, si responde con información que recuperó de la documentación o si deriva al equipo humano. Esa decisión forma parte de la arquitectura del sistema. Si el agente responde cuando no debería, el cliente recibe información incorrecta sobre un contrato vigente. Si deriva cuando debería responder, el agente pierde su razón de ser y el equipo humano queda igual de saturado que antes. La frontera entre los dos casos requiere definir con precisión qué tipo de consulta tolera una respuesta automática y cuál no, y esa definición se construye en conversación entre quien conoce el proceso de negocio y quien conoce las modalidades de fallo del sistema.
Hay un segundo frente arquitectónico que la facilidad de la demo oculta. Los agentes que encadenan varios pasos acumulan error en cada eslabón. Un agente que planifica cinco acciones y falla con probabilidad del 10% en cada una tiene una probabilidad de ejecución limpia de aproximadamente el 59%. La aritmética es trivial, el diseño que la contempla no lo es. Hay que decidir en qué puntos del flujo se chequea el estado antes de continuar, qué pasos son reversibles, qué pasos requieren confirmación y qué pasos pueden ejecutarse de forma optimista con un plan de rollback. Para el análisis completo de cuándo la arquitectura multi-agente complica más de lo que ayuda, ver sistemas-multi-agente-explicado.
La arquitectura también define los guardarraíles. Qué datos sensibles no entran al contexto, qué acciones requieren autorización explícita, qué respuestas se bloquean antes de llegar al usuario. Un agente sin guardarraíles explícitos opera con límites definidos por accidente, por los datos de entrenamiento del modelo y por la configuración por defecto del framework. Esa es una posición en la que ningún comprador que entiende su propio negocio debería quedarse.
La segunda brecha es de ingeniería
Si la arquitectura decide qué hace el sistema, la ingeniería decide cómo se comporta cuando algo sale mal. Y en los sistemas con componentes probabilísticos como los agentes, algo sale mal con frecuencia. Un agente en producción tiene que recuperarse de respuestas malformadas del modelo, de timeouts en las herramientas externas, de datos corruptos en la entrada, de instrucciones que el usuario expresó de una forma que el agente no anticipó. Cada uno de esos escenarios es un capítulo de código, de monitoreo y de pruebas que la demo no requirió.
Hay cuatro piezas que un agente de producción necesita y que una demo puede omitir sin consecuencias. La orquestación tolerante a fallos, con reintentos selectivos, backoff y mecanismos de compensación cuando una acción no se puede deshacer. La observabilidad, que permite saber qué hizo el agente en cada caso cuando el usuario reporta un problema tres días después. Los tests, que incluyen casos adversariales y casos de borde que no aparecen en el flujo feliz. Y la supervisión humana en los puntos donde el riesgo de la acción supera la confianza del sistema, un patrón que se desarrolla con más detalle en automatizacion-procesos-fijos.
Ninguna de esas cuatro piezas se construye en una tarde. Cada una requiere decisiones específicas al dominio del cliente y pruebas sobre su infraestructura real. El trabajo es, en gran medida, el que los ingenieros de software vienen haciendo hace veinte años en sistemas de misión crítica. Lo nuevo es que ahora uno de los componentes del sistema devuelve respuestas no deterministas, y eso cambia qué se puede garantizar y qué se puede testear. La necesidad de hacer el trabajo sigue estando ahí.
La ingeniería también tiene un capítulo que no es técnico y que sin embargo pertenece a su territorio. Un agente en producción necesita una métrica de negocio que alguien siga, un responsable humano que firme cuando pasa algo irreversible, y un acuerdo explícito sobre qué pasa cuando el agente se equivoca. Las empresas que lograron poner agentes a generar valor construyeron primero esas partes aburridas: datos limpios, un trabajo claro por agente, herramientas y permisos correctos, un humano que firma, un número que el negocio sigue. Lo brillante vino después, cuando esas condiciones ya estaban dadas.
El resultado es un piloto que no cierra
El patrón de fallo de los proyectos de agentes que no llegan a producción se repite. El prototipo funciona en condiciones controladas, impresiona en una presentación, y después se le pide que opere con los datos reales de la empresa, con los permisos reales, con los volúmenes reales, con los usuarios reales. Ahí es donde aparecen los costos que la facilidad del arranque había ocultado: el trabajo de limpieza de datos que nadie había cuantificado, la integración con sistemas internos que nadie había negociado, la responsabilidad humana que nadie había asignado, y la supervisión que nadie había diseñado.
Ese costo describe lo que vale construir un sistema que funciona en una organización. Lo que la ola de agent washing hace es ocultarlo durante las primeras semanas del proyecto, hasta que la demo deja de ser suficiente y hay que empezar a hacer el trabajo serio. En ese momento el equipo que lo construyó entiende que lo que le falta no viene de más potencia del modelo sino de criterio arquitectónico que el framework no proveyó y disciplina de ingeniería que la demo no exigió.
La proyección de Gartner sobre cancelaciones habla menos sobre la tecnología que sobre las organizaciones que la compran. Las que construyan agentes partiendo de las partes aburridas, en el orden correcto, llegarán a producción con sistemas que resuelven problemas verificables. La diferencia con el resto no depende de qué modelo se elija ni de qué plataforma se contrate. Depende del criterio técnico que se traiga al proyecto desde el día cero, y ese criterio sigue siendo un recurso escaso que la democratización del acceso no multiplicó. [AGREGAR TAMBIEN COMO CONCLUSION QUE ESTO NO SOLO LLEVA AL TRAAJO DE ARQUTECTURA, INGENIERIA QUE DIJIMOS SINO QUE TAMBIEN LLEVA VARIAS ITERACIONES. POR LO QUE ES POSIBLE PONER A FUNCIONAR UN AGENTE SIN ROBUSTEZ EN UNA TARDE PERO QUE LAS CONSECUENCIAS APARECERAN DESPUES DE LA DEMO Y EN MULTIPLES FORMAS. PERO CONSTRUIR UN SISTEMA DE AGENTES UNO QUE ESTE LISTO PARA TRABAJAR EN PRODUCCION DE FORMA ROBUSTA Y EFECTIVA UN CONOCIMIENTO Y EXPERIENCIA QUE NO SE SUPLEN CON LA SIMPLE DEMOCRATIZACION DE LAS HERRAMIENTAS. ALGO POR EL ESTILO]