A night in the workshop
What happens when two systems keep triggering each other
- ExperimentExperimentPublication typeA publication with a simulation: replay what happened yourself. Every number is labelled measured or reconstructed.All terms
- WorkshopWorkshopFieldExperiments and lessons from our own work, including what went wrong.All terms
- ±3 min play
- Draft, version 0.3
You are here
Step 05, A night in the workshop
Try it
Step through the night and apply the brake whenever you choose.
The sequence is reconstructed. Only the final counts were measured.
- Evening The Writer asks the Scheduler for a workspace. The Scheduler says yes. Why The Scheduler follows a fixed rule: when someone asks for room, say yes. Its rule cannot see whether the machine actually has room.
- Evening The workspace fails because the machine is full. The Writer immediately asks again. The Scheduler says yes again. Why The machine was already full of other work. The Scheduler's rule did not account for that.
- Evening Another failure, another request. The Scheduler displaces other work to make room. The loop has begun. Why The Writer has a fixed rule: after failure, immediately retry. The Scheduler makes room. Together they form a loop.
- Evening More and more work is displaced. Nobody notices. Why No rule counts how often something fails. So nothing raises an alarm.
- Night The machine gets hot. The Monitor sees the heat, but has no rule for the number of failed tasks. Why The Monitor watches heat and memory. It has no counter for failed tasks.
- Night The machine can do nothing else. Other work now fails too. Why The loop takes all available room. Other work can no longer get in.
- Night The Scheduler still says yes. A fixed rule never hesitates. Why A language model might have hesitated. A fixed rule does exactly what it says, every time.
- Early morning Nobody is awake. Only a person can stop this. Why There is no emergency brake that intervenes automatically. A person is needed.
- Morning A person arrives, sees the count and stops the Scheduler. The loop stops. Why The rule since then: one retry, then a person. Measured 20,478 failed tasks and 1,533 times other work was displaced.
With the lesson
- Evening The Writer asks the Scheduler for a workspace. The Scheduler says yes. Why The Scheduler's rule has not changed.
- Evening The workspace fails. The Writer gets one retry. Why One new attempt after a failure.
- Evening Another failure. The system stops and asks a person to take a look. Why If the retry also fails, the system stops and a person takes a look. The loop does not begin.
Reconstructed: this is how the rule we introduced after that night works.
With the lesson: 2 failed tasks (reconstructed). That night: 20,478 (measured).
How does a loop arise between two automatic systems?
In our workshopWorkshopTermWhere our AI colleagues and fixed rules work together, day and night. We share what we learn there in the Lab.All terms, two fixed rulesFixed ruleTermOrdinary code that always does exactly the same thing. Predictable and testable, but it never hesitates.Read more: step 01, Fixed rules, thinking colleaguesAll terms kept triggering each other. There was no limit on the number of retries. The monitoring saw heat, but did not count failed tasks. Our lesson: one retryRetryTermOne new attempt after a failure. If it also fails, the system stops and a person takes a look.Read more: step 08, Stay in control of your AIAll terms, then a person.
Summary
- What we did: we replay a real night in our workshop from September 2026.
- What it means: a fixed rule does not hesitate. So: one retry, then a person.
- The main limitation: the sequence through the night is simulated. Only the final figures were measured.
Why this went wrong
The biggest errors often come from the fixed rules between the intelligent components. This night shows how. Neither system hesitated. Both did exactly what they were supposed to do, and that was precisely why things went wrong.
Each role follows a fixed rule
In this simulation, the systems are called the Writerthe WriterNameA role in the night experiment. It turns conversations into reports. When a task fails, it immediately asks again.All terms and the Schedulerthe SchedulerNameA role in the night experiment. It allocates computing power. Its fixed rule: when someone asks for room, say yes.All terms. The Writer turns conversations into reports. The Scheduler distributes computing capacity. The Monitorthe MonitorNameA role in the night experiment. It monitors heat, memory and silence. It did not count failed tasks.All terms monitors the machines. Online, you see them on a stage, each alongside its rule. At each step, a note travels from one role to another: a task being passed along.
The monitoring saw heat, not counts
The Monitor saw the machine getting warm. But it had no rule for the number of failed tasks. That allowed the loopLoopTermTwo rules that keep triggering each other, without an end. That is what happened in the night experiment.All terms to continue all night.
One retry, then a person
- One retry. An automatic attempt gets one more chance. If it fails again, a person takes a look.
- The system is switched off. The Scheduler remains out of service until it is rebuilt with this brake.
- The lesson is in our rules. It became law 3 of our working policy Stay in controlControlTermA person decides what AI does and authorises irreversible actions. This is the core of our working policy.Read more: step 08, Stay in control of your AIAll terms of your AI.
Online, you can turn on the lesson and replay the night.
How we did it
The final figures come from our own log for that night. The sequence between them is a reconstruction based on what we found afterwards. Intermediate figures are rounded and marked as approximate. In the PDF, the steps appear in a table.
Limitations
- A simulated sequence. The steps through the night are a reconstruction. Only the final figures were measured.
- One night. This is one event in one small workshop, not representative of SMEsSMEsTermSmall and medium-sized enterprises: businesses with fewer than 250 people. ITARR builds working AI solutions for them.All terms.
- No baseline. At the time, we were not yet counting how many tasks failed on an ordinary night.
- No public dataset. This publication has no public dataset with which readers can independently recalculate the final figures.
- The names are roles. The Writer, the Scheduler and the Monitor are roles in this simulation.
What this means
Questions to considerTry it
What does this mean for you?
Turn a card over for our tip.
Where in your organisation do two systems trigger each other without anyone watching?
Tip: Look for automatic repetition: if it fails, try again. Allow each repetition one retry.
Does your monitoring count events, or only detect faults?
Tip: Also count how often something fails, rather than just whether a machine is hot or full.
Who can pull an emergency brake at night, and how do they know it is needed?
Tip: Agree who receives an alert and at what threshold. After that, a person takes a look.
Closing notes
With thanks to the people and AI colleagues at ITARR.
Also read: Fixed rules, thinking colleagues, the working policy Stay in control of your AI (law 3), and How does an AI colleague catch its own mistakes?.
How to cite this: ITARR Lab (2026). A night in the workshop. Version 0.3, as of 18 October 2026. itarr.eu/lab/een-nacht-in-de-werkplaats. CC BY 4.0.
Sources: our own log of a night in September 2026 (not public); the film of the night (as of 17 October 2026). The film depicts the incident; it is not an independent measurement of the final figures.
Change log: 22 October 2026, version 0.3: the core question, source links and limits of the evidence made clearer. The measurements and their reference date have not changed.
Licence: CC BY 4.0. Use, adapt and share it. Attribute ITARR Lab, link to the licence and indicate any changes.