Qué es harness engineering (y por qué no alcanza con "un GPT con tools")
Dani instaló cinco MCPs y el agente brilló en la demo — pero se rompió en la tercera tarea real. El problema no era el modelo: era el harness.
Dani tiene Claude Code, le agregó cinco MCP servers y el agente hace cosas impresionantes en demo. En la tercera tarea real — leer un ticket, consultar Postgres y avisar por Slack — se cuelga, repite la misma query tres veces y manda un mensaje con datos de ayer. El modelo no es malo. Lo que falta es harness engineering: la capa de software que envuelve al LLM y decide cómo planifica, qué tools ve, qué recuerda y cuándo para.
El harness vs el modelo
Un GPT con tools no es un agente. Es un motor sin auto. El harness es todo lo demás: el loop que decide el siguiente paso, el catálogo de herramientas expuesto al modelo, la memoria entre turnos, los guardrails antes de ejecutar una acción destructiva y los skills que empaquetan procedimientos repetibles.
Anthropic lo resume bien: el modelo es el engine, el harness es el car. Podés cambiar de motor (Claude, GPT, DeepSeek) y seguir usando el mismo loop — de hecho hay proyectos que portan el loop de Claude Code a otros backends y el comportamiento se mantiene. Lo que cambia el resultado en producción no es tanto el modelo como cómo configuraste el entorno.
En el directorio MCP de Savante la anatomía de un agente muestra esas piezas: loop al centro, MCPs a un lado, skills al otro, memoria y verificación alrededor. Cada pieza responde una pregunta distinta. Si te falta una, el agente improvisa — y la improvisación en producción suele terminar en tokens quemados o datos incorrectos.
Las seis piezas del harness
Agent loop. Planificar → actuar → observar → repetir. Sin un loop explícito con condiciones de parada, el agente o se queda corto o entra en ciclos infinitos. Un loop bien diseñado define cuándo terminar, cuántos tokens gastar y qué hacer cuando una tool falla.
MCP servers. Son la conexión del agente al mundo: bases de datos, APIs, repos, browsers. El protocolo estandariza cómo se exponen tools y datos. En Savante buscás por intención — agente que lee tickets y consulta una base de datos — no por Ctrl+F en un README de 200 entradas.
Skills. Procedimientos empaquetados (SKILL.md) que el agente carga cuando la tarea lo requiere. En Savante buscás por intención en el directorio de Agent Skills — mismo patrón que MCPs: describís la tarea y copiás npx skills add … sin salir del sitio.
Memoria y contexto. Ventana de contexto, RAG, checkpoints. Un agente que no recuerda qué hizo en el turno anterior repite trabajo o pierde estado. Los MCPs de knowledge-and-memory cubren parte de esto; el resto es diseño de sesión.
Verificación. Tests, permisos, human-in-the-loop. Antes de borrar un registro o mandar un mail a 500 personas, algo tiene que validar. La guía De prototipo a producción profundiza esto.
Tools (herramientas). Cada MCP expone funciones invocables. El agente elige cuáles usar según la tarea. Más tools no es mejor — cada tool ocupa contexto y aumenta la superficie de error.
Error común: confundir más tools con mejor agente
Instalar 40 MCPs porque “capaz alguno sirve” es el equivalente a darle a un dev acceso root a todo el monorepo. El modelo pierde tiempo eligiendo entre opciones redundantes, los schemas ocupan tokens y las tools abandonadas fallan silenciosamente.
Empezá con tres a cinco MCPs que cubran datos + acción + notificación para tu caso concreto. Probá el flujo end-to-end antes de agregar más. Si necesitás ayuda para filtrar, la siguiente guía — Cómo elegir MCP servers — tiene criterios prácticos.
Qué hacer ahora
- Abrí el directorio MCP o el directorio de Skills y describí tu agente en lenguaje natural — no busques por nombre de repo.
- Revisá la anatomía interactiva: clic en cada pieza para entender qué resuelve.
- Si ya tenés claro el stack MCP, usá el stack builder para combinar configs de Claude Code o Cursor.
El harness no se diseña una vez y listo. Cada componente asume que el modelo no puede hacer algo — y esas suposiciones caducan cuando el modelo mejora o cuando cambiás de proveedor. Por eso un catálogo vivo (con fecha de sincronización visible) y guías actualizables importan más que una lista estática de repos.
MCPs relacionados
Probalo
¿Querés que armemos el stack por vos?
Describí tu agente y te devolvemos MCPs + arquitectura + qué suele fallar en producción.
Ir al stack builder →