This essay presents an illustrative authority model for machine-connected agents. It is not a machine safety specification or a claim that a software approval interface provides certified physical protection.
An agent has prepared a workshop job and asks its owner to run it. The owner approves from a phone. Before execution, someone changes the fixture at the machine. The original plan may still be syntactically valid, and the approval still exists. The circumstances under which it was given no longer match.
This is why authority needs an interface that represents both a human decision and the conditions attached to it. A prompt can describe a desired boundary. The system responsible for releasing the action must separately decide whether that boundary is still satisfied.
Permission must attach to the actor
In this illustrative workshop, the agent can prepare a job, inspect available status, and request execution. A named operator can release a particular operation. Those are different roles. Giving the agent the operator’s broad credentials would conceal that distinction exactly when the history needs to explain who decided what.
A useful request identifies the agent, the accountable owner, the task, the target equipment, the operation, and the limits of the requested authority. The resulting approval belongs to that combination. It should not become a reusable token for any future operation that happens to resemble the original.
The interface should show the consequential differences between preparing and executing. A person may welcome automatic preparation while expecting to review anything that moves material. Making this separation visible allows more useful autonomy inside the agreed boundary without forcing a choice between constant interruption and blanket access.
Capabilities need physical envelopes
An operation has conditions, not just a name. The equipment configuration, permitted workspace, job version, duration, and applicable operating limits can determine whether a request is admissible. The exact limits must come from the equipment and its responsible operators; an agent should not invent them from a general description of the task.
In our scenario, the fixture change should make the earlier release insufficient until the relevant conditions are checked again. That is different from asking the model whether the change seems harmless. Enforcement belongs at the boundary that can withhold or constrain the machine action, using authoritative state for the checks it performs.
Loss of state requires a defined response. “Fail closed” should mean withholding unauthorized new work; it should not be read as a universal instruction to cut power to every process. The appropriate behavior for equipment already operating must follow its established controls and procedures. A web interface is not an emergency-stop system.
Intervention is part of collaboration
An operator needs to know what an intervention will do. Requesting a pause, acknowledging a warning, canceling queued work, and using a physical stop are different actions. Their labels and confirmation states should reflect those differences. The screen should not report “paused” merely because a pause request was transmitted.
The record should preserve the request, its acknowledgment, and the observed resulting state. If acknowledgment is unavailable, show that uncertainty. A remote collaborator must not be encouraged to assume that silence means the equipment stopped.
Resuming deserves its own decision. The person who intervened may have discovered a changed setup or a mistaken assumption. Keep that reason with the job, show what was corrected, and re-evaluate the applicable authorization before release. Otherwise, a helpful interruption can disappear into a log while the original plan resumes unchanged.
Make approval specific enough to mean something
Approval fatigue is a design failure as well as an operational concern. If every harmless edit produces the same prominent dialog as a machine release, the interface gives people little help allocating attention. Group routine preparation within an agreed scope and reserve consequential decisions for a clear, compact account of what will happen.
For the workshop job, show the proposed operation, target, current configuration, meaningful limits, and the reason approval is needed. If something changed since the last review, emphasize that change. Let the person narrow the request or reject it with a reason, rather than offering only an enormous accept button.
This makes the system more demanding to build: permissions need versions, decisions need context, and controls need understandable states. The reward is not a claim of perfect safety. It is a more precise relationship between what a person believed they authorized and what the system attempted.
The outcome returns to the same record
A successful command response may only confirm that a request was accepted. The work record should distinguish acceptance from the observed completion of the intended operation. Preserve the relevant device response, exceptions, and resulting state so the agent can reconcile its plan with what actually happened.
Test that relationship with uncomfortable cases. Revoke authority before a queued action starts. Change the job after approval. Disconnect the interface during execution. Have two operators intervene. In each case, ask what the person sees, what the execution boundary enforces, and what a later reviewer can establish from the record.
The same discipline applies beyond workshops. An agent preparing a file, sending it outside an organization, and operating equipment faces different consequences, but all three benefit from clear ownership and truthful state. Being in a location can make the right controls easier to find. It should never be the sole reason an action becomes authorized.
Good authority design connects a specific human decision to an enforceable scope and a truthful account of the outcome. Every handoff must preserve that connection.