Skip to main content

Quantum prep → Derek (Thursday)

Active tactic, this week. Erik meets Derek (IonQ's new head of product) on Thursday. Goal: walk through everything we've got going on in quantum — OptiHashi, the Q/Work paper-reproduction system, the Data Lake + Bucket 1 work — and make it all as impressive as possible. Rock solid. Easy to find. Easy to demo.

Owners: Nao + Ken Wallace · Due: Thursday this week · Status: 🚧 prep in flight

⚠️ Team change context. The previous quantum leads (the research-algorithm engineer who did the Iter-QAOA reproduction and the Q-Work platform owner) departed B4M for cultural / velocity reasons. Nao + Ken now absorb the quantum surface entirely. This raises the stakes of the prep work: there is no “ask the predecessor” fallback. The walk-through has to land on the artifacts and the platform, not on personalities.

The deliverable​

Treat Erik like royalty for the meeting. By Thursday morning, everything quantum should be:

  • Warmed up — no “let me find that” mid-demo
  • Up to date — documentation matches what's actually live
  • Rock solid — no broken links, no half-finished artifacts left lying around in screenshots
  • Easy to navigate — for Erik in the meeting AND for Derek if he wants to dig in afterwards

Specifically, every artifact in the quantum surface should be reachable in ≤ 2 clicks from a known starting point:

Artifact classWhere it should be reachable from
OptiHashi demo + briefing + patent doccatalog/optihashi · needs polish pass
IonQ engagement deckThe finding guide (see below)
Iter-QAOA reproductionThe finding guide
Q/Work codebase + how to run itThe finding guide
Datalake + Bucket 1 workThe finding guide + the B4M V3 blueprint
Quantum knowledge base (the curated corpus built over the program)The finding guide

What lives in ~/Desktop/quantum-work​

Erik has a substantial quantum work directory at ~/Desktop/quantum-work/ with many subdivisions:

  • q-work/ — the Q/Work agentic paper-reproduction codebase
  • iter-qaoa/ — the reproduction of the Iter-QAOA paper
  • ionq-engagement-deck/ — the deck for IonQ meetings
  • ionq-knowledge/ — curated IonQ-specific knowledge
  • optimal-viz/ — the OptiHashi visualization work
  • optimization-knowledge/ — quantum optimization domain knowledge
  • quantum/ — general quantum work
  • q/ and q-paper-neutron-scattering/ — additional quantum work
  • Plus briefing zips (IBM Gambetta), the OptiHashi encounter generator HTML, etc.

A finding guide at catalog/quantum-work-guide (🚧 inventory in flight) will be the navigable index Nao + Ken can use to point at any artifact in ≤ 2 clicks.

What Nao + Ken should each own​

The work splits naturally:

Nao (engineering surface):

  • Q/Work codebase health: README is current, entry point works, dependencies pinned, run command documented
  • Iter-QAOA reproduction artifacts: do they render correctly? are inputs+outputs labeled?
  • B4M V3 architectural ties to the quantum work (data lake + GenAI window + ReAct + tools) reflected in the finding guide

Ken (operational surface):

  • IonQ engagement deck: latest version, no dead slides, current numbers
  • OptiHashi catalog page + provisional patent reference up to date (catalog/optihashi)
  • Datalake + Bucket 1 status: what shipped, what's next, what would Derek need to see
  • Anything that requires SRE-style hardening before the meeting

Adjust as needed — this is the strawman split; Nao and Ken negotiate.

Stretch goal — Attention Is All You Need on Q/Work? Not quite.​

Erik asked for kicking off an agentic Q/Work reproduction of Vaswani et al., 2017. A background agent investigated and the honest finding is more interesting than the kickoff would have been:

What Q/Work actually is​

Q/Work is not an agentic paper-reproduction system. It is a job-orchestration platform for long-running quantum-enabled workloads — the durable execution substrate that lets researchers submit Qiskit / IonQ SDK / Cirq code, route it across QPU / GPU / classical backends, track lifecycle states, and audit costs.

The “agentic reproduction” intelligence is human-in-the-loop today. The Iter-QAOA reproduction was done by reading the IonQ paper, extracting 150+ parameters by hand, writing JSSP/QUBO/ansatz code in Python, then using Q/Work to submit circuits to IonQ Forte at 24/32/33/36q on QPU plus 50q/97q in MPS sim. The wow was the velocity of the human in the loop. Q/Work was the substrate; not the brain.

What Erik actually meant — and the real blocker​

The capability Erik is reaching for (point an agent at an arXiv URL, have it read the paper, write the code, run it, iterate to a correct reproduction) is @b4m/quest — the agentic experimentation layer named in the B4M V3 Blueprint. It is on the roadmap. It is not built yet.

Why Attention Is All You Need would be an awkward target even if @b4m/quest existed​

  • It's classical ML, not quantum. Q/Work's provider abstraction is IonQ + EC2; the EC2 rail is generic but the schema, the cost dashboards, the audit logs are all calibrated for shots-on-Forte, not GPU-hours-on-H100.
  • The default container build has Qiskit / IonQ SDK / CUDA-Q — not PyTorch / JAX / HuggingFace.
  • Reproduction shape is wrong: Iter-QAOA = many short circuit-submission jobs. Transformer reproduction = standing up WMT14 En-De, BPE tokenizer, multi-day GPU training, BLEU eval. Different domain, different cost model, different evaluation surface.
  • An honest end-to-end run for the base model: ~$50–$1,200 in GPU compute alone (depending on instance choice + spot/on-demand), plus 1–2 weeks of an ML-systems engineer to babysit. Order of magnitude more for a full “agent writes the code from the PDF” loop.

The recommendations​

Ranked by value:

  1. Nao does a Q/Work code deep-dive; Ken does a customer-engagement-surface deep-dive. Both write a one-paragraph “here's what I would say to Derek about this slice” for Erik to cross-reference before Thursday. No predecessors to ask — the artifacts and the platform have to speak for themselves. The good news: they do.
  2. Pivot the demo to LR-QAOA — the reproduction roadmap is already drafted (per quantum/docs-site/docs/papers/), it's Q/Work-shaped, and shipping it produces another open-source artifact for the IQMetry credibility story.
  3. Do Attention Is All You Need as a one-off Claude Code experiment, NOT on Q/Work. Fun afternoon project for someone; not a strategic investment; produces no Q/Work artifact.

The actually-impressive framing for Derek​

Walk Derek through:

“Today: Q/Work is the substrate — durable execution across quantum + classical backends, full lifecycle tracking, auditable cost controls. We've used it to reproduce Iter-QAOA on Forte, end-to-end.

Next: @b4m/quest — the agentic layer that reads the paper, writes the code, iterates to correct reproduction. That's the unlock for Bucket 2. It's on the B4M V3 roadmap, and the IonQ engagement is exactly what funds and scopes it.”

That's a stronger ask than “here's our paper-reproduction agent.” It tells Derek what the next dollar of investment buys, not just what the last dollar built.

Next steps (this week)​

  1. ✅ Tactic page stood up (this doc)
  2. ✅ Finding guide for ~/Desktop/quantum-work — quantum-work-guide shipped
  3. ✅ Q/Work Attention Is All You Need investigation — finding is “Q/Work is the substrate; @b4m/quest is the unbuilt agentic layer.” See section above.
  4. ⬜ Nao + Ken — one-paragraph “what I'd say to Derek about [my slice]” writeups (Nao: Q/Work code; Ken: customer-engagement surface). No predecessor to defer to — this is your domain now.
  5. ⬜ Nao — engineering-surface polish pass (Q/Work README current, Iter-QAOA artifacts render, V3 ties documented)
  6. ⬜ Ken — operational-surface polish pass (deck refresh, OptiHashi page current, Bucket 1 status, the @b4m/quest framing for Derek)
  7. ⬜ Erik dry-run the walk-through end to end on Wednesday so Thursday is muscle memory
  8. ⬜ Post-meeting: write up in a strategy update — what was Derek interested in, what did he share, what doors did this open