A Gate at the End Is Not a Gate Along the Way

A policy check can arrive too late. A new study makes the timing problem concrete: when a procedure can fail before its final action, a guard that wakes only at that action can discover the mistake without preventing the earlier deviation.

The signal

PolicyGuide: From Guarding One Action to Guiding the Whole Workflow for Policy-Compliant LLM Agents compares action-local checks with a persistent external verifier that follows a compiled workflow across user turns. The authors argue that an action-local verifier has complete coverage only when every reachable first deviation triggers that check. A workflow can instead go wrong during evidence gathering, an instruction, a branch choice, or a completion decision.

The system under study keeps workflow position outside the acting agent, examines open requests at user-turn boundaries, and gives remediation for the first unmet step. This is not a result about whether a model knows the policy. It is a result about whether the verification schedule can see the point where the procedure first departs from it.

The evidence

In the authors' three customer-service domains, the external workflow condition reported Pass@4 values of 0.620 for Airline, 0.614 for Retail, and 0.614 for Telecom. The compared ReAct condition reported 0.460, 0.596, and 0.193; the action-local PolicyGuard condition reported 0.580, 0.360, and 0.202. Their Telecom ordered-trace measure reported 56.2 percent process-valid runs for PolicyGuide, compared with 17.5 percent for ReAct and 13.1 percent for PolicyGuard.

The helpful distinction for WTK is between a policy representation and a firing schedule. A declared policy, a tool inventory, and even a final action check can all be present while the first relevant deviation occurs somewhere none of them is evaluated. Our take is that a WTK gate should name the part of an execution it is meant to constrain, when it runs, and what evidence it can inspect at that moment.

The boundary

This is a preprint on three English customer-service domains, a frozen simulator, four trials per multi-trial cell, and the authors' workflow construction and evaluator choices. Retail had only ten policy-violation tasks and its overall gain over ReAct was not significant. The Telecom trace measure is exploratory, author-designed, conditioned by gold task actions, and lacks a second-annotator agreement estimate.

The study does not evaluate WTK packages, WTK policy hooks, target projections, live users, or natural-language policy compliance in general. It does not show that WTK needs a workflow graph or that a persistent stateful check is better for every target. It is not a WTK Finding and does not promote the maturity of any WTK mechanism.

The builder impact

Builders should ask a sharper question than "is there a guard?" For each acceptance-critical procedure, identify the first deviation that matters, the event that triggers the check, the state the checker carries, and whether the available evidence can distinguish a correct path from a late but superficially valid one.

WTK already keeps policies, hook outcomes, package contracts, and target proof separate. The paper suggests a bounded way to pressure that boundary: do not credit a final allow or deny decision as evidence for steps that the gate never had a chance to observe.

The WTK test

WTK could compare action-local enforcement with a persisted workflow-state condition for one package and target harness. Hold the package, policy, tool inventory, target projection, model binding, evaluator, and held-out fixtures fixed. Retain every allowed, blocked, incomplete, and remediated path, then measure final outcome, ordered-procedure conformance, false blocks, latency, and cost separately.

That would establish a result for one declared execution form, if it is completed. Until then, this paper is a reason to make gate timing testable, not evidence that WTK's checks cover an entire workflow.