Agent harness: qué es y por qué importa más que el modelo en un agente de IA

Un agent harness es el programa que rodea a un modelo de inteligencia artificial para que pueda trabajar como un agente. El modelo entiende la situación, piensa y decide qué hacer. El harness le da el contexto, las herramientas, la memoria de lo que ya hizo y los controles para actuar sobre sistemas reales.

Dicho de forma sencilla:

Agente = modelo + harness.

Por eso el mismo modelo puede portarse de forma muy distinta según el producto en el que esté. Cambia lo que se le cuenta, las acciones que puede hacer, los permisos, lo que recuerda y la regla que dice cuándo el trabajo ha terminado.

Elegir un buen modelo es solo una parte. Buena parte de cómo se comporta el agente depende de lo que construimos alrededor. Lo contamos en el modelo no es el agente.

El bucle que convierte un modelo en un agente

Un modelo solo, si le das un texto, devuelve una respuesta. Un agente tiene que ir más lejos: hacer una acción, ver qué ha pasado y decidir el siguiente paso.

En su forma más simple, el harness repite este bucle:

while (!state.finished) {
  const response = await model.generate({
    messages: state.messages,
    tools: availableTools
  });

  if (!response.toolCall) {
    return response.content;
  }

  const result = await executeTool(response.toolCall);

  state.messages.push(response, {
    role: "tool",
    content: JSON.stringify(result)
  });
}

while (!state.finished) {
  const response = await model.generate({
    messages: state.messages,
    tools: availableTools
  });

  if (!response.toolCall) {
    return response.content;
  }

  const result = await executeTool(response.toolCall);

  state.messages.push(response, {
    role: "tool",
    content: JSON.stringify(result)
  });
}

while (!state.finished) {
  const response = await model.generate({
    messages: state.messages,
    tools: availableTools
  });

  if (!response.toolCall) {
    return response.content;
  }

  const result = await executeTool(response.toolCall);

  state.messages.push(response, {
    role: "tool",
    content: JSON.stringify(result)
  });
}

El modelo elige el siguiente paso. El código de alrededor decide qué acciones existen, cómo se ejecutan, qué resultado vuelve al modelo y cuándo hay que parar.

En un producto de verdad, a ese bucle se le suman el contexto, el estado de esta tarea, los permisos, la comprobación del resultado y el registro de lo que ocurrió. Ahí empieza el trabajo del harness.

LangChain lo describe en The anatomy of an agent harness como la infraestructura que rodea al modelo para que pueda repetir pasos y usar herramientas. Microsoft usa una idea parecida en su Agent Framework: herramientas, memoria, estado y control de la ejecución.

Las piezas de un harness

Qué información recibe el modelo

El modelo solo puede pensar con lo que tiene delante en cada pregunta. El harness decide qué entra: las instrucciones, los mensajes anteriores, el resultado de las acciones, documentos, archivos o en qué punto va la tarea.

A eso se le llama a veces ingeniería de contexto. No es lo mismo que el harness. Lo primero elige qué información hace falta en ese momento. Lo segundo es el sistema entero en el que el modelo trabaja.

La diferencia importa cuando la tarea es larga. No podemos guardar para siempre cada mensaje y cada resultado, así que hay que decidir qué se conserva, qué se resume y qué se vuelve a buscar más tarde.

Resumir no es borrar lo que parece poco importante si lo miras solo. Un detalle pequeño puede hacer falta muchos pasos después para entender por qué el agente decidió algo.

Lo comentamos en el análisis de Jev AI. Puntuar cada mensaje o cada acción por separado, para decidir qué guardar, parece eficiente. Pero mezcla dos preguntas: si ese dato parece útil él solo, y qué información necesita el agente para seguir pensando bien. La segunda depende de todo lo que ha pasado en la tarea, no de una pieza aislada.

Cómo pasa de pensar a hacer

Las herramientas son las acciones que el modelo puede pedir: consultar un sistema, leer un archivo, enviar un correo, ejecutar un programa o trabajar en un espacio cerrado.

Una acción se le puede enseñar al modelo con un contrato, un texto que dice cómo se llama y qué datos pide:

const getOrder = {
  name: "get_order",
  description: "Devuelve un pedido de este cliente",
  parameters: {
    type: "object",
    properties: {
      order_id: { type: "string" }
    },
    required: ["order_id"]
  }
};

const getOrder = {
  name: "get_order",
  description: "Devuelve un pedido de este cliente",
  parameters: {
    type: "object",
    properties: {
      order_id: { type: "string" }
    },
    required: ["order_id"]
  }
};

const getOrder = {
  name: "get_order",
  description: "Devuelve un pedido de este cliente",
  parameters: {
    type: "object",
    properties: {
      order_id: { type: "string" }
    },
    required: ["order_id"]
  }
};

El modelo puede decidir llamar a get_order. Esa decisión, sola, no cambia nada. El harness comprueba que los datos son válidos, añade quién es el usuario y ejecuta la función en el sistema que toca.

La separación importa: el modelo propone una acción, y el sistema decide cómo se ejecuta.

Cuando el agente puede hacer muchas cosas, también hay que decidir cuáles conoce en cada momento. Cargar cientos de definiciones desde el principio ocupa espacio en lo que el modelo puede leer, y le cuesta más elegir.

En una ejecución real de Devic, el agente necesitaba una capacidad que no tenía cargada al empezar y usó discover_tools para encontrarla durante la propia tarea.

Pedir acciones no es solo definir funciones. También es decidir cómo se descubren, cuándo se cargan, dónde se ejecutan y con qué claves.

Qué hay que recordar ahora, y qué para la próxima vez

Si la tarea tiene varios pasos, hace falta saber qué ha pasado: qué acciones se usaron, qué falló, si alguien tiene que aprobar algo o qué conviene reintentar. Eso es el estado de esta tarea.

La memoria es otra cosa. Guarda lo que puede seguir sirviendo en tareas futuras: preferencias, decisiones anteriores o conocimiento del proyecto.

Separarlas responde a dos preguntas: qué necesita el agente para seguir con esta tarea, y qué debería recordar cuando empiece la siguiente.

También sirve para decidir qué se queda delante del modelo, qué se guarda fuera y qué se puede tirar cuando la tarea termina.

El modelo propone, el sistema autoriza

En cuanto un agente puede cambiar archivos, ejecutar comandos o tocar sistemas reales, no podemos dar por hecho que toda idea del modelo se ejecuta sola.

Algunas reglas son fijas. Leer información puede estar permitido. Borrar datos, hacer un pago o tocar contraseñas puede pedir aprobación, o estar prohibido.

Otras dependen de lo que significa la acción. Si el agente tiene una herramienta para ejecutar comandos, git status y rm -rf ./data pasan por la misma herramienta, y el riesgo no tiene nada que ver.

Una opción es poner un evaluador en medio:

const evaluation = await commandEvaluator.evaluate({
  command: toolCall.arguments.command
});

if (evaluation.risk === "low") {
  return execute(toolCall);
}

if (evaluation.risk === "medium") {
  return requestHumanApproval(toolCall);
}

throw new PolicyViolation(evaluation.reason);

const evaluation = await commandEvaluator.evaluate({
  command: toolCall.arguments.command
});

if (evaluation.risk === "low") {
  return execute(toolCall);
}

if (evaluation.risk === "medium") {
  return requestHumanApproval(toolCall);
}

throw new PolicyViolation(evaluation.reason);

const evaluation = await commandEvaluator.evaluate({
  command: toolCall.arguments.command
});

if (evaluation.risk === "low") {
  return execute(toolCall);
}

if (evaluation.risk === "medium") {
  return requestHumanApproval(toolCall);
}

throw new PolicyViolation(evaluation.reason);

Es una de las cosas que estamos planteando en Devic: mirar ciertos comandos antes de ejecutarlos, para detectar los que pueden romper algo.

Ese evaluador no sustituye las reglas fijas. Los permisos del sistema, el aislamiento del espacio donde corre el código, los permisos de una API y el acceso a las claves siguen teniendo que estar en código e infraestructura. El evaluador añade una lectura del significado, para cuando una regla fija no basta.

Lo mismo vale para la aprobación de una persona. En ejecuciones reales de Devic, el agente puede parar y pedir un sí explícito antes de cambiar algo.

En un SaaS también importa quién es: quién empezó la tarea, sobre qué cliente actúa y qué permisos tiene. El modelo puede proponer la acción. La autorización final sigue siendo del sistema. Lo desarrollamos en identidad, permisos y límites.

Que una acción no falle no significa que el trabajo esté hecho

Que una función termine sin error no significa que el agente haya conseguido lo que quería. Por eso un buen harness mira el resultado y lo comprueba antes de seguir.

await template.update(change);

const result = await template.capture();

const verification = await verifier.check({
  expected: change,
  actual: result
});

if (!verification.ok) {
  await agent.retry(verification.reason);
}

await template.update(change);

const result = await template.capture();

const verification = await verifier.check({
  expected: change,
  actual: result
});

if (!verification.ok) {
  await agent.retry(verification.reason);
}

await template.update(change);

const result = await template.capture();

const verification = await verifier.check({
  expected: change,
  actual: result
});

if (!verification.ok) {
  await agent.retry(verification.reason);
}

Un agente que programa puede cambiar un archivo y pasar los tests. Uno que actualiza un CRM puede volver a leer la ficha. Uno que trabaja sobre una pantalla puede mirar una captura de después.

Esto también pasa en ejecuciones reales de Devic. Después de cambiar una plantilla, el agente vuelve a capturar la página para comprobar el resultado. Cuando una imagen de fuera no cargó, vio que el cambio no había salido como se esperaba y no dio la tarea por terminada.

Una acción que termina bien confirma que la función se ejecutó. La comprobación responde a algo más importante: si el trabajo quedó resuelto.

Poder reconstruir qué pasó

Cuando una tarea tiene varias preguntas al modelo y varias acciones, guardar solo la respuesta final no sirve. Hay que poder reconstruir qué decidió el modelo, qué acción usó, qué devolvió, cuánto tardó y cuánto costó.

En las ejecuciones de Devic, cada paso puede anotar la acción, el tiempo, los tokens de entrada y los que venían de caché, la salida y el coste.

Así se distingue si el problema estuvo en el razonamiento, en una acción, en la comprobación o porque el agente empezó a llenarse de demasiado contexto. El registro no hace al agente más acertado, pero permite entenderlo, corregirlo y operarlo. Lo explicamos en trazabilidad.

Cómo se ve junto

Imaginemos que un cliente escribe a un SaaS de comercio: "El pedido llegó roto. Quiero que me devuelvan el dinero".

El harness mete el contexto de ese cliente y en qué punto va la conversación. El modelo decide consultar el pedido con una acción y, al ver el resultado, consulta la política de devoluciones. Descubre que el caso admite un reembolso, pero que por encima de 50 euros hace falta una aprobación.

El modelo propone la devolución. El harness comprueba los permisos y la regla del negocio, pausa la tarea y pide confirmación a una persona. Cuando se aprueba, hace el reembolso, vuelve a consultar el sistema para ver que se ha procesado y deja todo el recorrido escrito en el registro.

El modelo ha pensado. El contexto, las acciones, el estado, los permisos, la comprobación y el registro los ha llevado el harness.

Ese es el salto entre una demo que llama a un sistema y un agente que puede trabajar dentro de un producto. También lo contamos en una demo no es un agente en producción.

Dónde debería estar vuestro esfuerzo

El caso, las reglas del negocio, las acciones propias de vuestro producto y los datos son vuestros. Ahí suele estar lo que os diferencia.

En cambio, el bucle, el estado, los reintentos, las aprobaciones, el registro, el espacio cerrado donde corre el código, separar a los clientes o poder cambiar de modelo son problemas que se repiten en casi todos los productos. Para un equipo de unas decenas de personas, construir y mantener todo eso dentro puede comer muchos recursos sin dar una ventaja equivalente.

La pregunta no es solo si podéis construir vuestro propio harness. Es qué parte de esa infraestructura merece ser vuestra. Si la ventaja está en conocer el negocio, en las integraciones y en la experiencia de quien usa el producto, el esfuerzo debería ir ahí.

Construir esa infraestructura o apoyarse en una plataforma está desarrollado en build vs buy.

El modelo importa. El harness también

Cuando los agentes se vuelven más capaces, el nombre del modelo explica cada vez menos por sí solo. El resultado también depende de qué se le cuenta, qué acciones puede usar, qué recuerda, con qué permisos actúa y cómo comprueba su trabajo.

El modelo aporta la capacidad de pensar. El harness convierte esa capacidad en acciones controladas sobre sistemas reales.

Por eso, al meter agentes en un producto, la pregunta ya no es solo qué modelo usar. También hay que decidir qué sistema necesita alrededor para hacer bien el trabajo.

Ese sistema es el agent harness.