Compilando un workflow agéntico en los pesos de un LLM: el caso del agente que no necesita orquestador
"¿Y si el procedimiento no fuese un prompt, sino los pesos del modelo?"
En 2026 todo agente de producción se construye igual: un modelo frontier en cloud, un orquestador externo que decide en cada turno qué nodo del flujo toca, herramientas inyectadas en el system prompt en cada llamada, y una factura que crece con cada conversación. Funciona. Es caro. Y, para muchos casos de uso, es arquitectónicamente innecesario.
El equipo de Dennis et al. publicó en mayo de 2026 un paper que merece detenerse: Compiling Agentic Workflows into LLM Weights: Near-Frontier Quality at Two Orders of Magnitude Less Cost. La tesis es directa: si el procedimiento es estable, en vez de inyectarlo turno a turno en el prompt, métetelo dentro de los pesos del modelo vía fine-tuning. En runtime no hay orquestador. El modelo, solo, decide cuándo triar, cuándo crear un ticket, cuándo escalar. Es el flujo el que aprende a vivir en los pesos.
Este artículo cuenta cómo lo probamos end-to-end con un caso real, con qué números nos quedamos, y los muros que nos comimos por el camino. Spoiler: un Qwen 7B compilado para soporte IT con acciones Jira alcanza el 91% de la calidad de Claude Sonnet usado como agente in-context en cinco métricas de evaluación, con tool-call validity perfecta (100%) y un coste por conversación entre ~15 y ~30 veces menor. En un 7900XTX local, el coste de inferencia tiende a cero.
A este patrón —procedimiento compilado en los pesos, sin orquestador en runtime— le hemos puesto un nombre propio en el proyecto: agentes subterráneos. La metáfora es literal: el procedimiento queda enterrado en los pesos, debajo de la superficie del prompt visible. No hay nodos que se inyecten en cada turno, no hay framework que reciba el control y lo devuelva, no hay routing que decida en runtime. Todo eso ocurre bajo tierra. El usuario solo ve un modelo que parece "saber" qué hacer.
1. La tesis: estructura en los pesos, estado en el prompt
El patrón estándar separa mal las cosas. La estructura del procedimiento (qué nodo viene después de qué, qué herramienta toca aquí, qué pregunta hace el agente cuando ha triado credenciales) es persistente: es la misma para todos los tickets. Y aun así, en cada llamada API la reenviamos como prompt, pagando por sus tokens. El estado transitorio (los datos de esta conversación: el usuario, el error concreto, el ticket abierto) sí cambia, y ese sí debe ir en el prompt.
El paper invierte el reparto: la estructura persistente se entrena en los pesos vía full fine-tuning sobre conversaciones sintéticas que recorren todos los caminos del procedimiento. El estado transitorio se sigue pasando como mensajes. El system prompt en runtime es minúsculo ("Eres un agente de soporte IT"), y el modelo —solo, sin orquestador— hace todo lo demás.
El procedimiento no se ejecuta, se compila. La diferencia entre un becario con el manual en la mano y un veterano que ya interiorizó el proceso.
2. El experimento: ITSM L1 con acciones Jira
Para validarlo elegimos un caso útil y bien acotado: soporte IT de nivel 1 con tres herramientas Jira (crear ticket, marcar resuelto, escalar a N2). El procedimiento se modela como un grafo dirigido con 21 nodos: el agente saluda, tría la incidencia en red / credenciales / software, recoge los datos mínimos de cada categoría, abre un ticket con prioridad, propone una solución, verifica, cierra o escala. Tres terminales (resuelto, escalado, abandonado), 15 caminos acíclicos válidos.
3. El pipeline en cinco fases
El método de Dennis et al. tiene cinco fases. El orquestador externo aparece solo durante la generación de datos; en runtime, desaparece.
Fase 1 — Diseño del procedimiento
Formalizamos el flujo como grafo F = (N, E, n0, T). Nodos agente, nodos usuario, nodos tool-call, terminales. Aristas con condiciones (categoria==red, resuelto==si). Validador local (sin GPU, sin coste): sin nodos huérfanos, todos los terminales alcanzables. Enumera 15 caminos válidos.
Fase 2 — Generación de datos sintéticos
Un modelo "profesor" recorre todos los caminos y produce conversaciones realistas turno a turno. El profesor juega dos papeles: el agente (sigue el guion del nodo) y el simulador de usuario (role-playea un cliente con variables de escenario y, deliberadamente, no conoce el grafo). La clave: el dataset final contiene solo diálogo natural y tool-calls; ninguna anotación de nodo. La estructura queda implícita.
En nuestro caso usamos Claude Sonnet 4.6 vía AWS Bedrock como profesor, generamos 600 conversaciones en ~30 minutos con 8 workers concurrentes. Distribución pesada hacia resoluciones positivas (57% success / 30% abandono / 13% escalado), categorías equilibradas (red / credenciales / software). Coste: ~$32 de créditos AWS Bedrock. Cero errores de coherencia: categoría y tool-args siempre consistentes con el camino.
Fase 3 — Fine-tuning (la compilación)
Full parameter update. No LoRA: los métodos low-rank fracasan en tareas procedurales según el propio Dennis et al. en un paper posterior (2026b). Tocamos todos los pesos del modelo base.
Hiperparámetros del paper, ajustados a la realidad de la VRAM disponible: bf16, optimizador AdamW 8-bit (bitsandbytes) o paged AdamW para single-GPU, learning rate 2e-5 con cosine decay, gradient checkpointing, batch efectivo 16-32, hasta 20 epochs con early-stopping por eval loss. El paper predice convergencia entre epoch 2 y 4; lo confirmamos.
| Modelo base | Hardware | Mejor epoch | eval_loss | Tiempo |
|---|---|---|---|---|
| Qwen2.5-3B-Instruct | 1× L40S 48 GB | 4 | 0.520 | ~35 min |
| Qwen2.5-7B-Instruct | 1× L40S 48 GB | 3 | 0.448 | ~75 min |
El 7B no solo converge a menor eval_loss; converge antes. La estructura del procedimiento se le da bien.
Fase 4 — Evaluación
Aquí está el rigor. Un simulador de usuario (Bedrock Haiku, sin acceso al grafo) conversa con el modelo bajo prueba; un juez LLM (Bedrock Sonnet, a ciegas respecto al sistema) puntúa cada transcript del 1 al 5 en cinco métricas: task success, information accuracy, consistency, graceful handling, naturalness. Encima, un chequeo determinista de tool-call validity (JSON parseable, nombre válido, esquema cumplido, ticket_id coherente).
Cincuenta escenarios por sistema, con disposiciones variadas (resoluble / persistente / abandono) y personas (preciso / vago, entusiasta / escéptico). Comparamos contra un baseline in-context: el procedimiento entero serializado en el system prompt de un modelo frontier, una llamada API por turno. Ese es el rival a batir.
Fase 5 — Despliegue
Servir el modelo compilado con vLLM (CUDA) o llama.cpp (todo). El system prompt en runtime cabe en dos líneas. Sin orquestador. El modelo decide.
4. Los resultados que importan
Tabla central. Tres sistemas, n = 50 escenarios cada uno, juez ciego.
| Métrica (1-5) | 3B compilado | 7B compilado | Baseline frontier | % baseline (3B / 7B) |
|---|---|---|---|---|
| task_success | 3.98 | 4.46 | 4.90 | 81% / 91% |
| info_accuracy | 3.12 | 3.84 | 4.58 | 68% / 84% |
| consistency | 3.66 | 4.22 | 4.98 | 74% / 85% |
| graceful_handling | 4.06 | 4.52 | 4.94 | 82% / 92% |
| naturalness | 4.46 | 4.64 | 4.50 | 99% / 103% |
| media 5 métricas | 3.86 | 4.34 | 4.78 | 81% / 91% |
| tool-call validity | 0.981 | 1.000 | 1.000 | 98% / 100% |
| failure_rate (task ≤ 3) | 0.34 | 0.08 | 0.02 | — |
| turnos / conv | 11.2 | 10.7 | 10.0 | — |
| wall-clock / conv | 32.7 s | 28.5 s | 44.0 s | compilados más rápidos |
| outcomes (R / E / I) | 23 / 25 / 2 | 28 / 22 / 0 | 25 / 22 / 3 | 7B sin incompletos |
Tres lecturas no negociables:
- El 7B compilado cruza el listón del 85% de la calidad del frontier (91% medio), con tool-call validity perfecta y, sorprendentemente, supera al baseline en naturalidad (4.64 vs 4.50, 103%). Cuatro fallos críticos en 50 escenarios, frente a uno del baseline. El procedimiento no solo se aprende: se ejecuta con rigor.
- El 3B compilado se queda en el 81%, pero alcanza al frontier en naturalidad (99%) y casi en tool-use (98%). El gap está donde el tamaño manda: information accuracy y consistency. Es decir, la forma del procedimiento se compila bien en cualquier tamaño; el fondo (conocimiento de dominio) escala con el modelo.
- Los compilados son más rápidos que el baseline en wall-clock por conversación. El 7B, 28.5 s vs 44 s del frontier. La razón: la inferencia local greedy tiene latencia constante y bajísima; el baseline paga round-trip de API por cada turno.
5. El coste, que es donde se decide la batalla
En este experimento, los compilados se entrenan en spot AWS y se sirven o bien en spot AWS o bien en un 7900XTX local. El baseline corre como API frontier por turno.
| Sistema | Coste por conversación | Cálculo |
|---|---|---|
| 3B compilado en spot (g6e.xlarge L40S, $0.37/hr) | ~$0.003 | 32.7 s × $0.37/3600 |
| 7B compilado en spot (g6e.4xlarge L40S, $1.02/hr) | ~$0.008 | 28.5 s × $1.02/3600 |
| 7B compilado en 7900XTX propio | ~$0 (solo electricidad) | hardware amortizado |
| Baseline Claude Sonnet por turno | ~$0.10 – $0.15 | ~10 turnos × tokens entrada/salida |
El 3B en spot es ~30-50× más barato. El 7B en spot, ~12-20×. En hardware propio (7900XTX) el ratio se vuelve absurdo: solo electricidad frente a una factura API que escala lineal con el uso. El paper de Dennis et al. cita 100-462×; ese rango se cumple para procedimientos más largos donde el baseline paga aún más prompt por turno.
Desglose detallado del experimento entero
Pa' no perder el detalle, el ticket completo del lab: 600 conversaciones generadas, dos modelos compilados (3B + 7B), tres evals n=50, smokes y experimentos. Todo facturado a créditos AWS y a cuota Bedrock; bolsillo $0.
| Concepto | Recursos | Coste |
|---|---|---|
| Generación dataset (600 convers, Sonnet 4.6) | ~6.4M tok input + 0.86M tok output, 8 workers | ~$32 (Bedrock) |
| Smokes y pruebas previas (5+3+3+5+12 convers) | Bedrock Sonnet/Haiku, varios intentos | ~$1 (Bedrock) |
| Training 3B Crawl (Qwen2.5-3B-Instruct) | g6e.xlarge spot 1.64h × $0.37/hr | $0.60 (GPU) |
| Training 7B Walk (Qwen2.5-7B-Instruct) | g6e.4xlarge spot ~1.25h × $1.02/hr | $1.30 (GPU) |
| Instancia para setup, descargas y evals (mismo spot, prorrateado) | ~2.5h adicionales × $1.02/hr | ~$2.50 (GPU) |
| Eval n=50 del 3B compilado (sim Haiku + juez Sonnet, ciego) | ~2-3M tok mixto | ~$3 (Bedrock) |
| Eval n=50 del 7B compilado (sim + juez) | ~2-3M tok mixto | ~$3 (Bedrock) |
| Eval n=50 del baseline frontier (Sonnet como agente por turno) | ~5-8M tok | ~$8 (Bedrock) |
| Storage S3 (modelos + dataset + reports, ~30 GB) y EBS prorrateado | ~1-2 días | ~$0.10 |
| TOTAL | ~$51 |
De esos $51, aproximadamente $47 son Bedrock (generación de datos + evaluaciones) y solo ~$4.5 son GPU spot (training + eval-serving). Una sola hora de uso intensivo del baseline Sonnet en producción cuesta el equivalente al experimento entero.
La distribución por tipo de gasto es la lectura accionable: el grueso del coste no está en entrenar (~$5), está en generar datos sintéticos de calidad y en evaluar con rigor (~$47). Si quieres bajar el ticket, ahí están las palancas: profesor más barato para casos sencillos (Haiku ~3× menos que Sonnet), menos escenarios de eval mientras iteras (n=20-30 en lugar de n=50), reusar el baseline entre experimentos.
6. Lo que se compila y lo que no
Después de mirar los transcripts de los tres sistemas, el patrón es claro:
| Dimensión | Compila bien (sale en pesos) | Sigue exigiendo modelo grande |
|---|---|---|
| Routing del procedimiento | ✓ 3B y 7B | — |
| Tool-call estructurado (JSON válido) | ✓ 7B perfecto, 3B 98% | — |
| Naturalidad / tono | ✓ 7B ≥ frontier; 3B 99% | — |
| Manejo de frustración / urgencia | ✓ 7B 92%; 3B 82% | — |
| Conocimiento técnico de dominio | parcial | aquí el frontier gana (3B 68% / 7B 84%) |
| Consistencia en conversaciones largas | parcial | el 7B se acerca (85%), el 3B no (74%) |
La forma del procedimiento (cuándo triar, cuándo emitir un tool-call, qué prioridad asignar, cómo cerrar con cortesía) entra perfectamente en los pesos de un 3B. El fondo (qué solución técnica concreta proponer para un error específico de GlobalProtect) escala con el tamaño del modelo. Esa es la frontera real, y es exactamente donde el paper la sitúa.
7. Despliegue en hardware propio: el cierre del bucle económico
La razón por la que esto deja de ser un experimento académico es el deployment. Un 7B compilado en bf16 ocupa ~15 GB. Cabe en una AMD Radeon 7900XTX (24 GB) de gama consumer, ROCm gfx1100 plenamente soportado, en una caja de despacho de ~900€. La inferencia se sirve con vLLM-ROCm o, más cómodamente, con LM Studio: GUI, servidor OpenAI-compatible local, function calling soportado.
convert_hf_to_gguf.py de llama.cpp), cuantizar a F16 o Q8 para preservar la precisión de tool-calls (evitar Q4 con un modelo cuya tarea crítica es emitir JSON estructurado), levantar LM Studio, apuntar el executor de Jira al endpoint OpenAI local. Demo completa sin internet.
En esa caja, el coste por conversación deja de ser un número y empieza a ser una decisión de capital: pagas una vez por el hardware, el resto es electricidad. Para un equipo que atiende 10.000 conversaciones de soporte L1 al mes, la diferencia frente a una factura de Sonnet por turno se mide en órdenes de magnitud, no en porcentajes.
8. ¿Y si quisiéramos cerrar el gap del todo? El siguiente modelo subterráneo
El 7B compilado llega al 91% del frontier en media, pero el gap se concentra en info_accuracy (84% del baseline) y consistency (85%). Naturalidad y tool-use ya están al techo. La pregunta natural: ¿qué hardware y qué modelo local cerrarían también esas dos métricas?
Extrapolando el escalado real que vimos del 3B al 7B (info_accuracy subió +16 puntos porcentuales solo con el cambio de tamaño) y manteniendo el mismo pipeline de compilación, aquí va mi estimación práctica:
| Modelo base | bf16 | ¿Cabe en 7900XTX 24 GB? | Calidad estimada (media 5 métricas) | Coste compilación aprox. | Comentario |
|---|---|---|---|---|---|
| Qwen2.5-7B (lo que ya tenemos) | ~15 GB | ✓ F16 / Q8 | 91% (medido) | ~$5 | gap visible en info_accuracy y consistency |
| Qwen2.5-14B | ~28 GB | ✓ Q5/Q6 (~10-12 GB tras cuantización) | ~95-97% (estimado) | ~$15-25 | sweet spot: cierra info_accuracy a ~92-95% sin desbordar VRAM consumer |
| Qwen2.5-32B | ~60 GB | ✓ Q4 (~18-20 GB) | ~97-99% (estimado) | ~$40-60 | Q4 puede comprometer ligeramente tool-call validity; precaución |
| Qwen3-14B / Qwen3-32B (cuando madure) | similar | según cuantización | +2-3pp sobre Qwen2.5 mismo tamaño | similar | familia más nueva, baseline preentreno más fuerte |
| Modelos 70B | ~140 GB | ✗ no cabe en 24 GB ni con Q4 | ~99% en teoría | ~$100-150 | requiere 48 GB+ de VRAM (RTX PRO 6000 Blackwell, MI300) |
Mi apuesta operativa: Qwen2.5-14B-Instruct compilado, sirviéndolo en F16 o Q8, es el siguiente experimento natural. Mantiene la economía de hardware consumer (cabe en una 7900XTX cuantizado a Q5/Q6), añade capacidad para retener conocimiento de dominio, y el coste de compilarlo no debería superar los $25-30 porque el dataset está ya generado y el pipeline está validado. Lo que faltaba en el 7B son los puntos de fondo que el doble de parámetros tiende a resolver casi solo.
Hay una vía paralela igual de interesante sin escalar el modelo: 7B compilado + RAG sobre la documentación técnica interna. El RAG le inyecta los hechos concretos (versiones de software, errores conocidos, políticas de la empresa) en cada query, dejando al modelo solo la tarea de aplicarlos. El 7B compilado ya sabe cómo aplicar; lo que le cuesta es retener hechos específicos en sus pesos. RAG resuelve exactamente eso. Híbrido elegante: estructura en pesos, conocimiento en retrieval. Coste marginal: una base vectorial pequeña en la misma caja.
Lo importante de cualquiera de las dos vías es que el deployment sigue cabiendo en hardware consumer (~900€). No hay que pasar a servidores de $25.000 para cerrar el gap; hay que elegir bien la siguiente iteración.
9. Cuándo aplica esto y cuándo no
El método es brutal donde tiene sentido y un mal encaje donde no. Una guía corta:
- Aplica: procedimientos estables, repetitivos, con tool-use estructurado, volumen alto, requisitos de soberanía del dato o latencia baja. Soporte L1, triaje de incidencias, agentes de back-office, asistentes de procesos internos, KYC, FAQ con acciones.
- No aplica: dominios abiertos donde cada conversación es estructuralmente distinta (asistente generalista), procedimientos que cambian cada semana (recompilar tiene un coste), o casos donde el conocimiento de dominio crítico no se puede sintetizar (medicina específica, jurídico complejo). Ahí el frontier en cloud sigue ganando.
- Híbrido es lo más realista: compilar el 70-80% de las conversaciones que siguen el patrón, y rutar al frontier solo cuando el modelo compilado detecta que está fuera de su zona. Ese routing se compila también.
10. Lo que se llevan los números
Lo que demostramos, con el ojo puesto en una empresa que quiere bajar la factura sin perder calidad:
- Un Qwen2.5-7B-Instruct compilado para un procedimiento ITSM completo, con tres acciones Jira, alcanza el 91% de la calidad de Claude Sonnet usado como agente in-context, supera al baseline en naturalidad, y emite tool-calls perfectamente válidos en 50 de 50 escenarios.
- El coste por conversación baja entre 15× y 30× en spot AWS, y tiende a cero en hardware propio. El coste de entrenar el modelo entero (datos + GPU + evaluación) está por debajo de $50.
- El 3B es un escalón menos rico, pero su naturalidad y tool-use son casi idénticos al 7B. Para casos donde el conocimiento de dominio es ligero, el 3B se despliega en una GPU consumer cualquiera y resuelve.
- La arquitectura desaparece: sin LangChain, sin orquestador, sin nodos inyectados en cada turno. Un modelo, un system prompt mínimo, herramientas. Lo que en 2024 era inevitablemente un framework, en 2026 es un fine-tune.
El paper de Dennis et al. cierra con una frase que, después de hacerlo a mano, cobra otro sentido: "agentic frameworks at inference time represent unnecessary computational waste". No para todo, pero para mucho más de lo que parecía hace un año.
La conclusión operativa, la que merece quedarse anotada en una pared del equipo de arquitectura: lo que en 2024 era un proyecto serio de ingeniería con un equipo dedicado, en 2026 lo replica una persona con conocimientos de fine-tuning, una cuenta de AWS con créditos y un fin de semana. La barrera de entrada para construir agentes subterráneos de calidad casi-frontier ha caído tan brutal como silenciosamente. El tooling es accesible (HuggingFace, llama.cpp, LM Studio, Bedrock), los modelos base open-source son cada mes más capaces, y el conocimiento —como el paper que origina todo este experimento— se publica en abierto y se aplica en semanas, no en años.
Eso tiene una implicación concreta para cualquiera que diseñe soluciones agénticas en producción: no decidas la arquitectura con la mentalidad de hace 12 meses. Lo que ayer requería un orquestador caro y un modelo frontier por turno, hoy es un fine-tune y un endpoint local. Lo que hoy parece magia frontier, dentro de seis meses puede ser un modelo open-source de 14B corriendo en una caja de escritorio. La diferencia entre llegar con la arquitectura óptima o con la obsoleta no es ya talento ni presupuesto: es leer los papers que salen.
Universidades y laboratorios de investigación —Dennis et al. son solo un ejemplo entre muchos— están publicando metodologías a una velocidad que cinco años atrás habría sido impensable. Para el arquitecto serio en 2026, mantenerse al día con la literatura ya no es un lujo intelectual, es parte del trabajo. Quien lo haga, sorprenderá a su empresa con stacks 10× más baratos que los del competidor. Quien no, será el sorprendido. La asimetría se ha invertido: hoy la ventaja competitiva no la da el presupuesto, la da la atención.
Volver a artículos