Your Kill Switch May Not Stop Your Agent

When an operator attempts to halt an AI agent's procurement actions, the process can get complex. The agent may have already executed an order before the operator intervenes. This can happen if the supplier accepted the order before the operator's action. The agent's stop button may not halt all actions, as there could be child tasks with their own credentials.

To ensure effective control, a precise promise is necessary. This promise should outline which new actions are restricted, where the restriction applies, and how the team accounts for work that has already been dispatched.

A procurement agent's kill switch could be designed using a hypothetical example. The operator could limit the agent's ability to create supplier orders for one tenant. This would prevent new orders from being placed, while allowing the viewing of existing orders. Another scenario might involve stopping all outbound connections from a compromised worker. Each scenario would require different controls.

To measure the effectiveness of a stop command, three observable milestones can be defined. The first milestone is 'Stop requested', which indicates that an authorized operator has requested containment. The second milestone is 'Dispatch blocked', which means that the relevant executor has installed a rule preventing new dispatch authorizations in that scope. The third milestone is 'Outstanding work accounted for', which means that every known operation crossing that boundary has evidence and an assigned disposition.

The user interface should display these milestones separately. An acknowledgement from the dashboard proves only that the dashboard accepted the request. The executor must also acknowledge its own enforcement point. If a supplier has no cancellation feature, the stop contract must explicitly leave accepted orders in an outstanding inventory until their outcomes are established.

When implementing this system, it's important to consider the operations that occur beyond the agent process. For example, if three operations (A, B, and C) belong to the same run, they may require different decisions at the time of stop request. Operation A has reached the supplier, operation B is waiting in the application's dispatch queue, and operation C has a pending retry after an earlier response was lost.

The timeline should consider three logical operations belonging to the same run. Before the stop request, operation A has been accepted by the supplier and has received an acknowledgement. Operation B is still in the dispatch queue, and operation C has a pending retry. After the boundary closes, operation A's supplier acknowledgement arrives, and the outcome is recorded without resuming the run. Operation C's supplier status remains unavailable, preserving uncertainty and assigning an owner.

The timeline avoids claiming that the button press and every downstream boundary share one instant. The scheduler, executor, and supplier have separate histories. Recording their acknowledgements and operation references helps with investigation. Wall-clock timestamps can provide information, but ordering must also come from evidence at the component making the decision.

In conclusion, a useful AI agent kill switch requires a precise promise outlining which new actions are restricted, where the restriction applies, and how the team accounts for work already dispatched. This promise can be implemented through a stop contract, which includes a timeline of observable milestones and a detailed process for handling operations beyond the agent process.