Arneses para LLMs: Por qué el wrapper importa más que el modelo

El arnés es todo fragmento de código, configuración y lógica de ejecución que no es el modelo en sí — el bucle de orquestación, las herramientas, la memoria, la gestión del contexto, el estado, el manejo de errores, los guardrails y las verificaciones que en conjunto determinan si un agente tiene éxito o falla. Si alguna vez has desplegado una funcionalidad LLM con el SDK de OpenAI o Anthropic y has visto cómo entra en bucle, alucina llamadas a herramientas, u olvida lo que el usuario dijo tres turnos atrás, ya has alcanzado los límites de un arnés delgado — y la mayoría de las veces el modelo no era el problema.

Este artículo te proporciona un modelo mental preciso sobre el arnés, evidencia de que impulsa más varianza en los resultados que la elección del modelo, un arnés en JS/TS ejecutable que puedes leer de principio a fin, y cuatro decisiones que un equipo de frontend realmente controla al desplegar una funcionalidad de IA en un producto.

¿Qué es un arnés de agente?

Un arnés de agente es el sistema de software completo que envuelve una llamada a un LLM: el bucle de orquestación que decide cuándo llamar al modelo, las herramientas que el modelo puede invocar, la memoria y el contexto que percibe, el estado que mantiene entre turnos, y los guardrails y verificaciones que controlan su salida. La fórmula canónica proviene de Vivek Trivedy de LangChain: “si no eres el modelo, eres el arnés.” El modelo produce tokens; el arnés es todo lo que convierte esos tokens en una funcionalidad confiable.

El modelo mental más claro para entender esta relación proviene del ensayo de 2023 de Beren Millidge que enmarca los sistemas LLM con scaffold como computadoras en lenguaje natural: el LLM equivale a la CPU, el prompt y la ventana de contexto equivalen a la RAM (rápida pero limitada), y la memoria externa como una base de datos vectorial equivale al almacenamiento en disco. Las herramientas actúan como controladores de dispositivos que acceden al mundo exterior, y el arnés es el sistema operativo que coordina todo. Una CPU sin sistema operativo no computa nada útil. El modelo es necesario, pero no suficiente.

La terminología en este campo es amplia, así que conviene fijarla de una vez. El modelo es el LLM — pesos y una API. El arnés (a veces llamado scaffold) es el código que lo rodea. El agente es el comportamiento emergente: una entidad orientada a objetivos, que usa herramientas y se autocorrige, con la que el usuario interactúa. El Curso de Agentes de Hugging Face define un agente como un sistema que usa un modelo de IA para interactuar con su entorno y alcanzar un objetivo definido por el usuario. Cuando alguien dice “construí un agente,” construyó un arnés y lo apuntó a un modelo. El propio anuncio del Claude Agent SDK de Anthropic describe el Claude Code SDK como “el arnés de agente que impulsa Claude Code.”

¿Por qué el wrapper importa más que el modelo?

El wrapper importa más que el modelo porque el mismo modelo, detrás de un arnés diferente, produce resultados radicalmente distintos — y las diferencias son grandes, repetibles y medidas en benchmarks públicos. El dato más contundente: el equipo de v0 de Vercel eliminó el 80% de las herramientas de su agente y observó cómo el éxito en las tareas subió del 80% al 100%, el uso promedio de tokens cayó un 37%, y una consulta en el peor caso bajó de 724 segundos a 141 — sin cambiar el modelo. La solución estuvo completamente en el arnés: menos herramientas, mejor delimitadas.

Dos resultados más apuntan en la misma dirección. LangChain reportó que su agente de programación pasó de estar fuera del top 30 al top cinco en Terminal-Bench 2.0 cambiando únicamente el arnés alrededor de un modelo sin cambios, según su propio artículo. Y en el leaderboard CORE-Bench Hard de Princeton HAL, Claude Opus 4.5 obtiene un 42,22% con el scaffold CORE-Agent y un 77,78% con Claude Code — una diferencia de 35,56 puntos en el mismo modelo, con el leaderboard reportando además un 95,5% bajo validación manual para la ejecución con Claude Code.

Estudio	¿Modelo cambiado?	¿Arnés cambiado?	Antes	Después
Vercel v0	No	Sí (−80% herramientas)	80% éxito	100% éxito, −37% tokens
LangChain / Terminal-Bench 2.0	No	Sí	Fuera del Top 30	Top 5
Princeton CORE-Bench Hard	No (Opus 4.5)	Sí (scaffold)	42,22%	77,78%

El debate no está resuelto, y simplificarlo en exceso resta credibilidad. SWE-Atlas de Scale AI compara los scaffolds de agentes de programación propios contra el mini-SWE-agent mínimo y muestra que los efectos del scaffold varían según el modelo, con los scaffolds nativos produciendo mejoras notables sobre la línea base mínima. Mientras tanto, METR encontró que Claude Code y Codex no eran estadísticamente significativamente mejores que sus propios scaffolds predeterminados en una evaluación de horizonte temporal. Ambos efectos son reales; cuál predomina depende del régimen de la tarea. La lectura honesta, como MongoDB lo expresa, es que “el LLM es la parte más pequeña” — pero las ganancias del arnés no son ilimitadas, y un modelo sólido en una tarea débil sigue teniendo un techo que el scaffolding no puede superar.

¿Cuáles son los componentes de un arnés LLM?

Un arnés de producción se descompone en ocho componentes, cada uno de los cuales es un punto donde un wrapper delgado puede fallar: bucle de orquestación, herramientas, memoria, gestión del contexto, construcción del prompt, estado, manejo de errores, y guardrails con bucles de verificación.

Bucle de orquestación. El bucle implementa el ciclo Pensamiento–Acción–Observación (el patrón ReAct): llamar al modelo, verificar si solicitó una herramienta, ejecutar la herramienta, devolver el resultado, repetir hasta que el modelo responda o se active un guardrail. Como lo describe el análisis de ingeniería inversa de Claude Code realizado por Vikash Rungta, el runtime es un “bucle tonto” donde toda la inteligencia reside en el modelo y el arnés solo gestiona los turnos. Mecánicamente es un bucle while con un límite de turnos.

Herramientas. Las herramientas son las manos del agente — funciones expuestas al modelo como esquemas (nombre, descripción, tipos de parámetros). La capa de herramientas gestiona el registro, la validación de argumentos, la ejecución y el formateo de resultados en observaciones legibles por el modelo. Una herramienta search_docs en un widget de ayuda es una herramienta; también lo es get_order_status.

Memoria. La memoria a corto plazo es la conversación actual; la memoria a largo plazo persiste entre sesiones. En un widget de chat, la memoria a corto plazo es el array de mensajes que se reproduce en cada turno; la memoria a largo plazo podría ser un resumen por usuario que se carga al inicio de la sesión.

Gestión del contexto. El recurso escaso es la ventana de contexto, y el modo de fallo es la degradación del contexto — la calidad se deteriora cuando la ventana se llena de tokens de bajo valor. Según la guía de ingeniería de contexto de Anthropic, el objetivo es el conjunto más pequeño de tokens de alto valor. Las estrategias incluyen: compactación (resumir turnos antiguos) y recuperación justo a tiempo (obtener bajo demanda en lugar de precargar).

Construcción del prompt. El arnés ensambla la entrada de forma jerárquica: prompt de sistema, definiciones de herramientas, memoria, historial de conversación, mensaje actual. El orden importa; el contexto importante debe estar al inicio y al final de la ventana.

Estado. El estado es lo que sobrevive entre turnos y fallos — la posición del agente en una tarea de múltiples pasos, las salidas intermedias, los checkpoints. Un widget de chat que “olvida” la restricción anterior del usuario tiene un problema de estado, no de modelo.

Manejo de errores. Una tarea de 10 pasos con un 99% de éxito por paso tiene solo un ~90% de éxito de extremo a extremo porque los errores se acumulan. El patrón clave: devolver un error de herramienta al modelo como una observación para que pueda autocorregirse, en lugar de lanzar una excepción y terminar la ejecución.

Guardrails y bucles de verificación. Los guardrails limitan lo que el agente puede hacer; los bucles de verificación comprueban lo que produjo. El artículo de ingeniería de arneses de Martin Fowler / Birgitta Böckeler enmarca la verificación como guías (feedforward — orientar antes de actuar) y sensores (feedback — observar y autocorregir), divididos en controles computacionales (deterministas: tests, linters) e inferenciales (LLM como juez).

¿Cómo construyo un arnés de agente en JavaScript?

Un arnés mínimo pero completo es un bucle ReAct con un límite de turnos, una herramienta bien delimitada, un manejador de errores como observación, y una verificación determinista. El ejemplo a continuación usa el SDK de Anthropic y Zod para la validación de esquemas. La verificación determinista es la parte que la mayoría de los wrappers delgados omiten — sin ella, el agente no tiene forma de saber que está equivocado.

import Anthropic from "@anthropic-ai/sdk";
import { z } from "zod";

const client = new Anthropic();

// Una herramienta, con alcance reducido. Menos herramientas = menos llamadas espurias.
const tools: Anthropic.Tool[] = [
  {
    name: "get_order_status",
    description: "Look up the status of an order by its numeric ID.",
    input_schema: {
      type: "object",
      properties: { orderId: { type: "number" } },
      required: ["orderId"],
    },
  },
];

// Verificación determinista: la entrada de herramienta del modelo debe coincidir con este esquema.
const OrderArgs = z.object({ orderId: z.number().int().positive() });

async function runOrder(orderId: number) {
  // Sustituto de una consulta real.
  return { orderId, status: "shipped", eta: "2026-03-04" };
}

export async function harness(userMessage: string) {
  const messages: Anthropic.MessageParam[] = [
    { role: "user", content: userMessage },
  ];

  // Guardia de turnos máximos: el guardrail de seguridad más importante contra los bucles.
  for (let turn = 0; turn < 6; turn++) {
    const res = await client.messages.create({
      model: "claude-sonnet-4-6",
      max_tokens: 1024,
      system: "You are an order-status assistant. Use tools when asked about orders.",
      tools,
      messages,
    });

    const toolUse = res.content.find(
      (b): b is Anthropic.ToolUseBlock => b.type === "tool_use"
    );
    if (!toolUse) return res.content; // Sin llamada a herramienta → el modelo respondió.

    messages.push({ role: "assistant", content: res.content });

    let observation: string;
    const parsed = OrderArgs.safeParse(toolUse.input);
    if (!parsed.success) {
      // Verificación fallida: devolver el error COMO una observación, no lanzar excepción.
      observation = `Invalid arguments: ${parsed.error.message}`;
    } else {
      try {
        observation = JSON.stringify(await runOrder(parsed.data.orderId));
      } catch (e) {
        observation = `Tool error: ${(e as Error).message}`; // también es una observación
      }
    }

    messages.push({
      role: "user",
      content: [{ type: "tool_result", tool_use_id: toolUse.id, content: observation }],
    });
  }
  return [{ type: "text", text: "Could not complete the request." }];
}

Cuatro decisiones de diseño en esas ~50 líneas concentran la mayor parte de la confiabilidad. El bucle for con límite de turnos es el bucle de orquestación y el guardrail anti-bucle. La herramienta única mantiene el esquema de herramientas pequeño. El safeParse de Zod es la verificación determinista que detecta argumentos alucinados antes de que lleguen a tu backend. Y tanto los fallos de validación como los errores en tiempo de ejecución se devuelven como observaciones, no se lanzan como excepciones — para que el modelo pueda corregirse en lugar de que la ejecución muera. La mecánica de uso de herramientas de Anthropic está documentada en la guía de uso de herramientas; el bucle equivalente con el SDK de OpenAI usa tool_calls y mensajes con role: "tool".

¿Por qué los desarrolladores frontend controlan más del arnés de lo que creen?

Los desarrolladores frontend ya son dueños de un arnés cada vez que despliegan un widget de chat con IA, un asistente de búsqueda integrado en el producto, o una interfaz de copiloto — simplemente son arneses más delgados que los agénticos. La mayoría de los fallos de los que se quejan los usuarios (bucles, llamadas alucinadas a herramientas, contexto olvidado, restricciones ignoradas) son fallos del arnés, no del modelo. Cuando un equipo de frontend despliega una funcionalidad de IA, la elección del modelo es una decisión entre muchas, y las decisiones del arnés — alcance de herramientas, qué contexto mantener, qué verificar — suelen recibir menos revisión de diseño de la que merecen.

El mapeo es directo. Un usuario que ve al asistente “regenerar” la misma respuesta incorrecta está viendo un bucle de orquestación sin verificación. Un usuario cuya restricción declarada desaparece dos turnos después está viendo una brecha en el estado y la gestión del contexto. Una llamada a herramienta que se dispara con un argumento basura y devuelve una respuesta confusa es un paso de validación de esquema faltante — exactamente el paso safeParse anterior. Ninguno de estos problemas se resuelve cambiando el modelo. Se resuelven ajustando el wrapper que ya controlas.

¿Qué tan grueso debe ser mi arnés? Cuatro decisiones que los equipos de frontend controlan

Un equipo de frontend que despliega una funcionalidad de IA en un producto controla realmente cuatro decisiones del arnés: alcance de herramientas, estrategia de contexto, bucles de verificación y grosor del arnés. La lista más amplia a nivel de campo — agente único vs. multi-agente, ReAct vs. plan-and-execute, permisos, ejecución durable, gobernanza de flota — se sitúa en capas de infraestructura que la mayoría de los widgets de chat nunca alcanzan.

1. Alcance de herramientas — empieza con menos de 10 herramientas y expande con cautela. Dar a un agente más herramientas de las necesarias degrada el rendimiento de forma consistente, porque cada esquema de herramienta adicional consume contexto y aumenta la probabilidad de una llamada espuria. El resultado de Vercel es la evidencia más sólida: eliminar el 80% de las herramientas mejoró todo.

2. Estrategia de contexto — compactación y recuperación justo a tiempo en lugar de saturar la ventana. No precargues toda la base de conocimiento en el prompt. Resume los turnos antiguos cuando te acerques al límite de la ventana, y obtén documentos bajo demanda. La guía de ingeniería de contexto de Anthropic define el objetivo como el conjunto de tokens de mayor valor y menor tamaño posible.

3. Bucles de verificación — todo arnés necesita al menos una verificación determinista antes de devolver el resultado al usuario. Un validador de esquema, una expresión regular, un test unitario — algo que el arnés pueda ejecutar que no dependa del juicio del propio modelo. Sin ello, el agente no tiene forma de saber que está equivocado. Según la división computacional/inferencial de Böckeler, empieza con una verificación computacional económica; añade un LLM como juez solo cuando se requiera corrección semántica.

4. Grosor del arnés — empieza delgado, añade estructura solo cuando un patrón de fallo se repite. No construyas orquestación de antemano para fallos que aún no has visto. Añade un reintento, un guardrail o un paso de verificación cuando un fallo específico aparezca más de una vez.

Revisar las repeticiones de sesión de una funcionalidad de IA en producción es una de las formas más rápidas de evaluar la calidad del arnés a partir del comportamiento del usuario, porque las firmas diagnósticas son visibles sin necesidad de telemetría a nivel del modelo. La reformulación repetida de la misma solicitud señala pérdida de contexto o un bucle de verificación que nunca se activa. El abandono a mitad de una tarea de múltiples pasos a menudo se debe a un error de herramienta silenciado que se manifiesta como una respuesta vaga. El comportamiento de copiar-y-editar señala una brecha de verificación — salida que pasó las comprobaciones del arnés pero falló al usuario. Los clics repetidos en “regenerar” o “intentar de nuevo” son la firma de un arnés en bucle que no puede detectar su propio estado de fallo.

¿Hacia dónde se dirige el diseño de arneses?

Los modelos ahora se post-entrenan con sus arneses en el bucle — como señala LangChain en su discusión sobre arquitectura de arneses de agentes, productos como Claude Code y Codex combinan el entrenamiento del modelo y el diseño del arnés en un ciclo de retroalimentación — lo que significa que el arnés ya no es un wrapper intercambiable sino una parte co-evolucionada de la superficie del producto. La implicación para los desarrolladores es que el arnés se está convirtiendo en parte del producto que diseñas, no en un adaptador genérico que puedes trasladar de un modelo a otro sin cambios.

Esto te ofrece una prueba clara de solidez a futuro, extraída de la metáfora del scaffolding: si tu diseño escala limpiamente con un modelo más potente — mismo arnés, mejores resultados — es sólido. Si necesita más scaffolding para compensar a medida que el modelo mejora, el arnés está enmascarando un problema de modelo o de tarea que deberías resolver en otro lugar. El scaffolding, como el de la construcción, está pensado para desmontarse cuando la estructura se sostiene por sí sola.

La próxima vez que tu funcionalidad de IA entre en bucle, olvide algo, o devuelva algo con confianza incorrecta, audita el arnés antes de auditar el modelo. Empieza con las cuatro decisiones anteriores — alcance de herramientas, estrategia de contexto, una verificación determinista y grosor — y añade la menor cantidad de estructura que haga que el fallo deje de repetirse.

Preguntas frecuentes

¿Cuál es la diferencia entre un arnés y un scaffold?

Los términos se usan indistintamente en la práctica; ambos se refieren a todo fragmento de código, configuración y lógica de ejecución que rodea al modelo y que no es el modelo en sí. 'Scaffold' es el término más común en la literatura de benchmarks, como en la comparación de CORE-Agent frente al scaffold de Claude Code en Princeton, mientras que 'arnés' se prefiere en contextos de producción y SDK. Vivek Trivedy de LangChain colapsa la distinción con la regla: si no eres el modelo, eres el arnés.

¿Debo devolver un error de herramienta al modelo o lanzarlo como excepción en mi arnés?

Devuelve el error al modelo como una observación en lugar de lanzarlo como excepción. Lanzar la excepción termina la ejecución; devolver el error como resultado de herramienta permite al modelo ver qué salió mal y autocorregirse en el siguiente turno. Esto importa porque los errores se acumulan en tareas de múltiples pasos, donde una tarea de 10 pasos con un 99% de éxito por paso cae a aproximadamente un 90% de extremo a extremo. Tanto los fallos de validación de esquema como las excepciones en tiempo de ejecución deben capturarse y devolverse como observaciones, nunca como excepciones no manejadas.

¿Añadir más herramientas mejora el rendimiento del agente?

No, añadir más herramientas degrada el rendimiento de forma consistente a partir de cierto punto. Cada esquema de herramienta consume tokens de la ventana de contexto y aumenta la probabilidad de una llamada a herramienta espuria o incorrecta. El equipo de v0 de Vercel eliminó el 80% de las herramientas de su agente y observó cómo el éxito en las tareas subió del 80% al 100% y el uso promedio de tokens cayó un 37% en el mismo modelo. La regla práctica es empezar con menos de 10 herramientas y expandir solo cuando aparezca una brecha real.

¿Puedo intercambiar modelos en el mismo arnés sin cambios?

Cada vez menos. Como señala LangChain en su discusión sobre arquitectura de arneses de agentes, productos como Claude Code y Codex combinan el entrenamiento del modelo y el diseño del arnés en un ciclo de retroalimentación. Esto convierte al arnés en una parte co-evolucionada de la superficie del producto en lugar de un adaptador genérico. Una prueba útil de solidez a futuro es si tu diseño escala limpiamente con un modelo más potente en el mismo arnés; si necesita más scaffolding para compensar a medida que el modelo mejora, el arnés está enmascarando un problema más profundo.