Context Is a Budget: How TrueForge Keeps Work Legible
TrueForge treats context as a runtime resource, not as an unlimited transcript. This chapter explains how the harness controls the information present before a run and the information that accumulates while a task is underway. The goal is practical: given a tool-heavy or long-running workload, the reader should be able to choose between deferred loading, progressive skills, subagents, result offloading, Code Mode, and compaction—and understand the latency, coordination, or fidelity cost of each choice.
Two kinds of context, two different problems
In TrueForge, context means everything the model can see on a step: instructions, skill material, tool definitions, conversation history, tool calls, tool results, and the final results returned by subagents. That broad definition matters because context pressure does not begin at the same time for every workload. A model can be overwhelmed before the user sends a message if an agent exposes a large catalog of tools. It can also start with a lean prompt and become overwhelmed later when a search returns a long document or a conversation accumulates dozens of intermediate steps.
The harness therefore separates input context from runtime context. Input context is assembled at the beginning of a run. It contains the agent’s focused instructions, the available MCP servers and whichever tool definitions have been loaded, and the names and descriptions of attached skills. Runtime context grows as the agent responds to the user, calls tools, receives results, and incorporates delegated work. The distinction is not merely descriptive. Input context is mainly a configuration problem; runtime context is a flow-control problem.
The temptation in both cases is to expose everything. If an agent might need any of one hundred tools, why not load all one hundred schemas? If a tool returns a large JSON object, why not place it all in the next model request? If a conversation is long, why not resend its entire history? The answer is that the model’s window is shared by instructions, evidence, reasoning, and the next action. More context can add capability while reducing the room available to use that capability. TrueForge’s mechanisms are attempts to spend that budget where it changes the decision.
The clearest input-context example is MCP tool loading. A tool definition includes a name, description, input schema, and output schema. A server with many tools can consume a substantial part of the window before the model knows which one the user’s request needs. TrueForge defaults an attached MCP server to deferred loading. Instead of placing every tool definition in the initial request, it gives the model the server’s name and description and exposes a small set of discovery operations.
The model can first list the available tool names, then request the description and schemas for a selected tool, and finally call that tool. The deferred wrapper makes this a visible sequence: discovery is not an implicit guess based on a tool name. The model is instructed to inspect the server before invoking an operation. An output schema can be requested separately when the next step will be Code Mode, which prevents a script from guessing the structure of a response it has not seen.
This design moves cost rather than eliminating it. Deferred loading adds discovery round trips the first time a tool is needed. In return, a large catalog does not occupy the model’s context on every call, and a server that is never used need not be fully loaded at startup. The trade-off favors deferred loading when a server has many tools or is used occasionally. Full preload is reasonable for a small connector whose tools are used almost every turn and where the discovery step would be repeated overhead. Selective preload occupies the middle ground: a few frequent tools can be loaded eagerly while the rest remain discoverable on demand.
The decision should be made per server and per workload, not as a universal setting. A web-search connector with two frequently used operations may benefit from preload. An internal platform connector with a hundred operations probably should not make all of them part of the first model request. A support agent may preload the order lookup but defer a rarely used account-maintenance operation.