DEV Community

Cover image for TrueForge keeps the agent loop out of the sandbox
Reno Lu
Reno Lu

Posted on

TrueForge keeps the agent loop out of the sandbox

TrueForge makes one architectural call: the sandbox is a tool the agent reaches for, not the room the agent lives in. The harness holds the loop, the session state, and the secrets, and isolated code and file execution gets provisioned only when it is needed.

It is also a useful lens for reading the rest of the feature list.

The harness is the product

The README opens with a claim: building an agent is easy, running one well is not. It then spells out what running well takes. Streaming, session persistence, tool servers, sandboxing, approvals, and a UI. TrueForge positions itself as the runtime layer that owns that work, running the agent execution loop across model calls, MCP tools, skills, sandboxing, approvals, context management, and session state.

Once the loop lives in the harness rather than inside an execution container, the split between control and execution becomes explicit. The README puts it plainly: secrets stay in the harness. The sandbox, which is Daytona today with more providers planned, becomes an execution target the harness brings up when a task calls for it.

Skills follow the same pattern. They are git-backed SKILL.md instruction packs, loaded on demand in the sandbox. The instructions show up where the work happens, at the point the work needs them.

Context engineering is built in

TrueForge lists its context engineering features as subagents, deferred tool loading, Code Mode, large-result offloading, and compaction.

You configure models, MCP servers, skills, and a sandbox once, and agents pick from what you connected. Presets come from shipped YAML catalogs you can customize. Model support covers OpenAI, Anthropic, Google Gemini, other catalog providers, and any OpenAI-compatible endpoint. Remote MCP servers can use header auth or OAuth, and authorization can happen inside the chat.

Where a person steps in

A runtime that holds the loop is also a sensible place to pause it. TrueForge ships human checkpoints: tool approval, ask-user-questions, and Generative UI in chat. These are configured when you create an agent, alongside the resources it can use.

The surfaces sit on top of that runtime. There is a bundled chat UI. There is an HTTP API with a TypeScript SDK, @truefoundry/trueforge-sdk, that covers sessions, turns, and events. And there is @truefoundry/trueforge-ui for embedding the chat into your own product. The API reference is published as OpenAPI paths and schemas.

Local first, but read the warning

A first run is one command, npx @truefoundry/trueforge@latest, and the README badge lists Node.js 22.14 or later. That starts local mode: one process, backed by SQLite, with no extra infrastructure. Hosted mode moves storage to Postgres with Redis and runs on Docker Compose, Helm, or Railway, aimed at teams and multi-replica setups. Optional OIDC login is documented for shared deployments.

The maintainers are direct about the limits of local mode. It has no login by default, data sits in a local SQLite file, and they ask users to keep it on localhost and use hosted mode for anything shared or production. If the separation of secrets from execution is what draws you to this project, keep in mind that the local setup is meant for trying it on your own machine, and the deployment story for a team runs through hosted mode.

The project also publishes a comparison against Claude Managed Agents and deepagents on the same tasks, tools, and model, and reports the same accuracy at lower cost. The setup to reproduce it lives in the benchmark/ directory, so you can rerun it against your own expectations before leaning on the result. TrueForge is released under the MIT License.


GitHub: https://github.com/truefoundry/trueforge


Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Top comments (0)