Bounded Action: Tools, Sandboxes, and Human Checkpoints

TrueForge’s context controls decide what the model can see; its side-effect controls decide what that model-driven process can do. This chapter examines the boundary between an agent’s request and a real change in an external system. The practical judgment is not whether TrueForge can make an action impossible, but whether a tool call is exposed, classified, paused, isolated, and resumed in a way the application and its users can understand.

When a tool is available, authority is not automatic

An MCP server is the route from TrueForge to a real system: a CRM, a ticketing platform, a document store, or an infrastructure control plane. Attaching the server to an agent does not mean that every operation should be equally visible or equally autonomous. TrueForge gives an agent-specific mount several policy controls. It can enable all tools, read-only tools, or named tools; subtract tools from that set; decide which definitions are preloaded; and require a human decision for selected calls.

Those controls act at different points. Enablement decides whether the tool is part of this agent’s capability surface at all. Preloading decides when its schema enters context. Approval decides whether a call can cross the execution boundary without an additional user input. A connector can therefore be attached but restricted to lookup operations, or a tool can be available for the model to discover but still stop before it changes data. Treating all three settings as one generic access switch hides the behavior the operator actually needs to predict.

The default approval policy uses the annotations published by the MCP server. TrueForge recognizes read-only, write, and destructive hints and normally pauses for tools classified as write or destructive. That is a sensible starting point for a well-described server. It is not an independent determination of business risk. The annotation belongs to the external MCP server, and an unannotated tool is exempt unless a literal name or an all-tools rule covers it. If a server describes a consequential operation as read-only, the harness has no general way to infer the mistake from the name alone.

This creates a useful diagnostic distinction. If a tool should not be available, inspect enablement and disablement. If the tool is available but its schema consumes too much context, inspect preload. If it is available and correctly described but should wait for a person, inspect approval selectors and annotations. These are different causes of an unsafe or surprising run, and they require different changes. Adding a warning to the system prompt does not repair an over-broad tool mount; changing the mount does not answer a missing user decision.

Suppose an operations agent receives the instruction “restart the billing service.” The model may emit a tool call with a service name and environment. TrueForge resolves the configured MCP server and the per-agent policy before allowing the operation to run. If the tool is covered by the approval rule, the call is not silently executed. The runtime emits tool.approval_required and records a reference to the model message that contains the tool name and arguments. The client can display those details, ask a person to allow or deny the request, and send the decision as a new user.tool_approval input.

The new turn is part of the execution protocol. It does not ask the application to reconstruct a hidden callback or repeat the original user message. The approval identifies the thread and tool-call ID, and the harness uses the stored context to attach the decision to the open call.