Denver International Airport opened on 28 February 1995, sixteen months late, with almost all baggage handling done manually by tugs and carts. The reason was the automated system it was supposed to open with: nearly 20 miles of track, roughly 4,000 robotic “Telecar” carts, and a hundred-plus 486 machines running custom control software on OS/2. It never achieved full operational capability and was finally shut down in 2005.
J.B. Crawford reconstructs how it got there, and separates the documented causes from the myths — including the persistent story that it was an AI ran amok.
Why the system was so big:
- Stapleton was landlocked — runways too close for simultaneous instrument approaches, no room to expand, no gates for Southwest
- The new site split operations across four buildings with underground movement, so the terminals sat 0.5, 1 and 1.5 km from ticketing
- United would only operate there if aircraft could be turned around in under 35 minutes, meaning transfer bags moved gate-to-gate in under ten minutes
- Boosters promised bags would reach the claim before the passenger, which required automation at a scale nobody had built or was planning to build
The failures that compounded:
- Airlines became the dominant design stakeholder after much of the design was finished; unleased terminals got a minimal spec, and every airline that later signed on demanded changes into already-built structures
- BAE’s contract assumed frozen requirements, priority site access and design authority. None of the three held. The City’s change orders went back and forth — a ski retrieval belt was lengthened, shortened, and lengthened again
- The demo system that won over skeptics exercised the mechanical design but none of the routing logic, which became the project’s worst problem
- Access was contested across four buildings and four construction managers; the control software, written back in Texas, reportedly hadn’t started when the countdown to opening went under a year
- Cart dispatching was hard enough that BAE’s main package was the “empty cart management system.” Munich’s comparable system needed nearly two years of tuning; Denver had less time than that
- No simulation, and almost no testing before commissioning. In April 1994 the City invited the press to a full-scale test without telling BAE; reporters watched bags flung onto concrete, contents piling in tunnel corners and a full-speed collision between two carts
The consequences are the transferable part:
- Behind the visible damage: empty carts sent between terminals, forgotten, sent back; no airline-schedule awareness, so dispatch was purely reactive; bags losing cart association; barcode readers failing faster than the re-labelling staff could keep up
- Logplan’s 24/7 test track performed so badly they abandoned the test plan and recommended a second, conventional baggage system — about $50M, against two years of delay
- “No plan B” wasn’t a late oversight. It was the premise: “The automated system was just supposed to work.”
The myth is worth the read on its own. The famous version — the software prioritised delivering bags, so it dumped them anywhere — isn’t what happened. Bags piled up because mechanical failures meant they never reached the decision points, and the pile locations followed the track geometry, squeezed into tunnels with hairpin turns. A complex failure retold as agentic intent.
Crawford is fair about the counterfactual: the design would still rank among the world’s largest today, and Dubai’s state-of-the-art network still misses DIA’s original delivery targets. The idea wasn’t absurd. The schedule and the change control were.