The History of Expert Systems

By Victor Hoang · Updated Oct 22, 2026

Picture a chemist in the mid-1960s. The printout from a mass spectrometer shows fragments of a molecule nobody has identified. The reasoning that turns those peaks into a structure lives in a few specialists' heads. No textbook writes it down as steps.

Expert systems are programs that capture a specialist's rules and apply them to new cases. They began in 1965 at Stanford with the DENDRAL project of Edward Feigenbaum, Joshua Lederberg and Bruce Buchanan. They reached business in 1980, when Digital Equipment Corporation put John McDermott's R1 program to work configuring computer orders. They stalled in the late 1980s when the rules became too costly to keep current. The throughline: the knowledge was always the hard part. Getting it out of an expert's head and keeping it right was the work nobody budgeted for.

Getting that reasoning into a program, and then into hospitals, factories and sales desks, is the story below. It is also an older story than computers, which is where it starts. For the wider field around it, see The History of AI and the AI timeline.

Timeline at a Glance

Rules Before Machines (c. 1600 BCE-1964)

A papyrus writes expert judgment as if-then steps

Imagine a scroll about 15 feet long, bought in Egypt in 1862 by an American antiquities dealer named Edwin Smith, later cut into 17 columns. According to the National Library of Medicine, it was written in hieratic script around the 17th century BCE, probably from material about a thousand years older. It holds 48 cases of wounds and trauma, and each follows a set formula: a description of the injury, a diagnosis, a prognosis and a treatment, followed by explanatory notes. The NLM curator Michael North notes the text mostly leaves the supernatural out of its explanations and contains only one incantation.

Stanford's Nils Nilsson, in his history of AI, quotes the Breasted translation of Case Thirty to show how close this is to the rule form AI researchers later used. The case begins "If thou examinest a man having a sprain in a vertebra of his neck," goes on to a prescribed diagnosis ("an ailment which I will treat"), and ends with a treatment, per Nilsson's Quest for Artificial Intelligence. He points out that IF-THEN reasoning in medicine has a long history, and quotes the neurosurgeon Robert H. Wilkins calling this papyrus one of the oldest known medical papyri.

Be clear about what this is. The papyrus is a precursor, not the concept. Nobody called it an expert system, nothing executed it, and its rules were meant for a human reader. What it shows is that the central move is old: take what a skilled practitioner knows, write it as conditions and conclusions, and hand it to someone less experienced. What changed in the 20th century was the idea of letting a machine apply the rules itself.

The pieces for that arrived in the 1950s and 1960s. Artificial intelligence took shape as a field after the 1956 Dartmouth workshop, and Allen Newell was developing the use of production rules, the "if condition, then action" form, as a model of human thinking. Buchanan and Shortliffe's account notes that conversations between Newell and Feigenbaum at Stanford in the 1960s led Feigenbaum to advocate production rules for encoding domain knowledge, per Chapter 1 of Rule-Based Expert Systems. Early chat programs like those in the story of the first AI chatbots matched patterns without any expertise behind them. The next step was to add a real specialist's knowledge.

For teams today: the oldest lesson is the simplest. Writing down how your best person decides, as conditions and outcomes, has been worth doing for 3,600 years. Start there before you buy anything.

The Stanford Years (1965-1979)

Chemistry and medicine prove knowledge beats clever search

In the mid-1960s, the Stanford Mass Spectrometry Laboratory had instruments that bombarded a small sample with high-energy electrons and recorded the fragments, and chemists had to work backward from those fragments to a molecular structure. In 1965, Feigenbaum, Lederberg and Buchanan began DENDRAL to do part of that job. Feigenbaum later described their dual motives: to study how scientists form hypotheses, and to test it in a domain with real experts and real data, as he wrote in The Art of Artificial Intelligence, presented at the 1977 IJCAI conference.

DENDRAL's lesson went against the mood of the time. Buchanan and Shortliffe's book calls it the first AI program to emphasize the power of specialized knowledge over generalized problem-solving methods. Feigenbaum put the conclusion bluntly: agents should be "knowledge-rich, even if methods-poor." He recalled that in 1967 the canonical question about DENDRAL was, "It sounds like good chemistry, but what does it have to do with AI?" By 1977, he wrote, the field had shifted.

The first problem DENDRAL ran into was maintenance. In the earliest version, facts lived inside code: a function named WEIGHT returned 12 for carbon, and every new element meant editing the function. Buchanan and Shortliffe explain in their chapter on knowledge engineering that the team moved facts into data structures, separating domain knowledge from the code that used it. Feigenbaum adds that around 1967 the team adopted rule-based representation to head off the program's "imminent ossification" as knowledge accumulated.

That same chapter names the next problem, and it is the one the whole field would carry. Putting domain-specific knowledge into a program, they write, was a bottleneck, and it was DENDRAL that taught them so. Feigenbaum used the same word for Meta-DENDRAL, a program built to infer new mass-spectrometry rules from data, because acquiring knowledge was "the bottleneck problem" in building practical intelligent systems. The job of getting expertise out of a person and into rules got a name: knowledge engineering. A knowledge engineer sits with a specialist, learns enough of the domain to ask good questions, and turns answers into rules. In the 1977 paper, Feigenbaum describes PUFF, a pulmonary diagnosis system whose 55 rules were extracted from an expert at a San Francisco medical center over a period of intensive work. No textbook held those rules.

MYCIN carried the approach into medicine, and its roots were practical. Stanford's Stanley Cohen was running a drug-interaction warning project, and he, Buchanan and the medical student Edward Shortliffe began to discuss a program that would check antibiotic prescriptions. The evidence for a need was grim. Buchanan and Shortliffe cite a 1972 study of 340 hospital patients on systemic antimicrobials in which a panel of experts judged just 13% of the therapy rational and 66% clearly irrational. A program that knew antibiotic selection could act as a consultant when an infectious disease specialist wasn't available. MYCIN stored its knowledge as IF-THEN rules and reasoned backward from a goal, asking the doctor for the facts it needed. By the time the team wrote up its work, the knowledge base held about 450 rules, as Chapter 36 states.

The evaluation is the best-known result. In a study published in JAMA in 1979 and reprinted as Chapter 31, eight specialists rated the therapy advice for ten difficult meningitis cases without knowing which prescriber was the computer. They rated 65% of MYCIN's prescriptions acceptable, against a mean of 55.5% for five Stanford faculty specialists. Seventy percent of MYCIN's therapies won a majority of evaluators, compared with a faculty average of 44%.

And yet MYCIN never saw a hospital ward. Its authors write that the trial on the wards was never carried out and that the infectious disease knowledge base was "laid to rest in 1978." The reasons were practical: the computers that ran Interlisp were still too expensive, and the system's narrow breadth and user interface meant it wouldn't be cost-effective for physicians, they explain in the closing chapter. Good advice wasn't enough to make something that fit into a doctor's day.

This era solved a real problem: specialists' judgment could now be applied by a program, tested and explained. It created two new ones. Rules had to be extracted from busy experts one at a time, and the programs lived in a single narrow domain with no way to widen.

For teams today: treat a rule-writing project as an interview project. Budget for the expert's time, expect the first rules to be wrong, and test the system against your own cases, as the MYCIN team did against ten hard ones. A system that scores well can still fail to fit the workflow.

The Boom (1978-1987)

Rule programs earn money, and governments bet billions

Consider an order arriving at Digital Equipment Corporation's manufacturing group in early 1980. A customer wants a VAX 11 computer with certain components, and someone has to check that the parts fit together and add whatever is missing. In December 1978, a team at Carnegie Mellon led by John McDermott began work on R1, a rule-based program that did this. By January 1980, per McDermott and Barbara Steele's 1981 IJCAI paper, DEC's manufacturing organization was using it to configure almost all VAX 11 systems it shipped. The system, written in the OPS5 rule language, held about 850 rules at that point.

R1 grew into a system called XCON at DEC. Nilsson reports that by 1989 DEC's configuration systems had about 17,500 rules, and quotes a DEC paper estimating that the net return was in excess of $40 million per year. The same 1981 paper shows the catch. DEC kept a group of 15 people responsible for maintaining R1 and extending what it could do. Each new product, each customer exception, meant more rules, and McDermott's team was already writing extensions so the program could accept ad hoc, customer-specific constraints.

Around R1, an industry formed. Nilsson lists the expert-system companies of the period: Teknowledge, organized by Stanford faculty and researchers and built on EMYCIN; Syntelligence, founded by Peter Hart and Richard Duda; Aion, Inference, IntelliCorp and others. Charles Forgy, who created OPS5 and the Rete algorithm that made rule matching efficient, left Carnegie Mellon and founded Production Systems Technologies in 1983. Hardware followed. MIT researchers designed workstation-style computers that ran LISP quickly, and two companies, Lisp Machines, Inc. and Symbolics, sold them.

Then came the national bet. In 1981 Japan laid out its plans for what it called Fifth Generation computers at the first FGCS conference, and in 1982 the Ministry of International Trade and Industry launched it and set up ICOT, the Institute for New Generation Computer Technology, under Kazuhiro Fuchi, per Nilsson's chapter on the Japanese project. The aim was machines that could do AI-style inference over large knowledge bases and talk to people in natural language, with Prolog as the base language and speed measured in logical inferences per second. The plan ran ten years in three stages: three years of initial research, four building intermediate systems, three finishing a prototype, on a total budget of ¥54.2 billion, roughly $380 million at the 1990 exchange rate. Nilsson writes that the project helped DARPA justify its Strategic Computing Initiative and provoked comparable programs in Europe, among them Britain's Alvey Project and the European ESPRIT programme.

Interest in the field soared. AAAI membership climbed from about 5,000 after its founding to a peak of 16,421 in 1987, most of the new members coming from industry and government. But warning signs came early. At the 1984 AAAI convention, a panel titled "The 'Dark Ages' of AI" discussed the risk that expectations had grown too high. Nilsson writes that some of the blame for the inflated hopes belonged to researchers who made exaggerated promises.

The boom solved the question of whether AI could do paid work, and the answer was yes, in a narrow, rule-heavy corner. It created a bill: every system needed engineers, every change needed new rules, and a hardware and funding race had been launched on promises.

For teams today: a rule system's cost is mostly after launch. Before approving a pilot, ask who updates the rules when the product line changes, and what that costs per year. DEC needed 15 people for one program in 1981.

The Second Winter (1987-1990s)

Maintenance costs and cheaper workstations end the party

By 1987, AAAI membership had stopped rising, and in the following years it slid. By 1996, Nilsson reports, it had leveled off between 4,000 and 5,000 members. The second AI winter has its own account, but the outline is quick. Advertising in AI Magazine dropped, industry and government participation at conference exhibits shrank, several AI companies closed, and AI research at some larger hardware and software companies ended. According to the historian Alex Roland, as cited by Nilsson, DARPA's budget for basic AI and Strategic Computing research fell from $47 million to $31 million between 1987 and 1989. Nilsson calls this the AI winter and says it grew from sponsors' inflated expectations combined with a failure to deliver systems that matched them.

Two specific pieces of the boom came apart. The LISP machine makers, Nilsson says, enjoyed initial success but gradually lost out to other providers of workstations. The expert-system vendors faced a different squeeze: it wasn't too difficult for clients to develop their own systems, which ran on low-cost workstations and personal computers, so many of these companies closed, were bought, or turned to services.

The Fifth Generation project reached its end of main phase around the same time, and its verdicts were mixed. Nilsson reports that the project was extended by two years in 1993. The independent evaluators who reviewed it in 1992 disagreed on how to read it. Wolfgang Bibel of Technical University Darmstadt called it an "outstanding success" for showing logic could unify machine design and software, while Seif Haridi and Siwert Sundström of the Swedish Institute of Computer Science judged its technical results to surpass expectations for a fixed time and temporary staff but also called it unfinished and urged porting its software to widely available machines. Both could be right. A lab can meet its research goals and still fail to produce a product the market wants.

The same pattern ran through all of it. Rules were written by hand, knowledge went stale, and cheaper general-purpose hardware made the specialized machines unnecessary. Nilsson adds that the winter lasted only a season, and that researchers turned to new ideas, including learning from data (see machine learning).

For teams today: a downturn in a technology is not proof that the idea was wrong. Expert systems failed as a product category while the underlying move, encode a decision once and apply it consistently, kept working. When you evaluate a tool, separate the idea from the platform it arrived on.

The Quiet Rules (1990s-2010s)

Expert systems become business rules and decision support

After the excitement faded, the rules didn't disappear. They moved inside other software. Nilsson traces how expert-system inference engines turned into business rule engines, and quotes the Business Rules Group's definition of a business rule: a statement that defines or constrains some aspect of the business, such as "when our widget inventory is below 200, notify widget production." Business rules take the form of IF-THEN statements, just like expert-system rules, and engines apply them to answer questions about business practice or to take actions such as placing orders or sending alerts.

The people carried over too. Forgy, who had built OPS5 and Rete, founded RulesPower in 2002 for business rules management, and in 2005 the company sold some of its assets to Fair Isaac, now FICO, according to Nilsson. Such engines suit decisions that need to be explicit and the same every time.

What did this era solve? It kept the part of expert systems that worked: transparent rules for stable policy. It also dropped the part that failed, the ambition of capturing all of a specialist's judgment. Messier tasks such as scoring, ranking and forecasting went to machine learning, which learned patterns from data instead of waiting for someone to write them.

For teams today: use rules where the policy is stable and someone must be able to explain a decision, and use learned models where patterns are too tangled to write down. Most real systems need both.

The Age of Agents (2020s-present)

Models decide and tools act, with rules guarding the edges

The knowledge acquisition bottleneck got a new answer in the 2020s. Instead of an engineer writing 55 or 850 rules, a language model absorbs patterns from text and can be pointed at a task in plain language (see the AI timeline for how that happened). The tradeoff is that the reasoning is no longer an auditable list. A model can be confidently wrong in ways a rule never would be.

At the same time, models learned to act. On December 9, 2025, Anthropic donated the Model Context Protocol, an open standard for connecting AI applications to outside systems, to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. The announcement counted more than 10,000 active public MCP servers. A system that calls tools and updates records is the core of agentic AI, and our guide to what an AI agent is explains the parts.

The old lessons return in a new form. An agent that can act needs limits on what it may do, and those limits are usually written as explicit rules: which actions need approval, which amounts trigger a human, which records are off limits. That is a close cousin of an expert system's rule base, now used as a fence around a model instead of as the model. Our guide to AI agent guardrails covers how teams set those fences. This is our reading of the pattern, not a claim that today's agents are descended from MYCIN. The shared problem is the same one: who writes the rules, who keeps them current, and who checks that they still match the business.

For teams today: pair a flexible model with a short, explicit rule layer for the decisions that must never vary, and give that layer an owner.

Key People

Key Facts

• The Edwin Smith Papyrus holds 48 trauma cases, each in a set formula of injury description, diagnosis, prognosis and treatment.
• DENDRAL was begun in 1965 with the Stanford Mass Spectrometry Laboratory.
• In a blinded 1979 study, 65% of MYCIN's prescriptions were rated acceptable, against a mean of 55.5% for five faculty specialists.
• R1 had been used since January 1980 to configure almost all VAX 11 systems DEC shipped, and DEC had 15 people maintaining it.
• Japan's Fifth Generation project had a ¥54.2 billion budget over ten years, about $380 million at the 1990 exchange rate.
• AAAI membership peaked at 16,421 in 1987 and settled near 4,000 to 5,000 by 1996.

The Pattern Behind the History

Across six eras, the same four moves repeat. We call the sequence the Codify-Scale-Maintain Loop. It's our synthesis of the history above, not a research finding.

1. Codify a narrow expertise. The papyrus, DENDRAL's chemistry, MYCIN's antibiotics and R1's VAX orders each picked one bounded domain.
2. Win on the narrow task. MYCIN beat faculty ratings on ten cases, and R1 handled almost every VAX order DEC shipped.
3. Hit the maintenance wall. The knowledge acquisition bottleneck and DEC's team of 15 show where the cost lived: in upkeep, not in the first build.
4. Let a cheaper platform absorb the idea. Workstations replaced LISP machines, and business rule engines replaced expert-system shells.

What It Teaches Teams Today

• Plan for the expert's time. Rules come from interviews, and the people who know the most have the least time.
• Pilot on your hardest cases. MYCIN's evaluation used difficult cases chosen by a physician outside the project.
• Count the upkeep. Ask who updates the rules, prompts or data when prices, products or policies change.
• Fit the workflow. MYCIN gave good advice and still stayed off the wards, partly because it didn't fit how doctors worked.
• Keep explicit rules where decisions must be explained. Pair them with learned models for the messy parts, and put an owner on both.

Expert systems taught the field that knowledge, not cleverness, does the work, and that someone has to keep it true. Read the history once, then ask of any new AI tool: who wrote down what it knows, and who will update it on the day the business changes?