Verification of Automated Quantum Agents — Operating Quantum Computers

Automated agents can help operate quantum platforms: recommend target choices, triage failed jobs, draft evidence packages, propose calibration actions, write benchmark summaries, or tune experiment plans. They can also waste capacity, corrupt evidence, hide assumptions, or push a fragile system outside its validated envelope.

NIST's AI Risk Management Framework provides a general approach for managing AI system risks, including governance, mapping, measurement, and management. Quantum operations needs a domain-specific version: every agent action must be bounded by policy, evidence, and rollback. [R159]

Diagram loads as you read

Verification of Automated Quantum Agents · Figure 1

View diagram source

flowchart LR
    Agent[Quantum operations agent] --> Suggest[Suggest]
    Agent --> Execute[Execute bounded action]
    Agent --> Explain[Explain evidence]
    Agent --> Monitor[Monitor drift]
    Policy[Policy] --> Agent
    Human[Human reviewer] --> Agent
    Agent --> Audit[Audit trail]

Agent classes

Diagram loads as you read

Agent classes · Figure 2

View diagram source

flowchart TB
    AgentClass[Agent class] --> Assistant[Read-only assistant]
    AgentClass --> Planner[Experiment planner]
    AgentClass --> Triage[Triage agent]
    AgentClass --> Optimizer[Optimization agent]
    AgentClass --> Calibration[Calibration assistant]
    AgentClass --> Operator[Bounded operator]

Each class needs a different permission set.

Agent class	Permitted actions
read-only assistant	search evidence, summarize docs, answer questions
experiment planner	propose manifests, estimate cost, identify missing controls
triage agent	classify failures, recommend runbook path
optimizer	propose parameter changes within budget
calibration assistant	recommend calibration candidates, never bypass safety gates
bounded operator	execute pre-approved low-risk actions with audit

Tool boundary

Diagram loads as you read

Tool boundary · Figure 3

View diagram source

flowchart LR
    Agent --> ToolGateway[Tool gateway]
    ToolGateway --> Read[Read tools]
    ToolGateway --> Sim[Simulation tools]
    ToolGateway --> Submit[Submission tools]
    ToolGateway --> Control[Control tools]
    ToolGateway --> Publish[Publication tools]
    Policy --> ToolGateway

Never let an agent call provider, lab, or publication tools directly. Route calls through a gateway that enforces policy and records the action.

Verification layers

Diagram loads as you read

Verification layers · Figure 4

View diagram source

flowchart TB
    Intent[User intent] --> Static[Static policy checks]
    Static --> Sim[Simulation or dry run]
    Sim --> Shadow[Shadow mode]
    Shadow --> Bounded[Bounded live execution]
    Bounded --> Review[Post-action review]

Verification is progressive. A new agent should first operate in read-only mode, then dry-run mode, then shadow mode, then bounded live mode.

Prompt and context control

Diagram loads as you read

Prompt and context control · Figure 5

View diagram source

flowchart LR
    User[User request] --> Context[Curated context]
    Context --> Agent[Agent]
    Agent --> Draft[Draft action]
    Draft --> Policy[Policy check]
    Policy --> Tool[Tool execution]

The agent should not retrieve arbitrary evidence or secrets. Retrieval should be scoped to project, role, purpose, and data class.

Action envelopes

Every executable action needs an envelope.

Illustrative listing · yaml

action_envelope:
  action: rerun_failed_job
  allowed_profiles:
    - exploration
    - research
  max_cost_usd: 25
  max_retries: 1
  allowed_targets:
    - simulator
    - qpu_nonproduction
  forbidden_if:
    - evidence_class: regulated
    - incident_state: active
  approval:
    required_above_cost_usd: 5

Diagram loads as you read

Action envelopes · Figure 6

View diagram source

flowchart TB
    Action[Proposed action] --> Envelope[Action envelope]
    Envelope --> Cost[Cost bound]
    Envelope --> Target[Target bound]
    Envelope --> Data[Data bound]
    Envelope --> Time[Time bound]
    Envelope --> Approval[Approval bound]

Agent evidence

Agent outputs become part of the evidence chain when they influence decisions.

Diagram loads as you read

Agent evidence · Figure 7

View diagram source

erDiagram
    AGENT_RUN ||--o{ INPUT_CONTEXT : used
    AGENT_RUN ||--o{ PROPOSED_ACTION : produced
    PROPOSED_ACTION ||--o{ POLICY_DECISION : evaluated_by
    POLICY_DECISION ||--o{ TOOL_CALL : authorizes
    TOOL_CALL ||--o{ RESULTING_ARTIFACT : creates

Record:

agent version;
prompt template;
retrieved context identifiers;
policy decision;
tool calls;
human approval;
outputs;
known limitations.

Hallucination is not the only risk

Diagram loads as you read

Hallucination is not the only risk · Figure 8

View diagram source

flowchart TB
    Risk[Agent risk] --> Fabrication[Fabricated fact]
    Risk --> Overconfidence[Overconfident interpretation]
    Risk --> Shortcut[Bypass golden path]
    Risk --> Capacity[Capacity waste]
    Risk --> Leakage[Data leakage]
    Risk --> Feedback[Bad feedback loop]
    Risk --> Drift[Model or context drift]

A perfectly factual agent can still be unsafe if it takes an action outside the validated operating envelope.

Shadow evaluation

Diagram loads as you read

Shadow evaluation · Figure 9

View diagram source

sequenceDiagram
    participant Agent
    participant Human
    participant Platform
    Agent->>Platform: propose action in shadow mode
    Platform-->>Agent: simulated outcome and policy result
    Human->>Platform: actual decision
    Platform->>Agent: compare proposal with human decision

Shadow evaluation metrics:

agreement with expert decision;
false approval rate;
false denial rate;
missing evidence rate;
cost estimation error;
unsafe recommendation rate;
explanation usefulness.

Rollback and kill switches

Diagram loads as you read

Rollback and kill switches · Figure 10

View diagram source

stateDiagram-v2
    [*] --> Enabled
    Enabled --> Restricted
    Restricted --> Disabled
    Enabled --> Disabled
    Disabled --> Review
    Review --> Enabled
    Review --> Retired

Disable conditions:

repeated policy violations;
unexplained tool calls;
evidence corruption;
capacity runaway;
sensitive data exposure;
incident state active;
model/version uncertainty.

Human review thresholds

Diagram loads as you read

Human review thresholds · Figure 11

View diagram source

flowchart LR
    Proposed[Proposed action] --> RiskScore[Risk score]
    RiskScore --> Low[Auto allowed]
    RiskScore --> Medium[Human approval]
    RiskScore --> High[Review board]
    RiskScore --> Forbidden[Denied]

Risk score should consider cost, target sensitivity, data class, reversibility, claim impact, and hardware safety.

Agent readiness review

Question	Required answer
What can the agent do?	documented tool permissions
What can it not do?	explicit deny rules
How is context scoped?	retrieval policy
How are actions logged?	evidence schema
How is it evaluated?	shadow metrics and tests
How is it stopped?	kill switch and owner

Automation is useful only when it makes operating discipline more enforceable, not less.