TrueForge: The Open-Source Alternative to Anthropic's Agent Harness
TrueForge is an open-source, model-agnostic agent harness with sandboxing, code mode, and human-in-the-loop controls for production AI agents.
What is an agent harness, and how is it different from an agent loop?
An agent loop is the basic mechanism where a model requests a tool, you call it, feed the result back into the prompt, and repeat. You can write one in about 15 lines of Python. An agent harness is everything wrapped around that loop that makes it survive contact with a real production workload: context management, retries, sandboxed code execution, session state, and human approval gates. TrueForge, built by Two Foundry, is an open-source, MIT-licensed implementation of that harness layer, designed to work with any OpenAI-compatible model instead of locking you into one vendor’s API.
TL;DR
- A plain agent loop breaks down on real tasks because context windows fill up with replayed tool history, degrading the model’s reasoning as the signal-to-noise ratio drops.
- The harness layer adds retry logic, isolated sandboxes, human-in-the-loop approval, and aggressive context management, none of which exists in a basic tool-calling loop.
- TrueForge is an MIT-licensed, model-agnostic harness that ships these mechanisms natively: deferred tool schema loading, file offloading, code mode, sandboxing, sub-agents, and context compaction.
- It runs as a production server with an HTTP interface, dashboard, and SDK, not just a Python library, and it uses Daytona as its default sandbox provider.
- Because it isn’t tied to a single model vendor, TrueForge can connect to hosted APIs or local models, and its own data claims cost savings of up to 75% compared to managed cloud agent platforms.
- Human-in-the-loop gating lets you mark specific tools (like destructive infrastructure changes) as requiring explicit approval, while read-only tools run automatically.
- Every agent run is traced end to end, which the harness surfaces in its dashboard so you can debug failed tool calls or refine schemas after the fact.
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
Why does a simple agent loop break down in production?
Two things kill a bare-bones agent loop once you move past toy examples. The first is the context window. Models have no memory between calls, so every turn has to replay the full conversation history, including every prior tool call and its output. As that history grows, the ratio of useful signal to accumulated noise drops, and the model’s reasoning quality falls off with it. The longer an agent session runs, the worse it tends to perform, not better.
The second issue is everything outside the model’s control: an external API times out and something has to handle the retry, a user steps away for an hour and the session state needs somewhere to live, and a generated script needs a safe place to execute so that a model hallucinating a destructive command (like dropping a database table) doesn’t actually do it. None of this is part of the 15-line loop. It’s scaffolding that has to be built separately, and building it well is a much harder problem than writing the loop itself.
How does TrueForge manage context so agents don’t degrade over long sessions?
TrueForge attacks context bloat from several angles rather than relying on one fix.
Deferred schema loading. A typical MCP integration loads every connected server’s full tool schema into the prompt before the user even sends a message, burning thousands of tokens up front. TrueForge instead passes just the server names plus a handful of small “meta tools,” letting the model discover the actual schema on demand. This keeps the upfront token cost low, at the cost of a bit of added latency the first time a tool is used.
File offloading. When a tool call returns more data than needed, a naive setup dumps all of it into the model’s context and hopes the model figures out what matters. TrueForge streams the raw response to disk inside the sandbox instead, feeding the model only a small preview and a file path. The agent can then use bash-style tools to grep for exactly the data it needs, which keeps token costs down and keeps the signal clean.
Sub-agents and compaction. For tasks that stretch across many turns, TrueForge can spin off a dedicated sub-agent with its own fresh context window to do noisy research work, reporting back only a distilled answer to the main thread. Separately, once the context window hits a set token threshold, a background model summarizes older tool outputs and swaps them in for the raw history. That compaction step is explicitly lossy: you trade fine detail for headroom.
What is “code mode,” and why does it matter?
In a standard tool-calling setup, a model calls an API, waits for a full JSON response, reads it into context, and then decides on the next call, often just to extract a single number or pattern from that JSON. That wastes tokens and pushes the model into doing arithmetic or pattern-matching inside its own context, which it isn’t especially good at.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Code mode has the agent write a short script that runs inside the isolated sandbox instead. Any tool calls made inside that script get bridged back through the harness, so the sandbox never sees production API keys directly, only the final result comes back to the model. This cuts context usage and avoids forcing the model to do “mental math” it should be delegating to actual code execution.
How does TrueForge handle sandboxing and security?
A common shortcut in agent platforms is to package the entire agent, loop, secrets, and execution environment, into one Docker container. It works, but every session then holds a full container hostage even while idle, which is wasteful and expands the attack surface unnecessarily.
TrueForge instead keeps the core orchestration loop on the server and treats the execution environment as an ephemeral, on-demand tool. A sandbox spins up only when code actually needs to run and tears down immediately after. Because the loop and its secrets stay outside the sandbox, production credentials are never exposed to the code execution environment. By default, TrueForge uses Daytona for sandboxing, and you supply your own API key to connect it.
What does building and deploying an agent in TrueForge actually look like?
TrueForge separates building from deploying. You build an agent through its UI by naming it, giving it instructions, and attaching tools, MCP servers for things like web search, custom internal APIs, or predefined “skills” you can import from GitHub. You choose the model per agent, which can be a hosted API model or a local model you’ve registered as a custom provider by pointing to its base URL.
Once an agent works the way you want in a test chat, you save it to an agent library and deploy it via the SDK or by calling the server’s HTTP API directly from your own application. A demonstrated example was an “on-call engineer” agent connected to a custom MCP server exposing infrastructure tools: checking deploys, reading metrics and logs, and applying fixes. Read-only tools ran automatically, but tools capable of destructive changes, like updating a live configuration, were gated behind human approval. When the agent proposed a fix, it surfaced the request in TrueForge’s dashboard and in the connecting application simultaneously, waiting for a human to approve before executing.
Is TrueForge worth using instead of a managed agent platform?
The main tradeoff is control versus convenience. Managed agent platforms from model vendors handle the harness for you but usually lock you into their models and cloud infrastructure. TrueForge gives up that convenience for openness: it’s MIT-licensed, works with any OpenAI-compatible API including self-hosted local models, and runs entirely on infrastructure you control. According to data cited by its maintainers, that combination can cut costs by up to 75% compared to managed cloud agent offerings, though actual savings will depend on model choice, usage volume, and self-hosting overhead.
For teams that already need self-hosting for compliance, cost, or model-flexibility reasons, and that need auditability (TrueForge logs full traces of every session, which helps with debugging tool schemas and diagnosing failures), it’s a reasonable fit. For a quick prototype where a hosted managed agent is faster to stand up, the added operational responsibility of running your own harness may not be worth it.
Frequently Asked Questions
What’s the difference between an agent loop and an agent harness?
An agent loop is just the tool-call, execute, feed-back-into-prompt cycle. A harness is the infrastructure around that loop, retries, sandboxing, context management, and approval gates, that makes the loop reliable enough for production use.
Is TrueForge only for coding agents?
No. It’s described as a general-purpose harness. It supports coding-style tasks through code mode and sandboxed execution, but it’s built to run any kind of agent, including operations, research, and on-call incident response agents, connected to arbitrary MCP servers.
Does TrueForge require a specific model provider?
No. It’s model-agnostic and works with any OpenAI-compatible API, including locally hosted models, by configuring a custom provider with a name and base URL.
How does TrueForge handle destructive actions like changing a live configuration?
Tools can be marked to require human-in-the-loop approval. Read-only tools execute automatically, but tools that modify state pause and wait for a human to approve the action through the dashboard or connected application before proceeding.
What sandbox does TrueForge use by default?
Daytona is the default sandbox provider, and it requires you to supply your own API key. The sandbox is treated as an on-demand tool rather than a persistent container holding the whole agent session.