Agentic Tool-Use With Bounded Actions

Every copilot action is a typed, bounded tool call — read, simulate, or propose — with no tool that writes directly to the plant.

Actions are tools, and tools are bounded

L5 copilots are agentic: they plan and call tools rather than emitting free text alone. The safety of the whole layer rests on one principle — every tool is bounded and typed, and no tool in a copilot's toolbox writes to the hard-real-time control path. The available actions fall into three classes: read (query L2, query twin state), simulate (run a twin module or surrogate), and propose (submit an action to L4 for authorization).

The three action classes

There is no fourth class. A copilot cannot command an actuator, arm a pulse, or change a persistent setting directly. The strongest thing it can do unilaterally is compute. Everything with a plant consequence becomes a proposal object handed to L4.

Typed tool schemas

{
  "tool": "twin.simulate_scenario",
  "class": "simulate",
  "args": {"machine": "breeder", "waveforms": {...}},
  "bounds": {"max_runtime_s": 30, "envelope_required": true},
  "side_effect": false
}

• Each tool declares its class, argument schema, resource bounds, and side-effect flag
• The planner may only call declared tools; unknown or malformed calls are rejected
• Resource bounds (runtime, memory, retrieval depth) cap every call
• Propose-class tools carry the full action for L4 to authorize or refuse

Bounded tool-use is what lets a copilot be genuinely agentic without being dangerous: it can chain dozens of reads and simulations to reason its way to an answer, yet it structurally cannot touch the machine. The next pages detail the action schemas and the planning loop that sequences them, and the L4 authorization gate that every proposal passes through.