Deja de desarrollar agentes de IA y usa flujos de trabajo con LLM más inteligentes

• La mayoría de los equipos que construyen sistemas basados en LLM intentan empezar por agentes (Agents), pero en la mayoría de los casos terminan colapsando por la complejidad, la falta de control y la dificultad para depurar
• Los verdaderos patrones de agente, donde se necesitan memoria, RAG, uso de herramientas y control del flujo de trabajo, en realidad son poco comunes; la mayoría de los problemas pueden resolverse mejor con flujos de trabajo simples (encadenamiento, paralelización, enrutamiento, etc.)
• Se recomienda aplicar primero 5 patrones de flujo de trabajo con LLM útiles en la práctica, y usar agentes con cuidado solo cuando de verdad sean necesarios
  • Encadenamiento de prompts, paralelización, enrutamiento, orquestador-worker, evaluador-optimizador
• Incluso cuando se necesitan agentes, al final lo más importante sigue siendo la participación humana, el control claro y la observabilidad (Observability)

---

¿De verdad se necesitan agentes de IA?

• Perspectiva de Hugo Bowne-Anderson, quien ofrece consultoría y capacitación sobre construcción de sistemas con LLM a distintos ingenieros y equipos, incluidos Netflix, Meta y la Fuerza Aérea de EE. UU.
  • Él imparte el curso Building LLM Applications for Data Scientists and Software Engineers

Un mal comienzo: por qué todos se obsesionan con los agentes

• Muchos equipos, al iniciar un proyecto con LLM, introducen primero estructuras complejas como agentes, memoria, enrutamiento, uso de herramientas y personalidad
• Cuando se implementan en la práctica, se presentan con frecuencia comportamientos anómalos y fallas persistentes en áreas como la colaboración entre agentes, la selección de herramientas y la memoria de largo plazo
• Como ejemplo, en un proyecto de agente de investigación basado en CrewAI, se experimentó que cada rol (investigador, resumidor y coordinador) no lograba colaborar como se esperaba y el sistema terminaba desmoronándose sin remedio

¿Qué es un agente?

• Cuatro características de un sistema con LLM: memoria, recuperación de información (RAG), uso de herramientas y control del flujo de trabajo
• La última, el control del flujo de trabajo (cuando el LLM decide directamente el siguiente paso o si debe usar una herramienta), es lo que se considera una característica agentiva
• En la mayoría de las tareas reales, los flujos de trabajo simples (encadenamiento, enrutamiento, etc.) muestran mayor estabilidad

Patrones de flujo de trabajo con LLM que conviene usar en la práctica en lugar de agentes

1. Encadenamiento de prompts (Prompt Chaining)

• Descripción: divide varias tareas en una serie de etapas (una cadena), de modo que el LLM procese cada paso de forma secuencial
• Ejemplo: extraer nombre, cargo y empresa de un perfil de LinkedIn → añadir información adicional de esa empresa (misión, vacantes, etc.) → redactar un correo personalizado con base en el perfil y la información de la empresa
• Ventajas: como cada etapa está claramente separada, es fácil rastrear y corregir la causa cuando aparece un bug; favorece la depuración y el mantenimiento
• Lineamientos:
  • Adecuado para tareas conectadas de manera secuencial
  • Si falla una sola etapa, toda la cadena puede venirse abajo
  • Si se divide en tareas pequeñas, se logran resultados más predecibles y una depuración más sencilla

2. Paralelización (Parallelization)

• Descripción: ejecuta múltiples tareas independientes al mismo tiempo para acelerar el proceso completo
• Ejemplo: extraer en paralelo varios elementos como educación, experiencia y habilidades de distintos perfiles para reducir el tiempo total de procesamiento
• Ventajas: es eficiente incluso con grandes volúmenes de datos en extracción o procesamiento independiente, y encaja bien en entornos de procesamiento distribuido
• Lineamientos:
  • Funciona bien cuando cada tarea es independiente y la ejecución simultánea mejora de forma importante la velocidad total
  • Hay que prestar atención a excepciones como race conditions, timeouts y otros problemas durante la ejecución paralela
  • Adecuado para procesar grandes cantidades de datos y analizar varias fuentes al mismo tiempo

3. Enrutamiento (Routing)

• Descripción: el LLM clasifica los datos de entrada y los dirige automáticamente al flujo de trabajo correspondiente
• Ejemplo: en una herramienta de soporte al cliente, clasificar si la entrada es una consulta sobre producto, un problema de pago o una solicitud de reembolso, y luego procesarla automáticamente con el flujo adecuado; si el tipo es ambiguo, enviarla al manejador por defecto
• Ventajas: aplica lógica de procesamiento especializada según el tipo de entrada y separa de forma limpia los distintos casos
• Lineamientos:
  • Úsalo cuando se necesite un tratamiento distinto según el tipo de entrada o la situación
  • En casos límite o excepcionales, el enrutamiento puede fallar o dejar entradas sin clasificar
  • Es indispensable diseñar un manejador catch-all para casos no clasificados o excepcionales

4. Orquestador-worker (Orchestrator-Worker)

• Descripción: un LLM con rol de orquestador descompone la tarea y toma decisiones para delegar subtareas a workers (LLM de ejecución), controlando directamente el flujo general y el orden
• Ejemplo: clasificar un perfil objetivo como tech o non-tech → si es tech, delegar la generación del correo a un worker especializado; si es non-tech, delegarlo a otro worker
• Ventajas: separa la toma de decisiones (clasificación/juicio) de la ejecución (procesamiento individual), lo que favorece el control dinámico del flujo y la escalabilidad
• Lineamientos:
  • Adecuado cuando cada tarea requiere manejo especializado, o cuando hay bifurcaciones complejas y coordinación paso a paso
  • Si el orquestador descompone o delega mal una tarea, se generan errores en todo el flujo
  • Mantén la lógica explícita y simple, y diseña con claridad la delegación, el orden y las condiciones de término

5. Evaluador-optimizador (Evaluator-Optimizer)

• Descripción: el LLM evalúa el resultado (score/feedback) y, si no cumple con el criterio, lo corrige o mejora de forma iterativa
• Ejemplo: generar un borrador de correo → el evaluador entrega puntaje de calidad y feedback → si cumple un umbral o supera el máximo de iteraciones, termina; si no, vuelve a corregirse
• Ventajas: permite mejorar iterativamente la calidad del resultado final hasta alcanzar el nivel objetivo, y resulta útil cuando se aprovechan criterios cuantitativos
• Lineamientos:
  • Adecuado para situaciones donde la calidad importa más que la velocidad y se necesita optimización iterativa
  • Sin una condición de término, puede caer en un bucle infinito
  • Es esencial definir criterios de calidad claros y límites de iteración

Cuándo sí se necesitan agentes

• Los agentes muestran su verdadero valor en entornos donde está garantizada la intervención humana en tiempo real (Human-in-the-loop)
  • Ejemplo 1: apoyo en ciencia de datos: consultas SQL, visualización, recomendaciones de análisis de datos, etc., donde el LLM prueba enfoques creativos y una persona evalúa o corrige el resultado
  • Ejemplo 2: partner creativo: ideas de copy, propuestas de titulares, recomendaciones de estructura de texto, etc., donde la corrección de rumbo y la revisión de calidad por parte de una persona son clave
  • Ejemplo 3: asistente de refactorización de código: sugerencias de patrones de diseño, detección de edge cases, optimización de código, etc., donde el desarrollador aprueba o complementa
• Característica: los agentes no son más efectivos cuando “resuelven todo por su cuenta”, sino en entornos donde una persona corrige errores y orienta la dirección en tiempo real

Cuándo los agentes no son adecuados

• Sistemas enterprise y mission-critical (finanzas, salud, legal, etc.):
  • Como la confiabilidad de la automatización y el comportamiento determinista son importantes, una estructura en la que un agente LLM tome decisiones resulta riesgosa
  • Deben usarse patrones de control claros, como orquestador o enrutamiento
• Cualquier situación en la que la estabilidad y la previsibilidad sean importantes
  • Casos anómalos: problemas en los que el agente elige mal herramientas repetidamente sin contexto ni memoria, o fracasa en la división del trabajo y la coordinación, haciendo colapsar todo el flujo
• Factores de falla de los sistemas de agentes que aparecen con frecuencia en la práctica
  • Falta de diseño de un sistema de memoria explícito, lo que provoca pérdida de contexto
  • Pocas restricciones en la selección de herramientas (uso innecesario o incorrecto de tools)
  • Dependencia exclusiva de una estructura de delegación libre, que termina fallando en la coordinación colaborativa

Lecciones para el diseño en la práctica

• Incluso al introducir agentes, sigue siendo indispensable contar con un nivel de diseño, observabilidad y control comparable al de un sistema de software bien terminado
• Más que usar frameworks complejos de agentes, es más rápido y seguro diseñar con observabilidad (Observability), bucles de evaluación claros y una estructura con control directo

Conclusión (TL;DR)

• Los agentes suelen estar sobrevalorados y usarse en exceso
• La mayoría de las tareas reales se resuelve mejor con patrones de flujo de trabajo simples
• Los agentes muestran su verdadero valor en entornos donde hay intervención humana directa
• En sistemas estables, más bien pueden convertirse en un factor de riesgo
• Diseña con observabilidad, control explícito y una estructura de evaluación iterativa

• En lugar de frameworks complejos de agentes, la clave para desarrollar servicios basados en LLM de forma más rápida y segura es diseñar con observabilidad, bucles de evaluación claros y una estructura con control directo

[samdo103]

Hace un mes, para aprender qué era la programación con IA usando CURSOR, empecé a desarrollar un framework de desarrollo.

Durante unas 3 semanas, repetí el ciclo de ver cómo el código fuente, que había sido validado con éxito por un Agente de IA, se arruinaba, e intenté por todos los medios controlar al Agente de IA, pero fracasé.

Entonces me di cuenta de que, antes de desarrollar el framework, lo prioritario era desarrollar el código fuente para controlar al Agente de IA.

Al final, exactamente un mes después de haber empezado para entender qué era la IA, logré completar el desarrollo de un software 100% implementable y 100% operable por IA con control perfecto sobre el Agente de IA (más precisamente, sin necesidad de un LLM externo ni de un Agente de IA).

Ahora llevo 14 días avanzando en el proceso de crear y hacer cumplir reglas operativas mientras sigo entrenando esa META IA para una mayor sofisticación; al mismo tiempo, estoy migrando, mejorando y estandarizando en paralelo tres sistemas MES que antes habían sido creados de forma incompleta por personas, y ya estoy entrando en la etapa final.

Y ahora también me estoy preparando para otra evolución.

[spilist2]

Pero, en el prompt chaining, ¿no sería válido llamar también agentes por separado al LLM que ejecuta cada prompt, al worker de ejecución, al worker orquestador, al LLM evaluador, etc.?

[spilist2]

Ah, así que existe eso de que “el control final del flujo de trabajo (que el LLM decida por sí mismo el siguiente paso o si usar una herramienta) se considera una característica agéntica”. Entendido. Entonces era un texto dirigido a los autonomous agents. Todavía no conozco muy bien el tema de los agentes, así que...

[GN⁺]

Opiniones de Hacker News

• Desarrollar agentes fue realmente divertido, pero está claro que hay problemas serios en la ingeniería de contexto. Por más que aumentes la ventana de contexto, igual hay que curar qué elementos puede ver el agente, y siento que faltan filtros eficaces que seleccionen solo la información realmente importante. Por eso hay que ayudarlo esparciendo archivos .md por todas partes, y también es importante asignar roles. Este sistema de .md es una especie de sistema de memoria primitivo, y se puede desarrollar de forma mucho más robusta. También creo que sería posible crear en tiempo real programas o modelos basados en lenguaje natural según la interacción del usuario. Usando Claude Code, me di cuenta de que “dirigir” al agente con una suite de pruebas es un mecanismo de aprendizaje por refuerzo realmente poderoso, y como este loop en la mayoría de los casos sigue funcionando bien, espero que surjan nuevas ideas para convertir a los agentes en colaboradores más inteligentes
  • Siento que termino pasando más tiempo peleándome con las herramientas que haciendo el trabajo real
  • Me pregunto si hay recomendaciones sobre cómo estructurar archivos .md en estos sistemas. Me preocupa que meter mucho marcado para que sea fácil de leer para personas termine afectando el procesamiento del llm. Quisiera saber si crear archivos .md pensados para lectura humana también entorpece su uso con llm
  • Por mi experiencia, la gestión del contexto es el núcleo de casi todos los problemas. Por ejemplo, crear el contexto correcto para tareas paralelas/recursivas, omitir ciertas etapas (como editar una respuesta previa) y mostrar solo el resultado modificado, hacer que el agente reconozca su propia salida cuando le dejo comentarios, etc.; en la práctica hay muchísimas situaciones distintas
  • Me parece interesante esa parte de reforzar al agente con una suite de pruebas; me gustaría saber si podrías explicar con más detalle qué procedimiento sigues exactamente
• Todavía no estoy seguro de si los agentes de IA se usarán de forma masiva como la gente dice en LinkedIn, pero dejo abierta esa posibilidad. Yo hoy uso IA con control fuerte, como Claude Code o Cursor. No porque al modelo le falte capacidad, sino porque quiero aportar con frecuencia mi propio “taste” y dirección. Darle más autonomía a la IA no me resulta necesariamente atractivo, porque necesito intervenir para sentir conexión e identidad con lo que se produce. Quizá cambie de opinión si cambia la forma de trabajar o aparece una UX nueva, pero por ahora no quiero que la IA sea demasiado agente
  • Me pregunto si crees que, con el tiempo, al entender bien cómo se comportan los modelos y dándoles más y mejor contexto e instrucciones, se puede llegar a cubrir en cierta medida ese taste del usuario y su necesidad de dirección. En mi experiencia, con una ingeniería de prompts bien hecha, en bastantes workflows la IA puede comportarse como uno quiere, y muchas veces no hace falta intervenir tan seguido
  • Coincido exactamente. Ya dejé comentarios parecidos en otros lados, pero sigo pensando que el viejo dicho de que “no hay almuerzo gratis” sigue siendo cierto. Si un LLM pudiera resolver problemas sin sacar por completo al humano de la ecuación, eso significaría que cualquiera podría construir el mismo sistema sofisticado con solo unas líneas de prompt, y entonces desaparecerían las diferencias y el valor entre sistemas. Si el prompt fuera un nuevo nivel de abstracción, por ejemplo pedirle a Claude “hazme una app de notas”, millones de personas estarían introduciendo el mismo prompt barato, y ahí me pregunto qué valor adicional aporta exactamente quien promptea
  • Yo creo que con el tiempo cada uno de estos elementos de “taste” también se podrá sistematizar cada vez más como prompts. Por ejemplo, con un prompt hago que al cambiar código no se introduzca mutabilidad innecesaria y que, si ya es posible, se escriba como immutable. Con otro prompt establezco reglas como evitar logs inútiles (según la definición específica que yo mismo fijé). Al revisar cambios de código, ejecuto todos esos prompts por separado y luego los junto como salidas MCP estructuradas. Aplico estas cosas a un agente de código para lograr iteraciones de revisión automatizada. Si surge una situación donde necesito agregar contexto manualmente, creo un prompt nuevo o amplío uno existente para reforzarlo
• Me parece curioso que en un campo que da la impresión de tener apenas 1 o 2 años de carrera ya estén apareciendo “autoridades”. Es como la versión invertida del meme de “se busca alguien con 10 años de experiencia en un lenguaje de 2 años”
  • Yo vengo construyendo lo que hoy se llama “ai agent” desde que salió GPT-3, y mucha otra gente tuvo la misma experiencia. Ya van 5 años, y si después de 5 años todavía no aparece gente experta, entonces yo diría que el problema es que no existen expertos como tal. Claro, hoy la palabra “agente” se está convirtiendo en un buzzword y se está vaciando de significado
  • Cuando lees testimonios tipo “he trabajado con decenas de equipos...”, la reacción inevitable es que suena un poco dramático
• Resumen central: si ya existe una solución predefinida, no hace falta usar un agente (por ejemplo, los “patrones” que aparecen en el artículo). Normalmente los programadores recomiendan soluciones más simples y confiables cuando el problema puede resolverse con un programa. En el futuro, la IA será tan inteligente que podrá resolver cualquier problema por fuerza bruta, pero por ahora solo añade complejidad. Creo que una de las razones por las que la gente se entusiasma tanto con los agentes es que la mayoría conoció los LLM usándolos como asistentes de chat. En esos asistentes de chat muchas veces no hay una solución fija y la interacción es compleja, así que ahí sí un agente muestra su valor. Ejemplo: “busca el viernes por la tarde más cercano y mándale un mensaje a Bob preguntándole si puede verse conmigo”; en algo así hay límites para programar de antemano todos los casos posibles. La forma de interactuar con el asistente se vuelve casi infinita, y por eso un agente encaja bien
  • Funciona muy bien cuando la velocidad de verificación es más rápida que hacerlo uno mismo desde cero. Aun así, me cuesta confiar en la IA sin validarla
• Me pregunto por qué tantos ejemplos terminan siendo, al final, “cómo enviar spam más rápido y mejor”
  • La verdad, también me da la impresión de que ese era exactamente el ejemplo: rastrear gente en LinkedIn con scraping y mandar spam por correo “personalizado”
  • Se podría comparar con que una rueda al final no gira sin aceite
• Esto era cierto a fines de 2023 e inicios de 2024, pero ya hacia mediados de 2025 creo que deja de aplicar para muchas tareas si usas LLM SOTA. Antes la mayoría llamaba al LLM como si fuera una función, pero eso también se debía a haber elegido mal la herramienta. Los LLM de primera línea de hoy (Gemini 2.5 Pro, Claude 4, etc.) son realmente inteligentes, y tienen muy buena capacidad de instruction following y selección de herramientas. Siguen haciendo falta herramientas tipo checklist, comandos delegate, división de tareas y demás. Pero la forma de construir instrucciones y definir comandos —sobre todo si en una UI se pueden especificar fácilmente comandos de herramientas— es más flexible y está un nivel arriba de abstracción respecto a un workflow. Los workflows visuales al final siguen siendo programación frágil y difícil de ajustar. Hace 6 a 12 meses esto no era posible, aunque si el LLM no es bueno entonces sigue sin aplicar. En términos generales, como todavía son pocos los modelos que hacen bien el instruction following y la integración con herramientas, conviene aplicar agentes sobre esos modelos. En los próximos 1 o 2 años habrá una tendencia grande de agentes para usar navegador/computadora. Estos también incorporarán buenos sistemas de memoria y un “modo demostración/observación” para aprender (grabando) cómo el usuario usa la UI, y también aprenderán procedimientos optimizados a partir de instrucciones humanas, ya sean verbales o escritas
  • Con la aparición reciente de los modelos de agente más potentes (Claude Opus 4, etc.), la situación cambió por completo. Sigue haciendo falta buen contexto, pero de verdad hacen una selección de herramientas sumamente precisa
  • Las técnicas del post original son, en su mayoría, “modelar el problema como un grafo de flujo de datos y seguirlo tal cual”. Si en vez de modelar uno simplemente se lanza con la idea de “seguro lo resuelve solo”, eso no es ingeniería, es fe
• En las últimas 3 semanas intenté hacer que un agente funcionara de forma estable, pero al final terminé cambiándome a patrones mucho más simples. Los agentes de hoy se sienten como una mano con seis dedos, algo todavía en una etapa muy temprana de evolución
• Cuando alguien ve cosas como “el coordinador se rinde si la definición de la tarea no está clara” y concluye “entonces hay que tirar también al coordinador y pasarse a lógica imperativa”, en realidad podría ser un problema que se resuelva escribiendo prompts o descripciones de herramientas más específicas, e incorporando procedimientos como resúmenes intermedios o compresión de contexto para LLM. Si el artículo ni siquiera trae ejemplos largos de prompts o descripciones de herramientas que realmente se puedan usar, es difícil juzgar. Intuitivamente, la respuesta es usar una orquestación adecuada a la tarea, pero yo sí creo que en la práctica la orquestación tipo agente puede funcionar eficazmente en muchas más tareas de las que parece
• Yo también estoy 100% de acuerdo. Los agentes son muy divertidos y buenos para experimentar, pero para aumentar la productividad real la clave es orquestar bien workflows y procesos específicos, y enfocarse en las partes donde la IA sí aporta algo único. Como referencia, también recomiendo el texto sobre AI workflows en ai.intellectronica.net
• Algo que se ve mucho últimamente es que se introducen LLM en herramientas existentes de orquestación de workflows para construir sistemas muchísimo más fácil. La mayor parte de la complejidad está en a) el propio modelo (los laboratorios punteros ya ofrecen modelos fáciles de usar), y b) la puesta en producción del workflow (las herramientas de workflow lo facilitan bastante). Como estos workflows se basan en trabajo ya existente, es fácil reconocer y medir su valor. Hay tantos patrones así que terminé publicando incluso un SDK empaquetado para Airflow (una herramienta de workflow muy popular).
  https://github.com/astronomer/airflow-ai-sdk

[sto1111]

Yo también actualmente estoy haciendo algo llamado UseDesktop

https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq

usedesktop.com

que es un Computer-use Agent, y estoy de acuerdo con la mayor parte.

Este texto, más que dar tips prácticos, solo cubre un panorama general, así que si agregara algunos consejos más para cuando desarrollas un agentic/agent basado en LLM, al final los LLM están basados en transformers (i.e., razonamiento probabilístico; en vez de entender semánticamente el siguiente token/palabra con base en el token/state actual y el contexto, generan el output de forma probabilística), así que por muy bien que escribas el sys prompt, muchas veces no te dan la respuesta que quieres (e.g., les pides que respondan en formato JSON y a veces se les olvida un } o cosas así). Por eso, siempre es indispensable agregar varias fallback fn basadas en regex.

Y cuando escribes un sys prompt para que entregue structured output, normalmente conviene usar un non reasoning model, y mientras más largo sea el contexto, más seguido aparecen alucinaciones, así que más bien es mejor crear varios sys prompt y encadenarlos.

Si estás desarrollando un servicio, pueden ocurrir muchos errores, así que la clave es diseñar la arquitectura del servicio de forma modular y fault tolerant (e.g., hacer el supervisor agent async y los demás agent sync), sobre todo con estos sistemas agentic/agent donde el unexpected output ocurre con frecuencia.
Por eso, desde el principio conviene escribir el código respetando al máximo el SRP y de forma declarative; quiero decir que es mejor abordarlo de manera funcional (=sin side effects y con un flujo intuitivo).

Y dependiendo de si usas el LLM vía API o si vas a servir tú mismo el modelo, será diferente, pero si vas a servir directamente un SLM o LLM, es mejor no hacer model serving en el mismo servidor donde alojas el backend, y separar en otros servidores las tareas IO bound y las CPU bound tasks (i.e., tareas que requieren GPU, multiplicación de matrices, etc.), porque así queda mejor en términos de fault tolerance (e.g., hospedar las CPU bound task en Runpod).

Hay varios tips de desarrollo más, pero lo dejo hasta aquí para que no se haga demasiado largo.

Ojalá le sirva a alguien.

[jypark]

Muchas gracias por compartir tu valiosa experiencia y opinión. De verdad ayuda muchísimo contar con la perspectiva de alguien que está en el terreno.