How do you stop an AI agent going wrong?
You stop an agent by deciding which actions need a human yes before they leave the system, and by making that decision in one place. Scatter the gate across every tool and you will miss a path. Put it at a single chokepoint, prefer reversible steps first, and treat irreversible work as something that must earn explicit approval.
What does an approval model actually control?
An approval model is not a personality setting. It is a rule about which proposed actions may execute without a fresh human decision. Drafting text, searching, summarising notes, and building a private preview usually sit on the free side of the line. Sending mail, posting in public, moving money, deploying to production, or changing shared calendars sit on the gated side.
The useful design question is not “does the agent feel careful?” but “which side effects can leave the sandbox without me?” If the answer differs by channel, you still need one place that knows the answer before anything is dispatched. Otherwise each connector invents its own half-policy and the strictest rule never applies to the path you forgot.
Which actions should be reversible by default?
Prefer work that can be undone, versioned, or discarded. Local drafts, staged branches, held messages, and dry-run trades teach the agent your intent without burning reputation or capital. Irreversible steps—public posts, settled payments, live deploys, signed agreements—should require a deliberate pass through the gate, not a silent default.
Reversibility is a property of the world, not of the model. A deleted cloud object with no recycle bin is irreversible even if the prompt sounded casual. A queued email with a delay is still reversible until send. Classify the side effect, not the wording of the request.
| Action class | Typical side effect | Default stance |
|---|---|---|
| Draft and research | Private artefacts only | Allow without prompt |
| Queued outbound message | Can cancel before send | Allow with short delay |
| Public post or live mail | Hard to fully retract | Require explicit approval |
| Payment or on-chain settle | Funds move | Require explicit approval |
| Production deploy | Users see the change | Require explicit approval |
Why put the gate at one chokepoint rather than every feature?
Feature-level toggles feel thorough and fail open. One team hardens email; another ships a social connector; a third adds trading; overnight routines appear later. Each path learns a different habit. The incident is almost always the path that never met the policy.
A single chokepoint sits where intent becomes an external act: one conversational surface that routes work to models, tools, and data, then either executes or holds. You review the proposed action once, with full context, instead of hunting switches inside every integration. GROX is built as that kind of surface—memory, connectors, code, and routines share one thread—so the approval question can be asked before mail leaves, code ships, or a trade runs, rather than inside each capability in isolation.
A simpler tool can still be the better choice. If you only need a single guarded mail merge, a dedicated client with a built-in confirm step may beat a general agent. Reach for a broad agent when the same operator must cross tools without losing the thread—and then insist the gate stays central.
- Chokepoint
- The one layer where a proposed external action is allowed, held, or refused before side effects escape.
- Reversible action
- Work you can undo, discard, or roll back without lasting harm to people, money, or public record.
- Irreversible action
- Work whose effects cannot be cleanly unwound: settled value, public speech, production changes, signed terms.
- Approval model
- The standing rules that map action classes to allow, delay, or ask—independent of any single feature screen.
How do you keep useful autonomy without silent damage?
Autonomy belongs on reversible loops. Let the agent research, draft, preview applications, and prepare routines while you sleep; wake a human when the next step would spend trust or money. Autopilot and unattended objectives only stay sane if irreversible exits still pass the same gate they would in daylight.
Write the policy in plain language you could hand to a colleague: what may auto-run, what queues, what always asks, and what is forbidden in this workspace. Review failures as routing bugs—did the action bypass the chokepoint?—not as proof that “AI is reckless.” The fix is almost always a clearer map from side effect to gate, not a longer system prompt.
- List external side effects you actually use: mail, chat, social, calendars, deploys, payments, trades.
- Mark each as reversible, delayed-reversible, or irreversible.
- Bind irreversible and delayed classes to one approval chokepoint.
- Keep drafts, previews, and research on the open path so daily work stays fast.
- Revisit the map when you add a connector; new reach is a new exit.
Common questions
What is the difference between a confirm button and an approval model?
A confirm button is a prompt on one screen. An approval model is a standing map from kinds of side effect to allow, hold, or ask, enforced wherever actions leave the system. Buttons without a model get skipped on new paths. A model without a single chokepoint fragments into per-feature habits that disagree under pressure.
Should every agent message require approval?
No. Requiring a human yes on pure drafts and research creates alert fatigue, then people approve blindly. Gate the exits that change other people’s inboxes, public channels, production systems, or balances. Leave reversible preparation open so the agent can still gather context and stage work you may reject in one glance.
Why not rely on the model to refuse bad actions?
Models infer intent from text; they do not own your risk budget. The same wording can be a harmless rehearsal or a live order depending on which tool is connected. Policy belongs in the execution path that can actually send, pay, or deploy. Treat model caution as a help, not as the control that replaces a chokepoint.
When is a simpler tool better than a general agent?
When your world has one external action type and a mature confirm flow already—for example a single payment tool or a mailing list platform. A general agent earns its keep when one operator must cross mail, code, calendars, and markets without dropping context. In that case, keep approval central rather than re-learning gates inside each add-on.