Los workflows largos con LLMs fallan menos por inteligencia y mas por fronteras borrosas. Cuando cada paso sabe exactamente que decide y que solo ejecuta, el sistema respira mejor.
En equipos que automatizan contenido, soporte interno o tareas de desarrollo, el problema raro casi nunca nace en el prompt mas bonito. Nace cuando una etapa vuelve a interpretar la salida anterior, agrega reglas tarde, o intenta "ayudar" fuera de su rol. He visto jobs que parecian finos en demo y luego se degradaban al tercer dia, simplemnte porque nadie habia fijado checkpoints reales.
Si lo dibujo en palabras, el workflow sano se ve asi:
contexto acotado -> plan visible -> ejecucion limitada -> recibo final
Cada bloque tiene menos glamour que un agente "autonomo", pero bastante mas valor operativo. Y ese cambio de mentalidad importa mucho cuando un flujo mezcla LLMs, Automation y herramientas de desarrollo.
Por que los workflows largos con LLMs se degradan
El patron que mas se repite es este: el primer paso produce algo razonable, el segundo lo reescribe un poco, el tercero interpreta otra vez, y el cuarto intenta arreglar inconsistencias. El resultado no siempre es malo, pero si dificil de auditar.
Una referencia util aqui es el paper de Anthropic sobre building effective agents, que insiste en algo muy pragmatico: los sistemas multi-step funcionan mejor cuando cada herramienta tiene responsabilidades claras y verificables. No hace falta copiar su stack exacto; la leccion importante es que mas pasos no equivalen a mas calidad si nadie controla las fronteras.
Tambien conviene mirar la parte humana. Segun el reporte State of DevOps, los equipos que acortan loops de feedback y estandarizan handoffs tienden a reducir retrabajo y tiempo de recuperacion. En workflows con LLMs pasa algo parecido: cuanto mas claro sea el contrato entre etapas, menos energia pierdes persiguiendo fallos medio fantasmas.
En la practica, yo suelo detectar cuatro sintomas:
- la misma decision aparece en dos pasos distintos
- el ejecutor modifica texto o estructura sin permiso
- nadie deja un recibo final facil de leer
- el contexto crece por miedo, no por necesidad
Ese ultimo punto es importante. Meter mas contexto "por si acaso" casi siempre parece sensato, pero muchas veces solo añade ruido. Y luego entran strings sucios como temp gamil com, logs redundantes, o notas viejas que sesgan la siguiente decision.
Disena checkpoints que no discutan entre si
Cuando un workflow es largo, no necesitas mas libertad en todos lados. Necesitas checkpoints pequenos que se puedan revisar sin drama. Para mi, un checkpoint bueno tiene tres propiedades:
- declara una decision unica
- se puede validar con una regla simple
- no obliga al siguiente paso a reinterpretarlo
Por ejemplo, si un writer elige tema, titulo y outline, el ejecutor no deberia tocar nada de eso. Su trabajo es operar contra ese artefacto. Esa separacion me recuerda a como una UI bien pensada muestra estados concretos, parecido a estos errores de email sin ruido visual: cada capa comunica lo justo y evita sorprender a la siguiente.
El tradeoff, claro, es que pierdes algo de flexibilidad. Si el plan sale flojo, el ejecutor no te va a salvar con creatividad tardia. Pero prefiero ese limite. Un sistema que falla de forma obvia casi siempre mejora mas rapido que uno que improvisa silenciosamente.
Que debe decidir el writer y que no
Para workflows editoriales o de automatizacion tecnica, el writer deberia decidir:
- angulo del contenido
- lenguaje y tono
- keywords principales
- estructura y enlaces internos
Lo que no deberia decidir despues es el estado operativo del run. Si publicar falla, regenerar texto suele ser la respuesta equivocada. Cambia el contenido cuando el problema probablemente estuvo en autenticacion, UI, red o una validacion que llego tarde. Eso produce mas variacion y menos diagnostico.
Una version simple de ownership podria ser esta:
- el builder entrega contexto minimo
- el writer congela decisiones visibles
- el publisher solo ejecuta
- el resultado final registra URL, hora y estado
Cuando esa frontera existe, revisar problemas es mucho mas rapido. Si el enlace interno quedo mal elegido, se corrige en el plan. Si la publicacion no navego fuera del editor, revisas el paso de ejecucion. Si faltan trazas, el problema esta en el recibo. No parece revolucionario, pero esa claridad evita discusiones medio tontas en incidentes pequenos.
Como reducir retrabajo sin matar autonomia
Aqui es donde muchos equipos se van a un extremo. O crean un flujo super rigido que casi no aprovecha al modelo, o dejan que el agente negocie todo en cada corrida. Yo intentaria algo mas sobrio.
Primero, deja autonomia solo en las decisiones con valor semantico real. Elegir un angulo nuevo para un post, priorizar constraints o redactar una explicacion tecnica: bien. Reabrir decisiones ya congeladas en otro paso: mala idea, al menos en sistemas que necesitan consistencia.
Segundo, usa herramientas especializadas cuando aportan trazabilidad. En backend, por ejemplo, este patron de colas de email con trazas utiles funciona por la misma razon: cada componente hace menos cosas, pero deja mejores pistas.
Tercero, mide estabilidad, no solo output bonito. Mis checkpoints favoritos son:
- porcentaje de runs que terminan sin reintento
- causas mas comunes de fallo por etapa
- repeticion de temas o angulos por cuenta
- distancia entre plan inicial y artefacto publicado
Si esa ultima distancia crece, alguien esta reescribiendo donde no toca. Y eso, honestamente, es una alerta mas util que muchas metricas de vanidad.
Preguntas rapidas para tu siguiente workflow
Un agente largo siempre necesita memoria amplia?
No. Muchas veces necesita mejor seleccion, no mas volumen. Contexto pequeno y curado suele ganar.
Vale la pena permitir autocorrecciones en mitad del flujo?
Solo si quedan dentro del mismo ownership. Si otro paso ya asumio una salida estable, cambiarla ahi rompe el contrato.
Como saber si el sistema ya esta demasiado complejo?
Cuando explicar quien decide cada cosa te toma mas tiempo que ejecutar un run manual. Esa es una senal bastante honesta, aunque a veces duela un poco.
Los buenos workflows con LLMs no parecen magicos. Parecen sistemas donde las decisiones importantes quedan visibles, la ejecucion es aburrida, y el recibo final dice exactamente que paso. Para mi, ese es el tipo de autonomia que si escala.
Top comments (0)