TrueForge Agent Harness: Practical Open-Source Guide

The short answer

TrueForge is an MIT-licensed, open-source agent harness from TrueFoundry. It runs the execution loop around a model: tool calls, MCP servers, skills, sandboxed code execution, approvals, context management, session state, and a user interface. The project is designed to run locally with SQLite or as a shared deployment with Postgres, Redis, Docker Compose, or Helm.

The practical reason to evaluate it is not that it replaces every agent framework. It occupies a different layer: instead of writing an orchestration library from scratch, you get a runtime that can take an agent from a local experiment toward a team deployment while keeping model and tool choices portable.

That portability comes with operational responsibility. TrueForge’s own repository warns that local mode is intended for a developer machine, not an internet-facing service. Teams still need to secure credentials, MCP servers, sandboxes, identity, network access, logs, and model endpoints.

What TrueForge adds around the model

A model can produce a plan, but it cannot safely perform a multi-step workflow without a runtime around it. The harness receives the plan, invokes tools, returns results to the model, manages context, pauses for approval when required, and persists the session.

TrueForge describes its runtime as three connected surfaces:

• A core server that runs the agent loop and manages sessions, approvals, context, and streaming events.
• An HTTP API with a TypeScript SDK for application integration.
• A bundled chat UI plus UI SDK for a ready-made or embeddable interface.

The repository also lists support for OpenAI, Anthropic, Google Gemini, and OpenAI-compatible endpoints; remote MCP servers with header authentication or OAuth; git-backed SKILL.md instruction packs; sandbox-as-a-tool execution; human checkpoints; generative UI; and local or hosted deployment modes.

Visual: the TrueForge request path

Architecture diagram based on TrueFoundry’s official product page and repository documentation. The diagram is an editorial reconstruction; it is not an official product screenshot. Sources: TrueForge product overview and TrueForge GitHub repository.

Local setup: the fastest evaluation path

The official launch article gives a one-command local start:

1npx @truefoundry/trueforge

The project’s README describes local mode as a single process using SQLite, with no extra infrastructure. That makes it useful for evaluating the interaction model, connecting a test model or MCP server, and learning how approvals and sessions behave.

Do not expose that default setup to the public internet. The repository explicitly says local mode has no login by default and is intended for localhost. If a team needs shared access, use the hosted deployment path and add identity, TLS, network restrictions, secret management, backups, and monitoring before onboarding real users or sensitive tools.

A sensible evaluation sequence is:

1. Start locally with synthetic data and a low-privilege model key.
2. Connect one read-only MCP server or mock tool.
3. Test a workflow that requires an approval checkpoint.
4. Inspect the event stream, tool arguments, returned data, and stored session state.
5. Move to hosted mode only after the threat model and data boundaries are documented.

Hosted architecture and migration boundary

TrueForge documents two broad modes:

The important design choice is that the harness can remain the same while infrastructure changes around it. The README describes Docker Compose or Helm for hosted operation, with Postgres and Redis and replicas behind a load balancer. That is a deployment pattern, not a turnkey security guarantee.

For a production migration, separate these concerns:

• Identity: configure OIDC or another trusted login boundary for shared access.
• Secrets: keep model, MCP, sandbox, and database credentials out of catalogs and source control.
• Tool permissions: start with read-only tools, then introduce narrowly scoped writes behind approvals.
• Data retention: define how long prompts, tool results, traces, and generated files remain available.
• Network placement: keep the server, database, Redis, and sandbox providers on controlled networks.
• Recovery: test Postgres backups, session recovery, and failure behavior rather than assuming persistence works because it is configured.

MCP, skills, and sandboxing

TrueForge is particularly relevant to teams already assembling agent systems from MCP servers and reusable skills. The repository says that MCP servers can be connected through header authentication or OAuth, while skills are git-backed SKILL.md instruction packs loaded on demand in the sandbox.

That creates a useful separation: the agent can select from configured resources, while the platform team can version the resources and review changes. It does not remove the need to treat instructions and tool metadata as security-sensitive. A malicious or overly broad skill can still steer an agent toward unsafe actions, and an MCP server can expose more authority than its description suggests.

The sandbox model is also worth understanding. TrueForge treats the sandbox as a tool and provisions it when the agent needs code or file execution, rather than running every turn inside a sandbox. That can reduce unnecessary compute, but the boundary must be tested. Confirm which credentials enter the sandbox, whether outbound network access is allowed, where generated files are stored, and how cleanup occurs after a run.

Visual: approval-first tool flow

Editorial request-flow diagram based on the official repository’s descriptions of human checkpoints, MCP tools, session state, and context management. Source: TrueForge README.

What the benchmark does—and does not—prove

TrueFoundry reports a benchmark using 14 DevRev Enterprise-Bench tasks across CRM, issue-tracking, and document systems. Its published comparison uses blind judging and reports roughly similar solved-task counts for TrueForge with GLM-5.2 and Claude Managed Agents with Opus 4.8, while claiming lower cost per run. The company’s product page summarizes the same direction as about 50% lower cost on the same model and up to 75% with an open model.

VentureBeat independently reported the launch and the company’s benchmark figures, including the reported $2.90 versus $11.80 comparison and the same-model $8.50 versus $11.80 comparison. That satisfies a publication-level cross-check for what TrueFoundry claims and what an independent outlet reported. It does not turn the figures into a universal production result.

Costs will vary with model pricing, prompt size, tool-result size, retries, latency, concurrency, sandbox usage, hosting, and the exact task distribution. Before adopting TrueForge for a cost-saving program, reproduce a representative workload with your own tools and policies. Measure at least:

TrueForge versus a library or managed runtime

TrueForge should not be evaluated as a direct replacement for every agent framework. A library such as LangGraph gives developers primitives and code-level control; a managed agent runtime reduces infrastructure work but may constrain model choice or deployment; a harness sits between those options by packaging a runtime, UI, APIs, tools, sessions, and deployment path.

The right question is not “Which harness has the best benchmark?” It is “Which layer should our team own, and which controls must remain centralized?”

Security checklist before production

Use this checklist before connecting write-capable tools or private data:

• Keep local mode bound to localhost during evaluation.
• Use separate development and production model and MCP credentials.
• Apply least privilege to every tool, skill, sandbox, and service account.
• Require explicit approval for deletion, payment, access changes, deployments, and external messaging.
• Validate tool arguments server-side; never rely on the model to enforce policy.
• Restrict sandbox filesystem and network access, and verify cleanup.
• Redact secrets and sensitive fields from traces and model-visible tool results.
• Pin and review skill revisions and MCP server changes.
• Add rate, budget, timeout, and concurrency limits.
• Test prompt-injection paths through documents, web results, tickets, and MCP responses.
• Keep an audit trail that links user, agent, model, tool call, approval, and result.
• Reproduce the failure path for rejected approvals, unavailable tools, expired OAuth, and model timeouts.

For broader design context, compare this runtime approach with harness engineering for AI coding agents, the OpenAI Agents SDK sandbox and harness model, the DeepSeek plugin-first harness, and MCP tool-server threat modeling.

Common evaluation mistakes

Treating the local command as a production deployment

The one-command start is excellent for a first test, but the README’s warning is explicit: local mode is not an internet-facing service. Do not put it behind a public reverse proxy without authentication and a real deployment design.

Comparing token totals without comparing outcomes

A harness that uses fewer tokens but misses a required CRM join or approval condition has not delivered a cheaper successful task. Grade end-to-end outcomes with a fixed rubric.

Assuming open source means centrally governed

The MIT runtime is portable, but standalone deployments still need their own RBAC, budgets, credential rotation, traces, and policy enforcement. TrueFoundry positions its AI Gateway as the optional governance plane for those controls.

Giving an agent too many tools at once

Large tool catalogs increase ambiguity and context overhead. Start with a small, reviewed set and load tools or skills only when the workflow needs them.

FAQ

Is TrueForge really open source?

TrueFoundry and the GitHub repository identify TrueForge as MIT-licensed. The repository is public and includes the runtime, deployment files, documentation, and security policy.

Can TrueForge use models other than TrueFoundry’s?

Yes. The official materials describe support for OpenAI, Anthropic, Google Gemini, and other providers through OpenAI-compatible interfaces. Model availability and configuration still depend on the endpoint and deployment you choose.

Does it require TrueFoundry’s AI Gateway?

No. The product materials state that TrueForge can run standalone. The gateway adds centralized access, budgets, RBAC, credentials, and tracing for teams that choose to use it.

Is the benchmark a guarantee of 50% or 75% savings?

No. Those are TrueFoundry-reported benchmark results, cross-checked by VentureBeat’s coverage. Your savings depend on workload, model, tool servers, context size, retries, and infrastructure.

Conclusion

TrueForge is worth a serious evaluation when a team wants an open agent runtime rather than another orchestration library or a fully managed, provider-specific execution environment. Its strongest proposition is the combination of model portability, MCP and skill integration, sandbox-as-a-tool execution, approvals, session state, and a path from local SQLite to hosted infrastructure.

The adoption decision should be verification-first: reproduce the workload, inspect the security boundary, test failure and approval paths, and measure cost per successful task. The open-source harness can make that experiment easier. It does not make production governance optional.

Sources and visual credits

• TrueFoundry: Introducing TrueForge — primary product announcement and architecture description.
• TrueForge official product page — capabilities, deployment positioning, and benchmark summary.
• TrueForge GitHub repository — MIT license, README, quickstart, deployment modes, security warning, and implementation surface.
• TrueFoundry benchmark write-up — company methodology and reported benchmark figures.
• VentureBeat independent coverage — independent reporting and source interview.
• Visual credits: Mermaid diagrams are original editorial reconstructions based on the official product page and GitHub README; no product screenshots or third-party images are reproduced.