La diferencia entre el "hype" por los agentes autónomos y los agentes de IA que realmente funcionan en producción

• A diferencia de la expectativa de que el boom de los agentes de IA llegará con fuerza en 2025, en entornos reales de producción existen límites prácticos
• Debido a la acumulación de errores y al problema del costo de tokens, hoy es imposible automatizar por completo flujos de trabajo de múltiples etapas
• La mayoría de los sistemas de agentes exitosos requieren un dominio estrictamente limitado y procesos obligatorios de aprobación humana o verificación
• La verdadera dificultad no está en el rendimiento de la IA en sí, sino en el diseño de herramientas y sistemas de retroalimentación que el agente pueda usar bien
• Se prevé que en 2025 las startups y empresas que pongan al frente a los agentes totalmente autónomos enfrentarán grandes obstáculos en la adopción real y el escalado

---

Por qué apuesto a que los agentes de IA no despegarán en 2025 (aunque estoy desarrollando agentes de IA)

• Abunda el hype de que 2025 será el año de los agentes de IA
• El autor ha construido directamente durante el último año diversos sistemas de agentes de IA que funcionan en entornos reales de producción
• A partir de razones surgidas de experiencia práctica directa, mantiene una postura escéptica frente a la "revolución de los agentes" del mercado

Experiencia construyendo distintos sistemas de agentes

• Agentes de desarrollo: generación de componentes React a partir de lenguaje natural, refactorización de código legacy, gestión automática de documentación de API, generación de funciones basada en especificaciones, etc.
• Agentes de datos e infraestructura: manejo de consultas complejas y migraciones, automatización de DevOps multicloud
• Agentes de calidad y procesos: corrección automática de lint, generación de código de pruebas, automatización de code review y Pull Request detallados
• Estos sistemas sí aportan valor real y ahorran tiempo, pero esa misma experiencia es el trasfondo de una mirada crítica frente al hype

Resumen clave: tres verdades incómodas sobre los agentes de IA

1. Acumulación de tasa de error: a medida que aumentan las etapas, la tasa de éxito cae exponencialmente. Es difícil cumplir el estándar de producción (99.9% o más)
2. Ventana de contexto y costo: mientras más larga es la conversación, el costo de tokens aumenta cuadráticamente, destruyendo la viabilidad económica
3. Dificultad de diseñar herramientas y retroalimentación: más que un límite técnico, el mayor reto es el diseño de herramientas y sistemas de feedback que el agente pueda aprovechar

La realidad matemática de la acumulación de errores

• Los flujos de trabajo autónomos de múltiples etapas son inviables a escala operativa real debido a la acumulación de errores
• Por ejemplo, incluso si cada etapa tuviera una confiabilidad del 95%, en 20 etapas la tasa final de éxito sería solo de 36% (requisito de producción: 99.9% o más)
• Incluso suponiendo una alta confiabilidad, la probabilidad de fallo aumenta drásticamente conforme crece el número de etapas
• En la práctica, en vez de automatizar por completo todos los procesos, se diseñan estructuras con verificación independiente y puntos de rollback en cada etapa, además de confirmación humana
• Patrón de los sistemas de agentes exitosos: contexto claramente limitado, tareas verificables y participación humana en los puntos importantes de decisión

Estructura de costos de tokens y límites económicos

• El costo de tokens para mantener la ventana de contexto y la conversación emerge como una realidad antieconómica a medida que el sistema escala
• Los agentes conversacionales deben procesar todo el historial de conversación en cada turno, por lo que el costo se dispara cuadráticamente conforme aumentan las rondas
• Una conversación de 100 intercambios puede costar 50 a 100 dólares solo en tokens, y al aplicarlo a un gran volumen de usuarios la viabilidad económica colapsa
• En cambio, los agentes de generación funcional stateless (sin estado), de una sola tarea y sin necesidad de contexto, son más favorables en costo y escalabilidad
• Los agentes de producción más exitosos se parecen más a "herramientas inteligentes con un propósito claro" que a agentes "conversacionales"

La barrera del diseño de herramientas y sistemas de retroalimentación

• La verdadera dificultad al desarrollar agentes altamente productivos es la capacidad de diseñar herramientas, algo que muchos equipos existentes subestiman
• La precisión del tool calling ha mejorado, pero la clave está en diseñar cómo resumir eficazmente estados y resultados complejos para devolvérselos al agente como feedback
• Ejemplos:
  • Cuando una tarea tuvo éxito parcial, es necesario decidir cuánta información y qué tipo de resumen se necesita
  • Por ejemplo, si el resultado de una consulta tiene 10,000 registros, se requiere una abstracción para entender el estado como "éxito, 10 mil registros, solo los primeros 5"
  • Cuando una herramienta falla, es necesario ajustar la cantidad de información para la recuperación y evitar contaminar el contexto
• La clave de los agentes de bases de datos que sí funcionaron en la práctica: proveer retroalimentación estructurada con la que el agente realmente pueda tomar decisiones
• En la realidad, la IA hace alrededor del 30% del trabajo; el 70% restante corresponde a habilidades tradicionales de ingeniería como feedback de herramientas, recuperación y manejo de contexto

Límites de la integración con sistemas reales

• Incluso si se resolvieran los problemas de confiabilidad y costo, la integración con el mundo real funciona como otra barrera
• Los sistemas organizacionales reales no son APIs consistentes; arrastran características legacy, errores excepcionales, autenticación cambiante, restricciones variables y requisitos de cumplimiento, es decir, complejidad impredecible
• Un agente de base de datos real requiere sí o sí programación tradicional para manejo de connection pools, rollback de transacciones, respeto por réplicas de solo lectura, timeouts de consultas, logs, etc.
• La promesa de que "la IA integrará todo el stack de manera totalmente autónoma" choca con la realidad al momento de construirlo

Patrones de lo que sí funciona bien en la práctica

• Principios comunes de los sistemas de agentes exitosos
  1. Agente de generación de UI: la experiencia del usuario la revisa finalmente un humano (la IA solo se encarga de la complejidad de convertir lenguaje natural → React)
  2. Agente de base de datos: las operaciones destructivas siempre las confirma un humano (la IA solo transforma a SQL; el control de preservación de datos lo mantiene una persona)
  3. Agente de generación de funciones: operación limitada dentro de especificaciones claras (sin estado, efectos secundarios ni integraciones complejas)
  4. Automatización de DevOps: la IA genera el código de infraestructura; despliegue, versionado y recuperación quedan en los pipelines existentes
  5. Agente de CI/CD: cada etapa se diseña con criterios claros de éxito y mecanismos de rollback
• Resumen del patrón: la IA maneja la complejidad, los humanos conservan el control y la confiabilidad la asegura la ingeniería tradicional

Perspectiva y predicciones de mercado

• Las startups impulsadas por agentes totalmente autónomos serán las primeras en chocar con problemas de rentabilidad
• En un flujo de trabajo de 5 etapas, el demo puede verse excelente, pero las empresas reales exigen más de 20 etapas y se topan con límites matemáticos
• Las empresas que solo agreguen agentes de IA a software existente probablemente enfrenten estancamiento en la adopción por falta de integración real
• Los verdaderos ganadores: equipos que, dentro de dominios claramente limitados, aplican IA solo a las tareas difíciles y ponen humanos y condiciones de borde en las decisiones importantes
• Se espera que el mercado aprenda, mediante experiencias costosas, la diferencia entre una IA que funciona bien en demos y una IA realmente confiable

Principios deseables para construir sistemas de agentes

• Definir límites claros: delimitar con precisión el rol del agente y los puntos de handoff con humanos o sistemas existentes
• Diseñar para el fallo: es indispensable diseñar estructuras de rollback y recuperación cuando la IA se equivoca
• Validar la economía: diseñar la estructura considerando el costo por interacción y el escalado (lo stateless es más económico que lo stateful)
• Priorizar confiabilidad sobre autonomía: un sistema consistentemente confiable gana más confianza del usuario que uno que hace magia de vez en cuando
• Construir sobre bases sólidas: asignar a la IA solo las partes difíciles (interpretación de intención, generación, etc.) y dejar el resto (ejecución, manejo de errores, etc.) al software tradicional

La verdadera lección obtenida de la experiencia práctica

• La brecha entre "funciona en un demo" y "opera realmente a gran escala" es enorme
• La confiabilidad de los agentes, la optimización de costos y la complejidad de integración siguen siendo problemas principales no resueltos en toda la industria
• La experiencia real de implementación y el compartir experiencias honestas son clave para el avance de la industria
• Cuanto más discutan quienes tienen experiencia práctica metodologías razonables y casos reales de fracaso, mayores serán las probabilidades de éxito colectivo

[GN⁺]

Opinión de Hacker News

• He hablado con un ingeniero de producción de IA de Amazon, y me comentó que actualmente ninguna empresa usa únicamente IA generativa en lugares donde habla directamente con clientes; todas las respuestas automáticas usan tecnología antigua no generativa, porque los problemas de confiabilidad de la IA generativa son demasiado grandes como para poner en juego la reputación de una empresa.

  • Antes me interesaban mucho los agentes que combinaban técnicas simbólicas de la "IA antigua" con machine learning tradicional, pero terminé trabajando sobre todo con redes neuronales pre-transformer; al final, siempre construyes primero un sistema con intervención humana y recopilas datos de evaluación y entrenamiento; después, el sistema se hace cargo de parte del trabajo y mejora también la calidad del resto. Especialmente en tareas "subjetivas", también hay que evaluar sí o sí los sistemas simbólicos. Si vas a entrenar el sistema, no puedes evitar la evaluación.

  • En la práctica, muchas empresas tecnológicas ya están implementando IA generativa en soporte al cliente por chatbot en tiempo real; conozco casos como Sonder y Wealthsimple. Si el LLM no puede responder una consulta, la conversación pasa de inmediato a un agente humano.

• Algo que aún no se ha discutido es la ventana de contexto. Los humanos, en su área de especialidad, pueden manejar en la práctica un contexto casi "infinito". Los modelos pueden superar parcialmente esa limitación con datos de entrenamiento más grandes y diversos, pero no creo que sea una solución real. Ahora mismo, la gente tiene que comprimir su propio contexto dentro del prompt, así que en idiomas flexibles como el inglés se siente menos como ingeniería y más como recitar hechizos o adivinar. En vez de un enfoque determinista, siento que se pierde gran parte de los datos.

  • En los humanos, "contexto" y "pesos" no están separados de forma fija; con el tiempo, la experiencia y los resultados siguen cambiando mis propios "pesos", pero en los LLM eso es imposible porque, por arquitectura, los pesos son de solo lectura.

  • Tengo mis dudas sobre si los humanos realmente tienen una ventana de contexto tan enorme. Yo me topo seguido con límites muy humanos de "ventana de contexto" al resolver problemas complejos. Me pregunto si hay ejemplos reales de eso.

• En general mi experiencia usando herramientas de IA ha sido positiva. Son de gran ayuda para delegar tareas pequeñas cuando necesito descansar, o para ordenar el trabajo y ponerlo en marcha. Pero el tema de costos aparece rápido. Por ejemplo, usar Claude Code en una base de código grande cuesta unos $25 en 1 o 2 horas, y si además le sumas corrección automatizada sube hasta $50/hr. Hay un trade-off entre velocidad, precisión y costo. Los Agents que han salido últimamente todavía tienen una posición poco clara dentro de ese triángulo, así que aunque muchos experimentos son interesantes, sigo viéndolos como un riesgo.

  • Viéndolo con un poco de cinismo, la estructura en la que el LLM se re-promptea a sí mismo sin parar para corregir errores, y el enfoque de "¡No hace falta RAG! Solo métanle todo el código a una ventana de contexto de 1m tokens", al final encajan perfecto con un modelo de negocio de cobro por token.

  • Una idea en la que he estado pensando últimamente es hacer que la IA genere varios borradores de commits desde cero, y luego filtrar y pulir esos resultados de forma manual o automatizada. Mientras más grande es la tarea, más probable es que pequeñas desviaciones iniciales arruinen el resultado completo. Por eso, incluso con el SOTA actual, dejar que los agentes prueben varias opciones en paralelo reduce el tiempo de refactorización manual. Ya había escrito sobre ese proceso en GitHub.

  • Me gustaría preguntar si es un servicio por suscripción.

• Los workflows humanos de múltiples pasos normalmente tienen checkpoints de verificación, porque los humanos tampoco somos precisos más del 99% del tiempo. En el futuro, los agentes también tendrán procedimientos de validación diseñados para sus salidas, y serán entrenados para pasar por ese proceso antes de avanzar al siguiente paso. Incluso podría hacerse una evaluación previa del riesgo, tipo: "aquí como mínimo necesitamos más de 99% de precisión".

  • Claude Code se detiene constantemente antes de seguir con una tarea y le pregunta al usuario si quiere continuar, además de mostrar por adelantado los cambios propuestos. Eso es efectivo para evitar desperdicio de tokens y trabajo ineficiente.

  • Muchas aplicaciones también necesitan rediseñarse para ajustarse a esta estructura. Yo creo que la arquitectura de microservicios combina bien con los LLM, así que podría volver a ponerse de moda.

• Estoy de acuerdo con la idea de que "el problema real no es la capacidad de la IA, sino diseñar herramientas y sistemas de retroalimentación que los agentes puedan usar de forma efectiva". Como no estaba seguro de cómo lo iba a recibir el mercado, me limité a observar y terminé uniéndome a una startup muy pequeña enfocada específicamente en crear agentes. En 5 meses pasé de escéptico a convencido. Si delimitas el tema de forma muy estrecha y te concentras en el tooling que necesita el modelo para trabajar, puedes lograr tasas altas de finalización. Hay una tendencia a rechazar lo no determinista, pero con buen tooling y un scope cada vez más acotado, en la práctica sí puede ser bastante útil. El tooling en sí parece difícil, pero creo que se puede resolver razonablemente bien. Soy optimista sobre el futuro.

• Creo que todos estos son problemas que se pueden resolver, pero muchas startups no se enfocan en ellos porque están compitiendo por conseguir ARR rápido. Tiene algo de razón la opinión de que los agentes no son tan útiles como prometen, pero en la práctica es un problema de ingeniería. Si se aborda desde otro ángulo, creo que va a funcionar; personalmente me inclino más por RL. Por ejemplo, necesitas un buen verificador. En muchas tareas, verificar es más fácil que hacer la tarea directamente. Incluso si solo tienes 5 resultados generados en paralelo con 80% de precisión, hay un 99.96% de probabilidad de que al menos uno esté bien, y el verificador puede escogerlo. También se vuelve matemáticamente ventajoso en situaciones de varios pasos. Es un enfoque distinto a lo que se ha hecho hasta ahora; el artículo también menciona el paradigma de workflows de 3 a 5 pasos, y eso encaja muy bien en la práctica. Necesitamos ver más modelos así en adelante.

  • Creo que en muchas tareas verificar sí es en realidad más difícil que la tarea misma. En particular, en QA de software muchas veces ha habido recortes con esa lógica, y siento que el resultado ha sido peor calidad. Los verificadores se vuelven muy difíciles porque el número de combinaciones posibles entre el sistema y los estados del mundo exterior crece de forma exponencial. Los LLM son atractivos para encargarse de trabajo repetitivo en entornos complejos, como mockear dependencias o rellenar datos por adelantado, pero para que una prueba de verificación sea significativa siempre termina exigiéndose que sea 100% correcta, y al final necesitas otro verificador para cada precondición. Si todas las etapas tienen que ser 100% correctas, la probabilidad acumulada termina cayendo. Los humanos, por lo general, prueban con cuidado casos específicos y no verifican perfectamente todos los casos posibles; las pruebas white-box son mucho más comunes que las black-box. Si el LLM produce mucho código, al final el operador tiene que entender todo el código para poder hacer una verificación white-box, y entonces el tiempo ahorrado vuelve a reducirse. Por ahora, el LLM genera cosas y yo tengo que corregir personalmente todos los errores, así que tengo menos confianza y además me toma más tiempo. En algunas situaciones eso se puede resolver ajustando la interfaz a lo que el LLM espera, pero no es algo generalizable. Fuera del software, muchas veces la verificación es directamente imposible, por ejemplo: "selecciona las 5 startups de videojuegos más prometedoras". Eso no tiene verificación objetiva. Si empiezas a delegar ciegamente esas áreas a una máquina que tampoco es humana, después ya no hay cómo arreglarlo.

  • Me pregunto si de verdad se puede asumir que esas cinco generaciones serán independientes entre sí.

  • Totalmente cierto. En la práctica funciona que varios agentes lo intenten, repitan varias veces y apliquen soluciones distintas. De hecho, he vivido casos donde un enfoque recibió feedback negativo y otro método diferente terminó teniendo éxito.

• Me sorprende que una sola persona, o un equipo muy pequeño, haya construido más de 12 agentes de IA en producción real para desarrollo, DevOps, operaciones de datos y demás. Si ves la tasa de fracaso de las startups, ya es difícil hacer "un" buen producto, así que haber hecho 12 me parece impresionante. Nosotros también usamos herramientas de stack de datos + agentes de IA como Definite, y nos tomó 2 años llegar a un punto que recién desde hace unos 6 meses se siente decente. Definite

  • En realidad no significa 12 productos independientes; quiere decir que construyó 12 herramientas de propósito muy específico para usar en el trabajo según se necesitaban. Tal como plantea el tema general del artículo, un agente solo resulta útil cuando se concentra en objetivos muy simples y claros.

  • Se siente un poco raro haber hecho más de 12 mientras además mantuviste un trabajo de tiempo completo durante 3 años.

• Yo también me dedico profesionalmente al desarrollo de automatización con agentes/IA. Los agentes de código abiertos y sin límites son simplemente una idea tonta. Los checkpoints de validación humana, un espacio de búsqueda pequeño y preguntas/prompts muy específicos, como "¿este correo tiene una factura? SÍ/NO", son lo realista. Entiendo el deseo de tener agentes totalmente automáticos, pero la tecnología todavía no está ahí. Yo no toco generación de contenido —texto, imágenes, código—, porque eso tarde o temprano te va a golpear.

  • Yo también, junto con frameworks de agentes y chat coding, he reducido alrededor del 50% de mi carga de trabajo. He visto efectos reales con GPT. Pero una de cada diez veces aparece un error sí o sí. Creo que esa tasa de error no se va a corregir a menos que cambie de raíz la arquitectura de los LLM. Si el hype actual no destruye la confianza de los desarrolladores, estoy convencido de que en el futuro saldrán sistemas mucho más robustos. De hecho, la mejora de productividad es tan evidente que ahora podemos contratar mucho menos personal que antes. La curva de aprendizaje en muchos temas también ha bajado drásticamente porque los LLM compensan el deterioro de la calidad de Google Search. En workflows automatizados, la estructura más importante es un orchestration framework donde el LLM se haga cargo de parte del trabajo humano, reporte también su nivel de confianza y, si el porcentaje de confidence es bajo, pase de inmediato a un humano. Si se tienen bien resueltos los tests, los guardrails y demás, hay suficiente posibilidad de reemplazar trabajo humano al menos en tareas no centrales. La meta no es reemplazar personas, sino automatizar trabajo para reducir el tamaño de los equipos. Por ejemplo, estoy convencido de que llegará el día en que un LLM se encargue de tareas humanas en e-commerce grande, como descripciones de productos, verificación de imágenes, detección de errores tipográficos o inconsistencias entre imagen y producto.

  • En general estoy de acuerdo, pero si se aborda así, tal vez lo que queda es "solo un sistema de workflow caro". Me hace pensar si realmente hace falta usar LLM para cosas que ya podían hacerse con tecnologías anteriores.

  • Yo también coincido. Hoy por hoy, el punto ideal para los agentes es "alcance estrecho, bajo riesgo y tareas repetitivas y aburridas". Como ejemplo, dejé aquí una experiencia usando agentes para tareas auxiliares de markdown en un dev-log: aquí.

  • Es cierto que la validación humana es lo más confiable para crear checkpoints, pero también existen otras formas adicionales, como unit tests o validación ad hoc del sistema completo.

• De hecho, yo creo que el autor debería ser incluso más optimista sobre los agentes autónomos que ahora. El 90% de lo que estamos haciendo hoy era imposible a inicios de 2024. No hay que subestimar la curva de progreso.

• Pienso lo mismo. También hay una entrada de blog relacionada. La diferencia clave es que reducir errores con HITL (Human in the loop) sí tiene sentido, mientras que HOTL (Human out of the loop) más bien crea problemas.