Section 1
The distinction that decides the risk
The dividing line is not intelligence. It is whether the system can act on the world without asking. A model that drafts an email and hands it to you is a tool. A system that reads your inbox, decides which messages need answers, writes them, and sends them is an agent. The technical difference is small. The difference in what can go wrong is not, because the second can be wrong in a way that reaches other people before you see it. So the design question is not how capable the system is. It is how far a mistake travels before a human notices. That question should be answered on paper before anything is connected, in the same way you would scope a new product, as [AI Automation in Product Development: From Idea to Launch](/blog/ai-automation-in-product-development-from-idea-to-launch) describes.
Section 2
Where agents work today
Three properties predict success, and tasks with all three tend to work now. Bounded: a defined end state and a small set of tools, not open access to everything. Reversible: a mistake can be undone without a phone call to a customer. Verifiable: correctness can be checked automatically, by running a test, matching a total, or confirming a record exists. Research compilation, data reconciliation, code migrations with a test suite, pulling information from documents into a structured table: all three hold, and results are genuinely good. The tasks that fail are the mirror image. Open-ended goals, irreversible actions, success criteria only a person can judge. Contacting customers sits squarely there, which is why it keeps producing incidents.
Section 3
Permissions are the real control surface
Every published agent failure comes down to the same thing: the system could do more than the task required. Grant the narrowest capability that completes the job. Read-only where reading is enough. A test environment before production. Spending limits enforced by the payment system rather than the instructions. Separate credentials per agent so you can revoke one without breaking everything. Then add the two limits people forget. A step budget, so a loop that goes wrong stops rather than running all night. A cost ceiling enforced by the platform, because an agent retrying a failing call is billed for every attempt. Write down the worst thing this configuration could do if every decision it made were wrong. If that answer is unacceptable, change the permissions, not the prompt.
Section 4
Design the checkpoints, not the autonomy
The productive question is not how autonomous to make it. It is where a human should be required to look. A workable pattern: the agent works freely inside a sandbox, then pauses at defined gates. Before anything external is contacted. Before money moves. Before a record customers can see is changed. Before a file is deleted. Run it in proposal mode first, where it prepares actions and a person approves them in a batch. You keep most of the time saving, you generate a log of what it wanted to do, and you learn its failure patterns while they are still free. Only after weeks of that record should any gate be removed, and only one at a time.
Section 5
Reading the current hype accurately
The gap between capability and marketing is unusually wide in this category. Products described as agents are frequently a workflow with a model in one step, which is fine, and not what the word implies. Three questions cut through a demo. What happens when the tool it calls returns an error. What does it do when the goal is impossible. Show me the log of a run that went wrong. A vendor who cannot produce the third is not showing a production system. The uncomfortable truth about the current wave is that reliability engineering, retries, verification, monitoring, is most of the work, and not the part being demonstrated. Broader forecasts on where this is heading are collected in [What's Next for AI Automation? Predictions from Experts](/blog/whats-next-for-ai-automation-predictions-from-experts).
Section 6
What to measure, and whether you are ready
Task completion rate is the headline, but measure it end to end, without human rescues counted as successes. Add intervention rate, average steps per task, cost per completed task including retries, and time from failure to detection. That last one matters most. An agent that fails openly is manageable. One that fails quietly and keeps going produces a mess someone finds a week later. You are ready to run agents if you have a task that is bounded, reversible, and automatically verifiable, plus an owner who reviews logs weekly. You are not ready if the appeal is that it will handle work nobody currently has the capacity to check. Explaining any of this to a board is a separate skill, addressed in [Storytelling in the Age of AI and Automation](/blog/storytelling-in-the-age-of-ai-and-automation).