What TrueFoundry Adds on Top of TrueForge

TrueForge is the open-source agent harness that runs the core agent loop — model calls, MCP tools, skills, sandboxing, approvals, context management, and session state. You can self-host it and wire up your own credentials, storage, and monitoring. TrueFoundry embeds that same harness unchanged, so the product behaviour is identical. What it adds is a hosted runtime and a direct connection to the rest of the platform.

​

Hosted TrueForge

TrueForge in local mode is meant for a single machine. TrueFoundry runs it as a shared production service, so teams get a harness that is already wired into the organisation:

• Nothing to operate — no harness deployment, database, object store, or sandbox infrastructure to provision and keep running.
• Shared with your organisation — agents, sessions, and schedules live in the platform, and access follows the same authentication and RBAC as everything else on TrueFoundry.
• Deployed where you need it — available as SaaS, self-hosted, or on-prem in your own cloud and region.
• Managed sandbox — colocated with the harness for low execution latency, provisioned on demand, with lifecycle and cleanup handled for you. Secrets never enter the sandbox.
• Defaults already set — subagents, context compaction, large-result offloading, ask-user questions, and Generative UI are enabled out of the box.

​

Deep gateway integration

Self-hosted TrueForge expects you to configure model providers, MCP server endpoints, and skill sources yourself. On TrueFoundry, none of that configuration exists: the harness reads directly from the AI Gateway, MCP Gateway, and Skills Registry, so whatever you already have access to is simply there when you build an agent.

​

Models

Every model enabled for you in the AI Gateway shows up in the model picker, grouped by provider. Switching models is a one-click change — no provider keys, no endpoint configuration, no new agent definition. Because access is resolved at the gateway, the usual controls apply without any agent-level setup:

​

MCP servers

MCP servers registered in the MCP Gateway are listed in the builder, and you pick the individual tools an agent should see. Authentication stays with the gateway — it holds the credentials, runs per-user OAuth flows, and refreshes tokens — so no bearer tokens or vault identifiers ever appear in an agent definition. If a user has not yet authenticated to a server, they can connect from the builder or inline during a conversation and carry on without leaving the chat. Tools flagged as destructive at the gateway automatically pause for human approval in every agent, rather than each agent having to declare its own approval policy.

​

Skills

Skills come from the Skills Registry — a versioned, RBAC-governed catalogue shared across teams — instead of files committed alongside each agent. Agents pick from the approved catalogue, versions can be pinned for production stability, and a bad version can be rolled back without touching the agent.

​

Observability

Because the harness runs in the same gateway plane as model and MCP traffic, every agent session is captured with cost, tokens, turns, tool calls, and a turn-by-turn transcript, with no instrumentation in your agent. It is one pane of glass across model, MCP, and agent traffic, and it inherits AI Gateway analytics, request logs, OpenTelemetry export, and Prometheus/Grafana. See Observability for the Sessions views and per-session metrics.

​

Comparison with other hosted harnesses

Claude Managed Agents and LangSmith Managed Deep Agents are both strong hosted runtimes. The differences become clear when you look at how each platform handles builder experience, credentials, governance, observability, and deployment.

​

Next steps