Will Ayers
← Back to all postssystems /

Setting Autonomy Boundaries for AI Coding Agents

How to give coding agents room to work without silently delegating consequential product and engineering decisions.

aiagentsautonomyrisk

This is part three of AI Working Agreements. Start with AGENTS.md Is a Communication Protocol for the complete working-agreement structure.

An AI coding agent that asks permission before every edit is frustrating. An agent that treats every request as permission to change anything is dangerous.

The useful position is between those extremes: enough autonomy to complete ordinary work, with explicit boundaries around decisions that are consequential, difficult to reverse, or owned by someone else.

I encode those boundaries in AGENTS.md so they do not depend on the wording of each task.

Autonomy is not one setting

Teams often discuss autonomy as if an agent is either autonomous or supervised. Real engineering work has several independent kinds of authority:

  • inspect files and logs
  • edit local source code
  • add dependencies
  • change architecture
  • modify data models
  • run commands
  • create commits
  • push branches
  • deploy production
  • access or change external systems

Permission in one category does not imply permission in another.

"Fix this form" can reasonably authorize local component changes and focused tests. It does not automatically authorize changing the authentication provider, migrating production data, or deploying the result.

A useful working agreement separates those actions instead of relying on a general instruction to "use judgment."

Start with reversibility and consequence

I evaluate a proposed action along two dimensions.

Reversibility asks how easily the action can be undone. A local CSS edit is easy to revert. A destructive migration may not be.

Consequence asks what the action can affect. Renaming an internal function has a narrow impact. Changing payment behavior has business, legal, and customer consequences even if the code diff is small.

The resulting model is simple:

1Consequence
2                    low                 high
3

4Reversible     act and validate     act locally, ask before release
5

6Hard to undo   explain and ask      stop and require explicit approval

This is a decision aid, not an automatic risk score. It makes the reasoning behind an escalation visible.

Define the default lane

The default lane should cover the work you want the agent to finish without procedural interruption.

Mine is approximately:

1- If a task is clearly scoped and reversible, make the change.
2- Prefer the smallest useful implementation.
3- Follow existing architecture and project conventions.
4- Run focused validation relevant to the change.
5- Report the resulting state clearly.

This allows ordinary implementation work: editing a component, fixing a bug, adding a focused test, updating documentation, or simplifying a local function.

The default lane works because it is bounded. "Clearly scoped" prevents a small request from becoming an unsolicited rewrite. "Reversible" keeps the cost of a mistaken interpretation low. "Existing architecture" prevents local autonomy from turning into silent system design.

Name the approval boundaries

Vague warnings such as "be careful with sensitive changes" are not enough. I list categories that require approval:

  • authentication and authorization
  • billing and payments
  • data deletion
  • database migrations
  • secrets and credentials
  • deployment configuration
  • production releases
  • new external services
  • material dependency or architecture changes
  • user-facing behavior outside the requested scope

The list should match the system. A medical product may add clinical logic and protected health information. A marketplace may add payouts and fraud controls. An embedded system may treat firmware flashing as a release boundary.

Do not copy another team's list without examining your own failure modes and ownership model.

Separate implementation approval from release approval

One of the most important distinctions is local work versus external effect.

I may ask an agent to implement a deployment configuration change. That authorizes a local patch and validation. It does not necessarily authorize applying the configuration to production.

The stages are separate:

1inspect → propose → implement locally → validate → commit → push → deploy

A task can authorize one or several stages. The agent should not infer the rest from momentum.

This avoids a common category error: treating "that looks good" as permission to publish, migrate, or delete.

A clear completion report helps:

1Implementation complete.
2Typecheck and focused tests passed.
3Changes remain local and uncommitted.
4Production was not modified.

The report tells me exactly which boundary we reached.

Questions should not grant write access

Autonomy boundaries also apply to intent.

Questions such as these are exploratory:

  • Could this API be simpler?
  • Should we move this state to the server?
  • How hard would it be to replace this dependency?
  • Is this migration safe?

An eager agent can interpret them as indirect commands. My working agreement says questions are read-only: answer first, then offer implementation if appropriate.

This protects architecture and product discussions from accidental anchoring. We can evaluate several directions before a patch makes one of them feel inevitable.

Escalate with a decision, not a permission request

When an agent reaches a boundary, "Should I continue?" is rarely enough information.

A useful escalation includes:

  1. What changed or was discovered
  2. Why the current plan no longer fits
  3. The smallest viable options
  4. The consequences and risks of each option
  5. A recommendation
  6. The exact approval needed

For example:

1The requested field cannot be added safely without changing the shared schema.
2

3O1  Add a nullable column with no backfill.
4O2  Store the value in existing metadata.
5

6K1  O1 requires a production migration.
7K2  O2 weakens type safety and queryability.
8

9R1  Use O1, deploy the schema first, then release the application change.
10

11Approval needed: create the migration and deployment plan. Do not apply it yet.

The agent has stopped at the correct boundary without returning the entire problem to me.

Avoid permission loops

Overly broad approval rules can make an agent ask about routine implementation details:

  • whether to rename a private variable
  • whether to run the typecheck
  • whether to update an affected test
  • whether to use an existing utility

Those questions add latency without protecting a meaningful decision.

The working agreement should explicitly permit small course corrections that stay inside scope. The agent can make them and summarize afterward.

Ask when the correction changes:

  • scope
  • architecture
  • dependencies
  • data shape
  • external behavior
  • release state
  • risk ownership

This creates a practical distinction between implementation judgment and product or system authority.

Validation does not expand authority

Passing tests can show that an implementation behaves as expected under tested conditions. It does not authorize the implementation.

A billing change with perfect test coverage still requires billing approval. A migration that passes locally still requires a rollout decision. A dependency with a clean audit can still create an unacceptable vendor commitment.

Validation reduces technical uncertainty. Approval resolves ownership and consequence. The working agreement should keep those concepts separate.

Build trust through bounded evidence

Autonomy can expand as the system becomes more reliable, but it should expand by category rather than by feeling.

A useful progression is:

1Level 1  Inspect and recommend
2Level 2  Make local changes with review
3Level 3  Complete bounded tasks and validation
4Level 4  Commit or open pull requests when requested
5Level 5  Perform approved external actions with explicit safeguards

Moving up requires evidence: consistent patches, accurate status reporting, reliable validation, and good escalation behavior.

Even at higher levels, some boundaries remain. Trust does not make destructive operations reversible or transfer business accountability to a model.

Encode the policy concisely

A starting section might look like this:

1## Autonomy
2

3- Make clearly scoped, reversible local changes without asking.
4- Prefer the smallest change that solves the requested problem.
5- Ask when implementation reveals meaningful alternatives or changes scope.
6- Ask before modifying auth, billing, deletion, migrations, secrets,
7  deployment configuration, or external services.
8- Treat questions as read-only unless the user explicitly requests changes.
9- Local implementation does not authorize commit, push, migration, or deploy.

Adapt the categories and stages to your environment. The objective is not a longer warning list. It is a shared understanding of where the agent can move quickly and where human judgment must re-enter the loop.

Good autonomy feels uneventful. Routine work proceeds without interruption. Consequential decisions arrive with enough context to resolve them. Nothing important happens because permission was assumed.

Resources