From Tokens to Topology: Teaching LLMs to Think in Simulink

A model engineer asks for a small change: add a temperature sensor between a fuel-cell stack and a pump-control input. Easy request. Annoying execution. The assistant must find the right Simscape block, use the correct library path, respect physical ports, avoid breaking the existing topology, and produce a model that actually compiles.

A generic LLM can sound confident while doing all of this wrong. It may choose a plausible but nonexistent block path. It may read a huge XML file, lose the signal routing in the noise, then write a MATLAB command that refers to an invalid object. Very fluent. Very broken. The usual enterprise AI experience, but with more ports.

The SimuAgent paper is interesting because it does not treat this as a prompt-engineering problem.¹ It treats Simulink modeling as a representation, validation, curriculum, and reinforcement-learning problem. That distinction matters. The headline result is that a Qwen2.5-7B-based SimuAgent pipeline reaches 51.89% average accuracy on SimuBench, narrowly above GPT-4o with XML prompting at 50.45%. But the paper is not really about a small model “beating” a frontier model by 1.44 points. That is the least useful way to read it.

The stronger point is this: graphical engineering work becomes more learnable when the system stops asking the language model to think in raw tokens and instead gives it a compact topology, executable feedback, staged practice, and reflection-shaped reinforcement learning. The model is not magically smarter. The task has been made less stupid.

The real bottleneck is not language, but topology under constraints

Simulink is not ordinary code. It is a graphical, hierarchical modeling environment where correctness depends on blocks, ports, signal directions, physical domains, parameters, and library conventions. A syntactically pretty answer can still be useless if one port is wrong or one required solver block is missing.

This makes Simulink a painful but valuable benchmark for LLM agents. The agent must handle language, graph structure, domain knowledge, and tool interaction at the same time. It also faces the usual enterprise problem: the source artifact is not naturally shaped for LLM consumption. XML is complete, but verbose. Screenshots are visually intuitive, but hard to edit and validate. MATLAB scripts are executable, but brittle when the model must reason about existing topology.

SimuAgent’s first move is therefore not a new reasoning slogan. It changes the object the model sees.

Instead of feeding the model raw XML, SimuAgent converts the Simulink model into a JSON-compatible Python dictionary. The dictionary keeps essential elements: blocks, types, parameters, and connections. It removes layout noise such as coordinates and styling. This is not a cosmetic compression. It changes the working memory problem.

A model that sees 20,000 tokens of XML is reading a bureaucratic corpse. A model that sees a compact dictionary is reading a graph.

That is why the paper’s mechanism-first reading matters. The workflow is built from four linked moves:

The business-relevant lesson starts here. Many AI automation projects fail because they begin with the model: choose GPT-4o, Claude, Gemini, Qwen, DeepSeek, then ask how to prompt it. SimuAgent begins with the work object. What representation lets the agent see the operational structure? What validator can cheaply reject bad intermediate states? What curriculum teaches the model simple tool skills before larger planning? Only after those choices does model training become meaningful.

Apparently, engineering automation is not improved by throwing a chatbot at a diagram and whispering “be accurate.” Tragic.

The dictionary is not just shorter; it is a different interface to reasoning

The Python dictionary representation does three jobs at once.

First, it compresses the model. XML includes visual layout, metadata, and repeated structural tags. Some of that is necessary for storage, but much of it is noise for reasoning. SimuAgent strips the representation down to blocks, parameters, and connections.

Second, it makes edits local. If the task is to insert a temperature sensor, the agent can modify a Blocks dictionary and a Connections list. That is closer to the actual causal structure of the model than scanning XML lines and writing MATLAB commands from memory.

Third, it enables cheap validation. SimuAgent can run Python-side checks on signal types, parameter ranges, and port wiring before invoking MATLAB or Simulink for higher-fidelity simulation. This matters because agentic workflows are iterative. If every failed step requires a heavy external environment call, exploration becomes expensive. If the model can get quick feedback inside a lightweight testbed, training and debugging become less wasteful.

This is the first major contribution: SimuAgent turns Simulink modeling into a compact, tool-validated plan–execute workflow. The system is still connected to Simulink, but it does not force the LLM to reason directly through Simulink’s heaviest textual form.

The paper’s case studies make the point clearly. GPT-4o can fail by selecting an invalid library path for a temperature sensor or by generating object references that Simulink rejects. SimuAgent, by contrast, uses tool-based block search, retrieves the proper Temperature Sensor information, edits the Python dictionary, validates the intermediate state, and then converts the dictionary into MATLAB commands. The difference is not that one model “knows” physics and the other does not. The difference is that one workflow lets the model search, inspect, modify, and validate against the structure of the task.

That is a small engineering detail with a large strategic implication: for domain-specific automation, the interface between model and artifact may matter more than the model size.

ReGRPO makes reflection a training signal, not a motivational poster

The paper’s second contribution is Reflection-GRPO, or ReGRPO. To understand why it matters, ignore the word “reflection” for a moment. In AI papers, reflection often means the model writes a paragraph about its own failure and then everyone pretends introspection has occurred. Sometimes it helps. Sometimes it is just expensive self-esteem.

Here the mechanism is more specific. Standard Group Relative Policy Optimization samples a group of responses for the same task and uses relative rewards within the group to update the policy, avoiding the need for a separate critic model. That is useful, but Simulink modeling has sparse rewards. A multi-step task may fail only at the end. The scalar reward says “wrong,” but not whether the model chose the wrong block, connected the wrong port, omitted a parameter, or gave up too early.

ReGRPO adds reflection traces generated from failed rollouts. The training group is split into two subgroups. The first subgroup attempts the task. When it fails, the system generates reflection text from the failed reasoning trace and environment feedback, while using safeguards to avoid leaking the reference answer. The second subgroup then receives the original prompt plus the reflection signal and attempts the task again. During optimization, the model can learn from richer feedback than a final binary or scalar reward.

The important subtlety: reflection is adaptive. The paper does not argue that the model should reflect forever. In fact, forcing reflection every turn performs worse. Reflection is used more heavily early in training, then reduced as the model becomes more competent. The goal is not to make inference permanently verbose. The goal is to shape learning when the agent is still bad at interpreting sparse failure signals.

The appendix ablation makes this point stronger. Removing reflection drops the 7B model’s average SimuBench score from 51.89% to 48.84%. Forcing reflection every turn is worse, lowering the average to 46.25%. A fixed reflection probability lands at 49.93%. The practical lesson is nicely unromantic: reflection is useful as a targeted training scaffold, not as an always-on ritual.

This is where the paper connects to broader agent engineering. Many business processes have the same feedback structure: a workflow fails at the end, but the root cause happened five steps earlier. The naive solution is to add more logging. The better solution is to convert failures into structured learning signals that identify which step most likely caused the failure. ReGRPO is one version of that idea for LLM tool use.

The curriculum teaches execution before planning, because chaos is not a syllabus

SimuAgent does not train the model on everything at once. It uses a two-stage curriculum.

Stage 1 focuses on execution. The agent learns low-complexity tasks: creating small systems, editing modules, tuning parameters, and invoking tools. These tasks provide denser feedback and teach the model how to operate inside the environment.

Stage 2 introduces larger systems and more planning. The model is encouraged to decompose tasks, use abstraction, replan when needed, and handle more complex architecture. This is also where the paper introduces abstract–reconstruct data augmentation.

The curriculum is not decorative. In the main results, using only Stage 1 gives 46.55% average accuracy. Using only Stage 2 gives 44.38%. Using both reaches 51.89%. In the appendix, skipping the curriculum drops the default score by 7.51 points, from 51.89% to 44.38%.

That is a strong signal about task sequencing. You do not teach an agent to architect large systems before it knows how to use the screwdriver. Or, in enterprise terms, you do not ask a workflow agent to “own the process end-to-end” before it can reliably complete the basic sub-actions.

The abstract–reconstruct loop adds another mechanism. Given a Simulink model, the agent first generates a structured summary. Then it attempts to reconstruct the model from that summary. This creates self-supervised training pairs from existing models, strengthening the mapping between high-level specifications and low-level implementation.

The effect is modest but meaningful. Removing abstract–reconstruct augmentation lowers average accuracy from 51.89% to 50.43%. This is not the main engine of the system, but it improves generalization. More importantly, it fits the domain: engineering work often moves between architecture descriptions, diagrams, requirements, and executable models. Training the model to travel both directions is exactly the kind of discipline a modeling assistant needs.

The benchmark result is real, but the margin is not the story

SimuBench contains 5,300 tasks across control, mechanical, electrical, fluid, thermal, and electromagnetic domains. Tasks include model creation, model editing, and model-based question answering. The benchmark also includes Simulink files, schematics, and reference Q&A pairs.

The headline comparison is Table 2. Here is the compressed reading:

The full SimuAgent pipeline is best overall. But the margin over GPT-4o XML is narrow: 51.89% versus 50.45%. A lazy reading would make this a “7B beats GPT-4o” story. That would be technically true in this table and editorially misleading.

The better interpretation is category-specific.

SimuAgent is not clearly superior everywhere. GPT-4o XML remains slightly better on small-system modification and small-system QA. SimuAgent’s advantage is more visible in large-system QA, large-system modification, and large-system creation. That pattern fits the mechanism: when topology, representation, tool use, and planning matter more, the specialized workflow helps more.

The baseline comparison is therefore main evidence, but not a general frontier-model ranking. It supports the claim that a smaller domain-trained agent with a better representation and tool loop can compete with a larger general model on a structured engineering benchmark. It does not prove that SimuAgent is production-ready. It does not prove that Qwen2.5-7B is generally better than GPT-4o. It proves something narrower and more useful: workflow design can substitute for some model scale when the task has a stable structure.

The ablations tell us which parts are load-bearing

The appendix is especially useful because it separates load-bearing mechanisms from nice-to-have additions. The paper reports a hyperparameter and design ablation on SimuBench, using accuracy as the metric.

Two results deserve attention.

First, the correctness-only reward performs badly. That matters because many enterprise AI evaluations still score only final answer correctness. For tool agents, that is too blunt. In SimuAgent, rewards also consider structural and functional similarity, completeness, executability, and successful tool usage. This is not evaluation bureaucracy. It is how the model learns the shape of acceptable work.

Second, the 14B model achieves the highest overall score at 52.78%, only modestly above the 7B default at 51.89%. This does not mean scale is irrelevant: the 3B model drops sharply to 38.69%. But it suggests that once the model has enough baseline capacity, representation and training design can do serious work. The intelligent move is not “always choose the biggest model.” The intelligent move is to find the point where domain structure, validation, and training create more marginal value than another model-size jump.

Cross-platform transfer is promising, but still early

The paper also tests whether the learned approach transfers beyond Simulink. ReGRPO is compared with GRPO across general reasoning, math, code generation, and cross-platform modeling settings. The gains are modest but consistent on MMLU, BBH, GSM8K, and MATH. They are larger in code tasks: HumanEval rises from 58.45% to 61.89%, and MBPP from 76.38% to 79.83%.

For Modelica and PSCAD, SimuAgent is trained only on SimuBench and then tested for zero-shot transfer. ReGRPO reaches 33.84% on Modelica and 33.04% on PSCAD, compared with GRPO at 31.96% and 31.21%. With small domain-specific fine-tuning sets — 607 Modelica examples and 730 PSCAD examples — performance rises to 44.54% and 43.49%.

This should be read as an exploratory extension, not as a finished cross-platform automation product. The result suggests that graph-like modeling principles can transfer when the target environment has comparable structure and when the developer implements the right APIs, component dictionaries, and tool libraries. That is encouraging. It is not plug-and-play.

The business implication is still important. If an engineering organization can standardize an intermediate representation across modeling tools, the AI layer may become less tied to one vendor environment. A common graph/dictionary abstraction could support assistants for Simulink today, Modelica or PSCAD tomorrow, and internal proprietary modeling systems later. But each environment still requires integration work. There is no free lunch, only a better cafeteria layout.

Failure analysis shows where autonomy breaks

The paper examines 1,400 SimuBench test tasks and analyzes 673 first-attempt failures. The failure distribution is useful because it tells us what an engineering assistant still cannot reliably handle.

This failure analysis is where the article should become less shiny and more useful. The largest failure category is not “bad prose.” It is topology. The second largest is block implementation. Together, they account for more than 60% of first-attempt failures. These are exactly the errors that can make an executable model invalid or physically meaningless.

For business adoption, this implies that SimuAgent-like systems should begin as assisted modeling infrastructure, not autonomous engineering authorities. They are good candidates for drafting model changes, searching block libraries, generating candidate topology, documenting existing systems, and running validation loops. They are not yet candidates for unreviewed changes in safety-critical models.

This does not weaken the paper. It makes the deployment path clearer.

The near-term value is not “replace the engineer.” The near-term value is cheaper iteration around annoying, structured tasks: find the right block, propose the change, check the wiring, generate the documentation, surface likely errors, and give the engineer a better starting point. That is still valuable. Many enterprise AI products would be healthier if they aimed for that before announcing the retirement of professional judgment. A radical thought, apparently.

What this directly shows, what Cognaptus infers, and what remains uncertain

The paper directly shows that a Simulink-specific LLM agent can improve performance on a new benchmark when it combines compact representation, tool validation, staged training, abstract–reconstruct augmentation, and ReGRPO. It also shows that adaptive reflection is better than no reflection and better than always-on reflection. It shows that curriculum design matters, and that reward shaping beyond final correctness is important for tool-based modeling tasks.

Cognaptus infers a broader business pattern: high-value AI automation in technical domains will often depend less on conversational polish and more on the engineering of intermediate representations. If the task artifact is a contract, a CAD file, a workflow log, a financial model, a legal clause graph, or a Simulink diagram, the key question is not merely “Which LLM?” It is “What structure should the LLM operate on, and what validator gives fast feedback?”

That inference is plausible, but bounded. SimuBench is a benchmark, not a deployed industrial certification environment. The reported first-attempt accuracy is still far below what safety-critical autonomy would require. The experiments use substantial training hardware: the appendix reports a single node with eight H100 GPUs. So the phrase “on-premise” should be read carefully. Deployment with a smaller model may be feasible; reproducing the full training recipe is not automatically cheap for every engineering team.

There is also a data question. SimuBench is public and useful, but real enterprise models contain proprietary conventions, messy subsystem histories, inconsistent naming, undocumented patches, and compliance constraints. A production assistant would need access control, audit trails, versioning, human approval, regression testing, and integration with existing model-management practices. The paper points toward that world; it does not finish the procurement checklist.

The business value is controlled assistance, not instant automation

For engineering firms using Simulink-like model-based design, the practical pathway is straightforward:

1. Convert existing models into compact intermediate representations.
2. Build validators that catch cheap structural errors early.
3. Let agents perform bounded tasks: search, modify, document, test, and explain.
4. Train or fine-tune on the organization’s common modeling patterns.
5. Keep engineers in the approval loop, especially for topology changes and safety-relevant parameters.

The ROI case is not only labor substitution. It is reduced rework, faster onboarding, better documentation, fewer low-level modeling mistakes, and less dependence on external cloud models for proprietary designs. If the assistant can run on-premise after training or fine-tuning, privacy-sensitive engineering teams may find the architecture more acceptable than sending full model artifacts to a general cloud LLM.

But the system must be sold internally as a modeling co-pilot with validation, not as an autonomous designer. That distinction affects trust. Engineers are more likely to use an assistant that says, “Here is the proposed block insertion, here are the changed connections, here are the validator warnings, and here is why I selected this library path,” than one that says, “I have solved your fuel-cell cooling system.” The former is useful. The latter sounds like a lawsuit warming up.

From tokens to topology

SimuAgent’s contribution is not that it discovered LLMs can write Simulink commands. We already knew large models can produce plausible scripts. The contribution is that it reorganizes the problem around the structure of graphical engineering work.

Representation compresses the model into something the LLM can reason over. Validation turns the environment into a feedback source. Curriculum teaches execution before planning. Abstract–reconstruct augmentation teaches movement between architecture and implementation. ReGRPO turns failure into training signal without making reflection an inference-time tax forever. SimuBench gives the field a benchmark large enough to argue over.

The result is still imperfect. First-attempt accuracy remains limited. Failures concentrate in exactly the places engineers care about: topology, block selection, parameters, completion judgment, and context limits. The training setup is not trivial. Cross-platform transfer is promising, not solved.

Still, the paper gives a useful blueprint for domain AI. Do not ask a language model to stare at the wrong representation and hope intelligence compensates. Give it the topology. Give it tools. Give it validators. Teach it in stages. Reward the shape of the work, not just the final answer.

That is how an LLM begins to act less like a fluent intern reading XML in the dark, and more like a modeling assistant that understands where the wires are supposed to go.

Cognaptus: Automate the Present, Incubate the Future.