Harness y scaffold: cómo entender los términos clave en agentes de IA

Por qué importa definir bien los términos

Cuando una disciplina avanza rápido, su vocabulario suele fragmentarse: palabras que se solapan, significados distintos según el autor, y conceptos que se convierten en jerga sin una definición clara. Esto está ocurriendo en el ámbito de los agentes de IA. Confundir términos como model, scaffold y harness puede generar malentendidos técnicos y decisiones de producto equivocadas. Después de ICLR 2026 surgió una pregunta que sintetiza esta confusión: ¿qué se entiende por “harness” y por “scaffold” en el contexto de agentes? Este texto busca ordenar esas ideas y ofrecer una referencia práctica para equipos de ingeniería, producto y tomadores de decisión.

Modelo (Model)

El modelo es el LLM: la pieza que toma texto y devuelve texto —por ejemplo Claude, Qwen, GPT, Kimi, DeepSeek—. Por sí solo es una función que responde a un prompt y se detiene; no tiene memoria persistente entre llamadas ni un bucle de ejecución. Puede generar la intención de usar una herramienta, pero no puede ejecutarla sin una capa adicional. En otras palabras, el modelo es el motor de generación, no el agente completo.

Scaffolding: qué ve y cómo funciona el modelo

El scaffolding es la capa que define el comportamiento alrededor del modelo: prompt de sistema, descripción de herramientas, formato de salida esperado y manejo del historial o memoria entre pasos. Moldea cómo el modelo interpreta su entorno y qué información tiene disponible en cada paso.

En algunos productos se usa la palabra “harness” para referirse al conjunto completo que envuelve al modelo, pero es útil distinguir scaffold cuando necesitamos hablar de las instrucciones y el contexto que el modelo recibe (el “qué”), separadas de la lógica que ejecuta el agente (el “cómo”).

Productos como Claude Code, Codex u otras soluciones pueden nombrar esta capa de manera distinta; algunos sistemas integrados empacan scaffold y harness en un único producto optimizado con un modelo específico.

Harness: la capa de ejecución

El harness es la parte que hace que el agente funcione: llama al modelo, interpreta instrucciones del modelo para ejecutar herramientas, maneja errores, decide cuándo terminar y orquesta el bucle de actuación. Si el scaffolding es la guía, el harness es el motor que sigue esa guía en tiempo de ejecución.

Ingeniería de harness significa diseñar cuándo y cómo se toman decisiones fuera del modelo, cómo se controlan los fallos y qué guardrails se aplican para mantener el comportamiento esperado. En evaluación, existe un concepto análogo: el “eval harness”, que recorre escenarios fijados y recoge métricas sin actualizar pesos del modelo.

Agente: modelo + scaffolding + harness

En aprendizaje por refuerzo la definición clásica de agente es una función que recibe una observación y devuelve una acción; en el mundo de LLMs, la noción se ha ampliado: un agente es el conjunto (modelo + scaffolding + harness) que permite ejecutar un bucle de actuación —recoger información, decidir y actuar—.

Una manera práctica de verlo: Agent = Model + Harness, donde el scaffold determina lo que el modelo percibe y el harness ejecuta las decisiones y mantiene el flujo.

Esto ayuda a entender por qué dos productos construidos sobre el mismo modelo pueden comportarse de forma muy distinta: sus harnesses y scaffolds hacen elecciones diferentes de diseño.

Context engineering

El diseño de contexto define qué entra en la ventana de contexto del agente en cada paso: prompt de sistema, historial de conversación, descripciones de herramientas, y conocimiento recuperado. Es una disciplina crítica porque el rendimiento del agente depende en gran medida de lo que el modelo puede ver y cómo se le presenta. El contexto no es estático: a medida que el agente avanza, hay que decidir qué preservar, qué resumir y qué recuperar desde almacenamiento externo.

Política, uso de herramientas y skills

La política del agente incluye reglas y guardrails: qué acciones están permitidas, límites operativos y criterios de seguridad. El uso de herramientas (tool use) es uno de los factores más relevantes: el modelo puede proponer invocar una API, ejecutar un comando o consultar una base de datos, pero el harness es el que valida, ejecuta y reporta el resultado.

“Skills” o habilidades son capacidades concretas que el agente puede invocar —por ejemplo, generación de código, acceso a un buscador o interacción con un sistema de tickets—. Estas habilidades suelen estar descritas en el scaffold y expuestas como herramientas que el harness administra.

Sub-agents y orquestación

Algunas arquitecturas dividen el trabajo en sub-agents: agentes especializados que interactúan entre sí o con un agente coordinador. El diseño de sub-agents permite aislar responsabilidades, reutilizar capacidades y escalar pipelines complejas. La orquestación entre sub-agents suele gestionarse en el nivel del harness.

Entrenamiento: entorno, trainer y recompensas

Cuando se entrena un modelo para comportarse como agente, se añaden componentes específicos: un entorno (environment) que simula pasos y acciones, un entrenador (trainer) que administra ejecuciones y actualiza pesos, y una señal de recompensa (reward) que guía el aprendizaje. En producción, la distinción entre el harness de entrenamiento y el de inferencia importa: en entrenamiento se requiere recoger datos, ejecutar muchos episodios y retroalimentar al modelo; en inferencia se busca robustez, registros y límites claros.

Evaluación y despliegue

En evaluación, el harness reproduce escenarios fijos y mide el comportamiento del modelo sin actualizarlo. En despliegue (rollout) el mismo harness debe afrontar condiciones reales: latencia, errores de integración, y cumplimiento de políticas. Elegir qué parte del sistema es configurable en tiempo de ejecución y qué parte es fija es una decisión de ingeniería que afecta seguridad y mantenibilidad.

Consideraciones prácticas para equipos y organizaciones en América Latina

• Separar responsabilidades: mantengan claras las fronteras entre modelo, scaffold y harness. Esto facilita intercambiar modelos, ajustar prompts o rehacer la orquestación sin rehacer todo el producto.
• Evaluación local y controles: diseñen harnesses que registren decisiones y errores. Esto ayuda a entender fallos y a cumplir requisitos regulatorios o de auditoría.
• Modularidad de herramientas: exponer capacidades como herramientas bien descritas hace que el scaffold sea más predecible y el harness más seguro.
• Capacitación y recursos: los equipos deben entrenarse en context engineering y harness engineering, no solo en ajustar prompts. La disciplina de ingeniería del harness es clave para la confiabilidad.

Conclusión

El vocabulario importa porque condiciona cómo concebimos y construimos sistemas. Entender que el modelo genera lenguaje, el scaffold define qué ve y el harness ejecuta ese comportamiento ayuda a diseñar agentes más robustos, auditable y escalables. Para equipos y responsables en la región, separar estas capas facilita tomar decisiones de proveedor, migración de modelos y alineamiento con políticas internas y regulaciones emergentes.

Si están construyendo o evaluando agentes, comiencen por mapear qué parte de su stack corresponde al modelo, al scaffold y al harness; esa claridad reducirá sorpresas y hará más limpio el camino hacia despliegues confiables.