Skip to content
Technology How it works Breeder — Hyperion Burner — Aegis Burner — MetroVolt AI-Native Architecture Magnets Fuel cycle Safety Roadmap
Solutions AI & Data Centers Defense & Government Grid & Baseload Neutron Detection Quantum
Learn Technical Library
Proof Publications Whitepapers Technical Library Open Science & Reproducibility The Honest Gates
Company About / Mission Leadership Environment Health & Safety Investors Careers Press Contact
3D Model
AI Architecture › L5 · Applications & Copilots
L5 · Applications & Copilots

The Plasma Copilot: Scope and Reasoning Loop

An advisory agent that designs shots, optimizes scenarios, and warns on disruption or operating-point risk — grounded in the twin, never actuating on its own.

THE STACK · click to jumpL7Ecosystem & StrategyL6Experience & VisualizationL5Applications & CopilotsL4OrchestrationL3Twin Modeling & AIL2Data FabricL1Control PlaneL0Foundation▲tlmctl▼L5 · APPLICATIONS & COPILOTSAgentic copilots that reason over the machine.1Plasma Copilotscenario design2Engineering Copilotsubsystem analysis3Operations Copilotrunbooks & procedures4Agentic Toolsbounded action-taking5Knowledge BaseRAG over the fabric6Guardrailssafety-boundedMACHINE TIEReads the twin and fabric; proposes actions that route through L4.KRONOS FUSION ENERGYAI-NATIVE S.M.A.R.T. GENERATORAPPLICATIONS & COPILOTSSHEET 07REV. 2026-08L5 · AI-NATIVE STACK
L5 · Applications & Copilots — its place in the stack (left, click any layer) and its internal components (right). Telemetry rises; control descends.

What the Plasma Copilot does

The Plasma Copilot is the physics-facing agent of L5. For the breeder (Hyperion) it drafts shot waveforms, optimizes scenarios against confinement and stability objectives, and advises operators when a disruption-avoidance margin is eroding. For the burner (Aegis / MetroVolt) it advises on plug/mirror operating points — end-plug density, ambipolar potential, and the DEC operating window. It is a reasoning layer over the KRONOS-CTRL twin, not a controller.

The reason-act loop

Each request runs a bounded reason-act loop. The copilot assembles context from live twin state and L2 retrieval, plans a sequence of tool calls (twin queries, scenario simulations, envelope checks), inspects results, and iterates until it can propose a grounded answer with citations and uncertainty. Every tool it can call is a read or a simulate action; no tool writes to the plant. Any action with a side-effect on hardware is routed as a proposal to L4 and requires human approval.

text
loop(request):
  ctx  = build_context(twin_state, rag_retrieve(request))
  plan = planner(ctx, request)          # sequence of bounded tools
  for step in plan:
    obs = call_tool(step)               # read/simulate only
    ctx = ctx + obs
    if planner.replan(ctx): plan = planner(ctx)
  ans = compose(ctx)                    # answer + citations + UQ
  if ans.has_side_effect: submit_to_L4(ans.proposal)
  return ans

Machine-specific specializations

The copilot's outputs are always explanatory: a proposed scenario is returned with the physics rationale, the twin-predicted margins, the confidence, and the specific telemetry or simulation runs that support it. An operator or the Plasma Copilot's own evaluation harness can trace every claim back to a source. See scenario design and disruption advising for the breeder-specific methods.

Content reviewed August 2026 · design-and-simulation stage