Escala los nodos, no las tareas: Una escalera de seis niveles para controlar los costos del flujo de trabajo de LLM

Muchos equipos que desarrollan pipelines impulsados por LLM comienzan con una única pregunta arquitectónica para cada nueva función: ¿debería ejecutarse como un DAG fijo o como un agente autónomo? Parece una revisión de diseño sensata, pero responderla a nivel de toda la tarea fija silenciosamente el costo del paso más incierto para todos los demás pasos. Este artículo explica cómo ocurre esto y luego presenta una escalera de escalada de seis niveles en la que cada nodo parte del nivel más económico viable y solo asciende cuando falla un contrato explícito. Al final, deberías poder descomponer tus propias tareas de “agente”, ver cuántas de ellas son realmente deterministas y establecer límites estrictos para lo que puede gastar el resto.

El escenario utilizado en todo momento es un producto que realiza dos funciones: convierte formatos de archivo cotidianos y ejecuta flujos de trabajo de entrada a salida de archivos, tanto como pipelines con un solo clic como a través de una herramienta que genera el pipeline a partir de una solicitud redactada en lenguaje cotidiano. La parte de conversión funciona de manera fiable. En la parte relacionada con los flujos de trabajo era donde surgía constantemente la duda sobre si utilizar un DAG o un agente, y donde se tardó casi un año en darse cuenta de que el problema radicaba precisamente en esa pregunta.

El punto de partida: clasificar cada tarea desde el principio

El proceso inicial para cada flujo de trabajo con un solo clic era metódico. Se investigaba el caso de uso, se redactaba una especificación y luego alguien decidía si el pipeline se implementaría como un DAG o como un agente.

Las tareas abiertas se asignaban a un agente

Las tareas consideradas verdaderamente abiertas se implementaron como un único agente ReAct en LangGraph. El caso de referencia era la búsqueda de empleo basada en un currículum. Un usuario sube su CV y el sistema debe encontrar puestos para los que valga la pena postularse y generar un currículum personalizado para cada uno. Esto implica currículos escritos en varios idiomas, la correspondencia entre candidatos y puestos según dimensiones que el solapamiento de palabras clave no puede capturar (tiempo de desplazamiento desde casa, composición del equipo, las tareas diarias del puesto, rango salarial) y, finalmente, la generación de un documento personalizado. Nadie puede predecir con antelación cuántos pasos se necesitarán, por lo que parecía el caso típico para un agente.

Las tareas predecibles se asignaron a un DAG estático

El trabajo secuencial y predecible se convirtió en un grafo fijo. El caso de referencia era transformar un video en subtítulos: extraer la pista de audio, ejecutar el reconocimiento de voz, dividir la transcripción en segmentos cronometrados y crear el archivo de subtítulos. Incluso los elementos opcionales podían enumerarse con antelación, como limpiar la transcripción literal para mejorar su legibilidad o verificar si las afirmaciones hechas en el discurso son ciertas. Dado que cada decisión podía tomarse antes de comenzar la ejecución, todo el grafo podía dibujarse con anterioridad a ella.

La división del trabajo parecía lógica y se puso en práctica. El problema era que los costos nunca disminuyeron.

Por qué el impuesto a los agentes nunca desaparece

El mecanismo detrás de la curva de costos plana es algo cotidiano, y precisamente por eso es fácil pasarlo por alto.

Cuando una tarea está etiquetada como “agente”, cada paso dentro de ella se ejecuta dentro del bucle del agente y genera un costo correspondiente. Un bucle ReAct solo puede elegir una acción si los esquemas de sus herramientas se encuentran en la ventana de contexto. Se puede comprimir la conversación, resumir el estado intermedio y reducir los documentos recuperados, y el equipo hizo todo eso, pero el costo mínimo por turno permanece igual, ya que ese mínimo corresponde al conjunto de esquemas de herramientas y se envía nuevamente en cada turno. Tampoco se puede simplemente darle al agente menos herramientas si se desea que siga siendo flexible: la razón por la cual es un agente en primer lugar es porque nadie sabe de antemano qué herramientas necesitará una ejecución determinada.

Una solución es predecir el subconjunto de herramientas relevante para cada tarea. Esa es una dirección de investigación legítima, pero requiere su propia inversión y un modelo que haga predicciones precisas. En cambio, lo que quería el equipo era algo que pudiera especificarse: una arquitectura cuyo costo esté determinado por su forma de construcción, y no por la precisión de un predictor. Si le interesa el enfoque basado en predicciones, el artículo sobre el descubrimiento progresivo de herramientas para agentes a gran escala lo analiza en profundidad.

Releer la literatura junto con meses de registros de producción llevó a una conclusión casi sorprendentemente simple:

La incertidumbre pertenece a los nodos individuales, no a las tareas completas.

La decisión de utilizar DAG o agente se tomaba por tarea. Pero una tarea no es más que un conjunto de pasos, y en casi todas las tareas clasificadas como “agente”, la mayoría de los pasos eran completamente deterministas. Tomar una decisión a nivel de tarea implica que cada nodo paga el precio del nodo más incierto en el grafo.

Si desglosamos el flujo de trabajo de búsqueda de empleo, el patrón resulta evidente:

• Extraer campos estructurados de un currículum en PDF no requiere ningún tipo de razonamiento basado en modelos.
• Identificar el idioma utilizado en el currículum es igualmente mecánico.
• Localizar la dirección residencial y calcular el tiempo de desplazamiento implica una sola llamada a una herramienta.
• Obtener las posiciones vacantes implica acceder a una API de empleos.
• Evaluar qué tan bien se ajusta un puesto a un candidato específico requiere una sola solicitud al modelo, un prompt fijo y cero herramientas.

Solo algo como “averiguar qué ha estado enviando este equipo en particular recientemente” no tiene un número predecible de pasos.

Ese último elemento es un nodo. Todo el grafo había estado pagando precios de agente para ser atendido.

La escalera de escalada

La solución fue dejar de tomar decisiones por adelantado. Bajo la nueva regla, cada flujo de trabajo comienza en el nivel más económico que pueda funcionar, y solo los nodos individuales que fallan avanzan. Hay seis niveles.

• L0: solo llamadas a herramientas, sin LLM. Si una solicitud puede satisfacerse completamente mediante operaciones deterministas, no se ejecuta ningún modelo. En el producto este es el camino rápido existente y sigue siendo una superficie separada. El costo son simplemente las llamadas a herramientas.
• L1: DAG estático de nodos mecánicos. Un grafo real con ramificaciones y despliegues en abanico, pero cada nodo es código ordinario. Tampoco hay llamadas a modelos.
• L2: DAG estática con nodos de LLM de un solo uso. La estructura del grafo no cambia, pero ahora ciertos nodos invocan un modelo una sola vez, con un contexto de alcance muy limitado. En la práctica, el nodo solo recibe sus entradas directas y nada más: sin historial de conversación, sin estado global y, lo que es crucial, sin esquemas de herramientas. A este nivel, el modelo se comporta como una función pura en lugar de un agente. El costo es O(n) llamadas, siendo n conocido antes de que comience la ejecución.
• L3: bucles de refinamiento limitado. Un nodo L2 puede intentar nuevamente cumplir con un contrato hasta un máximo fijo de N intentos. El contrato, y no el modelo, decide cuándo la salida es aceptable. El costo es O(n·N), el cual también se conoce antes de la ejecución.
• L4: un nodo opaco se convierte en subagente. Un nodo que no puede especificarse con antelación recibe un bucle ReAct real, pero sus herramientas están limitadas a ese nodo y tiene un presupuesto de pasos fijo. Nadie puede predecir cuánto gastará, y esa imprevisibilidad es la razón por la que debe tener un techo explícito.
• L5: replaneo total. El propio plan era incorrecto, por lo que el grafo se reconstruye. Esta es la opción más costosa disponible y debería ser algo raro.

Contratos, alcance y presupuestos

Una taxonomía por sí sola sería solo un vocabulario más elegante. Tres mecanismos hacen que la estructura funcione realmente:

• Los contratos desencadenan la escalada. Cada nodo indica qué forma debe tener un resultado aceptable, y solo una verificación fallida en relación con esa indicación justifica pasar a un nivel superior.
• El alcance mantiene a L4 accesible económicamente. Los esquemas de herramientas de los subagentes se encuentran dentro del contexto de ese nodo en particular y no aparecen en ningún otro lugar durante la ejecución, por lo que el costo asociado a los esquemas se paga localmente.
• Los presupuestos establecen un límite máximo. Cada nivel por encima de L2 tiene un número máximo de intentos o pasos; una vez alcanzado ese límite, el nodo either se rinde o continúa escalando.

Una forma práctica de entenderlo es la siguiente: el contrato responde a “¿es esto suficientemente bueno?”, el alcance responde a “¿qué puede ver y llamar este nodo?”, y el presupuesto responde a “¿cuánto puede gastar intentándolo?”. Si falta alguno de estos tres elementos, el nivel correspondiente deja de ser predecible. Para obtener más información sobre cómo mantener bajo control bucles como L3 y L4 en el código, consulte los bucles agentes limitados en TypeScript.

Recorriendo la cadena de subtitulación paso a paso

La mayoría de las ejecuciones nunca salen de la etapa L1. La cadena extrae el audio, realiza el reconocimiento de voz, segmenta según las marcas de tiempo y genera un archivo SRT, todo ello sin realizar ninguna llamada al modelo. A continuación, se verifica el resultado según los criterios establecidos: las indicaciones no deben superponerse, ninguna línea puede exceder el límite de caracteres y la velocidad de lectura debe mantenerse por debajo de un umbral determinado. Un video típico con voz clara y audio sin problemas pasa la verificación, y el proceso no requiere más que ffmpeg sumado a una sola pasada de reconocimiento.

Cuando una indicación en particular infringe la regla de longitud de línea o de legibilidad, solo esa indicación pasa a la etapa L2. Allí se realiza una única llamada al modelo cuyo contexto son dicha indicación y sus vecinos inmediatos. La transcripción completa, los metadatos del video y todos los esquemas de las herramientas quedan fuera del proceso, y el resto del sistema no se ve afectado.

L3 se justifica mediante la terminología. En una presentación técnica que incluye un glosario, las verificaciones de terminología pueden seguir fallando incluso después de una sola corrección, por lo que ese nodo puede perfeccionar su salida exactamente dos veces, siendo la verificación con el glosario quien decide cuándo el resultado es aceptable.

L4 aparece solo en un lugar: verificando que las afirmaciones hechas en la presentación sean correctas. Eso requiere realizar búsquedas, y nadie puede determinar cuántas búsquedas serán necesarias. Así, ese único nodo se convierte en un subagente cuyas herramientas se limitan a buscar y obtener información, y cuyos pasos están restringidos. El proceso secundario que lo rodea sigue siendo mecánico.

L5 se ocupa del caso en el que el plan fue incorrecto desde un principio. Supongamos que el archivo resulta ser una captura de pantalla en la que el significado está en el texto en pantalla y el audio es secundario. Ninguna cantidad de perfeccionamiento de los nodos individuales podrá salvar un plan basado en el reconocimiento de voz, por lo que el grafo se reconstruye utilizando OCR en su lugar.

Subiendo los escalones en la búsqueda de empleo

Este es el ejemplo que cambió la forma de pensar del equipo, porque parecía obviamente estructurado como un agente.

L1 abarca más funciones de las esperadas: analizar el currículum, detectar su idioma, hacer geocodificación y calcular el tiempo de desplazamiento, además de obtener listados. Todo ello es código sencillo.

L2 se encarga de la correspondencia. Para cada puesto de trabajo candidato, hay una llamada al modelo dentro de un contexto específico que devuelve una puntuación estructurada según las dimensiones relevantes, utilizando el resumen del currículum y esa única descripción de puesto como todo su contexto. Esto implica O(n) llamadas a un modelo económico, sin necesidad de esquemas de herramientas alguno, y reemplazó a un agente que razonaba sobre la misma lista cargando todo el conjunto de herramientas en cada turno.

L3 se encarga de reescribir el currículum, y aquí los contratos pasan a ser un medio de control de seguridad en lugar de uno de control de costos. El contrato exige que cada afirmación en el currículum reescrito sea rastreable hasta su origen, prohíbe inventar empleadores o fechas y establece un límite de longitud. Si un borrador incumple estas reglas, se perfecciona, como máximo dos veces, y luego el proceso termina. Este es un patrón útil más allá del aspecto económico: un contrato que verifica el origen constituye una medida económica y determinista para evitar que un modelo embellezca la historia profesional de alguien.

L4 es un único nodo: consiste en investigar el equipo de la empresa específica y su dirección reciente. Por naturaleza es abierto, pero está delimitado por su estructura.

L5 se activa cuando las propias categorías no son adecuadas. Imagine a un físico que solicita empleos en finanzas cuantitativas: las categorías de los puestos analizadas no coinciden bien con la formación real del candidato, por lo que es necesario reconstruir el plan de correspondencia en lugar de hacer ajustes menores.

El resultado principal es que la tarea, antes clasificada como de tipo agente, resultó ser aproximadamente un 80% trabajo de tipo L1 y L2. Esto no se trata de ajustar un prompt; implica que el flujo de trabajo sigue una curva de costos completamente diferente.

Lo que la estructura jerárquica aporta a un producto de archivo a archivo

Los flujos de trabajo de entrada y salida de archivos se superponen en gran medida. Los primeros 80% de casi cualquier par de pipelines se ven prácticamente iguales. Sin embargo, la calidad que perciben los usuarios reside exclusivamente en el 20% restante, y esa parte varía cada vez. Esta es la trampa de la personalización: o bien los ingenieros diseñan manualmente los detalles para cada tarea y el producto nunca escala, o bien se omiten esos detalles y el resultado es mediocre.

La escalera representa una salida de esa trampa. La personalización sigue ocurriendo, pero lo hace a través de decisiones de escalado impulsadas por contratos en lugar de horas de trabajo de ingeniería. El resultado es un ajuste específico para cada tarea sin necesidad de esfuerzo humano adicional por tarea.

Una comparación obvia es con los agentes de propósito general ofrecidos por Anthropic y OpenAI, que probablemente realizan algo estructuralmente similar. Esos sistemas son cerrados, por lo que se trata de inferencia y no de conocimiento, pero una suposición razonable es que gran parte de sus esfuerzos se destinan a inducir una estructura consistente en las tareas, y cuentan con mucho más datos para lograrlo. Ladder obtiene una estructura comparable gracias a la forma en que está diseñado su flujo de trabajo, y no mediante conjuntos de datos masivos, lo que lo convierte en una versión económica de la misma idea.

Cuando Ladder no vale la pena

El enfoque parte de la suposición de que se pueden redactar contratos significativos. Si la calidad de la salida de un nodo solo puede ser evaluada por un humano, no existe un desencadenante fiable para la escalada, y el proceso se convierte en una especulación. Además, implica mecanismos de orquestación; para un pipeline con dos o tres pasos y bajo volumen, una sola llamada a un modelo bien delimitado puede ser más sencilla y lo suficientemente económica.

Entregar primero el escalón más básico

Cuando cada flujo de trabajo recibe archivos y devuelve archivos, la capa de manejo de archivos se encuentra por debajo de todo lo demás. Cada uno de los escalones descritos anteriormente se reduce eventualmente a algo mecánico: abrir el contenedor, extraer el texto y mantener las tablas intactas. Nada en esa capa es incierto, por lo que pagar por procesos de inferencia allí sería un desperdicio total; además, su previsibilidad la convierte en el componente obvio para lanzar primero.

Fue lanzado como un SDK de Python de código abierto, publicado en PyPI bajo la licencia Apache-2.0 y usable como servidor MCP dentro de Claude Code. La instalación se realiza con un único comando, ya sea mediante uv o pip.

uv add convilyn          # or: pip install convilyn

El SDK convierte documentos a Markdown, transforma imágenes entre 26 formatos y reorganiza las páginas de PDF, todo localmente, sin necesidad de cuenta ni acceso a red. Cuando una tarea realmente requiere que un modelo lea algo, como una página escaneada, una foto o un archivo de audio, esta se envía a un servicio en la nube alojado, y es allí donde comienza a facturarse el uso.

Esa división es la escalera expresada como diseño de productos en lugar de arquitectura interna. La ruta local gratuita es L0: cuando el código determinista sencillo puede completar una tarea, no se carga ningún modelo y el trabajo solo pasa a una ruta de pago después de que la vía económica haya fallado de manera demostrable. Según el proyecto, el conversor sin conexión no necesita cuenta, clave ni cuota y no envía telemetría; consulte el README actual del repositorio para obtener detalles de instalación y el conjunto exacto de funciones, ya que ambos probablemente evolucionarán.

Estatus actual del motor de flujos de trabajo

En el momento de redactar este texto, las funciones de flujo de trabajo y de generador aún se estaban estabilizando, mientras que la reconstrucción descrita aquí se llevaba a cabo en segundo plano; el equipo espera finalizarla en aproximadamente un mes. La razón es válida: es mejor retrasar el lanzamiento de un motor de flujo de trabajo cuyo fin está previsto que promoverlo y migrar a los usuarios dos veces.

Tecnologías previas y trabajos relacionados

Ninguno de los componentes individuales es nuevo, y cada uno ya ha sido descrito anteriormente. Lo que parece no haberse publicado aún es esta combinación específica: escalada por nodo activada mediante contratos, el alcance de la herramienta utilizado como factor de costo, expansión recursiva permitida pero sujeta a un presupuesto, aplicada a una carga de trabajo de archivos a archivos. Los trabajos siguientes abordan cada uno de estos elementos.

Comience con lo simple y añada complejidad solo cuando sea necesario

• Building effective agents, publicado por Anthropic en diciembre de 2024, distingue los flujos de trabajo de los agentes y recomienda la solución más sencilla viable, añadiendo complejidad solo cuando es necesaria. La estructura en escalera difiere al aplicar ese principio mientras se ejecuta el proceso, nodo por nodo, en lugar de hacerlo una sola vez por tarea durante la fase de diseño.

Escala únicamente el componente que falló

• El artículo ADaPT, cuyo nombre significa descomposición y planificación según sea necesario (Findings of NAACL 2024), comienza con un plan de alto nivel y descompone una subtarea de forma recursiva, solo después de que su ejecución fracase, dejando intactas las partes que tuvieron éxito. Es la descripción publicada más cercana al mecanismo de activación L4, aunque no se enmarca desde la perspectiva del costo.

Contratos, recuperación limitada y reglas de escalado

• Un marco teórico de programación para ejecutar agentes LLM como grafos estructurados, publicado en arXiv en abril de 2026, utiliza un DAG estático con contratos de salida para cada nodo y un protocolo de recuperación en tres etapas: intentos repetidos, parches locales y replaneo completo, con invariantes de escalado explícitos. Sostiene que los nodos respaldados por modelos deben validarse contra contratos, ya que las comprobaciones de tipo no son suficientes, y que repetir pasos no idempotentes requiere presupuestos limitados. Intencionalmente excluye la expansión recursiva de subgrafos, que es donde se encuentra L4.

La Planificación Desacoplada de Tareas (TDP), analizada en el mismo artículo, divide el trabajo en un grafo de subobjetivos, cada uno con su propio contexto restringido, y limita cualquier replaneamiento al subtrabajo que esté actualmente activo. Indica reducciones de tokens de hasta el 82 %, la medición publicada más cercana que respalda el argumento del alcance L2.

El alcance de la herramienta como principal factor de costo

• Skillflow define un DAG en YAML que el motor, y no el modelo, recorre. Sus operaciones de entrada/salida están controladas por las capacidades: un paso recibe únicamente el contexto que solicita, y cualquier herramienta no cubierta por su contrato simplemente no aparece en su esquema. Su conclusión, de que un contexto pequeño específico para cada rol es lo que permite que los modelos económicos sean suficientes, coincide con el argumento L2.

Escaleras por etapas ya en producción

• PraisonAI incluye una funcionalidad de escalación en su SDK para agentes que define cuatro etapas progresivas: una respuesta directa sin herramientas ni planificación, uso de herramientas heurísticas sin llamada adicional al modelo, una sola llamada al modelo con restricciones, y finalmente un ciclo completamente autónomo que utiliza herramientas, subagentes y verificación. En resumen, corresponde a los niveles L0 a L4 condensados en cuatro pasos.
• El enrutador de escalación de NVIDIA NeMo Switchyard aplica la misma estructura a la selección de modelos en lugar de a la arquitectura: se comienza con un modelo más débil y se pasa a uno más potente cuando un evaluador detecta problemas persistentes.

Esa misma estructura en otros lugares

• Patrones de diseño agente (systemdesign.one, abril de 2026) utiliza la expresión “escalera de escalación” para referirse a la elección entre flujo de trabajo y agente, y recomienda optar por el arreglo menos complejo que permita cumplir la tarea.
• La guía de Vercel sobre marcos de evaluación de agentes de IA para producción (julio de 2026) aplica un orden basado en lo más económico primero para la evaluación: ejecutar la comprobación menos costosa capaz de detectar un fallo determinado, y escalar solo cuando dicha comprobación estructuralmente no pueda identificar el problema.

Puntos clave

• Elegir “DAG o agente” según cada tarea hace que cada paso contribuya a resolver el paso más incierto.

El costo irreducible de un bucle de agentes es el bloque de esquema-herramienta que se envía nuevamente en cada turno, el cual la compresión de historial no puede eliminar.

Comience cada nodo en el nivel más económico y solo ascienda cuando haya un contrato explícito que haya fallado.

Limite los esquemas de herramientas al nodo que los necesita y asigne un presupuesto fijo a cada nivel por encima de L2.

Esperar que la mayoría de las cargas de trabajo “de agentes” sean en gran medida deterministas una vez descompuestas; en el caso de la búsqueda de empleo, aproximadamente el 80% correspondía a los niveles L1 y L2.

Lecturas relacionadas

• Diseñando Sistemas Multi-Agente en Nodos A2A: Memoria y Gobernanza — Una arquitectura de referencia para sistemas multi-agente basados en el protocolo A2A, que abarca módulos de agentes, tipos de memoria, orquestación, riesgos de seguridad y una lista de verificación para el diseño.
• LangGraph en la práctica: Estado, nodos, aristas y cinco patrones de agente — Aprenda cómo definir el estado de LangGraph con anotaciones y reductores, conectar nodos mediante aristas e implementar los cinco patrones principales de flujo de trabajo basado en agentes en JavaScript.