Starter Project: Build an Autonomous Agent That Schedules Quantum Experiments

Hook: Stop wrestling with fragmented quantum tooling — build an autonomous desktop agent that runs experiments for you

If your team spends more time moving experiment files, provisioning simulator/QPU access, and stitching together logs than actually iterating on algorithms, you're not alone. Fragmented tooling, credential churn, and brittle integrations make quantum R&D slow and expensive. This tutorial gives you a practical, production-minded starter project — a desktop autonomous agent (in the spirit of Cowork) that reads experiment queues, provisions simulators and QPUs, executes jobs, and reports results back to your lab dashboard.

Why a desktop autonomous agent matters for quantum labs in 2026

Quantum software teams in 2026 increasingly run hybrid workflows: classical pre-/post-processing, classical ML models that score circuits, and quantum runs on both simulators and cloud QPUs. That hybrid stack demands orchestration that integrates with developer workflows (VS Code, CI/CD, local notebooks) and with cloud procurement and budget controls.

Two important trends changed the calculus in late 2025–early 2026:

• Desktop autonomous agents gained mainstream traction — Anthropic's Cowork research preview showed how desktop agents unlock powerful automations by interacting with local state and developer tools.
• Cheap edge AI inference (for example, Raspberry Pi 5 + HAT+ style accelerators) made it feasible to run the orchestrator and small LLMs locally, reducing cloud costs and improving privacy for lab environments.

These shifts mean you can safely run an agent on a lab machine that has file-system access, local cache of experiment artifacts, and the ability to spin up cloud QPUs when needed — balancing latency, cost and data governance.

Desktop agents and the new normal

"Anthropic launched Cowork, bringing the autonomous capabilities of its developer-focused Claude Code tool to non-technical users through a desktop application." — Forbes, Jan 16, 2026

Use that concept as inspiration: your agent should be a trusted local service with a narrow, auditable set of capabilities (read experiment queues, provision compute, submit runs, and report back). For inspiration on creative automation patterns and small LLM-enabled automations, see recent work on creative automation.

Project overview: what this starter repo delivers

The starter repository accompanying this article implements a minimal but extensible autonomous experiment scheduler with these features:

• Queue reader: polls a JSON/Redis queue for experiment descriptors.
• Provider abstraction: pluggable drivers for simulators (Qiskit Aer, PennyLane local) and cloud QPUs (IBM, AWS Braket, Azure Quantum).
• Execution engine: runs circuits or pulse sequences, tracks job state, and retries transient failures.
• Local desktop API & UI hook: exposes a small HTTP API so a desktop front-end (Electron/Tauri) can show live status.
• Results pipeline: stores outcomes in PostgreSQL/SQLite, emits artifacts to object storage, and posts summary webhooks back to your lab dashboard or Slack.
• Security controls: secrets manager integration, RBAC for requests, and audit logging.

High-level architecture (verbal diagram)

The architecture is intentionally simple and modular so you can adopt parts into existing CI or lab automation:

1. Experiment Queue — JSON messages in Redis Streams or an SQS-like queue authored by researchers or CI pipelines.
2. Local Agent — Python asyncio service that polls the queue, selects a provider, and runs jobs.
3. Provider Drivers — Adapter layer for Qiskit Aer, AWS Braket, IBM Quantum, and custom simulators.
4. Storage — PostgreSQL for metadata, S3-compatible object store for raw artifacts.
5. Desktop UI — Electron/Tauri front-end that talks to the local agent API (optional).
6. Policy & Audit — Secrets manager (Vault), role-based access and an append-only job audit log.

Tech stack & recommended tools

• Language: Python 3.11+ (asyncio-first design)
• Queue: Redis Streams (local friendly) or AWS SQS for cloud labs
• DB: PostgreSQL (production) / SQLite (local dev)
• Simulators: Qiskit Aer, PennyLane, Cirq's local simulator
• QPU Providers: IBM Quantum (qiskit-ibmq-provider), AWS Braket SDK, Azure Quantum
• Desktop UI: Tauri (Rust + webview) or Electron
• Secrets: HashiCorp Vault or OS-native store (Keyring) for local dev
• Containerization: Docker + docker-compose for local reproducibility

Walkthrough: get the starter agent running (practical steps)

This section shows the minimal commands and code snippets to get a working local agent that runs circuits on a simulator. Full code lives in the starter repo: github.com/flowqbit/quantum-agent-starter (clone that repo to follow along).

1) Quick start — clone and boot with Docker

git clone https://github.com/flowqbit/quantum-agent-starter.git
cd quantum-agent-starter
# Local dev uses docker-compose (Redis, PostgreSQL, local object store)
docker compose up --build -d
# Create a virtualenv for local agent development
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

2) Experiment queue schema (JSON)

Each queued experiment is a compact JSON descriptor. Keep it explicit so the agent can validate and enforce policy.

{
  "experiment_id": "exp-20260117-01",
  "owner": "alice@example.com",
  "priority": 50,
  "circuit": "qasm",
  "circuit_payload": "OPENQASM 2.0; qreg q[2]; h q[0]; cx q[0],q[1]; measure q -> c;",
  "backend": {"type": "simulator", "name": "aer_simulator"},
  "shots": 1024,
  "deadline": "2026-01-18T12:00:00Z",
  "notify_webhook": "https://lab-dashboard.example.com/api/job-callback"
}

3) Minimal Python agent loop (asyncio + Redis Streams)

This stripped code shows the core: poll the queue, pick a provider, submit, poll for completion and store results. In the real repo each provider is a class implementing a shared interface.

import asyncio
import json
import aioredis
from providers import ProviderFactory
from storage import JobStore

async def handle_message(msg):
    data = json.loads(msg)
    provider = ProviderFactory.get(data['backend'])
    job_meta = await JobStore.create(data)
    try:
        run_id = await provider.submit(data)
        status = await provider.wait_for_completion(run_id)
        results = await provider.fetch_results(run_id)
        await JobStore.mark_done(job_meta['id'], results)
        # deliver webhook (non-blocking)
        asyncio.create_task(notify_owner(data['notify_webhook'], results))
    except Exception as e:
        await JobStore.mark_failed(job_meta['id'], str(e))

async def worker_loop():
    redis = await aioredis.from_url('redis://localhost')
    while True:
        msg = await redis.xread({'experiment-queue': 0}, count=1, block=5000)
        if msg:
            await handle_message(msg)
        await asyncio.sleep(0.1)

if __name__ == '__main__':
    asyncio.run(worker_loop())

4) Example provider driver (Qiskit Aer simulator)

from qiskit import QuantumCircuit, Aer, assemble

class AerProvider:
    def __init__(self, config):
        self.backend = Aer.get_backend('aer_simulator')

    async def submit(self, data):
        qc = QuantumCircuit.from_qasm_str(data['circuit_payload'])
        qobj = assemble(qc, shots=data.get('shots', 1024))
        # synchronous call is fine on local simulator — wrap in ThreadPoolExecutor in real code
        job = self.backend.run(qobj)
        return job

    async def wait_for_completion(self, job):
        job.result()  # blocking in this toy example
        return 'COMPLETED'

    async def fetch_results(self, job):
        res = job.result()
        return {'counts': res.get_counts()}

For cloud QPUs (IBM, Braket) the provider will call the relevant SDK's submit job and poll the cloud job status asynchronously. The starter repo includes an AWS Braket driver implemented with boto3/braket-sdk and a small retry/backoff policy tuned for ephemeral throttling.

Desktop integration: expose a local API for a Cowork-like UI

Make your agent reachable on localhost: a small REST API allows a Tauri/Electron app to show live job logs, let users cancel jobs, or inspect artifacts. Keep the API authenticated with a desktop token and limit it to local connections only.

GET /api/v1/jobs
GET /api/v1/jobs/{job_id}
POST /api/v1/jobs/{job_id}/cancel
GET /api/v1/logs/{job_id}

Security and governance — production checklist

• Secrets separation: never store provider API keys in plaintext; use Vault or OS keyring and rotate keys frequently.
• Least privilege: agent service accounts should only request the minimal scopes required to submit jobs and fetch artifacts.
• Audit trail: append-only job logs with owner and action metadata so investigators can trace runs.
• Policy enforcement: deny high-privilege backends (public QPUs) unless a compliance check passes (cost center, ticket).
• Local-only UI pattern: bind the desktop UI to localhost; if you must allow remote access, require mTLS and IP allowlisting.

Benchmarking: latency and cost considerations (example results)

Benchmarks depend heavily on circuit depth, shots, network latency and provider queue times. Below are illustrative numbers measured in a local lab during December 2025 on a set of 50 small random circuits (3 qubits, depth < 20).

• Local Qiskit Aer (local machine): median end-to-end = 1.8s, cost = $0
• AWS Braket simulator (cloud): median end-to-end = 5.6s, cost = $0.002 per job
• IBM QPU (public backend, off-peak): median queue+run = 45–120s, cost = per-minute procurement or token-based; latency dominates

Key takeaways from those measurements:

• Use local simulators for rapid iteration and unit tests — they are orders of magnitude faster and free.
• Batch QPU runs and schedule them during low-demand windows to reduce queue wait time and cost.
• Cache result artifacts for reproducibility and to avoid repeated QPU runs.

Note: these are lab examples. For production procurement you should benchmark typical circuits and measure actual cloud spend using provider billing APIs.

Advanced strategies for production-grade orchestration

• Autoscaling providers: for large simulator workloads, run a pool of worker containers and horizontally scale by queue depth. Micro-edge and micro-VPS instances are an option for labs that want low-latency local compute.
• Hybrid pipelines: pre-process circuits with classical ML models (locally using a small LLM to prioritize experiments) before submitting to QPU.
• CI integration: include smoke tests that submit a trivial circuit to the agent in your GitHub Actions workflow. Use mocked providers in unit tests. If things go wrong, follow a documented recovery and runbook approach similar to cloud incident playbooks.
• Cost-aware scheduling: the agent should estimate expected runtime and cost, attaching a budget token; reject runs that exceed owner quotas — this mirrors strategies used by startups that cut cloud spend while improving throughput.
• Artifact provenance: sign artifacts and include the exact provider environment + SDK versions for reproducibility.

Developer ergonomics: patterns I use across teams

• Provider adapters: keep providers small and well-tested; each adapter handles credential refresh, submission, polling, and result normalization.
• Deterministic experiment IDs: include git commit and notebook cell hash in experiment metadata so you can trace code that generated the circuit.
• Local-first UX: default to local simulator unless the experiment explicitly requests a QPU; this avoids accidental vendor charges.

Starter repo structure (what's in the repo)

• /agent — asyncio service and the queue loop
• /providers — Qiskit Aer, Braket, IBM driver implementations
• /desktop — Tauri demo app that talks to localhost
• /infra — docker-compose and Terraform examples for optional cloud resources
• /docs — walkthrough notebooks and benchmark scripts
• /examples — sample experiment JSONs and CI snippets

Community resources, courses and starter projects

Upskilling is crucial to move from prototypes to production. The community below is active in 2026 and pairs nicely with this starter project:

• Qiskit Textbook & Qiskit Tutorials — good for circuit-level mastery and provider integration.
• PennyLane and the Quantum Machine Learning community — if your pipelines combine differentiable quantum circuits.
• Quantum Open Source Foundation (QOSF) — open-source governance and community projects.
• edX / MITx 2025–2026 quantum software courses — hands-on modules that map directly to experiment pipelines.
• Flowqbit community repo & starter projects — the starter agent and continuous examples live at github.com/flowqbit/quantum-agent-starter.

Case study: small R&D lab at a fintech startup

In late 2025 a fintech R&D team used a variant of this agent to batch-run portfolio optimization circuits during off-peak hours. They adopted two policies:

1. Default simulator for PR validation, QPU only for final benchmark runs.
2. Cost budget tokens attached to experiments; runs exceeding budget were auto-failed with audit message and ticket creation.

Outcomes in 3 months: experiment turnaround improved 3x, cloud spend decreased by 42% because the agent prevented ad-hoc QPU usage and consolidated runs into scheduled batches. For similar learnings on trimming cloud costs while improving engagement and throughput, see the Bitbox case study.

Actionable checklist before you deploy to production

• Run the starter agent locally and execute 10 sample experiments against the Aer simulator.
• Integrate secrets with Vault and test credential rotation.
• Set up cost alerts for cloud QPU providers via their billing APIs.
• Configure RBAC and require approval for QPU submissions from non-admin users.
• Add CI pipeline tests that use a mocked provider for unit tests and a small local simulator for integration tests.

Why this matters now — trends and future predictions (2026 outlook)

By early 2026 the intersection of desktop autonomous agents and edge AI inference means labs can run smarter orchestration locally without exposing intellectual property to cloud-only LLMs. Expect these practical consequences:

• More labs will use local-first agents to reduce operational costs and to comply with data governance regimes.
• Providers will publish more programmatic SLAs and billing APIs in 2026, enabling tighter cost-aware scheduling.
• Open-source starter agents (like this repo) will become the baseline for vendor evaluations; procurement will start requiring a working integration rather than documentation-only proofs.

Final notes on testing and reproducibility

Scientific rigor matters: always include the exact SDK versions and hardware revision for any published benchmarks. The starter repo includes a repro.yaml that pins package versions and records environment metadata as part of every experiment artifact.

Call to action

Ready to build your own autonomous experiment scheduler? Clone the starter repo, run the quickstart, and open an issue or PR with the provider you need. If you'd rather start with a guided workshop, sign up for our 2-week lab-up workshop where we help you integrate the agent with your lab's procurement and CI systems.

Get started: https://github.com/flowqbit/quantum-agent-starter — fork, run, and contribute drivers for your QPU.

Want help? Reach out at dev@flowqbit.com for tailored onboarding, security reviews, and production hardening.