Problem-Solution Page
Your AI Agent Can Act. You Do Not Know Where It Should Stop.
An agent that can send emails, update CRM records, issue refunds, book meetings, or delete files needs defined stop points. Not because the AI is untrustworthy, but because every system that can act on your behalf needs to know which actions need human approval and which can run without it.
The Core Problem
3 Action Risk Levels Every Agent Needs Defined
Level 1: Run freely
Reversible, low-impact
Drafting content, reading data, generating summaries, classifying records. These can run without approval. If wrong, a human can correct the output with no cost.
Level 2: Suggest and confirm
Potentially visible or moderately impactful
Sending a customer email, updating a CRM field, scheduling a meeting. The agent prepares the action. A human reviews and confirms. One approval step before it goes out.
Level 3: Human decides
Irreversible or high-value
Issuing refunds, cancelling orders, deleting records, modifying contracts, sending bulk messages. The agent prepares a recommendation. A named person approves before anything executes.
4 Control Layers
What Every Production Agent Needs Before It Runs
Action scope definition
Write a list of every action the agent can take. For each one, assign a risk level: run freely, suggest and confirm, or human decides. If you cannot list the actions, the scope is undefined. An agent with undefined scope can take actions that were never intended.
You can list 5 to 15 specific actions and assign a risk level to each in under 20 minutes.
The answer is "it depends on the task" with no defined list. That is not a scope. That is an open-ended tool.
Human approval gate design
For every Level 2 and Level 3 action, define who approves it, how they receive the approval request, how long they have to respond, and what happens if they do not respond. A timeout that defaults to "proceed" on no response is not a gate. It is a rubber stamp.
Each Level 2 and 3 action has a named approver, a delivery channel, a timeout, and a defined fallback on timeout.
The timeout defaults to "proceed" or the approval step was skipped to save development time.
Audit log for every action
Every action the agent takes should create a log entry: what it did, what data it used, what the outcome was, who approved it if approval was needed, and when. Without logs, you cannot tell customers what happened, investigate a complaint, or prove the agent behaved correctly.
You can pull the last 100 agent actions in under 2 minutes and see what each one did and why.
No structured logs. Or logs that show the output but not what data the agent used to produce it.
Rollback path for high-risk actions
For every Level 3 action, define how to undo it. A refund issued incorrectly can be reversed with Stripe. A customer email sent to 500 people cannot be unsent. Know which actions are reversible and design the rollback procedure before the action runs in production, not after the first mistake.
Each Level 3 action has a documented rollback procedure and it has been tested at least once.
The rollback assumption is "we will handle it if it happens." That is not a rollback path.
Diagnosis
Warning Signs Your Agent Needs Control Work
| What you see | What it usually means | What to do next |
|---|---|---|
| Agent sent an email or message you did not expect | No approval gate on outbound actions, or scope not defined explicitly | Add approval step for all outbound customer communication |
| Agent updated a record with wrong data | No validation on write actions before execution | Add a review step that shows the proposed change before it writes |
| You cannot tell what the agent did yesterday | No audit log or log is unstructured | Add structured logging before adding more capabilities |
| Agent took an action that cannot be undone | No rollback path defined for that action type | Remove or gate all irreversible actions until rollback is designed |
| Team is afraid to give the agent more access | Correct instinct. The scope and controls are not defined well enough | Document the scope and control layers before expanding permissions |
| Agent looped or retried an action multiple times | No idempotency check or retry limit on repeated actions | Add a max-retry limit and check whether the action already completed before retrying |
FAQ
Questions Teams Ask About Agent Control
Does every agent need approval gates?
Level 1 actions (reading, drafting, summarising) do not need gates. Level 2 and 3 actions do. The key question is: if this action runs incorrectly, what is the cost to reverse it?
How do we handle approval without slowing everything down?
Approval gates only slow down high-risk actions, which is the point. Low-risk actions run without gates. Most production agents have 2 to 4 actions that genuinely need approval. The rest can run freely.
What is the right approval channel?
Slack, email, or a simple web interface work fine. The requirement is that a named person sees the proposed action with enough context to approve or reject it in under 30 seconds.
Can we add control layers after the agent is live?
Yes, and it is worth doing even on live agents. Add logging first. It costs least and gives you immediate visibility. Add approval gates next for the highest-risk action types.
How does this relate to autonomous agent architecture?
Control layers are part of the architecture, not an add-on. An agent designed with defined scope, approval gates, audit logs, and rollback paths from the start is far more stable than one that has controls bolted on later.
What about multi-agent systems?
The same rules apply to each agent in the system. In a multi-agent setup, each agent should have its own defined scope. Agents should not inherit permissions from each other by default.
Related Problems
Other Problems Founders Check Around This
Agent Architecture
The scope and the controls should be designed before the agent runs.
If your agent can take actions your team cannot fully explain or audit, the architecture needs review before it gets more capabilities or more access.
Ask About The Architecture