TrueForge Agent Harness and UHP

Status first

TrueForge is a distinct application-side agent harness, not a UHP implementation. TrueFoundry describes it as the runtime layer that turns an LLM into a working agent. Its server owns model calls, MCP tools, skills, sandboxing, approvals, context management and session state, then exposes that runtime through a bundled chat UI, an HTTP API with a TypeScript SDK and an embeddable UI SDK.

The repository was created in July 2026 and is under active development. The latest observed application-package prerelease is @truefoundry/trueforge@0.2.0-rc.2, published 8 September 2026 at 03:47:10 UTC. Checked upstream main is a5f220f34d95b0822b6344b0efa3bdfab244f987 at this cutoff. Because the monorepo publishes several independently versioned packages and Helm-chart releases, this page names the application package explicitly instead of treating GitHub’s generic “latest release” label as the TrueForge application version.

Caution

No native UHP, ACP or A2A adoption is established. Reviewed TrueForge primary sources do not name UHP or ACP. The only reviewed A2A repository hit is example/research text rather than an advertised protocol surface. HarnessRouter v0.15.7 also does not list TrueForge among its ten released backends. MCP support is a separate tool-integration boundary and must not be reclassified as UHP support.

What TrueForge owns

TrueForge is a complete harness runtime rather than a thin model wrapper. Its current documentation describes these first-party responsibilities:

• model-provider selection for OpenAI, Anthropic, Gemini and OpenAI-compatible endpoints;
• remote MCP-server tools with header authentication or OAuth, including in-chat authorization;
• git-backed SKILL.md instruction packs loaded on demand;
• isolated code/file execution through a sandbox provider, with Daytona documented today;
• human checkpoints such as tool approval and user questions;
• subagents, deferred tool loading, Code Mode, large-result offloading and context compaction;
• session and turn persistence surfaced through the HTTP API / TypeScript SDK;
• a bundled chat interface and embeddable UI SDK.

That bundle is relevant to UHP research because it is almost exactly the kind of complete harness execution surface that a client-to-harness interoperability protocol could sit in front of. The existence of an HTTP API, however, does not make that API UHP-compatible.

HTTP API versus UHP

TrueForge’s native network boundary is its own server HTTP API. The SDK exposes TrueForge concepts such as agents, sessions, turns and events against that API. UHP separately defines a versioned client → UHP server → harness contract with its own task/session/response semantics and conformance suite.

No reviewed TrueForge source provides a UHP adapter, UHP endpoint map, UHP version declaration or UHP conformance result. Therefore:

• TrueForge’s HTTP API is not treated as a UHP implementation;
• similar words such as “session” or “turn” are not assumed to have UHP semantics;
• running TrueForge behind a future adapter would be an integration fact, not native TrueForge adoption unless TrueFoundry itself publishes that support.

MCP is a native tool boundary

TrueForge does document first-party MCP integration. Administrators can configure remote MCP servers from catalog entries or custom URLs, and the current documentation supports header authentication and OAuth. The harness resolves those tool sources for agent execution and can complete authorization from the chat flow.

This is an agent/harness → MCP tools boundary. It does not replace TrueForge’s surrounding agent loop, session store, approvals, sandbox or HTTP API, and it does not imply that MCP is part of UHP conformance.

The checked current main also deduplicates per-turn LLM resolution by model name so a parent agent and subagents sharing the same model use a single-flight resolution path, matching existing MCP tool-source caching. That is internal harness orchestration behavior, not an interoperability-protocol change.

Skills, sandboxing and subagents

TrueForge treats skills and execution infrastructure as harness capabilities:

• Skills: git-backed SKILL.md instruction packs are loaded into the sandbox on demand.
• Sandbox: isolated file/code execution is provisioned as a tool; the documented implementation uses Daytona today.
• Subagents: the harness can fan work out to parallel subagents and merge results while keeping their intermediate context out of the main agent’s context.
• Context controls: deferred tool loading, compaction and large-result offloading are runtime mechanisms rather than network protocol primitives.

These are useful examples of the implementation topology UHP should remain agnostic about. A UHP client can care about portable task/session behavior without dictating whether a server’s backing harness uses one agent, subagents, a sandbox, Code Mode or a particular skill-loader architecture.

Local and hosted security boundary

TrueForge explicitly separates a convenience local topology from shared deployment:

Mode	Storage / infrastructure	Authentication boundary
Local / standalone	Single process with SQLite	No login by default. Upstream warns to keep it on localhost and not expose it as a production or internet-facing service.
Hosted / distributed	Postgres + Redis; documented through Docker Compose, Helm or Railway	Optional OIDC login for shared/team deployments.

The distinction matters operationally. A local harness endpoint with no login should not be mistaken for a safe remotely addressable agent service merely because it exposes HTTP. TrueForge’s own documentation says the local mode is intended for personal use on the same machine.

0.2.0-rc.2 release boundary

The observed application prerelease 0.2.0-rc.2 adds several runtime/API refinements without establishing a new interoperability protocol:

• session listing accepts exact metadata-containment filters through OpenAPI deepObject query parameters;
• session source is persisted and can be filtered by source type/id for internally created sessions such as scheduled dispatches;
• MCP-server and gateway-installation lookups are fetched in parallel;
• TrueFoundry mode can share a Daytona sandbox through configured environment/settings state;
• native Windows npx @truefoundry/trueforge handling is hardened while sandbox guest paths remain POSIX.

These are useful current implementation coordinates, but the package is explicitly an RC. They should not be generalized into stable wire-contract guarantees beyond the published prerelease.

How the boundaries compare

Layer	Primary job	Verified TrueForge relationship
TrueForge	Complete agent execution runtime, session/turn API and UI	Native project surface.
MCP	Harness/agent → tools and external systems	Native documented integration with header auth/OAuth.
Agent Skills / SKILL.md	Reusable instruction/capability packs	Native documented harness capability.
ACP	Editor/client → agent protocol	Not established in reviewed TrueForge sources.
A2A	Agent → agent interoperability	Not established as a TrueForge protocol surface in reviewed sources.
UHP	Client → UHP server → complete harness	No native adoption established.
HarnessRouter	UHP reference implementation → released backend adapters	TrueForge is not in the released ten-backend set at this cutoff.

Evidence boundaries

• Observed application prerelease: @truefoundry/trueforge@0.2.0-rc.2, published 8 Sep 2026 UTC.
• Checked upstream main: a5f220f34d95b0822b6344b0efa3bdfab244f987.
• Native MCP: established by TrueForge README/documentation and source.
• Native skills/sandbox/subagents/session API: established by TrueForge primary documentation.
• Native UHP: not established.
• Native ACP: not established.
• Native A2A: not established by the reviewed evidence.
• HarnessRouter backend support: not present in v0.15.7’s ten released backends.
• UHP conformance evidence: none attributed to TrueForge.

Related pages

Read Pydantic AI Harness for another application-side harness architecture, AI SDK Harnesses for a framework-level harness abstraction, harness composition for runtime topology, UHP vs MCP for the tool boundary, and ecosystem for adoption classifications.

Primary sources

• TrueForge repository
• TrueForge README
• TrueForge application package 0.2.0-rc.2
• TrueForge MCP server documentation
• TrueForge authentication documentation
• TrueForge current main a5f220f3
• HarnessRouter v0.15.7