The tiny clock error that grew for 100 hours

On 25 February 1991, during the Gulf War, an Iraqi Scud missile hit a US Army barracks in Dhahran, Saudi Arabia, and killed 28 American soldiers. A Patriot missile battery was protecting the area. It did not even try to intercept the Scud.

A US government audit by the General Accounting Office (GAO) found the cause. The battery's computer counted time in tenths of a second, and converting that count into seconds lost a tiny amount of precision every time. The longer the system ran, the bigger the error got. After the battery's roughly 100 hours of running, the clock was off by about a third of a second. For a missile that fast, that was enough for the radar to look in the wrong place.

The Patriot was designed to defend against aircraft in Europe and to move often, running only a few hours in one place. On 11 February the Army received Israeli data showing that the aim had shifted noticeably after 8 hours of running. A software fix was released on 16 February, and on 21 February users were warned that very long run times could cause problems. The warning did not say how long was too long.

Restarting the system, which took a minute or two, reset the clock and removed the error. The battery at Dhahran had not been restarted. The fixed software reached Dhahran on 26 February, the day after the attack.

No single calculation was badly wrong. Each one was off by a sliver too small to notice. But the error added up with every tick, and the system was being used far longer than its designers had planned for. Nothing on the screen showed the drift. The battery looked healthy right up to the moment it missed.

AI tools can drift quietly in a similar way. The mechanism is different, but the shape is the same. In a very long chat, early instructions slip out of what the model can see, and small mistakes get built on. An AI agent that runs for hours can carry an early wrong assumption through every later step. Nothing flashes red. The fix is often as simple as the Patriot's: restart with a clean, checked summary.

The idea behind this caseLesson: The context window: AI's short-term memory →

1. 1For long projects, start a fresh chat now and then, pasting in a short summary you have checked yourself.
2. 2Re-check key facts and numbers at the end of a long AI session, not only at the start.
3. 3Break long agent jobs into stages, and check the output of each stage before the next one begins.
4. 4When a tool's limits are known, say them in plain numbers ("restart every 8 hours"), not vague words like "very long".
5. 5Treat an early warning from one team as a test of your whole system, not as an unusual case.