Lesson 27 — Involvement modes and host gating

Outcome

Separate “how often should the agent consult me?” from “what actions may execute without host approval?”

Why this comes now

A delegated agent can still attempt a destructive command. Conversational autonomy and execution permission are different axes.

Understand

Execution Mode answers who writes code. Involvement Mode is a preset over escalation reasons. Gating Tier is host enforcement over semantic tool capability classes such as read/write/exec.

An agent saying “this is safe” is a Claim. Host observation/classification is enforcement evidence. Unknown classification should not silently become safe when the consequence matters.

Build the real project

1. Implement policy snapshot captured immutably on Run start.
2. Define minimal Involvement Mode presets based on observed escalation behavior, not old names alone.
3. Add semantic host gating classes and decision path for blocked actions where the provider protocol exposes tool calls.
4. Keep gating independent from involvement.
5. Add tests: Delegate still blocks a destructive host-classified action; Teach/Collaborative mode unavailable on strategy without interactive Decision capability.
6. Never allow destructive-action Decisions to auto-default.

Completion gate

Policy behavior is derived from explicit snapshot/capabilities. Changing global settings later does not rewrite what policy a historical Run used.

Pitfalls to avoid

Do not map permissions by provider-specific tool names throughout the domain. Do not assume the agent's self-classification is the only safety layer. Do not make Delegate mean “anything goes.”

References

OpenHands security/confirmation concepts: https://docs.openhands.dev/sdk/arch/security ; Mux fail-closed policy behavior: https://github.com/coder/mux/blob/main/docs/config/policy-file.mdx

Checkpoint

M10 is complete when human judgement is a real end-to-end path rather than a UI concept.