Plan-Validate-Execute Pattern
A structural pattern for handling high-stakes irreversible actions in agentic systems: rather than letting the agent execute autonomously, the action sequence is decomposed into three stages with a deterministic gate between planning and execution. Documented as Google Workspace’s canonical implementation by Nicolas Lidzborski at [[unprompted-conference-march-2026|[un]prompted March 2026]].
The pattern operationalizes HITL for the specific case of irreversible writes — moves, deletes, sends, sharing changes — where post-hoc detection is too late.
The three stages
1. Plan
The agent enumerates explicitly what it intends to do before any execution begins. The plan is a structured artifact (action class, target resource, parameters, source of intent) — not free-form natural language. This is the input to the validation gate.
The structured-plan requirement matters: free-form intent (“I’ll email John about the contract”) is not validatable. A structured plan (“send_email; recipient=user_id_42; subject=…; attached_doc_id=…; intent_source=user_query_at_t1”) is validatable against policy and against what the user actually asked for.
2. Validate
A gatekeeper evaluates the planned action against:
- Dynamically generated policy — derived from session state, accumulated risk level, data sensitivity classifications, user history
- User intent — does the planned action actually match what the user asked for? Cross-reference against agency-gap failure modes (wrong recipient, wrong target document, wrong scope)
- Pre-defined deny rules — actions that are unconditionally forbidden in the current context (e.g. outbound web request after accessing high-sensitivity data)
Three outcomes:
| Outcome | Action |
|---|---|
| Pass | Proceed to Execute |
| Confirm | Block until human approves; surface the structured plan + reasoning to the user |
| Block | Refuse the action entirely; log the attempt; surface to the user with reason |
The Block path applies when off-the-rails behavior is detected by a contextual security framework that monitors for systemic failure (e.g., rapid-fire sensitive actions, scope escalation patterns).
3. Execute
Only after the gate passes does the agent invoke the underlying tool. Execution is mechanical — the policy decision has already been made, the tool call is constrained to the parameters in the validated plan.
The structural distinction from “ask before doing”
Naïve HITL implementations interleave the model’s reasoning with confirmation prompts. The model decides what to do, asks the user, then proceeds based on the user’s reply. Plan-Validate-Execute differs in three load-bearing ways:
- Validation is deterministic, not LLM-based. A non-LLM policy engine evaluates the plan. This breaks the recursive-injection failure mode where an LLM-based reviewer is itself vulnerable to the same injection.
- The plan is visible before execution. The user (when prompted) sees the concrete action — recipient, subject, attached resources — rather than a model summary that may or may not match what the agent will actually do.
- The gate is enforced by the runtime, not the model. The model can propose; only the runtime can act. This is the platform-layer-not-prompt-layer principle in concrete form.
Review fatigue — the honest caveat
Lidzborski is explicit: “There’s still a lot of UX research to deal with review fatigue and rubber stamping. Like, first people will keep verifying things, then they’ll just become approval bots.”
The Plan-Validate-Execute pattern doesn’t solve review fatigue; it just creates the surface where the problem becomes addressable. Specific mitigations being researched:
- Adaptive confirmation frequency — confirm-tier the first time an action class is performed for a session, auto-tier subsequent identical actions within the same context
- Risk-proportional UX — heavyweight modals for high-impact actions, inline notifications for low-impact
- Structured-plan summaries — surface the delta from expected behavior rather than the full plan, drawing attention to anomalies
- Post-hoc anomaly correlation — even when users rubber-stamp, drift detection catches sustained anomaly patterns
None of these has a settled best practice as of 2026. The pattern is sound; the UX layer remains an open problem.
Implementation surface across the RA
Plan-Validate-Execute is concentrated in the Control plane of the RA but touches multiple planes:
| Plane | Role |
|---|---|
| Control | Gatekeeper / policy engine; least-agency tier evaluation |
| Identity | Validates the agent identity issuing the plan; binds plan to human principal |
| Runtime | Lifecycle hook intercepts tool calls before execution |
| Egress | Tool-call broker enforces the validated plan parameters |
| Observability | Logs the full plan + validation decision + execution outcome for audit |
A reference implementation pairs:
- Cedar or OPA for the policy engine
- HITL confirmation UX for the user-facing gate
- Tenuo Warrants (where deployed) for the capability-token layer that constrains what the agent can request in the first place
- AgentGateway for tool-call brokering
CMM positioning
In the CMM:
- D3 (Runtime Guardrails) L3+ — Plan-Validate-Execute is the pattern that takes a deployment from “guardrails exist” to “guardrails are structurally enforced”
- D5 (Human Oversight Architecture) L3 — operationalizes HITL for irreversible actions
- D7 (Observability & Audit) L3 — the structured plan + validation + execution triple is high-value audit data
Cross-references
- HITL — Plan-Validate-Execute is the canonical HITL implementation for the confirm tier
- Bullen’s Stripe talk — Stripe’s three-ring containment uses analogous gate-before-action mechanics in the egress + tool-policy direction
- Agency gap — Plan-Validate-Execute is one of the few defenses against non-adversarial agency-gap failures (the validation step catches “wrong John” errors)
- Orchestration hijacking — the deterministic policy engine in the validation step is not vulnerable to the prompt-injection attacks that compromise LLM-based reviewers