TrueForge
An open-source runtime for turning language models into tool-using, stateful agents.
The workflows generally use empty top-level permissions and job-scoped contents, id-token, and pull-request grants. The README also describes isolated on-demand sandboxes and human tool approval, providing meaningful but incomplete support for least privilege, data-flow transparency, and controlled external effects. Authentication tests cover 401 handling, session probing, credentialed logout, and failure behavior, while the local-mode warning clearly states that login is absent by default and the service should remain on localhost. However, claims that secrets remain in the harness and that checkpoints govern tools are not backed here by storage, authorization, or approval-bypass tests. Dependency handling pins pnpm with an integrity value and pins Actions to major versions, but the reusable build workflow follows mutable @main and the downloaded yq binary has no checksum verification, so dependency security is thin. No general transactional undo, recovery, or rollback mechanism is shown for agent tool effects, making rollback absent. Copyright, license, security reporting, founder contacts, and repository attribution are explicit, justifying full source-attribution credit; registry non-verification is treated only as unknown identity.
The README, package scripts, authentication tests, and release workflows are broadly consistent about product surfaces, the Node requirement, deployment modes, and authentication paths. Node, pnpm, SQLite, Postgres, Redis, Docker, Helm, and external model or sandbox dependencies are identified, but complete installation details reside mainly in external documentation not included here, and release builds depend on a mutable external workflow. Tests show clear states or errors for selected authentication and logout failures, while release scripts validate versions and emit actionable errors. The evidence does not cover failure reporting across the agent loop, models, MCP servers, sandboxes, and session storage, so none of the reliability criteria receives full marks.
Personal trials, hosted teams, multi-replica operation, API automation, and embedded UI are clearly distinguished, and the local-versus-hosted infrastructure table thoroughly supports environment fit. Multiple model providers, configurable MCP servers, skills, sandboxes, and deployment formats provide substantial adaptability. Boundaries include a strong warning that local mode is neither production-safe nor internet-facing, and future sandbox providers are labeled as planned, but there is no comprehensive account of resource limits, policy limits, or unsupported capabilities. On-demand sandbox provisioning, deferred tools, and human approval support trigger precision in principle, though the supplied evidence does not include their implementation or tests.
The README has clear product, capability, architecture, deployment, documentation, contribution, security-contact, and licensing sections. Package naming across trueforge, trueforge-sdk, trueforge-ui, and trueforge-core is stable. The Node requirement and npx entry point are explicit, but repository-local installation guidance is brief and delegates essential steps to an external quickstart, so install notes are not complete. Feature lists and an architecture table are present, but no substantive end-to-end code example or FAQ is supplied. The local-mode warning and latest-release-only security policy document useful but incomplete limitations. The full MIT text earns full license credit. Changesets, version scripts, semantic-version validation, and release PR automation establish version management, but no actual changelog content is provided. Contribution routes, security response expectations, contact addresses, and maintainer-controlled release steps clearly establish maintenance responsibility despite unknown registry provenance.
Outputs are directly usable through a chat UI, HTTP API, TypeScript SDK, and embeddable UI, with both local and hosted deployment paths, supporting full output-usability credit. Combining streaming, persistence, tools, approvals, sandboxing, and UI offers plausible marginal value over assembling those components separately, but the supplied excerpts do not expose the complete agent-loop implementation. The claimed accuracy and cost advantage appears only as a README benchmark assertion and a reference to an unshown benchmark directory. Infrastructure tradeoffs are described, but methods, figures, and results are absent, so marginal value is adequate while cost-benefit support remains thin.
Several claims trace to package scripts, scoped workflow permissions, authentication tests, the security policy, and the license. README statements about authentication, deployment, and release practices receive some corroboration from independent repository files. Central claims about the agent runtime, sandbox isolation, secret protection, approval enforcement, and benchmark superiority are not directly supported by the supplied implementation or tests. Marking additional sandbox providers as planned appropriately separates a future capability from current support, but the marketing conclusion of equal accuracy at lower cost is presented without the referenced evidence, leaving fact-versus-inference separation weak.
- Local mode has no login by default; keep it restricted to localhost and use hosted mode with OIDC for shared or internet-facing deployments.
- The supplied evidence does not show how model credentials, MCP authorization headers, OAuth tokens, or sandbox secrets are stored, encrypted, redacted, and retired.
- No general undo or recovery mechanism is evidenced for agent tool side effects; configure per-tool approval, narrow scopes, and external recovery procedures before enabling write-capable tools.
- The build pipeline follows the mutable main branch of truefoundry/github-workflows-public and downloads yq without checksum verification, limiting supply-chain immutability.
- The equal-accuracy, lower-cost benchmark claim cannot be verified from the supplied files and should not drive procurement or production-capacity decisions by itself.
- This was a static review only; tests, installation, agent tasks, sandbox-escape checks, and dependency vulnerability scans were not executed.
What does this agent do, and when should you use it?
TrueForge is an open-source agent harness that operates the execution loop spanning model calls, MCP tools, skills, sandboxes, approvals, context management, and session state. It exposes that runtime through a bundled chat interface, an HTTP API, the `@truefoundry/trueforge-sdk` TypeScript client, and the embeddable `@truefoundry/trueforge-ui`. It can connect to OpenAI, Anthropic, Google Gemini, other catalog providers, and OpenAI-compatible endpoints, alongside remote MCP servers authenticated by headers or OAuth. Its deployment boundary ranges from a single-process SQLite local mode to a hosted Postgres and Redis setup run with Docker Compose or Helm. It is aimed at developers and platform teams that want a ready-made operational layer instead of assembling streaming, persistence, tool authorization, isolated execution, and agent UI infrastructure themselves.
An operator initially configures models, MCP servers, Git-backed SKILL.md skills, and a sandbox through customizable shipped YAML catalogs; agents then select from those connected resources. During a run, TrueForge manages model calls and the agent loop, invokes remote MCP tools, loads skills on demand, and provisions a Daytona sandbox when isolated code or file execution is needed. It can stop at human checkpoints for tool approval, ask the user questions, and present Generative UI in the conversation. Its context layer supports subagents, deferred tool loading, Code Mode, large-result offloading, and compaction. Sessions and turns can be driven from the chat UI or HTTP API, while the TypeScript SDK exposes sessions, turns, and events; results are delivered through the bundled UI, an embedded UI, or API event handling.
- An individual developer evaluating a stateful, tool-using agent on a workstation can run the single-process SQLite local mode.
- A platform team standardizing models, MCP services, skills, sandboxes, and approval controls for several internal agents can deploy TrueForge as a shared runtime.
- A TypeScript team with an existing product interface can use
@truefoundry/trueforge-sdkto manage sessions, submit turns, and consume events. - A product team that needs an agent chat experience inside its application can embed
@truefoundry/trueforge-uiinstead of rebuilding the entire interface. - A team whose agents must execute code or manipulate files in isolation can use the on-demand Daytona sandbox while retaining secrets in the harness.
- An organization requiring human review before consequential tool actions can add tool approvals, user questions, and Generative UI checkpoints.
What are this agent's strengths and limitations?
- Combines model calls, streaming interactions, persistent sessions, MCP, skills, sandboxing, human approvals, and context management in one runtime.
- Offers a bundled chat UI, HTTP API, TypeScript SDK, and embeddable UI SDK, covering both direct operation and integration into an existing product.
- Explicitly supports OpenAI, Anthropic, Google Gemini, other catalog providers, and OpenAI-compatible endpoints, reducing dependence on one model vendor.
- Scales from a single-process SQLite setup to a hosted Postgres and Redis deployment using Docker Compose or Helm.
- Includes subagents, deferred tool loading, large-result offloading, and compaction for longer or more complex execution flows.
- Provisions the sandbox only when needed, keeps secrets in the harness, and supports human review before tool execution.
- Local mode has no login by default and is restricted to localhost use; the project explicitly says it is not a production or internet-facing setup.
- Production deployment adds Postgres and Redis plus the operational burden of Docker Compose or Helm.
- Daytona is the only currently documented sandbox provider; additional providers are described only as planned.
- The supplied material omits complete configuration, SDK examples, a first HTTP call, ports, and credential environment variables, preventing an unambiguous end-to-end automated setup from this source alone.
- Remote model and MCP integrations require network access and may require separate header credentials or OAuth authorization.
- The benchmark claim says accuracy is equal and cost is lower under matched conditions, but the supplied material contains no numerical measurements.
How do you install or deploy this agent?
Local mode requires Node.js >= 22.14. Run npx @truefoundry/trueforge; this starts the documented single-process mode backed by SQLite and requires no additional infrastructure. After startup, connect at least one model and configure any required MCP servers, skills, and sandbox, then follow https://trueforge.dev/quickstart to create the first reusable agent. Provider credentials and header or OAuth credentials for remote MCP services depend on the services selected; the supplied material does not name credential environment variables. Shared or production use requires hosted mode with Postgres and Redis and supports Docker Compose or Helm, but no complete copyable hosted deployment command is included in the source.
How do you use this agent?
For the smallest documented path, run npx @truefoundry/trueforge, connect a supported model during initial setup, and select any needed MCP servers, SKILL.md skills, and sandbox. Create an agent and start a session from the bundled chat UI; TrueForge then runs the model-and-tool loop, persists session state, and requests approval at configured checkpoints. Programmatic clients can use @truefoundry/trueforge-sdk for sessions, turns, and events or call the HTTP API, while frontends can embed @truefoundry/trueforge-ui. The supplied material does not include SDK initialization code, a sample HTTP request, port numbers, configuration keys, or credential variable names, so a more specific first API invocation cannot be stated reliably.
How does this agent compare with similar options?
The project compares TrueForge with Claude Managed Agents and deepagents on the same tasks, tools, and model, claiming the same accuracy at lower cost. It says the experiment can be reproduced from the repository's benchmark/ directory. The supplied material provides no scores, cost figures, or experimental details, so the size of the difference cannot be quantified here.