Del prompt al grafo: las cinco capas que convierten un modelo en un sistema que trabaja

Resumen ejecutivo

Un modelo de lenguaje solo hace una cosa: procesar texto y generar texto. Todo lo demás —leer archivos, ejecutar herramientas, decidir cuándo parar, coordinar a otros— lo aporta lo que envuelve al modelo. Ing. Cristián Rojas Arredondo, chair del Consejo de Desarrollo e IA de Comunidad IA LATAM, resume esa idea en una fórmula: A = ⟨M, H⟩, un agente es un modelo más su arnés. A partir de ahí construye una progresión de cinco capas —prompt, contexto, arnés, bucle y grafo— donde cada una existe porque resuelve un límite concreto de la anterior. La clase culmina en algo poco habitual en una charla divulgativa: un argumento de convergencia. Auditar el repositorio completo en cada ronda de remediación diverge por construcción; fijar el universo de hallazgos una sola vez y podarlo garantiza que el proceso termine. Este artículo recorre las cinco capas y explica por qué esa distinción decide si tu agente arregla el proyecto o da vueltas en círculos.

01Un agente es control, no solo generación

La confusión más extendida sobre los agentes es tratarlos como un modelo más listo. No lo son. La diferencia no está en la calidad de la generación sino en la capacidad de operar: observar, decidir, actuar sobre archivos y sistemas reales, comprobar el resultado y volver a intentarlo.

Rojas ordena cuatro conceptos que suelen usarse indistintamente y no son lo mismo. Un LLM es el modelo de lenguaje. Un arnés (harness) es el entorno de ejecución y operación. Un agente es la unidad de operación y control que resulta de juntar ambos. Y un sistema multiagente es un conjunto de agentes coordinados.

Una precisión de vocabulario que la propia clase se detiene a hacer, porque genera confusión: «arnés» aparece en dos niveles. Como paraguas de runtime —todo lo que envuelve al modelo y lo hace actuar— y como una capa concreta dentro de la progresión didáctica. Es el mismo sistema mirado desde dos alturas: el todo y la pieza.

02La progresión: cada capa resuelve un límite

Lo que hace valiosa esta clase no es el catálogo de conceptos, sino el hilo que los une. Cada capa no se agrega porque sí: aparece cuando la anterior se queda corta.

03Prompt: la primera capa de control

La clase demuestra el salto con un ejemplo mínimo y muy reconocible: una función de login que concatena usuario y contraseña dentro de una consulta SQL.

Preguntar «¿está bien esta función?» produce lo que cabe esperar: «parece funcionar; podrías validar los campos y usar nombres más claros». Un resultado pobre para un prompt pobre. Cambiar la instrucción por «eres un auditor de seguridad senior; revisa esta función, razona línea por línea, señala las vulnerabilidades ordenadas por severidad y propón el fix de cada una» devuelve otra cosa: crítico por inyección SQL con la corrección parametrizada, alto por comparación de contraseña en texto plano con la recomendación de hashear, medio por ausencia de manejo de error.

Mismo modelo, mismo código, resultado incomparable. De ahí la anatomía que propone la clase para un prompt de auditoría: rol (quién eres), tarea (qué buscas), cadena de razonamiento (analiza módulo por módulo antes de listar), ejemplo (ubicación, severidad, causa, fix) y formato de salida estructurado, por ejemplo JSON con archivo, severidad, categoría y descripción. El formato no es cosmética: es lo que permite que la salida alimente al siguiente paso.

04Contexto: lo que el modelo ve cuando piensa

Un prompt perfectamente estructurado puede fallar igual. Peor: puede alucinar una respuesta creíble y falsa. La razón es que el prompt define el trabajo, pero no la información con la cual trabajar.

Rojas define contexto como la entrada completa que el modelo ve en el momento de iniciar la inferencia: las instrucciones, los archivos, los estándares y convenciones, los hallazgos de auditorías previas y los resultados de las herramientas. Y luego hace la pregunta que hay que hacerse: ¿más contexto es siempre mejor?

No, porque el presupuesto de atención es finito. La clase separa dos naturalezas que conviene no mezclar:

• Transitorio — el prompt y el archivo actual. Se arma en cada llamada al modelo.
• Persistente — la guía de estilo, el repositorio accesible vía herramientas, los hallazgos acumulados, el reporte. Sobrevive entre pasos y entre sesiones.

Esa distinción tiene una consecuencia económica directa que Rojas señala en la grabación: si el trabajo de una sesión queda en memoria, la sesión siguiente no necesita reconstruir todo el contexto desde cero, lo que reduce el consumo de tokens y el tiempo de ejecución.

05Arnés: darle manos al modelo

Un contexto bien compuesto aumenta la precisión y reduce las alucinaciones, pero el modelo sigue sin poder tocar nada. El arnés es la capa que convierte juicio en operación. Sus componentes, según la clase:

• Inventario de herramientas y enrutamiento — qué puede hacer y cómo se decide qué usar.
• Gestor de contexto y almacén de estado — qué recuerda y dónde lo guarda.
• Restricciones de seguridad — qué tiene prohibido, con independencia de lo que decida el modelo.
• Observabilidad y ganchos de ciclo de vida — qué queda registrado y dónde se puede intervenir.
• Bucle agéntico — el motor que repite observar, decidir, actuar.

La memoria merece un párrafo aparte porque cumple dos funciones a la vez: permite aprender de los éxitos y de los fracasos, y evita regenerar contexto que ya se produjo antes.

06Bucle: ciclos que saben parar

Aquí aparece el problema más sutil de toda la clase, y conviene leerlo despacio. El bucle de un arnés observa, decide, actúa, vuelve a observar y repite hasta cumplir una condición de término. Pero si esa condición la define el propio arnés, nada garantiza que cuando reporta éxito haya cumplido de verdad el objetivo sin producir daños ni regresiones en otros puntos del repositorio.

“

Un bucle que se autoevalúa reporta éxito con la misma confianza con la que alucina, y por eso la verificación tiene que venir de fuera del bucle.

Ing. Cristián Rojas Arredondo

Es el equivalente agéntico de dejar que el examinado corrija su propia prueba. Rojas cuenta en la grabación un caso que cualquiera que haya trabajado con agentes de código reconoce: estar editando un archivo y que el agente, a mitad del proceso, se dé cuenta de que cometió un error. Que lo detecte es bueno. Que sea él mismo quien certifique que ya está resuelto es el problema.

De ahí que la ingeniería de bucles consista en diseñar procesos reproducibles y autoverificables, con condiciones de parada definidas por quien diseña el bucle y no por quien lo ejecuta.

07Grafo: descomponer para poder terminar

Un solo agente choca con dos muros: los límites de su ventana de contexto y el sesgo autoinducido —seguir por el camino que él mismo eligió—. La ingeniería de grafos responde descomponiendo la tarea compleja en tareas menores, paralelizables y delegables.

El patrón que la clase desarrolla es fan-out / fan-in, ejemplificado sobre una auditoría de repositorio:

• Fan-out : N subagentes en paralelo, cada uno con su arnés y su bucle, mirando una perspectiva distinta —seguridad, rendimiento, estilo, dependencias—.
• Directorio compartido : cada trabajador escribe su reporte en un archivo común en lugar de devolverlo al orquestador. Así se coordinan sin saturar el contexto de quien coordina.
• Fan-in : un subagente sintetizador lee todos los reportes, consolida duplicados y produce el resultado único.
• DAG de hallazgos : la síntesis no es una lista, es un grafo dirigido acíclico de severidad × perspectiva.

El DAG: causas arriba, efectos abajo

En ese grafo, una arista a → b significa «a contribuye a b» o «a causa b». Las causas raíz quedan arriba y los efectos compuestos abajo. Y aquí aparece la idea más práctica de toda la clase: la severidad local de un hallazgo no basta para priorizarlo.

El ejemplo de la clase lo aclara. Una dependencia desactualizada tiene severidad baja. Pero de ella cuelgan una CVE transitiva de severidad alta y regresiones ocultas de severidad media. Su zona de impacto contiene un hallazgo crítico, de modo que el impacto real de esa dependencia baja se calcula como el par (máxima severidad en su zona, tamaño de la zona). Resultado: se remedia primero, pese a que aisladamente parecía lo menos urgente.

La priorización, entonces, tiene dos dimensiones y no una: el número de causas determina la accionabilidad —cuándo se puede tocar algo—, y la zona de impacto determina la prioridad —cuánto rinde tocarlo—.

08La trampa de la divergencia

Este es el aporte que distingue a esta clase de una introducción cualquiera a los agentes, y es un argumento de terminación, no una buena práctica.

Re-auditar todo el repositorio en cada ronda de remediación redefine el universo de hallazgos, y por lo tanto diverge por construcción. Cada auditoría global destapa cosas nuevas, ignora otras y reordena la prioridad, de modo que la ronda n+1 no trabaja sobre el residuo de la ronda n. No existe función de potencial monótona: nada garantiza que el proceso termine.

Es un fallo que se siente en el cuerpo cuando se sufre: el agente lleva horas trabajando, cada ronda encuentra hallazgos, se corrigen, y la cuenta de pendientes nunca baja. Parece falta de capacidad y es un defecto de diseño del bucle externo.

La corrección tiene cuatro piezas:

• Universo fijo — el DAG se construye una sola vez, con una auditoría profunda.
• Poda monótona — cada ronda solo tacha nodos resueltos o los deja pendientes de reintento por regresión. Nunca agrega nodos nuevos.
• Función de potencial — el número de nodos sin tachar solo puede bajar. Ese es el argumento de convergencia.
• Parada inequívoca — se detiene cuando el DAG se agota, cuando se acaba el presupuesto o cuando la verificación certifica.

El orden de trabajo también queda determinado: primero una restricción dura —las causas antes que los efectos, avanzando por la frontera del grafo—, luego el desempate por impacto, y finalmente verificación acotada y poda. Solo cuando el universo se agota se ejecuta una nueva auditoría global que construye un DAG nuevo. El ciclo externo existe, pero no se dispara en cada ronda.

09Conclusiones

Tres ideas para llevarse. La primera: el poder de un agente no está en el modelo sino en lo que lo envuelve. Cambiar de modelo mejora el juicio; cambiar el arnés cambia lo que el sistema es capaz de hacer y, sobre todo, lo que tiene prohibido hacer.

La segunda: quien define la condición de término define si el trabajo está hecho. Un bucle que se autoevalúa reporta éxito con la misma confianza con la que alucina, y por eso la verificación tiene que venir de fuera del bucle.

La tercera, y la más útil para quien ya está orquestando agentes: la convergencia se diseña. Si el proceso vuelve a mirar el mundo entero en cada iteración, no está avanzando, está reiniciándose con otro nombre. Fijar el universo una vez y podarlo es lo que convierte una sucesión de intentos en un proceso que termina.

El recorrido completo, en una línea: el modelo solo genera texto → el prompt dirige la generación → el contexto define la información → el arnés aporta operación y control → el bucle hace el proceso verificable → el grafo lo hace descomponible y convergente.