By Devy · Category: AI Dev Tools — Open Source
Building the first version of an agent is surprisingly easy.
You pick a model, give it a system prompt, connect a couple of tools and you get a demo that does something useful.
Then you try to put it behind a real application.
You need persistent sessions. Streaming. Context management. Authorization for tools. Sandboxing to run code. MCP. Skills. Human approvals. State. Recovery when an execution fails. An API so your product can talk to the agent. Maybe a UI. And if tomorrow you want to switch Claude for Gemini, OpenAI or a model served behind an OpenAI-compatible endpoint, ideally you don’t want to rebuild everything.
That’s where the concept of agent harness comes in.
And TrueForge, TrueFoundry’s new MIT project, attempts to turn all that infrastructure around the model into an open source layer you can run yourself.
The thesis can be summed up like this:
model ≠ agent
model
+
execution loop
+
tools
+
context
+
sandbox
+
state
+
approvals
+
UI/API
=
usable agent
TrueForge wants to take care of almost everything below the first term.
First: what exactly is an agent harness?
It’s worth clarifying because we’re using the word more and more.
A framework like LangChain, LangGraph or CrewAI helps you build the logic of an agentic system.
A harness mainly takes care of running it.
Think of it as the difference between writing a function and operating a service around that function.
TrueForge executes the agent loop and manages model calls, MCP tools, Skills, sandboxing, approvals, context management and session state. Then it exposes the agent through a chat interface, an HTTP API with TypeScript SDK or a UI you can embed in your own product.
The mental architecture becomes much cleaner:
YOUR PRODUCT
│
┌────────┴────────┐
│ │
API UI SDK
│ │
└───────┬─────────┘
│
TRUEFORGE
│
┌───────────┼────────────┐
│ │ │
MODEL TOOLS CONTEXT
│ │ │
OpenAI MCP sessions
Claude Skills compaction
Gemini sandbox subagents
OpenAI-
compatible
The application doesn’t need to know all those details.
It talks to the harness.
And it doesn’t force you to marry a model
This is probably one of the most important features of the project.
TrueForge supports OpenAI, Anthropic, Google Gemini, other providers in its catalog and OpenAI-compatible endpoints.
The latter opens the door to much more interesting architectures than:
my application → single vendor API
You can build:
my application
↓
TrueForge
↓
model chosen by us
and keep the operational layer of the agent relatively stable even as what’s behind it changes.
For teams that want to experiment with open weights models served through OpenAI-compatible infrastructure, this is especially attractive.
The model becomes an interchangeable dependency.
The harness remains.
How to test TrueForge in five minutes
Local mode is deliberately simple.
You need Node.js and you can start directly with:
npx @truefoundry/trueforge
TrueForge spins up everything in a single process and uses SQLite to store data locally. It doesn’t require Redis or PostgreSQL to get started.
It’s exactly the mode I’d use to evaluate the project.
But there’s an important caveat from the maintainers themselves: local mode is not a production deployment.
It has login disabled by default and information lives in a local SQLite file. The documentation explicitly asks to keep it on localhost.
The planned progression is:
testing
npx @truefoundry/trueforge
↓
SQLite
production
TrueForge
↓
PostgreSQL + Redis
↓
Docker Compose / Helm
For teams or multiple replicas, TrueForge offers hosted mode with PostgreSQL and Redis and can be deployed via Docker Compose or Helm.
This is a good design decision: you don’t need to deploy half a platform to find out if you like it.
Then you connect the model
TrueForge works with resource catalogs.
You configure the available models once and then agents select from those resources.
The same happens with:
models
MCP servers
Skills
sandboxes
Presets come defined through YAML catalogs that can be customized.
The difference seems minor, but it becomes important when you have more than one agent.
Instead of each application having:
OPENAI_API_KEY=...
ANTHROPIC_API_KEY=...
MCP_GITHUB_TOKEN=...
MCP_DATABASE_TOKEN=...
the architectural intent is for the harness to know the available resources and the agent to reference them.
That better separates:
what the agent needs
from:
how that resource is authenticated
TrueForge can also work standalone; connecting it to TrueFoundry’s AI Gateway adds an additional layer of governed access to models, MCPs and Skills, but the gateway is not required to use the open source project.
MCP stops being something each agent implements on its own
TrueForge can connect to remote MCP servers using authentication via headers or OAuth.
And there’s one particularly useful detail: it supports authorization within the chat itself.
Imagine an internal support agent.
It can query:
GitHub
Jira
PostgreSQL
logs
internal documentation
You don’t necessarily want to give it permanent, invisible access to all of that.
The harness can interpose:
agent
↓
wants to execute tool
↓
requires approval?
↓
human approves
↓
execution
That human checkpoint is one of the components that usually disappears in agent demos and reappears quickly when Security asks how the system actually works.
TrueForge includes tool approvals, user prompts and Generative UI elements within the conversation.
Skills are also first-class citizens
TrueForge supports Skills backed by Git and structured around SKILL.md.
Instead of permanently loading all procedural knowledge into the prompt, Skills can be retrieved when needed and loaded into the sandbox.
This lets you separate:
AGENT
base instructions
│
├── skill: investigate incident
├── skill: review PR
├── skill: generate report
└── skill: deploy staging
from the context that a concrete execution needs.
It’s an important distinction.
An agent with twenty procedures shouldn’t necessarily load all twenty procedures on each request.
The sandbox isn’t running all the time
Here TrueForge makes an architectural decision that also has economic consequences.
The sandbox is treated as a tool.
If the agent needs to execute code or manipulate files in an isolated environment, TrueForge provisions the sandbox. If it doesn’t need to, it doesn’t have to exist throughout the entire session. Currently the documented provider is Daytona, with more providers planned.
That produces something like:
user asks something
↓
agent reasons
↓
need to run code?
│
no │ yes
│ ↓
│ sandbox
│ ↓
│ isolated execution
│
└────→ response
Instead of:
create sandbox
↓
maintain sandbox
↓
maybe use it
```It is one of the mechanisms that TrueFoundry points to when explaining why it tries to reduce the total cost of execution.
## But the most interesting part is probably context engineering
An agent that runs for two minutes has a different problem than one that works for forty.
The second one accumulates:
- tool responses;
- files;
- search results;
- logs;
- operational reasoning;
- instructions;
- errors;
- intermediate results.
If you simply send everything back to the model on each turn, the context grows and the bill grows with it.
TrueForge incorporates several strategies to avoid this:
**subagents**, **deferred tool loading**, **Code Mode**, **large-result offloading** and **compaction**.
The common idea is quite simple:
> not everything the agent produced needs to remain within the active context.
For example, a tool can return 50,000 lines of logs.
The agent probably needs five.
Sending the other 49,995 back to the model over the next ten turns doesn't necessarily improve the result.
It does increase consumption.
That problem seems trivial until you multiply:
```text
unnecessary tokens
×
turns
×
agents
×
users
×
days
And then context engineering stops being premature optimization.
It becomes infrastructure.
The benchmark: up to 75% less, but you have to read the number carefully
TrueFoundry is making a fairly aggressive claim around cost.
In their own benchmark of 14 production-style tasks, the company reports approximately 30% lower cost using the same model compared to Claude Managed Agents. By also switching to an open model, they report savings of up to 75%, while maintaining accuracy in their evaluation.
The distinction matters.
It doesn’t mean:
TrueForge makes any agent 75% cheaper.
There are two different comparisons:
same model
→ ~30% lower cost reported
alternative/open model
→ up to ~75% lower cost reported
And the results come from TrueFoundry, not from an independent evaluation.
The good news is that the project includes the benchmark/ directory to reproduce the tests.
More interesting than the concrete percentage is the metric they’re trying to optimize:
cost per completed task.
Because comparing models solely by token price can be misleading.
A model that costs half but requires three times more tool calls isn’t necessarily cheaper.
The useful metric is:
total cost
──────────────────────────
task completed
That’s where model, tokens, context, tools, sandboxes, retries and execution duration come in.
Use case 1: an agent within your own SaaS
This seems to me to be one of the scenarios where TrueForge makes the most sense.
Let’s say you have a documentation and collaboration application and want to incorporate an agent capable of:
searching documents
summarizing projects
creating content
querying internal systems
executing workflows
You could build everything directly within your backend.
But you quickly end up implementing:
session store
LLM client
streaming
tool registry
MCP client
approval state
sandbox
context compaction
retry logic
UI events
With TrueForge the architecture can look like:
YOUR SAAS
│
TypeScript SDK
│
TrueForge
┌──────┼──────┐
│ │ │
model MCP Skills
│
internal services
Your product focuses on what the agent should do.
The harness focuses on how to run an agent consistently.
And if you don’t want to build the entire visual experience from scratch, you can use @truefoundry/trueforge-ui to embed the interface. The project also exposes @truefoundry/trueforge-sdk to work programmatically with sessions, turns and events.
For a team that wants to add agents to an existing product, this is probably the most compelling use case.
Use case 2: internal agents with sensitive tools
Now imagine an agent for Platform Engineering.
It has access to:
GitHub
Kubernetes
Datadog
Jira
AWS
internal documentation
The model by itself isn’t the hard problem.
The problem is:
what can it do?
You could define an agent where:
reading logs
→ automatic
searching documentation
→ automatic
querying Jira
→ automatic
modifying infrastructure
→ human approval
running script
→ sandbox
deploying
→ human approval
There the value of the harness isn’t “making the model smarter”.
It’s creating an operational boundary around its intelligence.
And that’s probably one of the most important functions this category will have.
Use case 3: experimenting with models without rewriting your product
There’s another less flashy but tremendously practical scenario.
Today you build with Claude.
In three months an open weight model appears that works well enough for 80% of your workloads.
If your entire application is built around a specific API:
product → Anthropic SDK → tools → state → UI
migrating can be painful.
If the architecture is:
product
↓
harness
↓
provider
the model decision is much more isolated.
TrueForge supports commercial providers and OpenAI-compatible endpoints, so the harness can function as that decoupling layer.
That doesn’t completely eliminate lock-in—models have different capabilities and behaviors—but it reduces it to a much more manageable place in the architecture.
What TrueForge is not
It’s also good to set boundaries.
TrueForge is not another model.
It’s not a replacement for Claude Code.
It’s not a multi-agent prompting framework in the style of CrewAI.
And it doesn’t mean that installing it automatically turns a demo into a production-ready system.
The documentation itself makes an explicit separation between:
local mode
for testing, and:
hosted mode
for teams and shared deployments.
For production you still need to make real decisions about:
- authentication;
- authorization;
- observability;
- availability;
- secrets;
- networking;
- backups;
- models;
- MCP servers;
- tool policies;
- sandbox lifecycle.
TrueForge gives you primitives for much of that work.
It doesn’t make all those decisions for you.
The important signal: the model is ceasing to be the entire product
For a long time we talked about AI applications as if the architecture were:
product
↓
LLM API
Agents made it clear that almost everything in the middle was missing.
Now the architecture looks more like:
PRODUCT
↓
AGENT HARNESS
↓
┌──────────────────────────┐
│ model routing │
│ context engineering │
│ sessions │
│ tools / MCP │
│ Skills │
│ sandbox │
│ approvals │
│ state │
│ streaming │
│ observability │
└──────────────────────────┘
↓
MODELS + REAL SYSTEMS
And that’s probably why we’re seeing so many harnesses appearing now.
Models are already capable enough to build useful agents.
The problem has shifted.
The question stopped being only:
What model do I use?
Now it’s also:
What infrastructure do I put around it so it can work without my application having to reinvent a complete runtime?
TrueForge is a fairly ambitious answer: MIT, vendor-neutral, runnable locally, deployable with conventional infrastructure and designed so that models, MCP servers, Skills and sandboxes are connectable resources rather than decisions embedded within each application.
To try it, the cost of entry is practically a single command:
npx @truefoundry/trueforge
And that’s probably the best way to evaluate whether this category makes sense for your stack: don’t start by building a new agent, but take one you already have and calculate how much code around the model you could stop maintaining yourself.