A practitioner guide whose most important argument is a restraint: give an agent the least autonomy the task needs, not the most the model can handle.
Why it matters
Most writing about agents is about how to make them more capable. The durable contribution of this one is the opposite instinct: a working distinction between systems where you control the path and systems where the model does, and a case for not reaching for the second until the first stops being enough.
The distinction it draws is between workflows, where the model and its tools run through paths you defined in code, and agents, where the model decides its own steps and tool use. That line is a behavioral decision disguised as an architecture choice. Every step of control you hand to the model is a step of behavior you no longer specify directly, and the guide’s repeated advice is to hand over only as much as the task demonstrably requires.
It belongs on a site about behavior because autonomy is the dial that sets how much of a system’s behavior is yours to govern. More autonomy buys capability and costs control, and the guide is unusually honest that this is a tradeoff to make on purpose, per use case, not a ladder to climb by default.
Builder read
Start with the least autonomous thing that works, and add autonomy only when it earns its place. A predefined workflow is easier to reason about, test, and trust than an agent that decides its own path, so the burden of proof is on the autonomy, not on the simplicity.
The decision turns on error cost and error visibility. An agent is a reasonable bet where mistakes are cheap, easily caught, or verifiable, which is why coding agents work: tests tell you immediately when the agent was wrong. Where mistakes are expensive or hard to detect, the guidance points toward tighter controls: read-only access, narrower tools, and a human in the loop for consequential actions. Those are behavioral controls expressed as architecture.
The practical move is to design the autonomy deliberately. Decide what the agent may do on its own, what requires a checkpoint, and where it must stop and ask, before you ship, rather than discovering those boundaries from incidents.
Exec read
How much an AI system is allowed to decide for itself is a governable choice, not a fixed property of using agents. The same task can be built as a tightly controlled workflow or as an autonomous agent, and the difference is mostly a decision about how much behavior to delegate and how much to keep under direct control.
The tradeoff is legible once named: autonomy raises capability and cost and the consequence of errors at the same time. For high-stakes work, the responsible default is less autonomy with human checkpoints, and treating that as a deliberate position rather than a failure to be more advanced.
Caveats
The guide is oriented toward building capable systems, with behavior and safety as one consideration among several. It is excellent on the autonomy tradeoff and not a complete treatment of behavioral governance.
Its advice reflects a fast-moving field, and the specific patterns and even the convergence on what an agent is have shifted since it was written. Read the principles, which are durable, over the specific patterns, which evolve.
It is one lab’s practitioner perspective, shaped by the kinds of systems that lab builds. The restraint it counsels is broadly right, but the specifics are a strong starting point, not a standard.
Source
Primary: Building Effective Agents (Anthropic, 2024).
Related
- Prompt Injection - why excess autonomy is also a security surface
- Behavioral Contracts - autonomy boundaries are behavior that gets specified
- Who Owns the Behavior - the autonomy and safety tradeoff is an ownership call
- Failure and Repair - human-in-the-loop is the escalation path made structural