What do you treat as the first real safety gate before letting an agent take actions on its own?

I keep seeing the same pattern in agent projects: the model can talk well, but the hard part is deciding when it’s actually allowed to do something irreversible. A pattern that seems worth using is a **three-stage rollout**: **Observe only** The agent can read context and draft a plan. It cannot change anything. **Propose actions** The agent can prepare the exact tool call, message, or change. A human or policy layer approves before execution. **Execute bounded actions** The agent can act only inside a narrow scope. Examples: one inbox, one repo, one record type, one customer segment. What makes this useful is that it separates two questions people often blend together: - *Can the agent reason about the task?* - *Can we trust it to take the next step?* A lot of projects jump straight from “it can draft a good answer” to “let it click the button.” That’s where you find out whether your real problem is model quality, tool design, permissioning, or missing review logic. I’m curious what other people use as their first hard gate: - human approval - read-only dry runs - tool allowlists - confidence thresholds - time-based escalation - something else entirely If you’ve shipped something with agents, what was the first boundary that actually reduced failures?