In Part 2, we built the technical infrastructure: registry, observability, policy, and control. But infrastructure is just the foundation. The harder question is operational:
Who decides what?
This is where most governance initiatives fail. Not from lack of technology, but from getting the human layer wrong. Either governance becomes a bottleneck that business units route around, or it becomes so permissive that it provides no actual governance.
This post introduces the autonomy spectrum - a model for balancing business unit freedom with enterprise control. The goal: maximum innovation velocity within acceptable risk bounds.
The False Binary
Most organizations think about governance as a binary choice:
Centralized Control: “All agent deployments require approval from the AI CoE.” Result: 6-month backlogs.
Full Autonomy: “Business units own their AI deployments end-to-end.” Result: Shadow AI everywhere.
Neither works. The answer isn’t choosing between them - it’s recognizing that different decisions deserve different levels of autonomy.
The Autonomy Spectrum
Autonomy isn’t binary. It’s a spectrum with at least five distinct levels:
L1: Prohibited
Some things agents simply cannot do. Not “shouldn’t” - cannot. Technical controls prevent it.
Examples: Autonomous medical diagnosis. Binding legal advice. Unsupervised financial transactions above threshold. Accessing certain regulated data categories.
L1 decisions aren’t about bureaucracy - they’re about hard limits that no amount of approval can override. The control plane enforces these regardless of who’s asking.
L2: Approval Required
High-risk deployments that need human review before proceeding. A governance team evaluates the request, asks questions, potentially imposes conditions.
Examples: Customer-facing agents. Agents with PII access. Novel use cases without precedent. High-value transaction processing.
L2 creates friction - intentionally. Some decisions should be slow. The key is limiting L2 to decisions that genuinely warrant it.
L3: Notify and Proceed
Deployment happens automatically, but governance is notified. Review happens post-hoc, not pre-approval. If something’s wrong, governance can intervene - but they don’t block by default.
Examples: Internal productivity tools. Known patterns deployed by experienced teams. Low-risk data access. Agents with proven architectures.
L3 is where most mature organizations should operate for routine deployments. It maintains visibility without creating bottlenecks.
L4: Self-Service
Business units deploy within pre-defined guardrails without any approval or notification. The control plane enforces bounds automatically. Governance only gets involved if bounds are violated.
Examples: Development and testing environments. Pre-approved agent templates. Teams with demonstrated maturity. Low-stakes use cases.
L4 requires robust guardrails - you’re trusting the system to catch problems, not humans.
L5: Autonomous
Full ownership. The business unit not only deploys agents but defines their own guardrails (within enterprise minimums). They’re accountable for outcomes, not just compliance.
Examples: Platform teams. Units with proven track records. Highly mature AI operations. Strategic initiatives with executive sponsorship.
L5 is earned, not granted. Very few teams should operate here, and they should demonstrate consistent L4 behavior first.
What Determines Autonomy Level?
Autonomy isn’t one-size-fits-all. The right level depends on multiple factors:
Use Case Risk:
- Customer-facing? Financial impact? Regulatory scope? Reversibility?
- Higher risk → Lower autonomy
Data Sensitivity:
- PII/PHI involved? Confidential data? Cross-border flows? Retention requirements?
- More sensitive → Lower autonomy
Team Maturity:
- AI deployment experience? Incident history? Compliance track record? Operational capability?
- More mature → Higher autonomy
Pattern Novelty:
- Established architecture? Known failure modes? Precedent exists? Tested guardrails?
- More novel → Lower autonomy
Environment:
- Production vs. dev? Blast radius? Rollback capability? Monitoring coverage?
- Production → Lower autonomy
The autonomy matrix isn’t static. The same team might operate at L4 for development, L3 for internal tools, and L2 for customer-facing deployments.
Guardrails vs. Gates
The most important mental model shift: guardrails beat gates.
Gates are checkpoints. You can’t proceed until someone opens the gate. Gates create queues. Queues create backlogs. Backlogs create workarounds.
Guardrails are boundaries. You can move freely within them. Hit the edge, and you’re stopped - but you didn’t have to ask permission to start moving.
The gate model asks: “Can this team be trusted to deploy this agent?”
The guardrail model asks: “What bounds should this agent operate within, and can we enforce them automatically?”
Guardrails don’t eliminate oversight - they shift it. Instead of reviewing every deployment upfront, you define bounds once and monitor for violations. Governance becomes proactive (designing guardrails) rather than reactive (processing requests).
Implementing Federated Governance
The autonomy spectrum requires a federated governance model. Not centralized, not decentralized - federated.
Enterprise Governance Sets Floors
The enterprise layer defines minimum standards that apply everywhere:
- L1 prohibitions: Things no agent can do, regardless of business unit
- Compliance mapping: How regulatory requirements translate to technical controls
- Audit requirements: What must be logged, how long retained
- Incident escalation: When and how to escalate to enterprise risk
Enterprise governance doesn’t approve individual deployments (except L2). They design the system that others operate within.
Domain Governance Adds Context
Business domains (retail banking, wealth management, operations) add requirements specific to their context:
- Domain-specific prohibitions: Wealth management might prohibit investment recommendations; operations might prohibit customer-facing deployment entirely
- Elevated requirements: Customer-facing domains might require higher testing standards
- Local L2 review: Domain governance handles L2 requests for their area
Domain governance understands their business context in ways enterprise governance can’t. They’re closer to the use cases, the risks, the nuances.
Teams Operate at Earned Levels
Individual teams have an autonomy level based on their demonstrated capability:
- Track record: How have past deployments performed?
- Incident history: Any compliance violations? Security issues?
- Operational maturity: Do they have monitoring? Runbooks? On-call?
- Certification: Have team members completed required training?
Autonomy level isn’t permanent. Teams can level up (through consistent performance) or level down (after incidents).
Trust-Based Permissions
Here’s the key insight: autonomy should be earned, not assigned.
New teams start at L2 or L3. As they demonstrate capability, they progress. This isn’t arbitrary - it’s based on observable metrics:
| Metric | L2 → L3 | L3 → L4 | L4 → L5 |
|---|---|---|---|
| Deployments without incident | 5+ | 15+ | 50+ |
| Months at current level | 2+ | 4+ | 6+ |
| Policy violations (last 6 mo) | ≤2 | 0 | 0 |
| Audit findings (last 12 mo) | ≤1 minor | 0 | 0 |
| Mean time to incident response | <4 hours | <2 hours | <1 hour |
| Team certifications | 50% | 80% | 100% |
The control plane tracks these metrics automatically. Level progression can be automated: hit the thresholds, get promoted. Fall below standards, get demoted.
This creates the right incentives. Teams that want more autonomy have a clear path: demonstrate competence. Teams that cut corners face consequences: reduced autonomy.
The Bounded Autonomy Model
We call the combination of these concepts bounded autonomy:
- Autonomy: Teams can deploy and operate agents without asking permission
- Bounded: Within clearly defined, automatically enforced limits
Bounded autonomy isn’t permissive governance or lenient oversight. It’s precise governance. The bounds are tight where risk is high and loose where risk is low. The precision comes from understanding context, not from blanket restrictions.
Avoiding the Bottleneck Trap
The #1 failure mode for AI governance: becoming a bottleneck. Here’s how to avoid it:
1. Default to L3, Not L2
Most organizations make L2 (approval required) the default. This is backwards. Make L3 (notify and proceed) the default for routine deployments. Reserve L2 for genuinely high-risk scenarios.
If more than 20% of deployments require L2 approval, your thresholds are wrong.
2. Automate Classification
Don’t make teams self-classify risk. They’ll either over-classify (to avoid pushback) or under-classify (to avoid approval). Instead:
- Automatically classify based on data accessed, actions permitted, deployment environment
- Use the registry and policy engine to determine autonomy level
- Human override for edge cases only
3. Time-Box Reviews
L2 reviews should have SLAs. If governance doesn’t respond within 5 business days, the request auto-approves with conditions. This creates accountability on both sides.
4. Create Pre-Approved Patterns
Most agent deployments follow common patterns. Create pre-approved templates:
- Customer FAQ agent (template: read-only, no PII, canned responses)
- Document summarization agent (template: internal docs only, no actions)
- Data analysis agent (template: read-only, aggregated outputs only)
Teams using pre-approved patterns operate at L4 regardless of their baseline level.
5. Invest in Guardrail Engineering
The more sophisticated your guardrails, the more autonomy you can grant. If you can automatically detect and prevent problematic behavior, you don’t need humans reviewing every deployment.
Governance team time should shift from reviewing requests to engineering better guardrails.
Making It Real
Here’s a realistic implementation path:
Month 1-2: Foundation
- Define L1 prohibitions (enterprise-wide)
- Document current state: who’s deploying what, at what implied autonomy level
- Establish baseline metrics for team maturity assessment
Month 3-4: Pilot
- Select 2-3 domains for federated governance pilot
- Define domain-specific policies
- Assign initial autonomy levels to teams (based on track record)
- Deploy guardrails for L4 self-service
Month 5-6: Scale
- Roll out to remaining domains
- Automate autonomy level assessment
- Build dashboard for governance visibility
- Establish level progression criteria
Month 7+: Optimize
- Analyze bottlenecks - where is L2 creating delays?
- Expand pre-approved patterns library
- Refine guardrails based on incident data
- Continuous improvement of autonomy thresholds
What’s Next
The autonomy spectrum gives you a governance model. But governance has costs - not just the overhead of review, but the infrastructure to enforce guardrails, the compute for trust scoring, the operational burden of monitoring.
In Part 4: Economics of Agent Operations, we’ll tackle the financial side. How do you right-size investment? How do you avoid over-governing low-value agents and under-governing high-value ones? How do you make the business case for governance infrastructure?
Autonomy without economics is just philosophy. Let’s make it practical.