Trustworthy Autonomy / Chapter 04 of 09

Autonomy requires
a Dial

A coding agent can inspect a repository, prepare a patch, or merge it. Each action needs its own grant of authority.

August 10, 20264 min read

Chapters in this collection 04 / 09

Autonomy is the freedom to act within a delegated boundary. A useful boundary changes with the action, its consequences, and the conditions around it.

Imagine a coding agent discovers a deprecated dependency. It could explain the problem, edit a scratch branch, open a pull request, merge the change, or publish a new package version.

Those actions deserve different permissions. A system that labels the entire agent “autonomous” has skipped the useful question: autonomous to do what?

The same agent, different kinds of freedom#

Reading a repository may be allowed within a defined scope. Preparing a patch in an isolated branch may be routine. Merging into a protected branch may require approval from a maintainer. Publishing a package can carry a different boundary again.

The agent can make the patch reviewable while it waits: tests, compatibility notes, affected packages, and recovery steps. Useful work continues within its current authority.

A correct diagnosis does not create a new permission. Confidence is one input to an action decision; authority also depends on scope, reversibility, environment, cost, and who has accepted responsibility.

Delegation is conditional#

The underlying philosophical idea is consent. Someone entrusts a system with a purpose and a bounded power to pursue it. That permission can expire or be withdrawn.

As a system demonstrates useful performance, specific permissions may expand under agreed criteria. Success in a scratch repository does not automatically authorize changes to a shared one.

Explore the seven levels below. They describe possible grants of authority, not a ladder every agent should climb.

An idea in practice

Set the authority

An illustrative policy ladder. Selecting a level explains it; no real action is executed.

0 · Observe

Level: 0
Writes: None

Inspect the repository

What happens: Read dependency manifests and test reports in the permitted repository.
What it means: Access allows observation; it does not authorize changes.
What the system does: Stay within the approved files and query budget.

Inspect the example record

{
  "autonomy_level": 0,
  "allowed": [
    "read repository"
  ],
  "writes": false
}

1 · Analyze

Level: 1
Writes: Assessment only

Explain the compatibility problem

What happens: Identify deprecated APIs and the packages that depend on them.
What it means: The agent may interpret evidence without changing shared code.
What the system does: Record the affected interfaces and remaining uncertainty.

Inspect the example record

{
  "autonomy_level": 1,
  "allowed": [
    "analyze",
    "record assessment"
  ],
  "shared_code_changes": false
}

2 · Recommend

Level: 2
Change status: Proposed

Propose the upgrade

What happens: Recommend a target version and explain its compatibility and maintenance tradeoffs.
What it means: A recommendation is not permission to install the dependency.
What the system does: Name the proposed change and the checks it needs.

Inspect the example record

{
  "autonomy_level": 2,
  "action": "dependency upgrade",
  "status": "recommendation"
}

3 · Prepare

Level: 3
Boundary: Isolated branch

Create a reviewable patch

What happens: Update code and run tests in the granted scratch environment.
What it means: Preparing an artifact can be authorized separately from publishing it.
What the system does: Keep the diff, test results, and migration notes together.

Inspect the example record

{
  "autonomy_level": 3,
  "scope": "isolated branch",
  "artifact": "patch and test results",
  "merged": false
}

4 · Approval

Level: 4
Approver: Repository maintainer

Execute the approved change

What happens: A maintainer approves one exact patch for one repository.
What it means: Approval for this patch does not authorize a larger rewrite or a package release.
What the system does: Check patch identity, scope, expiry, and continued validity before acting.

Inspect the example record

{
  "autonomy_level": 4,
  "action": "merge approved patch",
  "approval_required_from": [
    "maintainer"
  ],
  "if_no_approval": "retain patch for review"
}

5 · Policy

Level: 5
Boundary: Documentation fixes

Automate a bounded class of changes

What happens: A predefined rule permits documentation-only fixes after the required checks pass.
What it means: The runtime still verifies the changed paths and policy conditions.
What the system does: Evaluate the actual diff against the policy before merging.

Inspect the example record

{
  "autonomy_level": 5,
  "policy": "documentation-only maintenance",
  "required": [
    "allowed paths",
    "passing checks",
    "no executable changes"
  ]
}

6 · Delegated

Level: 6
Boundary: One maintenance mission

Work inside a mission contract

What happens: The agent may plan and complete a sequence of maintenance tasks within a defined repository and deadline.
What it means: Tool, time, cost, and publication limits remain enforceable and revocable.
What the system does: Escalate when the plan reaches a boundary.

Inspect the example record

{
  "autonomy_level": 6,
  "scope": "one approved repository",
  "limits": [
    "deadline",
    "cost",
    "permitted paths",
    "publication rights"
  ],
  "revocable": true
}

Put the dial outside the agent#

Each action should declare its level, permitting policy, affected scope, reversibility, required approvers, and behavior while approval is absent. If authority is ambiguous, execution waits at the boundary.

The surrounding system enforces these conditions. A model-generated claim that “the user would probably agree” cannot substitute for an approval record.

The dial also turns down. Stale evidence, exhausted budgets, an unexpectedly broad diff, or a revoked permission can reduce what is allowed halfway through a task.

Try the same proposed action in a scratch repository, a shared feature branch, and a protected main branch. A well-designed system can give three different answers, each with a reason someone can inspect.

Give the agent enough freedom to be useful, and make the boundary legible to everyone affected.

Further reading: Saltzer and Schroeder's principles of information protection, especially least privilege and fail-safe defaults.