The human failure appears to be mistake number 3 or 4.

1. Automated system fails 2. Decision is made to run the system manually 3. Iyro train fails to move on when instructed (Comms failure?, train failure?) 4. Controller uses imprecise language when instructing following train.

To say this is totally down to 4 is to scapegoat the last link in the chain.

Honestly, to blame the controller after the automated system has failed is pretty low. The system does not run this way normally for good reasons, and whilst the controller maybe trained to handle the situation they won't be well practised at it.

The primary reason is computer failure followed by the decision to run the system manually.

When computers fail here in the Netherlands, trains are just stopped until they can be fixed.

In some cases, trains can be ordered to drive "at sight" -- slow enough (walking speed, basically) to stop if there's something visible on the tracks that shouldn't be there (train, car, person, cow, whatever)

Not just when computers fail. When union negotiations fail, when it's too cold, when it's too hot, when it snows, when nature drops a leaf on the railroad tracks, or whenever they come up with a new excuse.

You haven't used trains elsewhere if you think Dutch ones are bad.

Try a few weeks of German trains. Sometimes no trains leave on time for weeks.

Those inconveniences prevent tragedies like this one.

All trains stopped. Then a train was cleared to continue full speed while next one was waiting on a red light.

Proper training focuses specifically on those exceptional situations (like it does for airplane pilots), with strong emphasis on always falling back on safe procedures. Even so, you can't cover 100% of possibilities.

The key point is, it's not language magic. It's library magic. You can write your own IO implementation if you want it to work a different way.

How are you serving them? This is most often caused by an incorrect template. (the thing that tells the inference engine how to parse the think/tool parts of the answer)

For vllm the official recipe [1] (for another model in the same family) is this:

  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser lfm2

[1] - https://recipes.vllm.ai/LiquidAI/LFM2.5-8B-A1B

...or...just hear me out now...we could limit it in the harness.

Don't give it shell access, just predefined tools.

What if it puts malicious code into test file and you allow `npm run test `?

Disclaimer - on the Docker DevRel team

One of the demos I run is how easy it is to circumvent the harness limits. For example, I can configure a harness not to access file `secrets.txt`. But, then I can immediately have it create a Python file that can read any file and have it read `secrets.txt`.

At the end of the day, "please" isn't security. You want to know that the agent can only do and access the things it should access.