Originally published in Temrel, a weekly newsletter on agentic engineering.
So you have spent time adding hooks and wiring up skills. Your agent verifies its own work without being asked. Then Anthropic push an update, you read the changelog, and get a sinking feeling. They have turned it all off, on purpose.
The vendor selling autonomy just pulled the leash
What changed: recent Claude Code releases made /verify, /code-review, and /deep-research manual-only. The agent no longer decides to run its most expensive behaviours, so now you do. It is obvious why (these are expensive operations and the vendor is absorbing the cost), but it still represents a regression in your productivity.
The search cap: alongside making certain skills manual, there is a session-wide WebSearch limit (default 200) to kill runaway search loops. This one is not remotely egregious. What new information could an agent reasonably gain from the 201st web search?
Why would Anthropic tighten the leash?
In all honesty, it is probably a decent move in aggregate. What percentage of auto-triggered deep research or code review is actually required? We have all had agents run off on research tangents, or take 10 minutes to review a whole codebase after a cosmetic change.
Add the trust angle: would you prefer the agent asks permission for long, token-intensive tasks? Definitely on the API, and probably if you sail close to your subscription limits. But it is a budgetary consideration, not a UX one. What we lose is the times Claude Code genuinely, autonomously uncovers something useful. You might not consider deep research essential for what you are doing, but it can be the only thing that surfaces the unknown unknowns.
Autonomy is a budget, not a slider
Autonomy is a budget consideration first. We are still in the early-Uber era of AI, where vendors heavily subsidise usage. Remember when Uber first started and you could get across town for half the taxi fare? Now it is more expensive. Expect the same for tokens once your organisation is fully dependent on them.
There are now two questions to ask for every hook, skill, and tool:
- What does it cost when it fires?
- What do I lose if the AI must ask me for permission first?
At one company we work with, Dagenta, I built a skill for backtesting price-forecasting models that iterates over hundreds of GB of data in S3. Developing new models with Claude sometimes triggered it, adding hours and tokens to a completion. In that case you definitely want to be asked. A crude mapping of task versus automation:
- cheap and reversible = auto
- expensive, long, or irreversible = manual gate
Run the leash audit on your own agent
Our free tool this week audits every skill, hook, and MCP tool your agent can trigger, to see which should be auto and which should be manually gated. It outputs an analysis with three columns: name, auto or manual, and cost-of-wrong. Rule of thumb: anything taking more than a minute, or touching anything external, should begin life manually gated until it has earned auto status.
You will find it as a new skill, /autonomy-audit, in the temrel-agentic-toolkit. Add it as a skill (run manually, naturally) and it writes an autonomy-audit.md file to your repo root. It makes no changes, only reporting what you might consider changing.
Do this today
- List every auto-triggering behaviour in your agent setup (hooks, skills, MCP tools).
- Tag each with cost-of-wrong: tokens, time, blast radius.
- Flip anything expensive or irreversible to manual for one week. Check your permissions:ask rules in settings.json and the Tool(param:value) rule syntax.
- Note which ones you actually missed. Those earned their autonomy. The rest stay leashed.
Why this matters
The industry narrative is a straight line to full autonomy, but the people with the most usage data (who are also losing money at a vast rate) just drew a line under it. Expect vendors to ship more constraints. Your edge is not maximum autonomy, it is calibration: knowing which behaviours have the right to fire on their own.
Subscribe to Temrel for weekly agentic engineering field notes.
Top comments (0)