Most of the agent threads here end up arguing about frameworks when the real disagreement is about how much rope the agent gets. This is the model I use when deciding that, written for people who have to ship the thing and then support it.
Autonomous does not mean unsupervised. It describes who makes the tactical decisions. You still set the goal, the constraints and the resources the agent can reach. The agent decides the steps between those.
The Loop Is What Makes It An Agent
A prompt returns a completion. An agent acts, observes the result of that action, judges whether it moved closer to the goal, and picks the next step. That loop can run for minutes or for days.
The loop is also the only place guardrails actually hold. A rule written into the system prompt is a suggestion the model can talk itself out of. A rule enforced between the decision and the tool call is a rule.
Autonomy Is Per Connection, Not Per Agent
This is the part most designs get wrong. Teams pick one autonomy setting for the whole agent, then discover that the same agent reads a calendar and issues refunds.
Set the level per tool instead. Read only lookups can run unattended. Writes to systems you own can run with logging and a rollback path. Anything that spends money, sends mail to a customer or touches production data earns a human in the loop, or at minimum a hard cap the runtime enforces.
The useful question stops being "do I trust this agent" and becomes "what is the cost of undoing this specific action."
Where It Earns Its Keep
Traditional automation executes a predefined sequence and is extremely reliable inside the scope its author imagined. It fails the moment reality steps outside that scope.
Agents handle the variability instead. A research agent that hits a paywall finds another source. A coding agent whose first approach fails the test suite tries a different one. That recovery behaviour is the whole reason to pay the extra cost and unpredictability of an agent, so if your task never varies, write the script.
The Honest Limits
The failure mode nobody plans for is a confident wrong step taken quickly, then built on. Observability matters more than raw capability here. If you cannot see which tool ran, with what arguments, and why the agent thought that was the right move, you cannot debug it and you certainly cannot widen its permissions.
Start narrower than feels necessary. Widen one connection at a time, once the logs give you a reason to.
I wrote the longer version, covering the levels of autonomy, the supervision spectrum, guardrail patterns, verification and override, and the risks stated honestly, in the autonomous AI agents guide.
