A behavioral framework that decides, action by action, when an AI assistant should act on its own, tell you afterward, advise you, or stop and wait for your approval.
An assistant that only answers questions can be wrong without lasting damage. An assistant that updates records, submits transactions, or sends messages can do harm that is hard to undo. Most teams handle this with a binary switch: confirm everything, or confirm nothing.
Both extremes fail. Confirming everything trains people to click "Approve" without reading, which is worse than having no gate. Confirming nothing hides consequential actions behind an undo button that may come too late.
I designed a shared behavioral layer that every agentic pattern inherits. Each action is classified by risk before it runs, and the risk sets how much human involvement it needs. Human-in-the-loop (L3, L4) and human-on-the-loop (L0, L1) become positions on one scale, with an advisory level between them.
Select a level to see how it behaves and how it appears in the interface.
The framework runs an ordered set of checks. The first "yes" decides the level, so the most restrictive condition always wins. Pick a scenario, or toggle the checks yourself.
A behavior spec is read by prompt engineers, developers, evaluators, and designers, and each of them needs to know which lines are hard limits. I tagged every statement so the spec translates cleanly into system prompts and automated checks.
Goes straight into system prompt instructions or hardcoded logic. A violation is always wrong.
Holds unless a documented exception applies. Exceptions are written inline, next to the heuristic.
Shapes designer and implementer judgment. Never appears in prompts or automated checks.
Three rules anchor the whole system:
At L3 and L4, an action moves through fixed states that patterns may not skip or collapse. Most confirmation dialogs offer only approve or cancel. Here the user can change the proposed action in place, and a rejected action produces no side effects, including partial ones.
The framework covers two kinds of gate: an action gate, before the assistant changes something in a system, and a content review gate, before generated content is sent or stored. The content gate keeps the original output and the approved version, with the diff, as a traceability record.
Every oversight moment at L2 and above must carry six elements. A generic "Are you sure?" fails this test.
| Element | What it covers |
|---|---|
| Action | An active-verb statement of exactly what will happen |
| Scope | Targets, quantities, and boundaries of the action |
| Impact | What changes, in plain language, and who or what is affected |
| Reason | Why this level of oversight applies right now |
| Alternatives | Edit and reject paths, as prominent as approve |
| Recovery | What cancelling means, and what can and cannot be undone |
If people rubber-stamp approvals, the system has too many gates or too little context. I wrote the friction rules and anti-patterns as explicitly as the safety rules, so teams can push back on over-gating with the same authority as under-gating.
Undo is a recovery tool. It does not replace oversight before the action.
An approval that does not show what will execute is a rubber stamp.
"Always allow" for a whole category, with no re-prompt for higher-risk actions.
Advisories on every response. People stop reading them, so they must stay rare.
When the assistant runs without approval, every step goes into an expandable action log, successful calls included. Exceptions do not wait in the log for someone to notice: a low-confidence step pauses and escalates to L3 for that step only, and an unexpected side effect blocks further execution.
[14:32:01] ✓ Called search_docs · query "Q3 revenue" · 3 results · View details [14:32:04] ✓ Read vendor-master · LF-00442 · View details [14:32:09] ⚠ Low confidence on intent · Paused for clarification
Voice users are often multitasking, which strains every assumption a screen-based gate makes. These questions are still open. I kept them in the spec as flagged items so no voice pattern ships as if they were solved.
Happy to walk through this framework, or any of my work, in more detail.