Expert systems made the field money and then became its cautionary tale

Narrowing the problem was the insight

The early ambition was general intelligence, and it was not going well. The expert system idea was to abandon generality deliberately and build something that performed expertly in one confined domain — diagnosing a class of infection, configuring a particular family of computers, interpreting a specific kind of geological survey.

Within such a domain the knowledge could actually be enumerated. A practitioner could be interviewed at length, their decision-making elicited as conditional rules, and those rules encoded in a form a machine could apply. The insight was that expertise in a bounded field is much smaller and much more explicit than general competence.

It worked. Several systems performed at a level comparable to human specialists on their narrow tasks, and unlike almost everything before them they were deployed in commercial settings where money depended on the answers.

The architecture separated knowledge from reasoning

A well-built expert system had two distinct parts: a knowledge base holding the rules, and an inference engine that applied them. The engine knew nothing about the domain and the rules contained no procedural logic, which meant one engine could serve many domains and a rule base could be revised without touching the machinery.

This separation was a genuine software engineering advance and it outlived the field that produced it. It is the same architecture as a modern business rules engine, and the reason so many insurance, lending, tax and logistics systems are built that way today traces directly back to this period.

The engines also handled uncertainty, with various schemes for attaching confidence to conclusions and combining evidence from multiple rules. Those schemes were mathematically shaky by later standards and drew sustained criticism, which eventually pushed the field towards proper probabilistic methods.

Knowledge acquisition was harder than anyone budgeted for

The process of getting expertise out of a person and into rules acquired a job title — knowledge engineer — and a literature about why it was so difficult. Practitioners frequently could not articulate what they did, gave rules that did not match their observed behaviour, or described the idealised procedure rather than the one they used under time pressure.

Different experts also disagreed, sometimes substantially, and the system had to encode one position. This is a familiar problem in any attempt to formalise professional judgement, and it does not have a clean solution.

The result was that building a system took far longer than projected, and the cost was concentrated in a scarce role requiring both domain understanding and formal skill. That economics, more than any technical limit, shaped what got built.

Maintenance was where they actually died

A rule base that solves a real problem grows. Every exception encountered in deployment becomes another rule, rules interact in ways nobody anticipated, and after a few thousand of them the base exceeds what any individual can reason about safely. Changing one rule can alter behaviour in cases nobody thought to test.

Meanwhile the domain itself moves. Products change, regulations change, and medical or engineering practice advances, so a system that is not continuously updated becomes quietly wrong. The updating requires the same scarce expertise that built it, indefinitely.

Systems were therefore expensive to own rather than merely expensive to build, and many were retired not because they stopped working but because the person who understood them left. That failure mode has nothing to do with artificial intelligence and everything to do with software maintenance, which is perhaps the most transferable lesson available.

What the episode is usually used to prove

The standard modern telling casts expert systems as proof that hand-coded knowledge cannot compete with learning from data, and that the field wasted a decade before discovering this. It is a convenient story and it is too neat.

The more careful reading is that the approach succeeded precisely where its assumptions held — bounded domain, stable rules, articulable expertise, and a real cost to unexplainable answers — and failed where they did not. Those conditions still occur, and systems meeting them are still built and still preferred, particularly where a decision must be auditable by a regulator.

There is a live argument that some of what was learned then is now being relearned expensively. The knowledge acquisition problem has reappeared as the problem of assembling good training and evaluation data; the maintenance problem has reappeared as the problem of keeping a deployed system correct as the world moves. The technology changed. The awkward parts did not.