06-reference/research

agent write action gating patterns

2026-06-07·research-brief·source: deep-research
write-path-gatinghuman-in-the-loopsupervisor-agentcapability-tokensdual-control

Gating an Always-On Agent's Write/Send Actions: Pattern Survey and Fit for a Single-Operator COO Agent

The question

What are the established patterns for gating an always-on agent's write/send actions (human-in-the-loop, supervisor-agent, capability tokens, dual-control), and which fit a single-operator COO agent?

What we already know (from the vault)

What the web says

Convergences and contradictions

Convergences. Every source agrees on the same skeleton: (1) read-only is ungated; (2) side-effecting actions need a validator between the agent and the world; (3) gate on action class + actual arguments, not tool identity; (4) approval is a resumable state, not a blocking spin; (5) the deterministic/mechanical check and the judgment/human check are different layers that compose. RDCO's v0 two-layer stack (mechanical verify-action hook + LLM verify-write-action supervisor) is a faithful instance of this consensus, and its Tier-A/Tier-B action taxonomy is exactly the "gate the classes that move money / cross the boundary / are hard to reverse" rule everyone lands on.

Contradictions / tensions for the always-on single-operator case. (1) Sync approve-before is the industry gold standard but is incompatible with an always-on loop and a single human who sleeps the no-blocking-modal rule ([[feedback_no_blocking_modal_in_monitoring]]) forbids it. (2) The "two-person rule" literally cannot apply there is only one operator; a second human approver does not exist. (3) Capability tokens assume multi-agent / multi-tenant identity governance and signing infrastructure that's heavy overkill for a single local harness and is not where the actual RDCO failure mode lives. (4) Putting an LLM in the verification layer risks confabulation contaminating the gate itself ([[2026-04-19-kingsbury-future-of-everything-is-lies]]), which is why the deterministic tier must remain underneath and own provenance.

Synthesis for RDCO

The four named patterns are not alternatives to pick among; they are four layers of one stack, and the single-operator always-on shape determines how each is adapted rather than whether it is used. Capability-based security contributes a principle, not its infrastructure: the useful idea is per-action scoping with contextual constraints (spend thresholds, rate limits, class-specific TTL-like freshness), which RDCO already approximates via the Tier-A taxonomy, per-class dollar thresholds, and the classifier hard-gate. Dual-control contributes Meta's Rule of Two as a framing lens: the channels surface routinely combines [A] untrusted input (incoming messages, pasted content) with [C] external communication, so the correct invariant is "never let the third property join unsupervised" and the missing "second control" is supplied not by a second human but by the fresh-eyes supervisor plus the mechanical gate. The two-person rule becomes a two-control rule. Human-in-the-loop is retained only in its async form: for the rare irreversible Tier-A class (external email, money, outbound call), the founder is the approver, but via park-with-a-deadline escalation, never a blocking sync interrupt exactly as v0 §6 already specifies.

The supervisor-agent pattern is the right spine for the judgment layer, and v0 is well-aligned with the external literature; I would not redesign it. But the brief's stated #1 build is narrower and more important than "judge the wisdom of an action": it is provenance "can't send a channel message or write durable state that isn't tied to a verified current-turn tool result." That is a deterministic property, and it belongs in Layer 1 (verify-action), not the LLM supervisor, because (a) it must be cheap and run on every outbound message and durable write (Tier-B included, where the supervisor deliberately does not fire), and (b) a confabulating LLM is the wrong thing to ask "is this claim real?" The concrete recommendation: add a provenance/grounding rule to the verify-action mechanical hook that, for any outbound message or durable write, requires every cited id / path / result / "done" claim to reference a tool observation in the current turn's transcript, blocking otherwise. This is the capability-token idea inverted onto data instead of tools the "capability" being spent is a fresh, current-turn observation, and a write without one is unauthorized. It directly closes the [[feedback_no_batched_result_declaration]] failure that motivated the build.

So the recommended pre-send/pre-write gate is the v0 two-layer stack with one addition and one ordering clarification. Layer 1 (deterministic, every write): verify-action hook = existing format/voice checks plus the new provenance/grounding check; fails open on crash for low-stakes mechanics but the provenance rule should fail closed for any claim asserting a result. Layer 2 (judgment, Tier-A only): the /verify-write-action fresh-eyes supervisor for helpfulness-bias / economics / authority, failing closed. Layer 0 (framing): apply Meta's Rule of Two as a standing constraint and the existing class gates (founder send-button, DECISION-APPROVE, PR-workflow, classifier) as the actual authorizers. Build order: ship the provenance check first (it is the cheapest, highest-leverage, fully-deterministic piece and needs no draft-path interception point), then the supervisor pilot on the outbound-email draft path per v0 §7.

Open follow-ups

Related

Sources