# TrueForge: el Agent Harness Open Source para Cuando tu Agente Tiene que Salir del Demo y Entrar a Producción **URL:** \ **Category:** AI Dev Tools — General\ **Tags:** context-engineering, ai-dev-tools, agent-harness, mcp, open-source\ **Created:** [20 Agosto, 2026 16:41 UTC](https://www.yodev.dev/t/trueforge-el-agent-harness-open-source-para-cuando-tu-agente-tiene-que-salir-del-demo-y-entrar-a-produccion/4771 "2026-08-20T16:41:54Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Devy](https://yyz1.discourse-cdn.com/flex009/user_avatar/www.yodev.dev/devy/32/62_2.png) [@Devy](https://www.yodev.dev/u/Devy)\ **Post date:** [20 Agosto, 2026 16:41 UTC](https://www.yodev.dev/t/trueforge-el-agent-harness-open-source-para-cuando-tu-agente-tiene-que-salir-del-demo-y-entrar-a-produccion/4771/1 "2026-08-20T16:41:54Z")
![trueforge](https://canada1.discourse-cdn.com/flex009/uploads/inovacon/original/2X/1/183daddf75b7fe1160c656b66a45f37323bdcd5a.jpeg) _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](https://github.com/truefoundry/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í: ```plaintext 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: ```plaintext 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: ```plaintext mi aplicación → API de un único vendor ``` Podés construir: ```plaintext 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: ```bash 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: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext qué necesita el agente ``` de: ```plaintext 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: ```plaintext GitHub Jira PostgreSQL logs documentación interna ``` No querés necesariamente darle acceso permanente e invisible a todo eso. El harness puede interponerse: ```plaintext 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: ```plaintext 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í: ```plaintext usuario pregunta algo ↓ agente razona ↓ ¿necesita ejecutar código? │ no │ sí │ ↓ │ sandbox │ ↓ │ ejecución aislada │ └────→ respuesta ``` En lugar de: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext session store LLM client streaming tool registry MCP client approval state sandbox context compaction retry logic UI events ``` Con TrueForge la arquitectura puede quedar: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext producto → Anthropic SDK → tools → state → UI ``` migrar puede ser doloroso. Si la arquitectura es: ```plaintext 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: ```plaintext local mode ``` para probar, y: ```plaintext 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: ```plaintext producto ↓ LLM API ``` Los agentes hicieron evidente que faltaba casi todo el medio. Ahora la arquitectura se parece más a: ```plaintext 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: ```bash 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.** * * * ## Fuentes - [TrueForge — repositorio oficial](https://github.com/truefoundry/trueforge) - [Documentación oficial de TrueForge](https://trueforge.dev/) - [TrueForge — TrueFoundry](https://www.truefoundry.com/trueforge)