the-custodian/docs/agent-autonomy-decision.md

# Agent-specific supervised and autopilot modes

Founder decision, 2026-09-28, `GOVERN @ estate`.
Recorded under CUST-WP-0073-T01. This supersedes the proposed permanent choice
between observation-only agents and unrestricted deployment access.

## Accepted direction

Autonomy is a characteristic of an identified agent, scoped to the work it is
trusted to perform. Start agents in **supervised-mode**. Record how often the
supervisor accepts privileged-action proposals unchanged and how well those
exact proposals work when executed. Only a demonstrated record of successful
operation without adaptation or refinement supports promotion to
**autopilot-mode**. Autopilot has both a cost budget and a risk limit in EUR,
which the supervisor can tune per agent and scope.

This decision accepts the model. It does not promote an agent, choose numerical
limits, authorize a live credential cutover or claim runtime enforcement exists.

## Minimal operating contract

An agent instance/assignment carries its stable identity, mode, supervisor,
allowed action/target scope, execution-profile revision and reference to its
promotion/limit decision. Mode persists across sessions. Trust in one scope does
not automatically grant trust in another. New scopes start supervised; material
model, tool-profile or execution-environment changes require a supervisor review
of whether prior evidence still applies.

In supervised-mode, ordinary already-authorized preparation, reads, local edits
and tests continue. For a privileged action the agent prepares the exact action,
target, expected result, verification/rollback, cost estimate and risk estimate.
The supervisor approves that proposal or performs it through the privileged
execution path. The receipt records whether approval or human execution was
needed. Approval is bound to the reviewed proposal revision; changing that
revision requires review again. The agent cannot approve itself.

In autopilot-mode, a privileged action may run without per-action approval only
inside the agent's granted scope and both monetary limits. Missing estimates,
expired grants, insufficient remaining budget, unbounded risk, or actions outside
scope return that action to supervision. Existing human-only lanes remain
human-only unless explicitly changed by the governing authority. Mode and work
record `lane` are separate dimensions; effective authority is their intersection.

## Evidence for promotion

Use existing approval and execution receipts, keyed by agent, scope, profile
revision and a stable proposal ID/digest. Record:

- the original proposal, supervisor disposition (unchanged / revised /
  rejected), revisions and reason; pending/withdrawn proposals stay visible;
- approval and execution identities, timestamps and the exact executed revision;
- outcome verification, interventions, rollback/recovery, observed cost and
  realized loss/incident evidence. Store references, not credentials.

For a declared review window, report counts as well as rates:

- **Unchanged acceptance rate:** proposals accepted without changes divided by
  all adjudicated original proposals. Revised and rejected proposals remain in
  the denominator; retries do not become fresh successes.
- **Unchanged execution success rate:** original proposals executed as accepted,
  passing the agreed verification with no corrective refinement or rescue,
  divided by all executed original proposals with completed verification.
  Execution of a supervisor-revised proposal does not earn an unchanged success.
- Also report pending/unverified outcomes and supervisor interventions/time.
  Approval without execution is not a successful outcome. No observations means
  unknown, never 100%.

The supervisor promotes explicitly for a named scope using an agreed minimum
sample, review window, acceptance/success thresholds and incident tolerance.
These values are not set by this decision; no default percentage grants access.
Successful harmless work alone does not establish competence for higher-risk
privileged actions. Promotion, revocation and limit changes retain history.
The supervisor can reduce autonomy immediately; failed verification or missing
enforcement stops further autonomous privileged actions pending review.

## Two distinct EUR controls

**Cost budget** bounds attributable spend and commitments over an explicit period,
including execution costs and resources/services the action commits to. Reserve
the estimated maximum cost before execution, reconcile actuals afterwards, and
count concurrent reservations against the same remaining budget. Unknown cost is
not free. Record the budget source, currency and reset period. Do not confuse a
token limit or provider subscription with a complete euro-denominated budget.

**Risk limit** bounds potential loss, separately from normal spending. Proposed
operational interpretation for each grant: a conservatively assessed credible
loss bound per action plus aggregate outstanding exposure from concurrent or
dependent actions. Include recovery expense, service interruption and data loss
where applicable, with assumptions and uncertainty. An expected-loss average
alone must not hide a much larger credible downside. An unpriced or unbounded
consequence requires supervision. EUR limits do not price away human-only or
other non-monetary prohibitions. The supervisor accepts the valuation method
and the action/exposure limits when granting autopilot; the agent cannot raise
its own limit or declare its own estimate authoritative.

Before enabling autopilot, verify that the execution path enforces reservations,
limits and revocation across concurrent actions. Recording fields in a manifest
does not enforce a budget. Until that proof exists, the mode remains supervised.

## Credential boundary and existing owners

Keep admin credentials out of the agent's direct reach in both modes. A scoped
privileged execution path performs approved actions in supervised-mode and
policy-authorized actions in autopilot-mode, returning sanitized outcome evidence.
Unrestricted sudo, admin kubeconfig access or unreviewed GitOps deployment would
bypass that path. Separate identities/isolation remain necessary, but the
observation-only profile is the supervised starting profile, not a permanent
limit on what an agent may accomplish.

Reuse existing boundaries rather than build another supervisor service:

| Concern | Existing surface / limit |
|---|---|
| Agent identity, mode and performance | Consumer-owned agent instance/assignment records; `agentic-resources` performance loop. Its broader workforce inventory/assignment contracts are still proposed. |
| Exact human approval and execution outcome | `approval-engine` approval object, `informed-decision` supervisor presentation, execution receipts. State Hub decisions record governance; they are not runtime approval tokens. |
| Runtime enforcement and credential custody | `glas-harness`, selected rein and sandbox; existing authorization and credential-owner paths. A prompt or mode label grants nothing. |
| Monetary authority | `fin-hub` budget source, with execution accounting supplied by the relevant runtime/service. |
| Risk judgement | Supervisor-approved estimates; `risk-nexus` can hold evidence but is not a live EUR risk gate. |
| Work and review evidence | Existing CUST-WP-0073 tasks and State Hub progress; no new task/workplan or service. |

## Bounded application to CUST-WP-0073

T01's policy choice is resolved by this decision. T02 implements and proves the
supervised starting boundary and records the existing execution path selected;
T04 adds per-agent mode and proposal/outcome evidence to guidance and the chosen
existing receipts. First implementation may use reviewed file records and
existing receipts. No new dashboard, automatic promotion engine, monetary risk
estimator or general workforce system is required to finish credential separation.

Autopilot is a promotion option requiring its own concrete grant and demonstrated
enforcement, not an activation promised by this workplan. No such grant exists
from this decision. T03's annotation policy and T05's deferred rotation remain
unchanged. CUST-WP-0071 retains its measurement and weekly-review scope.

## Supervised record in use

The initial consumer-owned record is
`.kaizen/agents/custodian-codex/supervision.json`. Generate its descriptive report:

```bash
python3 scripts/summarize_agent_supervision.py .kaizen/agents/custodian-codex/supervision.json
```

For each future scored proposal, retain the original digest before submission,
the supervisor's approval reference and approved digest, then the executed digest
and verification receipt. Use one stable proposal ID across revisions. Record
`refinement_or_rescue` explicitly. Accepted revised proposals, rejections and
rescued executions cannot earn unchanged success. Pending/unverified outcomes
remain visible. These records contain references and outcomes, never credential
values or executable approval tokens.

Earlier conversation authorization is retained as `unscored` where an exact
submitted revision was not recorded. It is not backfilled into promotion evidence.
The initial rates are unknown. The utility is descriptive and grants no authority;
autopilot remains disabled and the interactive runtime has not been migrated.
The existing sand-boxer isolation mechanism has a separate non-model proof in
`docs/evidence/2026-09-28-supervised-sandbox-proof.json`.