The story of XCON, the first commercially successful expert system — and what its triumph and its company’s collapse can teach every builder about the difference between solving a problem and leading an organization.
A company drowning in its own success
In 1978, Digital Equipment Corporation had a problem that was, in a strange way, the best kind of problem to have. They were selling too many computers and couldn’t keep up.
DEC — the second-largest computer company in the world, behind only IBM — built the VAX, a family of powerful minicomputers that businesses could customize to their specific needs. The selling point was the customization: each VAX system was configured from thousands of individual components — processors, memory modules, disk drives, controllers, cables, cabinets, power supplies — assembled into a unique combination tailored to what the customer ordered.
The problem was that configuring these systems required deep technical expertise, and even the experts got it wrong. A lot. If a customer ordered a disk drive, someone had to make sure the order also included the right disk controller, the right cables, the right power supply for the additional load, and the right cabinet space to house it all. A single VAX system could involve thousands of separate components, and the relationships between them were complex, interdependent, and poorly documented. Human configurators were getting orders wrong somewhere between 30 and 40 percent of the time. Wrong components shipped. Incompatible parts arrived at the customer site. Systems that should have worked didn’t. The manual configuration process was taking ten to fifteen weeks per order. DEC was hemorrhaging money on returns, rework, and angry customers — and the more systems they sold, the worse the problem got.
Into this mess walked a researcher from Carnegie Mellon University named John McDermott.
The man with 2,500 rules
McDermott was a specialist in artificial intelligence, specifically in a branch of AI called expert systems — software designed to capture the decision-making knowledge of human experts and apply it systematically. The idea was simple in theory: interview the people who know how to configure a VAX correctly, translate their knowledge into a set of if-then rules, and let the computer apply those rules to every incoming order, consistently, without fatigue, without mistakes, and without taking fifteen weeks to do it.
The practice was anything but simple. McDermott spent months interviewing DEC’s technical configurators, extracting their knowledge rule by rule. What he found was illuminating and a little alarming: the experts didn’t always agree with each other. Different configurators had different approaches to the same problem, different rules of thumb, different preferences. Part of building the system was not just capturing expertise but reconciling it — finding the underlying logic beneath the disagreements and encoding a single, consistent decision process that incorporated the best of what everyone knew.
The system McDermott built was called R1, later renamed XCON — short for eXpert CONfigurer. It was written in a rule-based programming language called OPS5, and when it went into production use at DEC’s plant in Salem, New Hampshire in 1980, it contained roughly 2,500 if-then rules. Each rule encoded a small piece of configuration logic: if the customer ordered this drive, then include this controller. If this controller is present and this cabinet is full, then add a second cabinet. If the power draw exceeds this threshold, then upgrade the power supply.
Twenty-five hundred rules, each one a tiny piece of a human expert’s hard-won knowledge, running in sequence against every incoming order, catching the errors that human configurators missed thirty to forty percent of the time.
The results were not subtle.
$25 million a year and 95% accuracy
By 1986, XCON had processed over 80,000 orders. Its accuracy rate was between 95 and 98 percent — a dramatic improvement over the 60 to 70 percent accuracy of the manual process. Configuration time dropped from weeks to minutes. The system was saving DEC an estimated $25 million per year in avoided errors, reduced rework, and faster order fulfillment.
XCON became the most famous success story in the history of expert systems. It proved, in a way that no academic demonstration had, that AI could work in a real industrial setting, at scale, on a problem that mattered. It wasn’t a research prototype. It wasn’t a toy. It was a production system processing every VAX order that came through the door, day after day, and it was doing the job better than the humans it was designed to assist.
The AI community celebrated. Papers were published. Conferences were held. Other companies rushed to build their own expert systems, hoping to replicate DEC’s success. The mid-1980s saw what historians of AI now call the “expert systems boom” — a wave of investment and enthusiasm driven in large part by XCON’s demonstrated commercial value. For a few years, it looked like expert systems were going to be the future of artificial intelligence, and XCON was the proof.
Meanwhile, the company that built XCON was starting to die.
The company that couldn’t see what was coming
Here is the part of the story that almost nobody tells when they talk about XCON, and it is the part that matters most for anyone who wants to build things that last.
Digital Equipment Corporation in 1988 was a colossus. Eleven and a half billion dollars in annual revenue. A hundred and twenty-five thousand employees. Operations in more than eighty countries. The number two computer company on Earth, behind only IBM. Fortune magazine called it one of the most admired companies in America.
And its founder, Ken Olsen — a brilliant engineer, a genuine visionary in the minicomputer era — was about to make a series of decisions that would destroy it.
The first and most famous was his stance on personal computers. In 1977, Olsen said publicly that there was “no reason for any individual to have a computer in his home.” When DEC’s own engineers demonstrated two prototype microcomputers in 1974 — before the Altair, before the Apple I — Olsen chose not to proceed. When another personal computer proposal came in 1977, he rejected that too. The market that would eventually eat the minicomputer alive was growing right in front of him, and he looked at it and saw nothing worth pursuing.
The second decision was to go upmarket instead of down. Rather than competing in the emerging PC space, DEC decided in the mid-1980s to challenge IBM in the high-end mainframe market. The result was the VAX 9000, a massive engineering effort that consumed an estimated $3 billion in development capital and landed in a market that didn’t want it. The VAX 9000 was a commercial failure. Three billion dollars, gone.
The third was a pattern of organizational dysfunction that Edgar Schein, the MIT organizational psychologist who studied DEC extensively, documented in his book DEC Is Dead, Long Live DEC. The company’s engineering-driven culture, which had been its greatest strength in the minicomputer era, became its greatest liability as the market shifted. Engineers were empowered to pursue their own projects with minimal coordination. Product lines multiplied and competed with each other internally. The company couldn’t execute a coherent strategy because it couldn’t agree on what the strategy should be.
By the early 1990s, DEC’s minicomputer sales were collapsing. The first layoffs came. Then more layoffs. Then more. The company that had employed 125,000 people began hemorrhaging talent and revenue simultaneously.
And here is the detail that should make every technologist in the world sit up and pay attention: during this entire period of decline, XCON was still working. The AI was still processing orders. The AI was still saving millions of dollars a year. The AI was still doing its job at 95 to 98 percent accuracy, day after day, exactly as it had been designed to do.
XCON could not save DEC, because XCON’s job was to configure VAX systems correctly, and the problem that was killing DEC had nothing to do with VAX configuration. The problem was leadership. The problem was strategy. The problem was a founder who couldn’t see that the market had moved, a management structure that couldn’t coordinate a response, and a $3 billion bet on the wrong product at the wrong time.
The AI solved the problem it was pointed at. The company died of the problems nobody pointed anything at.
The AltaVista footnote
I want to add one more detail, because it is so painful it borders on poetry.
In 1995, in the middle of its decline, DEC launched an internet search engine called AltaVista. It was, for a brief period, the most popular search engine in the world — dominant, widely loved, technically excellent. If you used the internet in the late 1990s, you probably used AltaVista.
According to multiple sources, in 1997, two Stanford PhD students named Larry Page and Sergey Brin approached DEC with their PageRank system, hoping to be acquired. They wanted AltaVista to adopt their technology — or, failing that, to be brought into the company. DEC, deep in its death spiral, passed.
Page and Brin went on to found Google.
DEC was sold to Compaq in 1998 for $9.6 billion — a fraction of what the company had been worth a decade earlier. AltaVista was eventually shut down. Google became one of the most valuable companies in the history of civilization.
The company that built the first commercially successful AI system also had the first dominant search engine and was offered the technology that would become Google. It lost all three — not because the technology failed, but because the leadership couldn’t see what they had.
What this story is actually about
I did not tell you this story so you could feel sorry for DEC. DEC’s collapse is forty years old and the company is gone. I told you this story because it contains, compressed into a single corporate biography, the most important lesson a builder can learn — and it is a lesson that is not about technology at all.
The lesson is this: a brilliant technical solution, perfectly executed, applied to the wrong level of the problem, will not save you.
XCON was a perfect solution to a real problem. Configuration errors were costing DEC millions. XCON fixed that. XCON did exactly what it was built to do, and it did it beautifully, for years, without fail. If the only thing wrong with DEC had been configuration errors, XCON would have saved the company.
But the things wrong with DEC were not technical. They were strategic. They were organizational. They were about vision, leadership, market awareness, and the willingness to cannibalize your own success before your competitors do it for you. No expert system in the world can solve those problems, because those problems live in the minds and decisions of the people running the organization, not in the systems the organization uses.
This is the mistake technologists make over and over again, in every era, with every new technology. They build something brilliant. It works. It solves a real problem. And then they assume that solving a real problem is the same thing as building a successful organization. It isn’t. Solving a real problem is necessary. It is not sufficient. The gap between “our technology works” and “our company thrives” is filled with strategy, leadership, market timing, organizational design, and a hundred other things that have nothing to do with how elegant your code is or how many rules are in your expert system.
What I want you to take with you
If you are reading this as a student — someone learning to build things, someone at the beginning of a career in technology or game design or immersive environments or any of the other fields this academy touches — I want you to hold two things in your mind at once.
The first is respect for the craft. John McDermott built something remarkable. Twenty-five hundred rules, extracted painstakingly from human experts who didn’t always agree, assembled into a system that processed eighty thousand orders at near-perfect accuracy and saved a company $25 million a year. That is beautiful work. That is the kind of work you should aspire to do — deep, careful, expert, and genuinely useful. The craft matters. The technology matters. Do not let the rest of this story make you cynical about the value of building things well.
The second is a clear-eyed understanding that the craft is not the whole game. DEC had the best expert system in the world. DEC had the best search engine in the world. DEC had access to the technology that would become Google. And DEC is gone, because the people running the company could not see the market changing around them, could not coordinate a strategic response, and could not make the painful decisions that survival required.
The builder who only knows how to build is McDermott. McDermott did his job perfectly. The company died anyway, and there was nothing McDermott could have done about it from where he sat.
The builder who knows how to build and how to lead — who understands technology and strategy, who can write the code and read the market, who can solve the technical problem and see the organizational one — is the builder who survives. That is the builder this academy is training you to be. Not just a technician. Not just an engineer. A producer. A leader. Someone who can look at the whole board, not just the piece in front of them.
XCON was a masterpiece. The company it lived inside was a cautionary tale. Hold both of those truths at the same time, and you will be better prepared than most of the people you will ever compete with.
Build brilliantly. Lead wisely. And when somebody offers you the next Google, for the love of everything, don’t pass.
Sources and further reading
On XCON (R1) — development, architecture, and impact: McDermott, J. (1982), “R1: A Rule-Based Configurer of Computer Systems,” Artificial Intelligence, 19(1), 39-88. Also: Bachant, J., and McDermott, J. (1984), “R1 Revisited: Four Years in the Trenches,” AI Magazine, 5(3). The ACM case study: “Expert Systems for Configuration at Digital: XCON and Beyond,” Communications of the ACM, 1989. The system processed 80,000+ orders by 1986 with 95-98% accuracy and saved DEC an estimated $25 million annually.
On Digital Equipment Corporation — rise and fall: Schein, E. H. (2003), DEC Is Dead, Long Live DEC: The Lasting Legacy of Digital Equipment Corporation, Berrett-Koehler Publishers — the definitive organizational analysis by the MIT psychologist who studied DEC for decades. For the corporate timeline: “Digital Equipment Corporation,” Wikipedia, which compiles the $11.5B peak revenue (1988), 125,000 employees, the Ken Olsen “no reason for any individual to have a computer in his home” quote (1977), the rejected PC prototypes (1974, 1977), and the Compaq acquisition ($9.6B, 1998).
On the VAX 9000 failure: Multiple sources estimate the development cost at approximately $3 billion. The system was a commercial failure in the high-end mainframe market that DEC was attempting to enter in competition with IBM.
On AltaVista and the Google connection: AltaVista launched in 1995 as DEC’s internet search engine and was briefly the most popular search engine in the world. The account of Larry Page and Sergey Brin approaching DEC in 1997 appears in multiple sources covering DEC’s decline, though the details vary. What is documented is that DEC passed on the opportunity, Page and Brin founded Google, and AltaVista was eventually discontinued.
On the expert systems boom of the 1980s: The commercial success of XCON was a major catalyst for the expert systems investment wave of the mid-1980s. For context on the broader AI timeline: Russell, S. J., and Norvig, P. (2020), Artificial Intelligence: A Modern Approach (4th ed.), Pearson — Chapter 1 provides a historical overview including the expert systems era and the subsequent AI winter.
Note to readers: verify the primary sources yourself before quoting. The DEC story in particular has been told many ways by many people, and the details — especially around the AltaVista/Google connection — vary across accounts. The citations above are entry points into a much larger and contested corporate history.