Your agent is at "A2"? Prove it: ask it to merge.

Chapter 13 - Autonomy is set by harnessability × blast radius, never by enthusiasm

The Agentic Development Lifecycle - Chapter 13 - Part III — The Lifecycle

Your AI Agent Is at A2? Prove It: Ask It to Merge.
Autonomy is determined by harnessability × blast radius, not by how confidently you instruct an AI agent.
You say your coding agent operates at A2. It can complete tasks, run tests, and open pull requests for human review.
But here's a simple question:
Can it merge its own pull request?
If yes, your agent may have more authority than your policy allows.

The Autonomy Ladder

Higher isn't always better. A dependency update might be suitable for A4, while a payment-system change may require A0 or A1.
Autonomy should depend on the type of work, not one global setting.
Instructions Aren't Controls
Telling an agent not to merge isn't enough if it has merge permissions.
Real controls include:
• Restricting repository permissions.
• Isolating agent workspaces.
• Protecting production credentials.
• Requiring CI checks before merging.
• Preventing agents from modifying their own security boundaries.
Don't just tell an agent what it shouldn't do. Remove its ability to do it.
What Determines the Autonomy Ceiling?

Two factors matter:

1. Harnessability: How reliably can your tests, types, boundaries, and automated checks detect or prevent mistakes?
2. Blast radius: How much damage could a mistake cause? Strong verification doesn't automatically justify high autonomy when the potential impact is severe. Blast radius can veto higher autonomy. For ordinary feature development, A2 may remain the sensible ceiling when automated checks cannot reliably verify intended behaviour. Where A4 Makes Sense A4 is promising for low-risk, mechanically verifiable tasks, such as: • Dependency updates. • Formatting and linting. • Dead-code removal. • Documentation generation. • Mechanical migrations with equivalence checks. • Architectural drift detection. These tasks offer opportunities for continuous automation without giving agents unrestricted authority over consequential changes.

Try This
Take an agent you classify as A2 and give it a harmless task in an isolated repository.
Ask it to make the change, run tests, and open a pull request.

Then check:
• Can it merge?
• Can it push directly to shared branches?
• Can it access unnecessary credentials?
• Can it modify the checks that constrain it?
Ask what the agent can do—not just what you've instructed it to do.
If it can merge despite your A2 policy, fix the permission boundary before granting more autonomy.
The goal isn't maximum autonomy. It's the right amount of autonomy for each task, enforced by real controls.

---

📖 Read the full chapter: Chapter 13 — The Autonomy Ladder
Next: measuring autonomy and harnessability across your engineering organisation.

Your turn: What level is your coding agent really at—and if it's A2, can it merge?