The Harness as a Control Plane

TrueForge becomes easier to judge when its reusable agent definition and its running turn are treated as one operating model rather than two separate features. This checkpoint connects those ideas to a practical question: given a simple task, can you predict what is loaded at startup, what accumulates as the agent works, what the client can observe, and where an interruption will be handled? That judgment is more useful than memorizing the names of individual capabilities, because it reveals which boundary is doing the work and which dependency remains outside the harness.

From shared resources to a bounded turn

Start with a configured model, an MCP connector, perhaps a skill and a sandbox provider. Those resources do not yet constitute a running agent. They are available infrastructure. The agent definition selects a model, gives it a role, attaches named resources, and turns on runtime behaviors. A session then binds that definition to one issue. Only when a turn is created does TrueForge resolve concrete resources, reconstruct the relevant thread context, validate the new input, and begin the model/tool cycle.

That sequence matters because each transition changes what is owned. Shared resource configuration owns provider credentials and connection details. The agent definition owns the intended capability surface: which model, which instructions, which tools, which procedures, and which runtime controls. The session owns the conversation boundary. The turn owns one bounded attempt to advance that conversation. The client owns the immediate presentation and, when the runtime asks for help, the response that allows work to continue.

flowchart LR Resources["Shared resources\nmodels, MCP, skills, sandbox"] --> Spec["Agent definition"] Spec --> Session["Session\none issue"] Session --> Turn["Turn\nbounded execution"] Turn --> Context["Model context\ninputs and results"] Turn --> Effects["MCP and sandbox\nexternal work"] Turn --> Events["Events and\ndurable snapshot"] Events --> Client["API, SDK, or UI\nobserve and respond"] Client --> Turn

The feedback edge from the client to the turn is not an implementation convenience. It is what allows a model-driven process to remain autonomous without pretending that every decision should be automated. A user message starts ordinary work. A tool approval, a clarification answer, or an OAuth completion starts the next piece of work after a pause. The same turn vocabulary can support a browser interaction and a programmatic workflow because the client supplies typed input rather than manipulating hidden runtime state.

Consider a lookup that later becomes an action. The support agent’s model and instructions establish the role. The MCP mount makes the order system available. The first turn may load only the information needed to inspect the order and return a response. A second turn can carry the request to refund it, but the runtime can stop before the write if policy requires approval. The important distinction is not simply “read versus write.” It is that the agent definition describes a possible action, while the turn decides whether the action is currently ready to execute and the client may have to authorize the transition.

This model also explains why TrueForge’s agent spec is not a security boundary by itself. It can keep credentials out of the saved definition and narrow the tools an agent sees, but the external MCP server still supplies the tool annotations and implements the downstream operation. The sandbox can separate code execution from the server and keep model/MCP credentials in the harness, but the operator still chooses the provider and the skill sources. The control plane coordinates these interfaces; it does not take ownership of every external truth.

A useful ownership test is to ask four questions about any step. What information must be present for the model to choose the step? That belongs to the working context. What authority makes the step possible? That belongs to the configured resource and the agent’s tool policy. What can stop the step before it changes the outside world? That belongs to approval, authentication, or another client-side checkpoint. What lets the next turn understand what happened? That belongs to durable context and events. The questions overlap in a real run, but they should not be answered by the same object.