The Runtime Between a Model and the World

TrueForge is an open-source agent harness: a runtime that turns a model’s ability to generate text into a process that can use tools, work through a long task, pause for a human decision, and preserve a conversation. The question here is not whether TrueForge can produce a plausible reply. It is what has to surround a model when the reply is only one step in work that touches external systems. This series uses that question to examine TrueForge’s architecture, execution loop, context controls, side-effect boundaries, and deployment surfaces so a reader can judge where the harness helps and what remains their responsibility.

The problem is not generating a reply

A model call has a deceptively simple shape: provide instructions and a message, receive an answer. That shape is useful for summarization, drafting, and many other tasks that end when the response arrives. It becomes incomplete when an agent must look up a record, call an external service, write a file, ask the user to choose between alternatives, or continue after a connection drops. The model can suggest the next action, but something else must decide how that action is represented, which credentials are used, whether the action is allowed, and what happens to the result afterward.

TrueForge’s own definition of an agent harness starts at this missing layer. The harness runs the execution loop around the LLM: it plans a turn, routes and executes tools, manages context as the task grows, enforces boundaries such as sandboxing and human approval, and retains session state across reconnects and restarts. Those responsibilities are not interchangeable. A tool router that cannot preserve state is not a session manager; a database that records messages does not decide when a write operation needs approval; and a sandbox that runs code does not by itself know which part of a tool result the model needs.

Consider a support request that begins as “Where is my order?” and becomes “Issue a refund.” The first question may require a read from an order system; the second may require a consequential write. The model can choose those calls, but the surrounding runtime must carry the conversation from one turn to the next, connect each result to the correct tool call, stop before the refund if approval is required, and continue after the user responds. If the client disconnects while the lookup is running, it also needs a durable identity for the turn rather than a new, ambiguous request. The useful behavior is therefore not just the final sentence. It is the controlled sequence that makes the sentence trustworthy enough to act on.

The same logic applies to less dramatic work. A research agent may need to search several sources and produce a file; an internal assistant may need to summarize a large data response without placing all of it in the model’s context; a team may need the conversation to survive a server restart. These are different workloads, but each exposes a gap between asking a model what to do and operating the result. TrueForge’s purpose is to make that gap a set of explicit runtime decisions.

This distinction also explains why TrueForge does not present itself as a replacement for every service an agent uses. Model providers remain the source of model calls. MCP servers expose tools and data from systems such as SaaS applications, internal APIs, and data platforms. Skills provide procedures that teach the agent how to handle a specialized task. A sandbox supplies isolated computation and file operations. TrueForge coordinates these pieces and exposes the result to an application, but the external providers still own much of the behavior and correctness at their boundaries.

flowchart LR Models["Model providers"] --> Loop["TrueForge agent loop"] MCP["MCP servers"] --> Loop Skills["Skills"] --> Loop Loop --> Sandbox["Sandbox as a tool"] Sandbox --> Loop Loop --> State["Sessions and turns\nSQLite or Postgres"] API["HTTP API + TypeScript SDK"] --> Loop UI["Chat UI + React UI SDK"] --> Loop

The architecture is therefore easier to understand as a set of boundaries than as a stack of product names. Information enters the loop through a configured model, instructions, skills, and available tools. Work accumulates as messages, tool calls, tool results, and sometimes subagent output. Potentially consequential actions pass through tool policy or a human checkpoint. The outcome is written into a session and turn structure that a client can stream or later replay. Each boundary answers a different operational question: what should the model see, what may it do, who must decide, and what can be recovered?

One harness, several ways to meet it

The same runtime appears through three public surfaces. The server is the center of execution. It connects the configured resources, runs the agent loop, streams its steps, and serves the bundled chat experience. The HTTP API makes those operations available to another program, while the TypeScript SDK gives application developers a client for creating sessions, streaming turns, and responding to pauses. The chat UI makes the same process visible to a person: they can select an agent, watch a response arrive, approve a tool call, authorize an MCP connection, or download an artifact.

This is more than a choice between a command-line interface and a browser. The surface changes who owns the immediate interaction, not what an agent fundamentally is. A browser may render a tool-approval card; an automated application may receive a tool.approval_required event and send a structured approval input. A chat interface may show streamed text as it arrives; an SDK consumer may merge model deltas into a message indexed by its event ID. In both cases, the harness has to preserve the same relationship between a model decision, an external action, and the turn that contains them.

That common event model matters because a running agent is not always ready to return a final answer. It may be waiting for an approval, an answer to a clarifying question, or authorization for an external MCP server. In those cases, the meaningful output is a durable indication of what is pending and how the client can respond. Conversely, a client that sees only text can miss the difference between “the agent finished” and “the agent stopped safely before doing something.” TrueForge makes the event stream part of the product surface, not an implementation detail hidden behind a completed response.

The separation also allows the UI to remain replaceable. A team can use the bundled interface for exploration, automate a workflow through the SDK, or embed the React UI SDK and change its layout, theme, or individual components. Those choices do not require moving the agent loop into the browser. The server still owns model and tool execution; the client chooses how to present progress and how to supply the human input that the loop requests.

The UI also makes the composition visible before the first message is sent. Administrators configure models, connectors, skills, and a sandbox provider under Settings. A person then assembles an agent by selecting a model, attaching the connectors and skills it needs, and choosing runtime behaviors. In a hosted deployment, Settings can be restricted to administrators while users continue to chat and use agents. That separation is practical: resource credentials and catalog choices are shared infrastructure concerns, whereas an agent’s role and permitted tools are part of a reusable definition.

TrueForge’s local and hosted modes show the same principle at a larger scale. Local mode is a single process using SQLite and is intended for personal use on a machine. Hosted mode places durable storage in Postgres and uses Redis to coordinate streams and cancellations across replicas. The agent features are intended to remain the same, but the operating conditions do not. A local process can assume one identity and a local file; a shared deployment must account for authentication, replica routing, secret management, and the consequences of a user disconnecting from a long-running turn.

The important result is a division of responsibility. TrueForge supplies a common execution model and several ways to drive it. The deployment operator supplies the model credentials, external connectors, skill sources, sandbox provider, storage, and identity configuration. The application integrating the API or UI supplies the user experience and, where relevant, the logic for handling events and required actions. Treating any one of these as “the agent” obscures where a failure or security decision actually belongs.

Reliability is a boundary problem

The project’s central idea can be stated without reducing it to a slogan: an agent becomes operationally useful when the runtime controls the boundaries that a model call leaves implicit. Context must be selected rather than allowed to grow without shape. External actions must be mediated rather than assumed to be harmless. User decisions must be represented as part of execution rather than improvised around it. State must be durable enough for a client to reconnect and continue instead of starting over.

These boundaries also create trade-offs. Bringing your own model and MCP servers gives TrueForge flexibility, but it means model quality, external data, tool annotations, and service availability remain outside the harness. A sandbox can keep credentials in the server and run code separately from the agent loop, but provisioning it introduces provider readiness and lifecycle concerns. Local mode is quick to start, but its no-login default is unsuitable for a public host. A reusable agent definition avoids rebuilding the same setup for every conversation, but a shared library may expose more configuration than a team expects if access policy is not designed carefully.

The boundary model is most useful when its conditions are stated plainly. Keeping a credential out of an agent definition reduces accidental duplication; it does not make a badly configured connector safe. Persisting a turn gives a client something to resume; it does not undo an external action that completed just before a network failure. A sandbox separates code and files from the server process; it does not make arbitrary code, downloaded skills, or generated artifacts harmless. Likewise, approval creates an opportunity for judgment, but the person approving still needs enough context to recognize an unsafe request. These distinctions keep “reliability” from becoming a vague promise.

They also give an operator a way to start small. A local, model-only conversation tests the basic loop with little infrastructure. Adding a read-only connector tests the resource boundary. Adding a skill or artifact-producing task introduces sandbox lifecycle and file handling. Only after those behaviors are understood does a shared deployment raise the harder questions of identity, replica coordination, and library visibility. TrueForge’s architecture supports that progression because the same named agent and turn concepts persist as the surrounding resources become more capable.

That is why the right first question about TrueForge is not “How many features does it have?” It is “Which boundary does this workload need, and who owns the boundary when it fails?” A simple question-and-answer task may need only a model and a session. A research brief may need deferred tools, parallel subagents, and a sandbox for artifacts. An operations assistant may need an approval gate, a clear identity model, and a recoverable event stream. The harness is valuable when it makes those differences explicit enough to configure and inspect.

The next concrete unit is the reusable agent definition. Once the surrounding architecture is visible, the distinction between shared resources, instructions, tools, procedures, and runtime behavior becomes the key to understanding what TrueForge actually saves—and why that contract can reference credentials without putting them inside the agent itself.

References