Si no puedes automatizar tu flujo de trabajo, los agentes de tus usuarios tampoco podrán

El artículo, publicado por Waldek Mastykarz el 18 de octubre de 2026 en su blog Innovation Matters, parte de un escenario concreto: construir una evaluación (eval) para comprobar si un agente de programación con IA es capaz de desplegar una aplicación en tu plataforma cloud. Para verificar que la aplicación generada funciona, hay que aprovisionar recursos, desplegar el código, validar su funcionalidad y limpiar después. En teoría es sencillo, pero al intentar automatizarlo aparecen obstáculos: operaciones que exigen navegar por un portal, autenticación con pasos interactivos, aprovisionamiento que coordina varios servicios con su propia configuración y modos de fallo, e incluso dificultad para saber si el despliegue ha tenido éxito.

La tesis central es que se pueden esquivar esos problemas dentro del arnés de evaluación, pero eso es un error de enfoque: si a ti te cuesta automatizar tu flujo de trabajo, es probable que los agentes de tus usuarios tengan exactamente las mismas dificultades. Los obstáculos del arnés son, por tanto, un problema de producto, y rodearlos en el arnés los deja intactos para todos los demás.

El autor sostiene que los agentes dejan al descubierto una fricción que los humanos hemos aprendido a tolerar. Muchos flujos de desarrollo se diseñaron pensando en personas: navegamos por portales, copiamos valores entre pantallas, interpretamos mensajes de error y esperamos con paciencia a que terminen las operaciones. Con el tiempo aprendemos las manías de cada herramienta y desarrollamos atajos. Un agente normalmente no tiene esa experiencia: debe descubrir cómo realizar una tarea, llegar a la funcionalidad que necesita, coordinar las operaciones y determinar si ha tenido éxito. Un flujo que requiere interacción manual o conocimiento no documentado puede detenerlo por completo, y aun cuando todas las operaciones sean técnicamente accesibles, coordinar decenas de pasos añade complejidad y más oportunidades de fallo.

Como muestra de la escala a la que los agentes ya operan sobre infraestructura, el artículo cita el informe State of AI Agents 2026 de Databricks, según el cual los agentes de IA crean el 80 % de las bases de datos en Neon y el 97 % de sus ramas de base de datos. A medida que los agentes se convierten en una vía habitual de trabajar con la tecnología, los flujos que presuponen un operador humano se vuelven un problema para cada vez más usuarios.

La fricción también cuesta dinero. Un desarrollador humano puede tolerar varios minutos de configuración manual en un despliegue ocasional, pero los agentes ejecutan los flujos de forma repetida, y cada operación innecesaria, cada reintento y cada ronda de razonamiento repetido consume tiempo e inferencia. Con agentes, la fricción del flujo incrementa directamente el coste de completar una tarea. Por eso un flujo puede ser técnicamente ejecutable por un agente y aun así ofrecer una mala Experiencia de Agente (AX, Agent Experience).

Hacer accesible un flujo es solo el principio. La solución obvia es exponer la funcionalidad mediante interfaces programáticas como APIs, CLIs o herramientas MCP, de modo que el agente no tenga que navegar por una interfaz gráfica. Es una mejora valiosa, pero deja intacta la complejidad subyacente. Si un despliegue exige crear un proyecto, configurar un entorno, aprovisionar infraestructura, asignar permisos, desplegar código y verificar el resultado, tener una API para cada operación lo hace automatizable, pero el agente sigue teniendo que descubrir y coordinar cada paso.

Una «skill» puede ayudar describiendo la secuencia y gestionando los escollos habituales, y puede ser una solución provisional razonable. Pero trae sus propias dependencias: los usuarios deben enterarse de que existe, instalarla y mantenerla actualizada, de modo que apuestas la usabilidad de tu tecnología a que los usuarios den esos pasos adicionales. En cambio, un agente base que descubre y usa tu tecnología con sus herramientas habituales y la documentación pública funciona para cualquier usuario que pida ayuda a un agente, incluidos quienes nunca han oído hablar de tu skill.

La oportunidad a más largo plazo es simplificar el propio flujo. Por ejemplo, una plataforma podría ofrecer una única operación que lo gestione todo, del aprovisionamiento a la validación, con información de progreso clara y errores accionables. En lugar de enseñar a cada agente a coordinar un proceso complicado, se simplifica el proceso para todos. Y cuando los desarrolladores despliegan decenas o cientos de veces al día mediante agentes, las mejoras de fiabilidad y latencia se acumulan, igual que los ahorros, hasta poder diferenciar a la plataforma.

¿Cómo encontrar los flujos que requieren atención? El autor propone empezar como se haría para mejorar la Experiencia de Desarrollador: usar tú mismo la tecnología, hablar con los usuarios y observar cómo trabajan. Elige una tarea común y pide a un agente que la realice con un prompt sencillo, orientado al objetivo, sin prescribir los pasos. Si pruebas el despliegue en tu plataforma, nómbrala, pero deja que el agente averigüe cómo usarla. Advierte además de que la propia experiencia del equipo juega en contra: cuando conoces el producto a fondo, es tentador dar al agente los comandos exactos, la configuración y los enlaces a la documentación correcta, y así se le dirige sin darse cuenta lejos de los problemas que encontrarían usuarios menos expertos. Cuanto más conocimiento específico del producto presupone el prompt, más estrecha es la audiencia que representa. La prueba es si el agente puede tener éxito sin tu ayuda.

Después hay que observar: ¿dónde se atasca el agente?, ¿encuentra las interfaces adecuadas?, ¿puede autenticarse?, ¿entiende los errores?, ¿repite operaciones innecesarias?, ¿puede verificar que la tarea está completa? También conviene mirar más allá de los fallos evidentes: un agente que acaba teniendo éxito tras decenas de llamadas innecesarias a herramientas sigue revelando un flujo caro e ineficiente. Ante un problema, hay que investigar su causa antes de elegir solución: a veces hay que mejorar la documentación o los mensajes de error, a veces falta una API o hay que rediseñar el flujo, y a veces el problema está en el agente o sus herramientas y no en el producto. Una nueva skill o un servidor MCP son solo una de las respuestas posibles.

Otro aviso del texto se refiere a la telemetría. Los datos de uso ayudan a priorizar, pero tienen un punto ciego: un flujo que los agentes usan poco parece poco importante, cuando quizá lo usan poco precisamente porque no logran completarlo. Un bajo uso por parte de agentes puede ser señal de una barrera y no de baja demanda. Por eso no basta con las estadísticas: hay que hablar con desarrolladores y probar escenarios representativos, buscando flujos que la gente querría que hicieran los agentes pero que aún completa a mano. La ambición a largo plazo debería ser que la tecnología sea ampliamente utilizable por agentes, empezando por los flujos más importantes, decididos tanto por el uso observado como por las necesidades no cubiertas.

Finalmente, la Experiencia de Agente no se evalúa una sola vez. El producto evoluciona, los modelos cambian y los arneses de agentes incorporan nuevas capacidades y comportamientos, de modo que un flujo que hoy funciona bien puede mostrar nuevos cuellos de botella mañana. El autor recomienda integrar flujos de agente representativos en el desarrollo continuo del producto y dejar que los fallos e ineficiencias guíen las mejoras. No todo hallazgo exige actuar de inmediato: a veces lo correcto es aceptar una limitación porque corregirla costaría más que el beneficio esperado, algo legítimo siempre que sea una decisión deliberada. Además, el arreglo puede corresponder a un equipo distinto del que detectó el problema, porque mejorar la AX implica mirar más allá de los límites de cada herramienta o componente.

La conclusión es que, a medida que los agentes asumen más tareas de desarrollo, su capacidad para ejecutar tus flujos por sí solos pasa a formar parte de cómo funciona tu producto. Exponer APIs y herramientas es un comienzo; la mayor oportunidad está en hacer esos flujos descubribles y fiables para un agente, sin malgastar su tiempo ni los tokens de los usuarios. La próxima vez que te cueste automatizar un flujo, ya sea para una eval o para otra cosa, el autor aconseja no recurrir enseguida a un arnés más sofisticado: quizá hayas encontrado justo el punto donde tu tecnología debe mejorar. Elige una tarea común, deja que un agente la intente, observa dónde tropieza y pregúntate si el problema está en el agente o en el flujo que le has pedido recorrer.

Nota: el autor es Developer Advocate en Microsoft y el texto es un artículo de opinión basado en su experiencia; la única cifra concreta que aporta (80 % y 97 % de bases de datos y ramas creadas por agentes en Neon) procede de un informe de Databricks que el artículo cita, y no la hemos verificado de forma independiente.