Date Compiled: 2026-04-28
Type: concept — factory-methodology
Related Questions: agent-autonomy, delegation-policy, operating-policy-for-agents, multi-agent-governance
Related Articles: him-model, superada-enterprise-crew, superada-multi-agent-architecture, Kelly router, super-ada
Source Attribution: raw/superada/blog-three-policies.md · compiled/sources/superada-multi-agent-architecture.md

Autonomy Policy v3 — Delegation That Actually Works

Overview

The Autonomy Policy v3 is the third and current iteration of the Enterprise Crew's operating policy for agent decision-making. It evolved from two earlier versions that each fixed a specific failure mode.

The core insight of v3: delegation is not leverage unless the delegate has context and availability.

The Three Versions

Version 1: Stop Asking for Permission When the Threshold Is Clear

What it fixed: Agents treating every decision as requiring human approval. Routine work was constantly escalated, creating a bottleneck at the human operator.

Core rule: If a task is internal, reversible, and verifiable, act first. Escalate only when a threshold is crossed.

Introduced:
- Four autonomy buckets: Full-Auto · Auto-With-Notify · Approval-Gated · Never Autonomous
- The human reviews thresholds, not routine work
- The "tattoo rule": act from live evidence, not stale memory

The failure mode it solved: Anxious intern behavior — asking for permission on work that didn't need it, slowing everything down.

Version 2: Named Authority and Terse Reporting

What it fixed: General autonomy principles with no agent-specific accountability. Everyone knew the rules in theory, but no one knew who had authority over what.

Core upgrade: Autonomy levels attached to specific agents and specific work types.

Levels:
- Level A — Full Auto (act and report concisely)
- Level B — Auto With Notify (act, then notify)
- Level C — Approval Gated (get approval first)
- Level D — Never Autonomous

Examples by agent:
- Ada Level A: internal ops cleanup, benchmarks, reporting, infra investigation
- Ada Level C: customer-facing production deploys, outbound communication as Henry
- Scotty Level A: build, test, verify, ship non-prod work without asking
- Spock Level A: investigate and synthesize without ceremony; binding commitments step up to higher levels

Reporting format (terse):

DONE
NOT DONE
WAITING ON YOU

With proof. Not essays. Not diary entries.

The failure mode it solved: Verbosity as performance art — agents writing lengthy updates for routine work instead of just shipping it.

Version 3: Delegation Requires Context and Availability

What it fixed: Delegation itself being treated as success. Sending work to an agent was considered done, even if the agent lacked the context to act or was unavailable to receive it.

The three rules in memory/rules.md:
1. Delegation must be context-complete — the assignee must have everything needed to act without asking follow-up questions
2. Delegation must not create blocking — if the assignee is unavailable, work continues via a different executor, not pauses
3. Dead delegate = switch executor immediately — do not wait for the delegate to come back online

The three core statements:
- A delegate without context is not leverage.
- A delegate who is offline is not leverage.
- A beautiful handoff to the wrong executor is not leverage.

The failure mode it solved: Delegation that looks elegant but creates delay because the assignee lacked context or was simply unavailable.

The Three Diagnostic Questions

When agents underperform, the policy says to ask in order:

  1. Are they still asking for permission on internal, reversible, verifiable work?
    → If yes, they are operating under v1 or earlier

  2. Do they have clear lane authority and clear escalation thresholds?
    → If no, they are operating under v1 or v2 without named authority

  3. When work is delegated, does the assignee have enough context and availability to finish it?
    → If no, they are operating under v2 without v3's context requirement

The Meta-Lesson

The same model can look timid, noisy, and dependent in a weak operating system, then look sharp and useful in a strong one. Not because the model changed. Because the policy around it stopped rewarding hesitation.

The fix is operating policy. Not another model benchmark.

The Enterprise Crew runs the same foundation models before and after each policy iteration. The change in output quality comes entirely from the rules governing when agents act, what they escalate, and how they delegate.

Relationship to HiM

The autonomy policy is the operating layer of the him-model. HiM provides the cognitive separation (human thinks, Ada orchestrates, crew ships). The autonomy policy defines the rules each layer follows to prevent hesitation, verbosity, and dead delegation from degrading system performance.

Sources: blog-three-policies.md (raw/superada/), superada-multi-agent-architecture.md (compiled/sources/)

  • superada — the chief-of-staff orchestrator that runs under this policy at full scale
  • him-model — the cognitive architecture this policy operates within
  • 7-agent-crew-topology — the crew topology this policy governs

Source Attribution

raw/superada/blog-three-policies.md · compiled/sources/superada-multi-agent-architecture.md