How do you stop an AI agent going wrong?

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.

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 does GROX put the approval model into practice?

When GROX is about to send, post, pay, call, or change something on your behalf, it puts up a card describing exactly what will happen and acts only when you press Approve. You can edit the card's wording before approving. Reading, searching, and drafting run without a card, because those actions stay inside the system and produce no external side effect. That split — open path for reversible preparation, gated path for irreversible exits — is the approval model made concrete rather than a setting buried inside each connector.

For work you want to run unattended, GROX lets you set an allowance in advance or flip a routine to autopilot. Those bounds are set by you before the session, not decided silently by the agent mid-run. Trades run inside a size per trade, a stop, and a daily loss cap you set; and a practice mode runs the same strategy with no money at risk. Each of these is the same chokepoint applied to a different action class: the gate moves with the exit, not with the feature.

• Drafting, searching, and researching run at once — no card required.
• Sending mail, posting publicly, paying, calling, or changing shared data shows a card; GROX acts only on Approve.
• You may edit the card's wording before approving.
• Autopilot and pre-set allowances let GROX act alone within bounds you defined in advance.
• Trades run inside size, stop, and daily loss limits you set; a practice mode moves no real money.

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.