Por Devy · Categoría: AI Dev Tools — Open Source
Construir la primera versión de un agente es sorprendentemente fácil.
Elegís un modelo, le das un system prompt, conectás un par de tools y conseguís una demo que hace algo útil.
Después intentás ponerla detrás de una aplicación real.
Necesitás sesiones persistentes. Streaming. Manejo de contexto. Autorización para tools. Sandboxing para ejecutar código. MCP. Skills. Aprobaciones humanas. Estado. Recuperación cuando una ejecución falla. Una API para que tu producto pueda hablar con el agente. Quizás una UI. Y si mañana querés cambiar Claude por Gemini, OpenAI o un modelo servido detrás de un endpoint compatible con OpenAI, idealmente no querés reconstruir todo.
Ahí aparece el concepto de agent harness.
Y TrueForge, el nuevo proyecto MIT de TrueFoundry, intenta convertir toda esa infraestructura alrededor del modelo en una capa open source que puedas ejecutar vos mismo.
La tesis se puede resumir así:
modelo ≠ agente
modelo
+
execution loop
+
tools
+
context
+
sandbox
+
state
+
approvals
+
UI/API
=
agente utilizable
TrueForge quiere encargarse de casi todo lo que está debajo del primer término.
Primero: ¿qué es exactamente un agent harness?
Vale la pena aclararlo porque estamos usando la palabra cada vez más.
Un framework como LangChain, LangGraph o CrewAI te ayuda a construir la lógica de un sistema agentic.
Un harness se ocupa principalmente de ejecutarlo.
Pensalo como la diferencia entre escribir una función y operar un servicio alrededor de esa función.
TrueForge ejecuta el agent loop y administra model calls, tools MCP, Skills, sandboxing, approvals, context management y session state. Después expone el agente mediante una interfaz de chat, una HTTP API con SDK TypeScript o una UI que podés embeber dentro de tu propio producto.
La arquitectura mental queda mucho más limpia:
TU PRODUCTO
│
┌────────┴────────┐
│ │
API UI SDK
│ │
└───────┬─────────┘
│
TRUEFORGE
│
┌───────────┼────────────┐
│ │ │
MODELO TOOLS CONTEXT
│ │ │
OpenAI MCP sessions
Claude Skills compaction
Gemini sandbox subagents
OpenAI-
compatible
La aplicación no necesita conocer todos esos detalles.
Habla con el harness.
Y no te obliga a casarte con un modelo
Ésta es probablemente una de las características más importantes del proyecto.
TrueForge soporta OpenAI, Anthropic, Google Gemini, otros providers de su catálogo y endpoints compatibles con OpenAI.
Eso último abre la puerta a arquitecturas mucho más interesantes que:
mi aplicación → API de un único vendor
Podés construir:
mi aplicación
↓
TrueForge
↓
modelo elegido por nosotros
y mantener la capa operacional del agente relativamente estable aunque cambie lo que hay detrás.
Para equipos que quieren experimentar con modelos open weights servidos mediante infraestructura compatible con OpenAI, esto es especialmente atractivo.
El modelo pasa a ser una dependencia intercambiable.
El harness permanece.
Cómo probar TrueForge en cinco minutos
El modo local es deliberadamente simple.
Necesitás Node.js y podés arrancar directamente con:
npx @truefoundry/trueforge
TrueForge levanta todo en un único proceso y utiliza SQLite para almacenar los datos localmente. No requiere Redis ni PostgreSQL para empezar.
Es exactamente el modo que usaría para evaluar el proyecto.
Pero hay una advertencia importante de los propios maintainers: local mode no es un deployment de producción.
No tiene login habilitado por defecto y la información vive en un archivo SQLite local. La documentación pide explícitamente mantenerlo en localhost.
La progresión prevista es:
probar
npx @truefoundry/trueforge
↓
SQLite
producción
TrueForge
↓
PostgreSQL + Redis
↓
Docker Compose / Helm
Para equipos o múltiples réplicas, TrueForge ofrece hosted mode con PostgreSQL y Redis y puede desplegarse mediante Docker Compose o Helm.
Esto es una buena decisión de diseño: no necesitás desplegar media plataforma para descubrir si te gusta.
Después conectás el modelo
TrueForge trabaja con catálogos de recursos.
Configurás una vez los modelos disponibles y después los agentes seleccionan entre esos recursos.
Lo mismo ocurre con:
models
MCP servers
Skills
sandboxes
Los presets vienen definidos mediante catálogos YAML que pueden personalizarse.
La diferencia parece menor, pero se vuelve importante cuando tenés más de un agente.
En vez de que cada aplicación tenga:
OPENAI_API_KEY=...
ANTHROPIC_API_KEY=...
MCP_GITHUB_TOKEN=...
MCP_DATABASE_TOKEN=...
la intención arquitectónica es que el harness conozca los recursos disponibles y el agente los referencie.
Eso separa mejor:
qué necesita el agente
de:
cómo está autenticado ese recurso
TrueForge además puede funcionar standalone; conectarlo al AI Gateway de TrueFoundry añade una capa adicional de acceso gobernado a modelos, MCPs y Skills, pero el gateway no es requisito para utilizar el proyecto open source.
MCP deja de ser algo que cada agente implementa por su cuenta
TrueForge puede conectarse con servidores MCP remotos usando autenticación mediante headers u OAuth.
Y hay un detalle especialmente útil: soporta autorización dentro del propio chat.
Imaginemos un agente interno para soporte técnico.
Puede consultar:
GitHub
Jira
PostgreSQL
logs
documentación interna
No querés necesariamente darle acceso permanente e invisible a todo eso.
El harness puede interponerse:
agente
↓
quiere ejecutar tool
↓
¿requiere aprobación?
↓
humano aprueba
↓
ejecución
Ese checkpoint humano es uno de los componentes que suele desaparecer en las demos de agentes y reaparecer rápidamente cuando Seguridad pregunta cómo funciona realmente el sistema.
TrueForge incluye tool approvals, preguntas al usuario y elementos de Generative UI dentro de la conversación.
Skills también son ciudadanos de primera clase
TrueForge soporta Skills respaldadas por Git y estructuradas alrededor de SKILL.md.
En vez de cargar permanentemente todo el conocimiento procedural dentro del prompt, las Skills pueden recuperarse cuando hacen falta y cargarse dentro del sandbox.
Esto permite separar:
AGENTE
instrucciones base
│
├── skill: investigar incidente
├── skill: revisar PR
├── skill: generar reporte
└── skill: desplegar staging
del contexto que necesita una ejecución concreta.
Es una distinción importante.
Un agente con veinte procedimientos no debería necesariamente cargar los veinte procedimientos en cada request.
El sandbox no está corriendo todo el tiempo
Acá TrueForge toma una decisión arquitectónica que también tiene consecuencias económicas.
El sandbox se trata como una tool.
Si el agente necesita ejecutar código o manipular archivos en un entorno aislado, TrueForge provisiona el sandbox. Si no lo necesita, no tiene por qué existir durante toda la sesión. Actualmente el proveedor documentado es Daytona, con más providers previstos.
Eso produce algo así:
usuario pregunta algo
↓
agente razona
↓
¿necesita ejecutar código?
│
no │ sí
│ ↓
│ sandbox
│ ↓
│ ejecución aislada
│
└────→ respuesta
En lugar de:
crear sandbox
↓
mantener sandbox
↓
quizás usarlo
Es uno de los mecanismos que TrueFoundry señala al explicar por qué intenta reducir el costo total de ejecución.
Pero la parte más interesante probablemente sea el context engineering
Un agente que corre durante dos minutos tiene un problema distinto de uno que trabaja durante cuarenta.
El segundo acumula:
- respuestas de tools;
- archivos;
- resultados de búsquedas;
- logs;
- razonamiento operacional;
- instrucciones;
- errores;
- resultados intermedios.
Si simplemente enviás todo nuevamente al modelo en cada turno, el contexto crece y la factura crece con él.
TrueForge incorpora varias estrategias para evitarlo:
subagents, deferred tool loading, Code Mode, large-result offloading y compaction.
La idea común es bastante sencilla:
no todo lo que el agente produjo necesita permanecer dentro del contexto activo.
Por ejemplo, una tool puede devolver 50.000 líneas de logs.
El agente probablemente necesita cinco.
Mandar las otras 49.995 de vuelta al modelo durante los próximos diez turnos no mejora necesariamente el resultado.
Sí aumenta el consumo.
Ese problema parece trivial hasta que multiplicás:
tokens innecesarios
×
turnos
×
agentes
×
usuarios
×
días
Y ahí context engineering deja de ser optimización prematura.
Se convierte en infraestructura.
El benchmark: hasta 75% menos, pero hay que leer bien la cifra
TrueFoundry está haciendo una afirmación bastante agresiva alrededor del costo.
En un benchmark propio de 14 tareas de estilo producción, la compañía reporta aproximadamente 30% menos costo usando el mismo modelo frente a Claude Managed Agents. Cambiando además a un modelo abierto, reporta ahorros de hasta 75%, manteniendo la precisión en su evaluación.
La distinción importa.
No significa:
TrueForge hace cualquier agente 75% más barato.
Hay dos comparaciones diferentes:
mismo modelo
→ ~30% menor costo reportado
modelo alternativo/open
→ hasta ~75% menor costo reportado
Y los resultados provienen de TrueFoundry, no de una evaluación independiente.
La buena noticia es que el proyecto incluye el directorio benchmark/ para reproducir las pruebas.
Más interesante que el porcentaje concreto es la métrica que están intentando optimizar:
costo por tarea terminada.
Porque comparar modelos únicamente por precio de tokens puede ser engañoso.
Un modelo que cuesta la mitad pero necesita tres veces más tool calls no necesariamente es más barato.
La métrica útil es:
costo total
──────────────────────────
tarea completada
Ahí entran modelo, tokens, contexto, tools, sandboxes, retries y duración de la ejecución.
Caso de uso 1: un agente dentro de tu propio SaaS
Éste me parece uno de los escenarios donde TrueForge tiene más sentido.
Supongamos que tenés una aplicación de documentación y colaboración y querés incorporar un agente capaz de:
buscar documentos
resumir proyectos
crear contenido
consultar sistemas internos
ejecutar workflows
Podrías construir todo directamente dentro de tu backend.
Pero rápidamente terminás implementando:
session store
LLM client
streaming
tool registry
MCP client
approval state
sandbox
context compaction
retry logic
UI events
Con TrueForge la arquitectura puede quedar:
TU SaaS
│
TypeScript SDK
│
TrueForge
┌──────┼──────┐
│ │ │
modelo MCP Skills
│
servicios internos
Tu producto se concentra en qué debe hacer el agente.
El harness se concentra en cómo ejecutar un agente de forma consistente.
Y si no querés construir toda la experiencia visual desde cero, podés usar @truefoundry/trueforge-ui para embeber la interfaz. El proyecto también expone @truefoundry/trueforge-sdk para trabajar programáticamente con sesiones, turnos y eventos.
Para un equipo que quiere agregar agentes a un producto existente, probablemente éste sea el caso de uso más convincente.
Caso de uso 2: agentes internos con herramientas sensibles
Ahora imaginemos un agente para Platform Engineering.
Tiene acceso a:
GitHub
Kubernetes
Datadog
Jira
AWS
documentación interna
El modelo por sí solo no es el problema difícil.
El problema es:
¿qué puede hacer?
Podrías definir un agente donde:
leer logs
→ automático
buscar documentación
→ automático
consultar Jira
→ automático
modificar infraestructura
→ aprobación humana
ejecutar script
→ sandbox
hacer deployment
→ aprobación humana
Ahí el valor del harness no es “hacer más inteligente al modelo”.
Es crear una frontera operacional alrededor de su inteligencia.
Y ésa probablemente sea una de las funciones más importantes que tendrá esta categoría.
Caso de uso 3: experimentar con modelos sin reescribir tu producto
Hay otro escenario menos espectacular pero tremendamente práctico.
Hoy construís con Claude.
Dentro de tres meses aparece un modelo open weight que funciona suficientemente bien para el 80% de tus workloads.
Si toda tu aplicación está construida alrededor de una API específica:
producto → Anthropic SDK → tools → state → UI
migrar puede ser doloroso.
Si la arquitectura es:
producto
↓
harness
↓
provider
la decisión de modelo queda mucho más aislada.
TrueForge soporta providers comerciales y endpoints OpenAI-compatible, por lo que el harness puede funcionar como esa capa de desacoplamiento.
Eso no elimina completamente el lock-in —los modelos tienen capacidades y comportamientos distintos—, pero lo reduce a un lugar mucho más manejable de la arquitectura.
Lo que TrueForge no es
También conviene poner límites.
TrueForge no es otro modelo.
No es un replacement de Claude Code.
No es un framework de multi-agent prompting al estilo CrewAI.
Y tampoco significa que instalarlo convierta automáticamente una demo en un sistema production-ready.
La propia documentación hace una separación explícita entre:
local mode
para probar, y:
hosted mode
para equipos y deployments compartidos.
Para producción todavía necesitás tomar decisiones reales sobre:
- autenticación;
- autorización;
- observabilidad;
- disponibilidad;
- secretos;
- networking;
- backups;
- modelos;
- MCP servers;
- políticas de tools;
- lifecycle de sandboxes.
TrueForge te entrega primitives para buena parte de ese trabajo.
No toma todas esas decisiones por vos.
La señal importante: el modelo está dejando de ser el producto entero
Durante mucho tiempo hablamos de aplicaciones de IA como si la arquitectura fuera:
producto
↓
LLM API
Los agentes hicieron evidente que faltaba casi todo el medio.
Ahora la arquitectura se parece más a:
PRODUCTO
↓
AGENT HARNESS
↓
┌──────────────────────────┐
│ model routing │
│ context engineering │
│ sessions │
│ tools / MCP │
│ Skills │
│ sandbox │
│ approvals │
│ state │
│ streaming │
│ observability │
└──────────────────────────┘
↓
MODELOS + SISTEMAS REALES
Y ésa es probablemente la razón por la que estamos viendo aparecer tantos harnesses ahora.
Los modelos ya son suficientemente capaces como para construir agentes útiles.
El problema se desplazó.
La pregunta dejó de ser solamente:
¿qué modelo uso?
Ahora también es:
¿qué infraestructura pongo alrededor para dejarlo trabajar sin que mi aplicación tenga que reinventar un runtime completo?
TrueForge es una respuesta bastante ambiciosa: MIT, vendor-neutral, ejecutable localmente, desplegable con infraestructura convencional y diseñado para que modelos, MCP servers, Skills y sandboxes sean recursos conectables en lugar de decisiones incrustadas dentro de cada aplicación.
Para probarlo, el costo de entrada es prácticamente un comando:
npx @truefoundry/trueforge
Y ésa probablemente sea la mejor manera de evaluar si esta categoría tiene sentido para tu stack: no empezar construyendo un agente nuevo, sino tomar uno que ya tengas y calcular cuánto código alrededor del modelo podrías dejar de mantener vos mismo.