El harness es el producto: una guía práctica sobre los harnesses en la IA agente.

Imagínese dar el mismo modelo de lenguaje a dos equipos diferentes. El equipo A crea un agente que repara errores en un enorme repositorio, ejecuta el conjunto de pruebas y envía una solicitud de integración bien organizada. El equipo B desarrolla un asistente de chat que pierde el hilo de la conversación después de unos pocos mensajes y, sin problemas, inventa políticas de la empresa. Las ponderaciones son idénticas, pero los resultados son completamente distintos.

El “arnés” es todo lo que se construye alrededor del modelo: incluye el bucle que permite que el modelo actúe, las herramientas que puede utilizar, la forma en que se gestiona su ventana de contexto, las medidas de seguridad que evitan que haga algo insensato y la retroalimentación que indica si está teniendo éxito. Lo que sigue parte de cero, explica qué es un agente y aborda las partes que componen el arnés, los patrones de producción como los subagentes y la compactación, algunos sistemas bien conocidos y los frameworks disponibles hoy en día. No se requiere experiencia previa con agentes.

Los conceptos básicos

Qué significa la IA agente

Sin exageraciones, un agente es simple:

Un agente es un modelo de lenguaje que funciona en un bucle, utilizando herramientas, hasta alcanzar un objetivo.

Esto requiere tres ingredientes: un modelo que pueda razonar y elegir el siguiente paso, herramientas que el modelo puede utilizar, como búsquedas en la web, acceso a archivos, ejecución de código, búsquedas en bases de datos o envío de correos, y un bucle que devuelva el resultado de cada herramienta para que el modelo pueda decidir qué hacer a continuación.

Un chatbot responde una vez y se detiene. Un agente, en cambio, continúa: realiza una acción, observa el resultado y luego realiza otra. Este ciclo es lo que permite a un predictor de texto llevar a cabo tareas reales, y el resto de este texto lo explica en mayor detalle.

Qué es un harness

Imagínese el harness como el entorno de ejecución de ese bucle. El modelo elige qué debe suceder a continuación, mientras que el harness lo lleva a cabo y mantiene todo el proceso seguro, económico, visible y controlable. El nombre hace referencia a un conjunto de pruebas en software o a las bridas de un caballo: la potencia bruta necesita estructura para dirigirse hacia tareas útiles.

En términos concretos, el framework ejecuta las llamadas a herramientas que solicita el modelo, controla lo que ve el modelo en cada paso, aplica permisos, gestiona fallos, intentos repetidos y bucles infinitos, sigue el progreso y determina cuándo se ha completado la tarea o cuándo debe detenerse y pedir ayuda a un humano.

Una forma útil de imaginarlo es que el modelo no tiene memoria entre una intervención y otra. Cada vez que se le llama, comienza en blanco, lee el texto que se le proporciona y emite un único resultado. Todo lo demás, el script, los elementos auxiliares, el escenario y la red de seguridad, constituye el framework. Al reorganizar estos elementos, el mismo “actor” actúa de manera completamente diferente.

Por qué es importante el framework

Destacan tres razones prácticas.

Los avances del modelo convergen, mientras que los del entorno de desarrollo no lo hacen. Los modelos de vanguardia están cada vez más cerca en términos de capacidad bruta. En pruebas que miden la resolución de problemas reales en software, el mismo modelo puede obtener resultados notablemente diferentes dependiendo únicamente del entorno que lo rodea, gracias a herramientas, indicaciones y ciclos de retroalimentación más eficaces. En algún punto, el entorno de desarrollo se convierte en el factor diferenciador.

Las tareas largas amplifican los pequeños errores. Si un modelo es un 99 por ciento fiable en cada paso, una tarea de 50 pasos tiene éxito solo en aproximadamente el 60 por ciento de los casos, ya que 0,99 elevado a la potencia 50 es aproximadamente 0,605. La verificación, las repeticiones, los puntos de control y la corrección de rumbo son las herramientas del entorno de desarrollo que ayudan a combatir este efecto acumulativo. Ellas separan una demostración de un producto real.

La libertad necesita límites. Cualquier agente capaz de ejecutar comandos de shell, mover dinero o comunicarse con clientes debe tener límites de permisos, entornos aislados y registros de auditoría. Estos elementos forman parte del sistema de control, y el modelo no aporta ninguno de ellos.

Anatomía de un sistema de control

Los agentes de programación, de investigación y de soporte suelen compartir siete componentes. A continuación se presentan uno por uno.

1. La instrucción del sistema, las directrices básicas

En esta sección se le indica al agente su rol, sus limitaciones, sus normas de comportamiento y el propósito de cada herramienta. En los productos maduros, este texto abarca miles de palabras y se mantiene con el mismo cuidado que el código fuente, teniendo en cuenta el tono, la seguridad, cuándo hacer preguntas primero y cómo manejar instrucciones poco claras.

Un principiante podría escribir una sola línea indicando que el agente es un asistente de programación útil. En cambio, una instrucción de producción establece procedimientos: abrir un archivo antes de editarlo, preferir cambios pequeños, ejecutar pruebas después de cada edición, detenerse e informar tras dos intentos fallidos de prueba, y nunca subir directamente al branch principal, y luego continúa con muchas más reglas similares.

2. La capa de herramientas, las manos

Una herramienta es una función a la que se le permite al modelo hacer llamadas, definida por un nombre, una descripción y un esquema tipado para sus argumentos. El modelo solicita la llamada como salida estructurada, luego el mecanismo la ejecuta y envía el resultado de vuelta.

El diseño de herramientas es un oficio subestimado. Equivale al diseño de API para un usuario muy literal:

• Las descripciones funcionan como instrucciones. El modelo elige las herramientas a partir de sus descripciones, por lo que una descripción vaga conduce a la herramienta incorrecta.
• Unos pocos herramientas bien estructuradas son mejores que muchas que se superponen entre sí. La proliferación de herramientas confunde a los modelos de la misma manera que un menú de cuarenta opciones confunde a los comensales.
• Devuelve errores con los que el modelo pueda actuar. Un mensaje que indique que el archivo es de solo lectura y que se debe solicitar acceso primero es mejor que un rastro de errores sin formato.
• Mantén las herramientas peligrosas limitadas. Una herramienta que solo envía borradores previamente aprobados es mucho más segura que una que ejecuta código arbitrario.

Un avance importante en este ámbito es el Protocolo de Contexto del Modelo, que Anthropic hizo de código abierto a finales de 2024 y que ha sido adoptado por gran parte de la industria. Estándariza la forma en que los proveedores de herramientas las exponen a cualquier agente, funcionando como un conector universal: se escribe la integración una sola vez y se conecta a cualquier sistema.

3. Gestión de contexto, la memoria de trabajo

La ventana de contexto representa todo el mundo perceptual del modelo. Las ventanas suelen abarcar desde cientos de miles hasta un millón de tokens, lo cual parece enorme hasta que un agente ha leído cuarenta archivos y ejecutado sesenta comandos.

Elegir qué ve el modelo en cada paso es probablemente la herramienta más importante del sistema, y los especialistas ahora la denominan ingeniería de contexto, la cual ha reemplazado en gran medida a la ingeniería de prompts como habilidad central. Las técnicas van desde las simples hasta las sofisticadas: truncación (mantener solo los mensajes recientes o una parte de un archivo), recuperación (indexar la base de conocimientos y obtener únicamente lo necesario en ese momento) y compactación. Con la compactación, cuando la ventana está a punto de llenarse, el modelo escribe un resumen de la sesión; ese resumen reemplaza la transcripción original y el trabajo continúa. Así es como los agentes pueden mantenerse enfocados en tareas durante horas.

4. Memoria, el almacenamiento a largo plazo

El contexto dura una sesión, mientras que la memoria persiste. Por lo general, se utiliza una estructura en capas para ello:

• memoria del proyecto, como los archivos de instrucciones en un repositorio que enseñan a un agente de programación tus convenciones y comandos de construcción, y que se leen al inicio de la sesión,
• memoria del usuario, es decir, las preferencias adquiridas a lo largo de las conversaciones,
• memoria episódica, que guarda registros de ejecuciones anteriores, a menudo en un almacén vectorial, para poder recuperarlos cuando surjan situaciones similares.

5. Límites, permisos y aislamiento, los frenos

La capa de seguridad pregunta continuamente si realmente se debe ejecutar una acción. En la práctica, eso significa:

• Niveles de permisos. Las lecturas se realizan libremente, las escrituras pasan por verificaciones de política, y las acciones irreversibles como desplegar, enviar, eliminar o pagar requieren la aprobación explícita de un humano.
• Aislamiento en entorno de pruebas. El código se ejecuta dentro de contenedores aislados con límites estrictos en cuanto a archivos y red, de modo que un agente que esté confundido o haya sido secuestrado por texto inyectado no pueda dañar la máquina anfitriona.
• Filtrado. Los resultados de la herramienta se analizan en busca de intentos de inyección y de datos que revelen secretos filtrados.
• Límites estrictos de recursos. Los límites de iteraciones y gastos evitan que las ejecuciones se salgan de control. La mayoría de las plataformas de producción tienen una explicación sobre por qué existen estos límites, ya que nadie los establece de forma proactiva.

6. Verificación y retroalimentación, los ojos

Nada mejora a un agente de manera más fiable que una forma de probar sus propios resultados. Los agentes de programación compilan, verifican la sintaxis y ejecutan pruebas después de cada edición. Los agentes de investigación comparan las afirmaciones de varias fuentes. Los agentes de navegador capturan la pantalla para ver qué se cargó realmente. Algunos sistemas añaden un revisor, un segundo modelo que evalúa la respuesta del primer modelo según un criterio antes de que sea aceptada.

Esto aborda directamente el problema del error compuesto. Un agente que puede darse cuenta de que ha fallado puede intentarlo de nuevo, mientras que uno que no puede hacerlo entregará confiadamente información inútil.

7. Observabilidad, el registrador de vuelo

En producción, se registra cada solicitud de modelo, cada llamada a una herramienta y cada token utilizado. Con esas pistas se puede reproducir una ejecución fallida, localizar el paso que salió mal y corregir el prompt, la herramienta o la política responsable del problema. Alrededor de esto surgió toda una categoría de productos, como LangSmith, Langfuse, Braintrust y las convenciones de OpenTelemetry para la IA generativa, ya que depurar un agente sin información es tan difícil como depurar servicios distribuidos sin registros.

Ejecutar el ciclo correctamente

Asignar nombres a las partes es lo sencillo. La diferencia entre un sistema que resiste una demostración y uno que funciona bien en un día normal radica en las prácticas que se describen a continuación.

Planificar, actuar, verificar

Los agentes simples intervienen de inmediato. Los sistemas más avanzados imponen un ritmo: se elabora un plan dividiendo el objetivo en una lista de tareas, se dan pasos pequeños, se verifica cada resultado antes de continuar, y luego se revisa el plan para intentarlo de nuevo. El plan escrito cumple dos funciones: mantiene al modelo enfocado en tareas a largo plazo porque se vuelve a leer en cada turno, y permite a quien lo observa ver el progreso en tiempo real, lo cual resulta más valioso de lo esperado.

Salidas estructuradas

Cada vez que un programa vaya a utilizar la salida del modelo, hay que restringirla mediante un esquema. Las API actuales permiten llamadas forzadas a herramientas y generación validada con esquemas. La prosa está destinada a las personas; el código debe tener estructura.

Costo y latencia

Los agentes consumen rápidamente los tokens, lo que convierte a la economía de recursos en un problema importante. Al almacenar en caché el gran prefijo estático (la instrucción del sistema más las definiciones de herramientas) entre turnos, el costo es mucho menor que enviarlo de nuevo, lo cual representa una gran ventaja en sesiones largas. La ruta de procesamiento envía los pasos rutinarios a un modelo pequeño y rápido, reservando un modelo avanzado para los pasos que requieren razonamiento. Las subtareas independientes, como leer diez archivos o verificar cinco fuentes, pueden ejecutarse simultáneamente.

Sistemas multiagente y más allá

Subagentes y orquestación

Cuando las tareas superan el límite de una ventana de contexto, los sistemas pasan a ser multiagente. Un orquestador divide el objetivo y crea subagentes, cada uno con un contexto nuevo, a menudo un conjunto de herramientas más reducido y una instrucción específica. Cada subagente realiza su trabajo y solo devuelve su conclusión, no toda su historia de procesamiento.

La verdadera ventaja es menos evidente que la velocidad: cada subagente funciona en su propio contexto aislado, y no simplemente de forma paralela. Diez subagentes pueden llenar cada uno una ventana completa con un subsistema, mientras que el orquestador solo conserva diez resúmenes breves.

Las topologías más comunes incluyen el orquestador y los trabajadores (de lejos las más frecuentes), pipelines como boceto, crítica y revisión, y paneles de debate en los que varios agentes abordan un problema de forma independiente y un juez sintetiza las respuestas. El debate es costoso, pero es adecuado para preguntas de alto riesgo.

Los equipos que elaboraron este informe obtuvieron algunas lecciones valiosas:

• Indique el nivel de esfuerzo esperado para cada tarea; de lo contrario, incluso una pregunta trivial puede provocar docenas de búsquedas.
• Redacte instrucciones detalladas y autónomas, ya que un subagente no puede ver el contexto del agente principal.

Aíslen los espacios de trabajo desde temprano, ya que eventualmente ocurrirá que dos agentes editen el mismo archivo.

Puntos de control y durabilidad

Los agentes que ejecutan tareas durante mucho tiempo fallan debido a caídas, límites de velocidad y reinicios. Los entornos de producción utilizan puntos de control que registran la conversación, la lista de tareas y los resultados de las herramientas, de modo que la ejecución pueda reanudarse desde el paso 37 en lugar de comenzar de nuevo. Este es el ámbito de los motores de flujos de trabajo duraderos, y varios marcos de trabajo para agentes se construyen directamente sobre dicha infraestructura.

Evals, el conjunto de pruebas del entorno

El comportamiento de los agentes es probabilístico, por lo que una instrucción que funciona el lunes puede fallar el martes. Los equipos sólidos mantienen un conjunto de pruebas que incluye desde decenas hasta miles de tareas realistas cuyos resultados se pueden verificar automáticamente. ¿Pasaron las pruebas? ¿Se encontró la respuesta correcta? ¿Se mantuvo el costo dentro del presupuesto? Las modificaciones en las instrucciones, las herramientas nuevas y los cambios de modelo se prueban todos a través de este conjunto antes del lanzamiento. Desempeña el papel que cumple CI/CD en otros contextos, y omitirlo significa trabajar sin instrumentos adecuados.

El uso de computadoras, el examen final

En la vanguardia, a los agentes se les proporciona una pantalla, un teclado y un ratón, y pueden ejecutar cualquier aplicación, tenga o no una API. Esto aumenta la dificultad de todos los problemas anteriores: las capturas de pantalla consumen una enorme cantidad de tokens, por lo que el control del contexto debe ser estricto; un clic incorrecto puede causar daños reales, así que las permisos se vuelven más estrictos; y la verificación implica visualizar realmente la pantalla después de cada paso.

Cómo aplican estos conceptos los sistemas conocidos

Claude Code, un entorno de programación. Es una lección compacta sobre diseño. El conjunto de herramientas es pequeño pero eficaz, con funciones de lectura, escritura y edición de archivos, comandos de shell y búsqueda de código, en lugar de cientos de microherramientas. La verificación es fundamental: ejecuta compiladores, analizadores y pruebas, e itera cuando estas fallan. Un archivo de instrucciones del proyecto funciona como memoria. Nada de esto constituye una capacidad del modelo, y por eso el mismo modelo se siente diferente al usarlo.

Productos de investigación profunda, un arnés de investigación. Las herramientas de investigación de los grandes laboratorios convierten una consulta en una investigación autónoma que dura varios minutos y que finaliza con un informe citado. Su característica distintiva es un plan de investigación elaborado de antemano, a veces presentado para su aprobación, lo que permite involucrar al humano en el proceso en el momento más económico, antes del trabajo costoso. Los ciclos de búsqueda leen, detectan lagunas y vuelven a buscar, y los metadatos de las citaciones viajan junto con los hechos a lo largo del proceso.

Manus y la escuela de ingeniería de contexto. El equipo de Manus publicó notas excepcionalmente francas sobre los detalles internos de Harness alrededor de su lanzamiento en 2025, y varios puntos se difundieron ampliamente. Considere la caché KV como una restricción de diseño: mantenga estable el inicio del prompt (sin marca de tiempo al principio del prompt del sistema), ya que los tokens de entrada pueden superar en gran medida a los tokens de salida. Evite agregar o eliminar herramientas durante una sesión, ya que esto invalida la caché y confunde al modelo cuando las llamadas anteriores mencionan herramientas desaparecidas; mantenga la lista fija y oculte aquello que actualmente se puede elegir.

Cursor y el entorno del IDE. El editor nativo para IA presenta una filosofía distinta de integración profunda con el entorno. Utiliza el índice semántico del editor sobre la base de código para una recuperación rápida, guarda los cambios como diferencias revisables para que quien aprueba la fusión sea el modelo de permisos disfrazado de interfaz, ejecuta agentes en segundo plano en ramas separadas y vuelve a introducir los resultados del analizador de estilo y del verificador de tipos en el ciclo de trabajo. Los mismos siete componentes aparecen con una presentación diferente.

Agentes de soporte en empresas, donde el enfoque principal es el cumplimiento normativo. Los agentes que interactúan con los clientes cambian las prioridades: evitar una acción incorrecta es más importante que la capacidad bruta. Por lo tanto, parten de medidas de control: el alcance se limita al conocimiento aprobado, las acciones se verifican contra los esquemas del sistema empresarial (reembolsos limitados, confirmación previa de la identidad), se requiere la transferencia obligatoria de tareas a otros cuando la confianza es baja y se mantienen registros de auditoría completos. En sectores regulados, este conjunto de herramientas funciona efectivamente como el producto en sí.

Marco de trabajo y herramientas disponibles actualmente

Rara vez se construyen estos conjuntos de herramientas a partir únicamente de llamadas a API. A continuación se presentan opciones comunes, agrupadas de forma aproximada según su filosofía:

• Claude Agent SDK. El conjunto de herramientas detrás de Claude Code, expuesto como una biblioteca que incluye bucles, herramientas, subagentes, permisos y funcionalidades de compresión. Es la mejor opción para crear agentes avanzados rápidamente en Claude.
• OpenAI Agents SDK. Primitivas ligeras para agentes, transferencias de control, restricciones, sesiones y seguimiento. Ideal para aplicaciones multiagente en el ecosistema de OpenAI.
• LangGraph. Agentes como máquinas de estado explícitas, con guardado de puntos de control, interrupciones con intervención humana y ejecución duradera. Perfecto para flujos de trabajo complejos, controlables y de larga duración.
• CrewAI. Equipos basados en roles como investigadores y redactores. Óptimo para prototipos multiagente rápidos y pipelines de contenido.
• AutoGen, AG2 y Semantic Kernel. Herramientas multiagente centradas en la conversación que convergen en soluciones empresariales. Adecuado para entornos .NET y Azure, así como para experimentos de investigación.
• smolagents. Una biblioteca minimalista donde los agentes escriben código como sus acciones. Ideal para desarrollos modificables con modelos abiertos.
• Pydantic AI. Agentes seguros desde el punto de vista tipológico y basados en esquemas, con resultados validados. Ideal para equipos de Python que buscan tipado estricto.
• Vercel AI SDK. Primitivas basadas en TypeScript, con control del bucle de agentes. Mejor opción para ingenieros web y de productos en el ecosistema JavaScript.

Alrededor de estos elementos se encuentra el tejido conectivo: MCP para herramientas estándar, plataformas de seguimiento y evaluación, motores de ejecución duraderos y proveedores de entornos aislados para una ejecución segura del código.

Consejo para elegir: al aprender, escribe tú mismo el bucle básico una vez, utilizando una API de modelo, un bucle while y dos herramientas, en aproximadamente cien líneas. Después de eso, ningún framework parecerá mágico, y ese es precisamente el objetivo. Al lanzar el producto, elige el framework más cercano a tu proveedor de modelos y a tu lenguaje, y dedica el tiempo ahorrado a lo que ningún framework puede ofrecerte, es decir, tus herramientas, tus evaluaciones y tus medidas de seguridad.

# The whole idea, in miniature
while not done:
    response = model.generate(context, tools)      # model decides
    if response.tool_calls:
        results = execute(response.tool_calls)     # harness acts (safely!)
        context = manage(context + results)        # harness curates memory
    else:
        done = verify(response)                    # harness checks the work

Modos de fallo

A continuación se presentan las formas típicas en que fallan los agentes, cada una acompañada de una solución correspondiente:

• Decadencia del contexto. La ventana se llena gradualmente de resultados obsoletos de las herramientas y la calidad disminuye hasta que, después de unas horas, se olvida el objetivo. Solución: compactación, registro de notas y reafirmación periódica del objetivo.
• Bucles sin fin. La misma orden defectuosa se repite eternamente, costando unos pocos centavos por intento. Solución: detección de bucles, límites de iteraciones y cambios forzados de estrategia.
• Descontrol de herramientas. Con cuarenta herramientas similares, el modelo elige la incorrecta en el peor momento. Solución: un conjunto más reducido de herramientas más eficaces con descripciones claras.
• Inyección de comandos. El texto en una página web o en un correo electrónico indica al agente que ignore sus instrucciones y descargue una base de datos; como el agente no puede separar inherentemente los datos de los comandos, podría acceder a esa solicitud. Solución: filtrado de entradas, herramientas con mínimo privilegio, entornos aislados y aprobación humana para acciones de gran impacto, ya que ninguna defensa por sí sola es fiable.
• Fin falso. El agente anuncia que ha completado la tarea cuando en realidad aún no está terminada. Solución: verificar los resultados con un método independiente y no permitir que el agente evalúe su propio trabajo.
• Gasto descontrolado. Una distribución entre varios agentes puede hacer que la factura aumente silenciosamente muchas veces. Solución: presupuestos, enrutamiento, caché y una evaluación honesta sobre si un único agente capaz habría sido suficiente.
• Deriva silenciosa de las capacidades. La actualización del modelo altera su comportamiento, y los estímulos ajustados para la versión anterior dejan de funcionar. Solución: ejecutar el conjunto de pruebas de evaluación tras cada cambio.

Qué recordar

El modelo proporciona inteligencia, y el marco de trabajo la convierte en acción concreta. Un marco de trabajo consta de un ciclo más siete componentes: instrucciones establecidas, herramientas, gestión de contexto, memoria, medidas de seguridad, verificación y capacidad de observación. Alrededor de estos se encuentran patrones para ejecutar tareas prolongadas, como planificar, actuar y verificar, compactación, puntos de control, subagentes y pruebas de evaluación. La mayoría de los fallos de los agentes se deben a problemas en su marco de trabajo, y la mayoría de las mejoras en ellos provienen de mejoras en dicho marco. Por lo tanto, cuando un agente no rinde como debería, primero examine su estructura de soporte y luego cambie el modelo.

Leer más

• Subagentes en la práctica: roles, presupuestos, prohibiciones y fallos silenciosos — Cómo crear subagentes para Claude Code que duren: roles, archivos de transferencia, estado de ejecución, presupuestos, prohibiciones, verificaciones de fallos silenciosos y un complemento para Copilot, basado en agentes utilizados en una docena de repositorios.
• El análisis agenético es más que texto a SQL: lecciones de Anthropic — Qué indica el artículo de Anthropic sobre análisis de autoservicio acerca de las capas semánticas, habilidades, evaluaciones y fundamentos de los datos, y por qué el texto a SQL por sí solo genera una falsa sensación de precisión.

D3.js dentro de React: Vinculación de datos, SVG y la regla de propiedad de useEffect — Aprenda qué es realmente D3, cómo funciona la vinculación de entrada/actualización/salida, por qué SVG es adecuado para él, y cómo dividir el control del DOM para que D3 y React colaboren en un gráfico de barras.