How to Build a Controlled AI Assistant for Quantum Computing

An architectural approach in which free-form dialogue is turned into a controlled computational workflow: the lifecycle stage determines the AI's goal, the context available to it, and the set of tools it is allowed to use right now.

The user describes a task in ordinary language, the assistant translates it into a structured scenario, helps gather the missing information, guides it through validation, runs it on a simulation-first basis, and explains the result. The LLM does not own the computational process: experiment state is stored separately from the dialogue, the AI tools available depend on the current lifecycle stage, and any run goes through independent validation and an execution policy.

This article describes architectural boundaries: how roles are distributed across layers and who owns each action. Internal contracts, data schemas, and the composition of specific checks are not covered here — the subject is where the boundaries run, not what code draws them.

Let me state up front the conclusion the article arrives at: a sensible default is not to let the AI layer submit jobs to physical hardware. The assistant carries an experiment as far as simulation, while hardware confirmation remains a separate, explicitly enabled capability of a trusted perimeter. The article is about the path leading up to that button — and about why the button itself does not belong to the model.

Free-form dialogue must not mean free-form execution. The lifecycle stage determines what the AI knows, what it may propose, and which tools it is allowed to use right now.

Why Quantum Computing Needs a Conversational Interface

Quantum algorithms rarely present themselves to a user as a "Run" button. Before any computation, you need to understand what problem the person is solving, what data to use, whether the input is sufficient, whether the chosen algorithm fits, and in what environment it may be executed at all.

A traditional interface pushes this complexity onto the user: pick an algorithm, fill in a form, figure out the parameters, check the constraints, interpret the technical result yourself.

An AI assistant inverts the process. The user starts from an applied formulation:

"Estimate the probability that this asset drops in value by more than five percent."
"Find unusual sales declines by product over the last three months."
"Analyze this set of medical images."

For a human, this is an ordinary conversation. For the platform it must be a strictly controlled process — because behind the "Run" button there may be access to real quantum hardware.

Hence the central tension: the conversation must stay flexible, while the computation must stay formal. People speak in incomplete phrases, change their minds, wander off and come back. A computational system, by contrast, has to know exactly which configuration is current, whether it has passed validation, and whether it may be executed.

A conversational AI cannot simultaneously be the interface, the source of truth, and the owner of execution — and it is precisely those three roles that get blended together when the model calls computational tools directly.

Why a Direct Tool Call Is Not Enough

The naive design looks simple:

The model is handed every function the platform offers, decides for itself which one fits, and constructs the call. For a demo this works. Once it is integrated with a platform that grants access to quantum hardware, five problems surface.

Incomplete and ambiguous requests. Users rarely supply every parameter in a single message. The model may decide a missing value is obvious and substitute something plausible. In an ordinary answer that is an inaccuracy. In a computational process it means running a different task.

Conflicts between old and new values. The dialogue history contains several versions of the same parameter: "use a 3% threshold," and then, ten messages later, "no, let's go with 5% after all." Both values remain in the context. If the message history is the only source of state, the model decides for itself which value is current — and that choice is hard to reproduce and hard to audit.

Repeated and stale calls. An LLM may repeat a tool call after a timeout without knowing whether the backend accepted the previous request. Between the moment a call is formed and the moment it is processed, the user may have changed the task through another interface — the control panel or the API.

Generated text is not a computed result. The model is good at continuing a conversation plausibly and can "explain" an expected result before the actual job has finished. In systems handling financial, medical, or scientific data, that kind of uncertainty is unacceptable.

User data is untrusted input too. The assistant works with tables, exports, and file sets uploaded by the user. Text inside the data — a column name, a row comment, image metadata — enters the model's context on equal footing with the person's message, and the model has no reliable way to tell one from the other. If the execution tool is available to the model, anyone able to plant data gains indirect access to that tool.

None of these problems is solved by a long system prompt — a prompt remains an instruction, not a guarantee. Understanding a request has to be separated architecturally from the right to act.

What Quantum Hardware Specifically Adds

Everything above is the general story about agents and dangerous actions. The specifics begin where the thing behind the control layer's boundary is a physical device with a queue and a maintenance calendar.

Beyond the contract boundary lies an irreversible operation. While a job sits in the queue it can usually still be cancelled; once it starts, it cannot. The platform does not control this irreversibility — it is inherited from the execution environment. But it is exactly what dictates the shape of the confirmation: single-use, short-lived, and bound to a specific scenario version.

A job outlives the session. The queue on a popular backend is measured in hours: the user will close the tab, and the assistant will restart. The experiment lifecycle therefore has to survive a model restart and cannot live in the dialogue context.

A valid scenario ≠ one that is executable on a device. Transpilation decomposes the circuit into native gates and maps it onto the connectivity topology; only there does the actual depth become clear, along with whether the circuit fits a particular backend. This check is tied to the pair "scenario + device" and does not carry over to anything else.

Device suitability goes stale. Calibration, maintenance, and error drift change a backend without the platform's involvement. This is the same race condition as a stale scenario version, but with an external source of change — and that is why any permission to run has an expiry date.

Architectural Principles

1. The dialogue is not the source of truth. Message history is there to support natural communication, but it does not define experiment state. The current configuration is stored separately and carries its own version.
2. The LLM does not own the experiment lifecycle. The model helps interpret intent, gather parameters, and explain results. Decisions about readiness, permissible transitions, and actual execution are made by a deterministic control layer.
3. The stage determines authority. At each stage the system explicitly defines the assistant's goal, the context available to it, and the permitted set of tools — not every platform capability at once.
4. Algorithms are decoupled from the shared lifecycle. The rules for preparation, confirmation, and execution do not depend on any particular quantum algorithm; domain parameters and checks plug in as independent modules.

Terminology

Two words in this text carry more weight than the rest. A scenario is a concrete configuration of a computational task: type, parameters, data, version; it is what gets prepared, validated, confirmed, and executed. An algorithmic module is a class of tasks and the knowledge about it: which parameters are required, which values are admissible, what the result looks like. A module describes a kind of task; a scenario is an instance.

Throughout the text, domain validation means checking parameters inside an algorithmic module, an ECL check means the platform-level check performed before execution, and a transition check means verifying that an action is permissible within the lifecycle. These are three distinct operations, and they do not substitute for one another.

Top-Level Architecture

An important detail of the diagram: chat is not the only entry point. The panel and the API address the domain layer directly, bypassing the conversational AI, and this is not an optimization but a precondition for the whole construction to work.

• User interfaces. Chat is only one way of working with an experiment; the same scenario can be viewed and modified through the panel or the API. Experiment state therefore does not belong to any single interface.
• Conversational AI. Turns a free-form request into structured proposals, asks clarifying questions, explains verified results. It does not hold the definitive version of the task and does not make execution decisions.
• Domain control layer. The owner of the lifecycle: it stores experiment state and its version, checks whether actions are permissible, determines the available capabilities, and coordinates transitions between stages.
• Algorithmic modules. Knowledge about specific classes of tasks — required parameters, admissible values, domain constraints, result format. The shared state machine stays unchanged.
• Execution Control Layer (ECL). A deterministic boundary between a prepared scenario and the computing environment. It does not trust the LLM's judgment that a task is ready.
• Execution service. Receives an already normalized, validated, and authorized scenario and is responsible for the actual execution. A separate section below is devoted to this contract boundary.

This separation makes the conversational layer replaceable: even if the LLM or agent runtime is unavailable, the panel and the API keep working with the same experiment state and the same transition rules.

Dialogue and Experiment State Are Different Entities

The dialogue history answers the question: "What did the user and the assistant say?"
Experiment state answers a different one: "Which task configuration is current right now?"

Experiment state is a versioned representation of the current configuration and lifecycle of a computational task, which the domain layer uses as its source of truth.

Experiment state contains: task type, current configuration version, user parameters, missing data, errors and warnings, the outcome of the latest check, the current lifecycle stage, a reference to the external job, and the verified result.

The LLM may propose a change to the scenario, but it does not declare that change accepted. A change passes through normalization, a check of permitted fields, and domain validation — only then is a new version saved. That is how the dialogue becomes an interface to the task rather than its storage.

What reproducibility means here. What is reproducible is the configuration, not the number. The scenario version, parameters, execution mode, target environment, and job identifier are stored in full — enough to answer, a month later, exactly what was run and who confirmed it. Matching results on a repeat run on physical hardware, however, is guaranteed by no one: the state of the environment changes outside the platform. It is worth distinguishing these two senses explicitly, because a reader will by default read "reproducible experiment" as the second one.

The State Machine as the Experiment Lifecycle

The canonical set of stages, used consistently below in every diagram and table:

No scenario → Preparation → Clarification → Correction / Ready → Simulation: queued → Simulation: running → Simulation: completed → Hardware ready → Hardware: queued → Hardware: running → Completed | Error.

Two things are deliberately absent from this list. Validation is not a stage but an internal operation: domain validation and the ECL preflight run on every change to the scenario, and their outcome moves the experiment into clarification, correction, or readiness. Confirmation is not a stage but a user action taken at the ready stage: the scenario waits for it while remaining in the ready state, and moves on only together with it.

The hardware branch is optional: for many scenarios the lifecycle ends when the simulation completes.

From correction, a scenario does not move straight to readiness: an edit goes through normalization and validation again, as does any parameter change made at the ready stage itself. The state machine answers concrete questions: may parameters be changed right now, is more information still needed, is a run permitted, can the result be treated as trusted, is a new experiment required instead of modifying the old one.

The queued and running stages behave identically in both branches and are collapsed into a single row in the table.

The stage formula:

A stage governs not only the backend process but also the assistant's behavior.

Authority: Three Levels of Restriction

Between "the model proposed an action" and "the action was performed" there are three independent filters. None of them substitutes for the others.

Level 1. The Toolset Is Shaped by the Stage, Not by Relevance

In many agentic systems the model is handed a general list of capabilities from the outset: create, update, validate, run, status, get_result, and then picks the right tool itself. The longer the list, the higher the risk of a wrong choice — but the problem runs deeper: the model can see actions it currently has no authority to take.

A tool is provided not because it is relevant to the request, but because the action is permitted at the current stage.

A user may write "run it right now," and the run tool will be semantically relevant. But if the task has not passed validation, the model simply does not have that tool. Once execution begins, the parameter-editing tools disappear; a completed experiment cannot be quietly rolled back into preparation — new parameters mean a new lifecycle.

Level 2. Some Actions Are Never a Model Tool at All

Even a stage-dependent toolset does not mean the LLM receives every action the system permits at that stage. Capabilities are divided among three owners:

• AI: identify the class of task, provide background information, create or extend a scenario, propose parameter corrections, obtain verified facts about the result, and explain them to a person.
• The user, through a controlled interface: review the final configuration, confirm a run, choose a permitted execution mode, request status, start a new experiment.
• The platform, on its own: validates parameters, applies the compute policy, checks permissions and the scenario version, hands the job to the execution service, stores the result, and maintains an audit trail of transitions.

The difference from classic human-in-the-loop is fundamental. In the usual scheme the LLM proposes a dangerous tool call, the runtime pauses execution and asks a human to confirm. Here a stricter option is chosen: a critical action may not be a model tool at all. It belongs to the control panel, which addresses the domain layer directly. The LLM knows that the user can perform the action and can explain what is required for it — but it is not the initiator.

This does not fully close off injection via user data, and it is worth saying why. An injection cannot press a button the model does not have. But the model does have a parameter-editing tool permitted at the preparation stage — and text inside an uploaded table may try to substitute the threshold, the column, or the direction of the event. Then a human presses the button, just on a tampered configuration.

What protects against this is not the absence of a tool but two other properties of the design. First: confirmation is issued only at the ready stage, where the user is shown the entire final configuration — not a diff against the previous step, but the complete set of values the task will be executed with. Second: any parameter change raises the version and invalidates the previous confirmation, so a value cannot be swapped after the person has agreed — the agreement applies to a version, not to the task in general.

The takeaway to keep in mind: separating owners removes the direct path from injection to execution, but not the indirect one. The indirect path is closed by mandatorily displaying the configuration before confirmation — which makes the ready stage not a formality but part of the protective perimeter.

Level 3. The Backend Re-Checks Before Every Transition

A toolset reduces the surface for mistakes, but it does not replace a server-side check. Consider this race:

1. The AI received a set of tools for a ready scenario.
2. The user changed a parameter through another interface.
3. The scenario received a new version and requires validation again.
4. The model sent a call based on the stale context.

If the backend trusts a tool list assembled a few seconds ago, an impermissible action becomes possible. Therefore, before every significant transition, the system re-reads the source of truth and checks: the current stage, the configuration version, whether the action is permissible, the initiator's permissions, the presence of a confirmation, the outcome of the latest validation, the compute policy, and the repeat-request identifier (idempotency key).

Tool availability improves the model's safety and accuracy, but the final decision is always made by the backend.

Execution Control Layer: validate → policy → execute

The state machine and the ECL solve different problems.

• The state machine is responsible for the lifecycle of the user's experiment: which stage is current, which actions are permissible, which tools the model receives.
• The ECL is responsible for the right to move from a prepared scenario to a computation: is this workflow supported, are the parameters safe, is the request trying to control infrastructure, which execution mode is permitted, is a prior simulation mandatory, is additional confirmation required.

The scheme is not new in itself, and that is a virtue. validate → policy → execute is admission control in its purest form: the same principle behind admission controllers in Kubernetes or a policy engine such as OPA. In access-control terms the ECL is a Policy Decision Point and the executor is a Policy Enforcement Point; decision and enforcement are separated deliberately. Requiring a separate human confirmation for an irreversible transition is the four-eyes principle, familiar from banking systems. The novelty here is not in the mechanism but in what it is applied to: the subject being controlled is neither a person nor a service, but a language model.

Validate. The ECL receives a formalized scenario, not free-form LLM text. It checks whether the workflow belongs to the permitted catalog, whether the required data is present, whether the values are admissible, and whether there are any attempts to override infrastructure parameters — provider, hardware, execution mode.

The response takes exactly three forms: the scenario is valid; the scenario lacks data, with a statement of exactly which; the scenario is inadmissible, with a reason. The state machine translates this into readiness, clarification, or correction. There is no fourth form, and no "unknown" state exists: any unexpected response is treated as a rejection.

Policy. Invoked only for a valid scenario. It determines the permitted execution mode, the simulation-first requirement, the available provider capabilities, limits on job size, the need for human confirmation, and the possibility of a subsequent hardware flow. Policy is not chosen by the model and is not passed to it as an editable parameter — the assistant can explain the decision but not change it.

Execute. Accepts only a scenario that has passed validation and policy. If policy limits execution to simulation, that becomes a hard boundary at this very step. It is invoked after an action from the user panel and a re-check of the experiment state — not by the LLM directly.

How many times the ECL is invoked. Counting passes is pointless — the number depends on the route. What matters is the invariant: no job is ever handed to a computing environment without a full ECL pass immediately beforehand. Neither a successful preflight, nor a user confirmation, nor a successful simulation substitutes for that pass.

There are, however, two kinds of pass, and they should not be conflated.

Preflight — validate and policy during scenario preparation, without execution authorization. Its job is to show the user missing data and constraints as early as possible. It authorizes nothing, is invoked as many times as needed, and its result may be stale by the time of the run.

The authorizing pass — the same path in full, including execution authorization, immediately before the job is handed over. Only its verdict has force, and only it closes the race described above: between preparation and confirmation, the scenario version, the policy, or the state or availability of the environment may have changed.

On a simple simulation route this yields one preflight and one authorizing pass. The hardware branch adds its own checks before confirmation — hardware support, choice of backend class, whether the circuit fits after transpilation — and its own authorizing pass before the job is submitted, because the previous one applied to the simulation.

Fail-closed. If the ECL is unavailable, returned an unexpected contract, or did not confirm the simulation-first policy, execution is blocked. The system does not treat the absence of a prohibition as permission. For quantum computing this is critical: a temporary failure of the control layer must not lead to constraints being bypassed and a job being sent straight to the provider.

The Executor Contract Boundary

The domain layer does not perform the computation itself. Behind the ECL sits an execution service: it accepts a normalized job, submits it to the chosen environment, watches the queue, obtains status, and returns the result. To the domain this is a single contract — "a permitted computing environment" — with the specific provider hidden behind it.

Hence a division of responsibility worth spelling out, because it explains what is deliberately absent from this architecture:

• The progress of execution — submission, queue tracking, callback handling, recording the result — belongs to the execution service. The domain layer stores the job identifier and the last known status; it does not reimplement the logic of obtaining it.
• Cancelling a running job is proxied to the same contract. The domain does not decide whether the operation made it in time — it records the state the contract returned. The availability of such an operation depends on the environment rather than on the lifecycle stage, which is why it is marked as conditional in the tables below.
• Assessment of executability and of hardware-run conditions comes from the same place, together with the eligibility check. The platform does not compute these; its job is to show the assessment to the user before confirmation and to bind that confirmation to a specific scenario version.

A useful side effect: the execution environment is replaceable. The state machine does not change when the provider changes, because it knows nothing about the provider beyond the contract.

Failures: two classes. There is a single "Error" stage in the state machine, but different things lead to it, and their recovery paths differ.

The first class is errors the domain layer sees for itself: incomplete or inadmissible parameters, a policy prohibition, a version conflict, a missing or expired confirmation. The scenario stays alive, the experiment returns to correction or to re-confirmation, and the user can continue with the same task.

The second class is errors that arrive from beyond the contract boundary. The domain does not interpret their nature: it records a terminal state with safe diagnostics. Recovery here does not mean stepping back through stages but starting a new experiment — with the same configuration if needed, but with a new version and a new confirmation.

The distinction is practical: in the first case the assistant can propose a specific fix; in the second it can only explain what happened and offer to start over. Merging them into a single state without a class distinction means forcing the model to guess which recovery path is appropriate.

The Full Path: From a User Message to a Result

The mechanics are easier to see in an end-to-end example. It is hypothetical and given only to illustrate the transitions.

The key moments in this trace: step 3 — the user sees the whole configuration, not a description of the changes; step 4 — a parameter change raises the version and invalidates the confirmation; step 5 — the confirmation applies to a specific version, not to the task in general; step 6 — the stage closes off tools regardless of how reasonable the user's request is; step 7 — the explanation appears after the result, not in place of it.

Simulation-First: A Technical Gate Before Hardware

Simulation-first is a platform policy, not an LLM decision. It has two concrete functions, and both concern configuration rather than the domain quality of the answer.

A viability check. A successful simulation run shows that the scenario really does assemble and execute from end to end: the parameters are mutually compatible, the circuit is built, the job travels the whole path through the executor, and the result comes back in the expected format and within the stated limits. This is a cheap end-to-end run of the configuration — what other systems would call a smoke test, only performed on the real execution path rather than a mock-up of it.

Admission to the next stage. Simulation is a precondition for the hardware flow. A scenario that has not proven executable in a cheap environment is not considered a candidate for an expensive one. Hardware eligibility is checked only after a successful simulation and is confirmed anew by the ECL.

Hence an important clarification about what simulation-first is not. It is a configuration check, not an assessment of result quality on a real device: an ideal simulator knows nothing of noise, readout errors, or topology constraints, and no one guarantees that the numbers from simulation and hardware will match. The boundary is worth keeping explicit, because users readily read "the simulation passed" as "the result is confirmed" — and the assistant should not reinforce that reading.

Where simulation-first hits a ceiling. Exact classical simulation is exponential in the number of qubits: beyond a few dozen it becomes an expensive computation in its own right. Large scenarios have to be checked in reduced form — fewer qubits, fewer shots, approximate methods — and such a check confirms that the configuration assembles but no longer reproduces the target computation. Up to what size simulation counts as a full-fledged precondition for the hardware flow should be stated explicitly in policy.

In execution-control terms, simulation is a mandatory prior step in the chain of permissions, on a par with validation and policy. It answers the question "is this configuration executable at all," not the question "should the resulting number be trusted."

Running on Quantum Hardware as a Separate Branch

Hardware execution is not just another parameter value the LLM might propose, but a separate controlled branch.

Compatibility check. Not every algorithm, provider, or current configuration supports physical hardware. The LLM cannot change the outcome of this check with the phrase "use a real quantum computer."

Provider and backend. The user may express a preference, but the final choice of device stays with the platform — it is determined by trusted configuration and ECL policy, not by a supplied parameter.

Transpilation and capacity. Changing the backend requires re-transpilation: a check result from one device does not carry over to another.

Calibration window. Eligibility has an expiry date. If the state of the environment changed between the issuing of an authorization and the submission of the job, the authorization is redeemed without a run and the user goes back to confirmation under new conditions.

Confirmation. At the hardware-ready stage the user sees the final configuration along with the conditions returned by the eligibility check, and separately confirms two things: that they want to move from simulation to hardware, and that they accept those conditions. The confirmation is bound to a specific scenario version, short-lived, single-use, not exposed to the model in cleartext, and becomes invalid once parameters change or the deadline passes.

A repeat policy check immediately before the job is submitted — between the issuing of the confirmation and the run, the conditions of the environment, its availability, or the scenario itself may have changed.

What remains in the audit trail. The single-use authorization itself is not retained. What is retained is the record of its lifecycle: identifier, scenario version, initiator, time of issue and time of redemption, plus safe job metadata — job ID, target, status. This is enough for incident analysis and not enough for reuse.

The default boundary. This entire branch is a separate capability of the trusted perimeter: by default it is disabled for the AI layer, and the assistant carries the experiment only as far as the completion of the simulation. This is an architectural decision, not a technical limitation — the hardware is supported.

Summary Table: Tools by Stage

The hardware-branch rows describe a configuration in which this capability is explicitly enabled. In the default configuration they are absent from the model's context: for the assistant, the lifecycle ends when the simulation completes, and the hardware-ready stage and everything after it are unavailable to it, along with all the tools that belong to them.

The same action exists within the platform but belongs to different participants: submitting a job belongs to the internal executor, confirmation to the user panel, and the LLM gets only explanatory and preparatory tools.

Explaining the Result: The Last Boundary

The entire perimeter described above exists to support the claim that generated text is not a computed result. Yet the final step of the workflow is precisely generation — and without a separate restriction it brings back exactly the problem the whole construction was built against.

The restriction is simple: the assistant receives not "the result" but a fixed set of verified fields, and everything it asserts must be traceable to a specific field.

• Numbers are not recomputed in prose — the model does not derive new quantities from the ones it received.
• An estimate with a confidence interval is not collapsed to a point: "0.07 ± 0.03" does not become "about seven percent."
• Housekeeping properties of the run — execution mode, backend, number of repetitions — are not invented but taken from stored metadata.
• The applied conclusion is kept separate from the computed fact: the model may say what a quantity means, but it does not pass an interpretation off as a measurement.
• If a statement cannot be backed by a field, the model does not make it.

This does not eliminate wording errors entirely, but it moves them from the class "invented number" to the class "poorly phrased sentence" — and the latter is noticeable and fixable.

Examples of Algorithmic Modules

Four modules from different domains are plugged into the shared state machine — a test that the lifecycle really is independent of the algorithm.

The names matter here only as labels: to the lifecycle, a module is a set of required parameters, rules for checking them, and a result shape, while the internal mathematics never leaves the module's contract.

The difference between modules lies entirely inside them: IQAE requires a threshold and an event direction, anomaly search requires a temporal aggregation and a deviation criterion, image work requires the composition and validation of a dataset. The shared lifecycle — intent → scenario → clarification → validation → readiness → confirmation → execution → result — stays the same for all four, including the two non-quantum ones. Knowledge about the algorithm does not leak into the experiment lifecycle.

Why a Domain Layer Rather Than an Agent Graph

Technically the problem could be solved with LangGraph or a similar framework — it has state, nodes, conditional edges, persistence, interrupts, human-in-the-loop, and dynamic tool selection based on current state is implementable there too. The argument for a purpose-built domain layer is not that the library lacks these capabilities.

A quantum experiment is an independent, long-lived object. It can be driven by chat, the panel, an external API, background processes, the execution service, or a callback from an external platform. Making an agent graph the owner of experiment state would tie the lifecycle to the agent runtime: you would have to synchronize graph checkpoints with changes coming from the UI, the API, and external jobs, and you would still have to implement domain validation, versions, authorization, and transition rules separately.

The point is not rejecting agent frameworks as a technology, but rejecting the idea of making one the owner of a quantum experiment's lifecycle.

An agent framework can be used on top of the domain layer — for complex conversation routing, branching, or additional orchestration — but it is not the source of truth for the computational process. This makes it possible to swap out the LLM or the agent runtime without rewriting the execution rules, and to keep the algorithms working through the UI and the API even when the model is entirely unavailable.

The Cost of the Approach: When You Don't Need It

The fair question to ask of any such scheme is how much of the above can be achieved considerably more cheaply. The answer: quite a lot. A versioned record in a database resolves conflicts between old and new values. Structured outputs remove free-form parsing of the model's proposals. An idempotency key handles repeated calls. A confirmation screen before an irreversible action provides human control. None of this requires a separate domain layer.

The separation starts to pay off when three conditions coincide: the object lives longer than the user session, several interfaces drive it at once, and the cost of a wrong action exceeds the cost of an extra check. If chat is the only entry point, the experiment lives for minutes, and only simulation is ever run, the construction described here will be an expensive way of getting what a database table and a single button already provide.

The other trade-offs:

Design complexity. The state machine has to be designed and maintained: a model that is too general stops expressing domain constraints, while one that is too detailed becomes hard to evolve.

Coordinating changes. Versions, idempotency, and re-checking state become mandatory parts of the system rather than an option.

Observability and testability. A dynamic toolset makes behavior harder to analyze: you need to know not only which tool the model called but also which tools were available to it at all at that stage. The "stage × tool" correspondence is worth keeping as an explicit matrix and covering with tests — with the mandatory condition that an action outside the matrix is rejected by the backend regardless of what the model received in its context. Otherwise the third level of restriction is only verified on paper.

Conversational UX. Rigid rules can degrade the dialogue. If the assistant mechanically asks templated questions, the user starts to perceive the chat as a slow form. The state machine should define boundaries, not dictate every sentence.

Comprehension errors remain. The LLM can still misidentify an intent or extract a wrong value. The difference is that such an error does not automatically turn into execution.

Applicability Beyond Quantum Computing

The approach grew out of the specifics of quantum computing: mandatory prior simulation, restricted access to hardware, sensitivity to parameters, asynchronous execution, a traceability requirement.

But the logic is broader and applies to any system where the cost of a wrong action exceeds the cost of an extra check: training ML models, financial transactions, medical workflows, cloud infrastructure management, engineering simulations, publishing or deleting user data.

Conclusion

The main difficulty in designing an AI assistant for a computational platform is not understanding natural language, but what should happen next, once the intent has already been understood.

Wiring an LLM directly to computational tools makes the model too influential a participant in the process: the dialogue history does not guarantee that the parameters are current, a tool's relevance does not confer the right to use it, and human-in-the-loop on its own does not solve the problem if the model remains the owner of the task's lifecycle and the initiator of critical transitions.

The approach described here is one possible answer, and it is justified under quite specific conditions: a long-lived object, several control interfaces, irreversible execution beyond a contract boundary, a traceability requirement. Outside those conditions it is overkill.

Within them, it helps to remember what the architecture does not do. It does not make the model more accurate — the model makes exactly the same mistakes. It makes the mistake unexecutable: a misunderstood intent lands in a formalized scenario, goes through independent validation, and at worst turns into a question for the user rather than a job on a quantum processor.

The LLM is a smart interface to a computational platform, but not the owner of the experiment. It helps understand, prepare, and explain the task. The state machine drives the process, the control layer makes the decision, the backend executes.