The long-term operating goal is not a fully autonomous quantum computer that hides all complexity. That would be unsafe and misleading. The goal is supervised autonomy: systems that can observe, diagnose, recommend, and sometimes act within explicit guardrails.
Autonomous operation is a control problem across the whole platform: calibration, compilation, scheduling, mitigation, routing, evidence packaging, cost control, and user guidance. Each action must have a policy boundary and a rollback path.
View diagram source
flowchart LR
Observe[Observe] --> Diagnose[Diagnose]
Diagnose --> Plan[Plan]
Plan --> Act[Act]
Act --> Verify[Verify]
Verify --> Learn[Learn]
Learn --> ObserveAutonomy levels
View diagram source
flowchart TB
L0[L0 manual] --> L1[L1 recommend]
L1 --> L2[L2 approve-to-act]
L2 --> L3[L3 bounded auto-action]
L3 --> L4[L4 adaptive policy]| Level | Description | Example |
|---|---|---|
| L0 | humans inspect and act | manual recalibration decision |
| L1 | system recommends | suggest target drain |
| L2 | human approves action | approve reroute or recalibration |
| L3 | bounded auto-action | auto-reject production job on red health |
| L4 | adaptive policy | adjust benchmark cadence within approved limits |
Do not jump to L4 for safety-critical or claim-critical actions.
Control domains
View diagram source
flowchart TB
Autonomy[Autonomy domains] --> Calibration[Calibration]
Autonomy --> Scheduling[Scheduling]
Autonomy --> Compilation[Compilation]
Autonomy --> Mitigation[Error mitigation]
Autonomy --> Evidence[Evidence packaging]
Autonomy --> Cost[Cost controls]
Autonomy --> Support[User support]Each domain needs a separate risk model.
Guardrail architecture
View diagram source
sequenceDiagram
participant Agent
participant Policy
participant Simulator
participant Human
participant Runtime
Agent->>Policy: propose action
Policy-->>Agent: allowed with conditions
Agent->>Simulator: dry-run if required
Simulator-->>Human: evidence summary
Human-->>Runtime: approve high-risk action
Runtime-->>Agent: result and audit recordGuardrails should be machine-enforced, not policy documents in a shared drive.
Action taxonomy
View diagram source
flowchart TB
Action[Autonomous action] --> Safe[Safe reversible]
Action --> Reversible[Reversible but impactful]
Action --> Risky[High-risk]
Action --> Forbidden[Forbidden]Examples:
| Class | Example | Control |
|---|---|---|
| safe reversible | add extra validation probe | budget limit |
| reversible but impactful | reroute nonproduction jobs | audit log |
| high-risk | change calibration policy | human approval |
| forbidden | modify evidence after claim approval | block |
Autonomy evidence
View diagram source
flowchart LR
Proposal[Action proposal] --> Reason[Reason]
Reason --> Policy[Policy decision]
Policy --> Execution[Execution record]
Execution --> Outcome[Outcome]
Outcome --> Learning[Learning update]Every autonomous action should leave an evidence trail:
autonomous_action:
action_id: auto_2026_04_19_001
proposed_by: calibration_agent_v4
reason: two_qubit_error_trend_exceeded_policy
policy_version: qpu_health_policy_7
risk_class: reversible_but_impactful
dry_run_required: true
approval: human_required
outcome: target_restricted_for_production
rollback: restore_prior_admission_policyLearning loops
View diagram source
flowchart TB
History[Operational history] --> Features[Feature store]
Features --> Model[Recommendation model]
Model --> Recommendation[Recommendation]
Recommendation --> HumanReview[Human review]
HumanReview --> Outcome[Outcome]
Outcome --> HistoryThe learning loop should learn from rejected recommendations, not only accepted actions.
Failure modes of autonomy
View diagram source
flowchart TB
Failure[Autonomy failure] --> OverAct[Over-action]
Failure --> UnderAct[Under-action]
Failure --> Feedback[Bad feedback loop]
Failure --> Objective[Wrong objective]
Failure --> Opacity[Unexplainable action]
Failure --> Drift[Model drift]Mitigations:
| Failure | Mitigation |
|---|---|
| over-action | action budgets and cooldowns |
| under-action | missed-detection review |
| bad feedback loop | holdout probes and causal review |
| wrong objective | multi-objective policy including claim risk |
| opacity | explanation requirement |
| model drift | model monitoring and periodic reset |
Human operating cadence
View diagram source
gantt
title Supervised autonomy cadence
dateFormat YYYY-MM-DD
section Daily
Autonomous action review :a1, 2026-04-20, 1d
section Weekly
Policy threshold review :b1, 2026-04-21, 1d
section Monthly
Model performance review :c1, 2026-05-01, 2d
section Quarterly
Autonomy risk review :d1, 2026-07-01, 3dAutonomy does not remove humans. It changes their job from routine reaction to policy design, exception review, and system learning.
Roadmap for adoption
View diagram source
flowchart LR
Instrument[Instrument everything] --> Recommend[Recommendation-only mode]
Recommend --> Approve[Approve-to-act mode]
Approve --> Bounded[Bounded auto-action]
Bounded --> Audit[Audit and expand]Start with observability. A platform that cannot explain its past should not automate its future.
Operating rule
The safest autonomous quantum platform is not the one that acts most often. It is the one whose actions are bounded, explainable, reversible, evidenced, and aligned with the scientific claim being made.