What MolLean is, in practice

MolLean is a language and runtime for doing chemistry with models under process verification instead of plain chain-of-thought.

The core change of stance is:

  • Instead of asking a model to explain chemistry in free-form text and trusting the narrative,
  • You make the model operate on an explicit molecular state, through a constrained language whose steps are checked as they go.

Concretely, MolLean introduces:

  • A layered Lean-based kernel that:
  • Tracks an explicit molecular state.
  • Checks state transitions, from primitive graph edits up to compound transformations [\[1\]](http://arxiv.org/abs/2610.20459v1).
  • Checks assertions over molecular readouts.
  • A typed witness protocol that:
  • Separates native structural checks (what the kernel can verify internally) from externally supplied measurements (what needs outside evidence) [\[1\]](http://arxiv.org/abs/2610.20459v1).
  • MolLean-MCP, a stateful tool interface that:
  • Exposes transitions, checks, and readouts to the model during generation.
  • Provides feedback on each attempted action.
  • Ensures rejected actions leave the state unchanged [\[1\]](http://arxiv.org/abs/2610.20459v1).

On top of this, the authors define three execution modes:

  • Direct chain-of-thought (baseline, no process verification).
  • One-pass trace execution and whole-trace refinement over MolLean traces.
  • Interactive reasoning via MolLean-MCP [\[1\]](http://arxiv.org/abs/2610.20459v1).

They evaluate these modes on 8,800 matched examples across 12 tasks covering molecular generation, editing, optimization, and reactions [\[1\]](http://arxiv.org/abs/2610.20459v1).

Why chemical chain-of-thought needs this

The motivating problem: chemical chain-of-thought can hallucinate structural and property claims [\[1\]](http://arxiv.org/abs/2610.20459v1).

Typical pattern today:

  • You give a description of a molecule or reaction.
  • The model writes a step-by-step explanation.
  • Inside that explanation, it may:
  • Implicitly modify structures.
  • Assert properties (“this intermediate is stable”, “this functional group appears”) that don’t follow from any explicitly tracked state.

MolLean’s design is a direct response:

  • Force every structural change to go through an explicit state transition.
  • Make every assertion about structure or readouts an object that can be checked.
  • Distinguish what the system can self-verify from what it must be told by an external measurement.

This is not about nicer explanations; it’s about replacing narrative with an executable trace.

How the Lean-based kernel works, step by step

The MolLean kernel is built on Lean, a proof assistant, but what matters for an agent builder is the control flow it enforces.

From the abstracted description [\[1\]](http://arxiv.org/abs/2610.20459v1), the kernel does:

  1. Start from an explicit molecular state
  • The state is an explicit representation of one or more molecules.
  • It’s sufficient for:
  • Primitive graph editing.
  • Defining compound transformations on top of those edits [\[1\]](http://arxiv.org/abs/2610.20459v1).
  1. Apply primitive graph edits

The lowest layer is primitive graph edits [\[1\]](http://arxiv.org/abs/2610.20459v1). Conceptually:

  • Add/remove/modify atoms or bonds.
  • Ensure the resulting graph is structurally well-formed according to the kernel’s rules.

Each edit:

  • Takes an input state.
  • Produces an output state.
  • Is checked before being accepted.
  1. Compose compound transformations

On top of primitive edits, MolLean supports compound transformations [\[1\]](http://arxiv.org/abs/2610.20459v1):

  • These bundle multiple low-level edits into higher-level operations.
  • They are still executed as explicit state transitions, verified by the kernel.
  1. Compute and assert molecular readouts

The kernel also handles assertions over molecular readouts [\[1\]](http://arxiv.org/abs/2610.20459v1):

  • A readout is some function of the molecular state.
  • An assertion ties a readout to a claimed value or property.

When the model emits an assertion, the kernel checks it against the type of readout and the available information.

  1. Separate internal checks from external measurements

This is what the typed witness protocol is for:

  • Some readouts/claims can be derived from the internal state and rules: native structural checks [\[1\]](http://arxiv.org/abs/2610.20459v1).
  • Others depend on externally supplied measurements [\[1\]](http://arxiv.org/abs/2610.20459v1).

The protocol:

  • Tags which assertions require external evidence.
  • Manages the “witnesses” that certify those external values.
  1. Reject invalid transitions without corrupting state

Any step that fails verification is rejected, and the state remains unchanged [\[1\]](http://arxiv.org/abs/2610.20459v1).

This creates a strong guarantee:

  • The current molecular state always reflects a valid history under the kernel rules.
  • Errors become visible rejections, not silent corruption.

Why Lean matters here

While the paper only states that the kernel is Lean-based [\[1\]](http://arxiv.org/abs/2610.20459v1), for your stack this implies:

  • The semantics of MolLean programs are formally defined.
  • Checks are done by a small kernel instead of spread across ad-hoc tooling.

The main operational takeaway: you get a deterministic, auditable executor for molecular traces, not just ad-hoc validation scripts.

MolLean-MCP: putting the kernel behind a tool interface

MolLean-MCP wraps this kernel into a stateful tool interface [\[1\]](http://arxiv.org/abs/2610.20459v1).

Key behaviors:

  • It exposes transitions, checks, and readouts during generation [\[1\]](http://arxiv.org/abs/2610.20459v1):
  • The model can inspect the current state.
  • It can see what checks/readouts are available or have been performed.
  • The model receives feedback to decide its next action [\[1\]](http://arxiv.org/abs/2610.20459v1):
  • For each attempted operation, the interface tells the model if it was accepted or rejected.
  • On rejection, the state is unchanged.

From a tool orchestration point of view, this gives you:

  • A loop of: observe state → propose action → get kernel verdict → adjust.
  • In contrast to plain chain-of-thought, you’re not guessing whether intermediate steps were “right” — the kernel decides.

Since this is described as MCP, you can treat it conceptually as:

  • A stateful tool that holds the canonical molecular state.
  • A contract: every mutating call is either committed or rejected, never partially applied.

Three modes of using MolLean

MolLean supports three reasoning modes [\[1\]](http://arxiv.org/abs/2610.20459v1):

  1. One-pass trace execution
  • The model generates a MolLean trace in one go.
  • The kernel executes it once, checking each step in sequence.
  • Invalid steps are rejected; the state only reflects accepted steps.

Use this when:

  • You want an executable log of what the model “claims” to be doing.
  • You don’t need the model to adapt mid-trace based on failures.
  1. Whole-trace refinement
  • You run a pass, get a trace, check it.
  • The model gets feedback about which steps or assertions failed.
  • It refines the entire trace based on this feedback.

Empirically, with Qwen3.6-27B, this mode outperforms direct chain-of-thought on all 12 tasks [\[1\]](http://arxiv.org/abs/2610.20459v1).

This suggests:

  • Even without interactive step-by-step adaptation, batch verification and revision yields robust gains.
  1. Interactive reasoning via MolLean-MCP
  • The model interacts with the MolLean-MCP tool in a loop.
  • It sees outcomes as it goes and can adjust next actions.

The evaluation shows:

  • MolLean-MCP complements whole-trace refinement with stepwise verification feedback.
  • This reaches better performance in reaction tasks [\[1\]](http://arxiv.org/abs/2610.20459v1).

For tasks involving reactions, interactive feedback about which intermediate steps are legal or consistent seems especially valuable.

How it fits into an agentic stack

Given what’s documented, you can think of MolLean as:

  • A domain-specific planning language for chemistry, with a formally checked executor.
  • A stateful tool the model calls through MolLean-MCP.

A minimal stack for a chemical agent around this would look like:

  • Policy model: e.g. Qwen3.6-27B as in the paper [\[1\]](http://arxiv.org/abs/2610.20459v1).
  • Stateful kernel service: runs the Lean-based MolLean executor.
  • Tool interface: presents MolLean-MCP to the model:
  • Action schemas: primitive edits, compound transforms, readout queries, assertion submissions.
  • Responses: success/failure flags, updated state, readout values, and witness requirements.

The control flow options:

  • Direct CoT baseline: no MolLean, just text → answer. (Used only for comparison in the paper.)
  • Batch mode with whole-trace refinement:
  1. Prompt model to produce an initial MolLean trace for a task.
  2. Execute under the kernel.
  3. Summarize failures and ask the model for a refined trace.
  4. Repeat a fixed number of refinement rounds or until acceptance conditions.
  • Interactive MolLean-MCP loop:
  1. Initialize a task in the kernel (starting state, targets).
  2. Let the model issue MolLean-MCP actions.
  3. For each attempt:
  • Kernel checks it.
  • Tool returns result + any readouts.
  • Model updates its strategy.

You choose between batch and interactive modes based on:

  • Task type (reactions seem to benefit more from interactive feedback [\[1\]](http://arxiv.org/abs/2610.20459v1)).
  • Latency/complexity budget (interactive can be more token and call intensive).

Why this matters now for builders

From the evidence in the paper [\[1\]](http://arxiv.org/abs/2610.20459v1):

  • Hallucinated structural and property claims are a concrete failure mode in chemical chain-of-thought.
  • Simply scaling the model and hoping it will “learn chemistry” is not sufficient.

MolLean provides a mechanism to address this:

  • Explicit molecular state → no hidden changes in prose.
  • Checked state transitions and assertions → you catch impossible or unsupported steps immediately.
  • Separation of internal vs external validation → you know which parts of the reasoning rest on kernel rules vs lab or external data.

Performance-wise:

  • On 8,800 matched examples, across 12 molecular tasks, whole-trace refinement with Qwen3.6-27B beats direct chain-of-thought on all 12 tasks [\[1\]](http://arxiv.org/abs/2610.20459v1).
  • MolLean-MCP further improves on reaction tasks via interactive feedback [\[1\]](http://arxiv.org/abs/2610.20459v1).

So even with a single model and this single kernel, process verification itself yields consistent gains.

For production systems, this has two direct implications:

  • You can turn parts of your chemistry stack from “LLM-generated explanation we hope is right” into checked programs with formal semantics.
  • You get operational hooks (accepted/rejected steps, witness requests) that are observable and can be logged, audited, or fed into downstream control logic.

Failure modes and trade-offs to expect

Based on the architecture as described [\[1\]](http://arxiv.org/abs/2610.20459v1), there are predictable trade-offs:

  • Verbosity and latency:
  • Representing reasoning as explicit MolLean traces is more verbose than plain text.
  • Interactive MolLean-MCP adds a per-step tool roundtrip.
  • Action space constraints:
  • The model must learn to speak the MolLean language and respect the primitive/compound action types.
  • Early attempts may hit many rejections before converging to valid strategies.
  • Witness bottlenecks:
  • Assertions requiring external measurements depend on the typed witness protocol.
  • If your external measurement layer is slow or unavailable, it can stall reasoning that depends on those values.
  • Coverage of kernel rules:
  • The Lean-based kernel only checks what it encodes.
  • Unsupported chemistry behavior falls back to the external measurement side, or cannot be expressed.

On the flip side, these constraints are exactly what give you:

  • The guarantee that invalid actions never corrupt state [\[1\]](http://arxiv.org/abs/2610.20459v1).
  • Fine-grained observability into:
  • What the model is trying to do.
  • What the kernel accepts.
  • Where external evidence is needed.

In agent terms, this makes MolLean-MCP a high-signal tool: almost every interaction yields useful control information.

What to watch next

The paper’s evaluation shows:

  • Whole-trace refinement dominates direct chain-of-thought for chemical tasks under Qwen3.6-27B [\[1\]](http://arxiv.org/abs/2610.20459v1).
  • Interactive MolLean-MCP pushes reaction performance even further [\[1\]](http://arxiv.org/abs/2610.20459v1).

This sets up a few clear directions for builders and researchers:

  • Scaling to larger or different models:
  • The current documented experiments use Qwen3.6-27B [\[1\]](http://arxiv.org/abs/2610.20459v1).
  • Understanding how process-verifiable languages interact with other architectures and sizes is the next obvious axis.
  • Expanding task coverage:
  • The current evaluation spans generation, editing, optimization, and reactions [\[1\]](http://arxiv.org/abs/2610.20459v1).
  • Extending the kernel and typed witness protocol to more complex domains (e.g., more elaborate reaction systems or property landscapes) will test the approach’s generality.
  • Tighter integration into closed-loop workflows:
  • The separation of structural checks vs external measurements [\[1\]](http://arxiv.org/abs/2610.20459v1) matches how many labs and platforms already work.
  • Plugging real measurement systems into the typed witness protocol is an obvious next step for end-to-end autonomous experimentation.

The conceptual move is general: replace free-form domain reasoning with process-verifiable, tool-mediated state evolution. MolLean is a concrete instance of this for chemistry, backed by a proof assistant kernel and demonstrated performance gains.

What is not documented

From the provided source [\[1\]](http://arxiv.org/abs/2610.20459v1), the following are not established:

  • The concrete syntax of MolLean programs or examples of specific graph edits and compound transformations.
  • The exact structure of the layered kernel, e.g., how many layers or what each layer formally contains.
  • The detailed design of the typed witness protocol beyond its high-level role and separation of internal vs external checks.
  • The precise API of MolLean-MCP, including method names, parameter formats, or integration examples with any specific orchestrator.
  • The identities or detailed definitions of the 12 tasks, their datasets, metrics, or per-task results, beyond task categories and the aggregate statements about performance.
  • Any numerical performance metrics (error rates, scores) beyond relative statements like “outperforms” or “better performance”.
  • Implementation details such as runtime performance, resource requirements, or deployment environment for the Lean-based kernel.