AI history is usually told as weather. Spring: a new idea blooms, the press arrives, and someone explains that general intelligence is now mostly an engineering problem. Winter: the idea meets maintenance costs, messy inputs, and the discovery that the world contains more than the demo. The first AI winter interrupted the early ambitions; the second caught a field that had found commercial customers and expensive hardware to sell them.
I The Ideas That Avoided the Funeral
The seasonal story captures the funding cuts and collapsed businesses. It is less good at following what happened to the work.
Some of the ideas from those same doomed eras did not die at all. They simply changed clothes, stopped saying "artificial intelligence" at parties, and got hired by the rest of computing.
AI has very good obituaries. The perceptron: mathematically humbled in 1969, then exiled from polite funding circles. Expert systems: briefly rich, then crushed under the weight of their own rulebooks. Lisp machines: elegant, expensive, and eventually defeated by cheaper computers with worse manners and better prices.
Each of those stories has a beginning, a boom, a disappointment, and a retrospective. They fit the seasonal narrative neatly. They make excellent cautionary tales. They also make AI history sound as if the failed label took the work down with it.
A failed research promise did not necessarily make the underlying technique useless.
From the same symbolic AI culture came a quieter set of tools that never needed a comeback because they never quite left. Frames, semantic networks, and constraint satisfaction problems were born inside AI's grand project of making machines reason. Their influence, and sometimes a closely related engineering pattern, can be found in knowledge graphs, software object systems, schedulers, and configuration tools: the things still working after the keynote ends.
This is the less dramatic form of survival: a useful technique becomes ordinary infrastructure, even when the theory around it loses support.
Everything Is Still a Slot
In June 1974, Marvin Minsky's MIT AI Lab Memo 306 proposed a simple, powerful idea: understanding is often not deduction from scratch. It is recognition plus filling in blanks.
You do not see a birthday party and derive the possibility of cake from first principles. You have expectations: candles, gifts, someone pretending not to care about the singing. The situation supplies a structure, and the mind spends its effort on what is unusual.
Minsky called these structures frames. A frame had slots. Slots had default values. New information could override the defaults. It was a theory of ordinary understanding built around the most human of all computational strategies: assume the normal thing until reality becomes rude.
A related idea, Roger Schank and Robert Abelson's scripts, described familiar sequences such as ordering, eating, and paying in a restaurant. Frames organized expectations about a situation; scripts gave familiar events an order.
Frames did not deliver general intelligence. Encoding the expected parts of a birthday party is easier than knowing why somebody has left it in tears.
But the basic move survived beautifully.
A fixed structure with named places for information? Defaults? Overrides? Inheritance? That is not a relic. That is Tuesday.
The pattern is familiar in classes, schemas, configuration objects, and forms: named fields, expected values, and ways to handle exceptions. A customer profile does not need to understand its customer to give software a useful structure for handling one.
This is a resemblance, not a claim that frames invented software objects. Simula's classes and Smalltalk's early objects predated Minsky's memo. Object-oriented programming had its own history, drawing from simulation, Lisp, message passing, and other design pressures. Frame systems explored overlapping problems of slots, defaults, and inheritance. The useful continuity is the problem they addressed: how do you represent a thing without restating the entire universe every time?
A representation could fall short as a theory of understanding and still be useful as a way to organize information. The smaller job did not require the larger promise to come true.
A Search Engine Walks Into a Canary
In the 1960s, Ross Quillian proposed that memory for word meanings might be organized as a network. Concepts were nodes. Relationships were edges. Facts could be inherited through connections. A canary is a bird. A bird is an animal. Animals breathe. The canary inherits the fact about breathing. The graph saves it a separate entry.
Quillian and Allan Collins tested the idea with reaction times. People were faster to confirm "a canary is a bird" than "a canary is an animal." Their model explained the difference as an extra step through the hierarchy. It was a way to turn a proposed structure of memory into a prediction somebody could measure.
The AI dream was that semantic networks might give machines a structure for meaning. Not just words in a list, but concepts related to other concepts: inheritance, association, hierarchy, implication. Meaning as geography.
That dream, in its strongest form, ran into all the usual difficulties. Human concepts are not tidy. Categories leak. Context changes everything. A penguin is a bird, but it defeats the default expectation about flying. A tomato's useful category changes between botany and the kitchen. "Bank" depends on whether you are holding money, standing near a river, or explaining why a language model just invented a citation.
Still, the graph survived.
Modern knowledge graphs retain that central move: represent entities and the relationships between them explicitly. Google putting a person's birth date, films, spouse, and awards into a box beside the search results. Wikidata linking entities through "instance of," "subclass of," "part of," and a thousand other relations. Recommendation systems, entity resolution pipelines, fraud detection networks, biomedical databases, corporate data catalogs: all of them depend on the same basic refusal to treat facts as lonely little islands.
The funny part is that the idea became most successful after it stopped insisting it had solved meaning. A knowledge graph does not need to understand "canary" the way a person does. It needs to know that canaries are birds, birds are animals, animals have properties, and users get cranky when the answer box decides Paris Hilton is a hotel in France.
That is enough to be useful. It does not establish human-like understanding. It gives other software something dependable to work with.
The Great Art of Not Even Trying the Bad Options
Search is one of those words that sounds harmless until you ask how many possibilities there are. Then it becomes a horror film with math.
Scheduling a set of exams is not hard because nobody knows what an exam is. It is hard because students cannot sit two exams at the same time, rooms have capacities, instructors have availability, courses overlap in annoying ways, and every solution that satisfies one constraint appears to insult three others. Airline crews are worse. Chip layouts are worse. Delivery routes are worse in a way that involves both mathematics and traffic.
The naive solution is simple: try combinations until one works. This is also how you turn a computer into a small, expensive space heater.
In 1977, Alan Mackworth's "Consistency in Networks of Relations" helped formalize a better approach. A constraint satisfaction problem has variables, possible values for those variables, and rules about which combinations are allowed. Instead of blindly searching the whole space, propagate constraints first. If one choice makes another impossible, remove it. If a value can never participate in a valid solution, throw it out before search begins.
Arc consistency is difficult to put in a cinematic trailer. Its practical appeal is easier to explain: do not spend effort on choices you can already rule out. Local checks do not guarantee a complete solution, but they can leave much less work for the search.
That principle is everywhere.
A Sudoku solver removes candidates. A university timetable keeps chemistry finals from colliding with calculus. A configuration tool rejects incompatible options before somebody orders the product. Constraint programming shares this territory with operations research and other traditions; its usefulness does not depend on assigning the whole territory to AI.
In ordinary use, these systems are often described by the job: scheduling, planning, configuration. The name tells the customer what the software does. It makes a less exciting keynote.
But the family resemblance is direct: AI tried to make search smarter by making the impossible visible early. That idea did not need to become conscious. It just needed to save time.
II The Net That Kept Working
The Limit Was Not the Whole Field
Neural networks complicate the story. Unlike a frame-like structure disappearing into a schema, the method remained recognizably a neural network. What changed was the scale of the job it had to justify.
Minsky and Papert's 1969 critique examined limitations of perceptrons. A single-layer network cannot represent XOR; that is a limit of the architecture, not simply a failure to train it long enough. It is also not a proof that multilayer networks cannot work. The reception of the book helped make an already difficult research direction harder to pursue.
Frank Rosenblatt, the perceptron's inventor, died in a boating accident in 1971. He did not live to see the later systems. But the research did not stop with him, and the route from his work to a bank's check reader was not an unchanged algorithm waiting quietly for employment.
The Research That Continued
By 1986, Rumelhart, Hinton, and Williams had helped bring backpropagation for multilayer networks to a much wider research audience. In 1989, Yann LeCun and colleagues demonstrated convolutional networks recognizing handwritten digits. Architectures, training methods, and engineering practice were changing. There was a research revival before there were products to put in a pocket.
The Products That Shipped
Apple supplied one of those products. Its Newton handwriting recognizer, developed by Larry Yaeger, Brandyn Webb, and Richard Lyon, paired a neural-network character classifier with a search through possible character groupings and words. It began shipping in Newton OS 2.0 devices in late 1995. The network supplied evidence; the surrounding software helped turn that evidence into a word.
LeCun and colleagues' 1998 work on document recognition and LeNet-5 described another route into ordinary use. Their broader check-reading system combined learned recognition with machinery for locating, segmenting, and interpreting the amount. Commercial systems from that work had been deployed in banks from 1996. A network recognizing digits was an important component. A bank needed the rest of the system, too.
Neither product settled the question of general intelligence. Both showed that learned recognition could earn its place inside software people used.
The distinction matters to the argument. Neural networks survived through continued research as well as practical deployment. They did not have to disguise their mathematics, and their funding history cannot be reduced to a change of label. But to a customer, the result could still disappear into an ordinary feature: handwriting recognition, document processing, the thing that finally reads the number correctly.
III From Magic to Plumbing
The Smaller Job
Why did these ideas remain useful when the larger promises faltered?
A modest job helped, but modesty alone is not the explanation. MYCIN explored a bounded medical problem. XCON configured computer systems. Lisp machines served a particular computing community. Narrow scope did not exempt them from maintenance costs, deployment barriers, or cheaper competition.
Nor were frames and semantic networks born without grand ambitions. They belonged to attempts to explain understanding and meaning. The difference was that useful parts could be taken out of those theories and asked to do less.
Fifth Generation computing proposed a much larger programme built around logic programming and parallel inference. A scheduler could be judged on whether it produced a workable timetable. A knowledge graph could improve retrieval without becoming a complete theory of meaning. A handwriting recognizer could fail to understand the note and still transcribe it.
The practical advantage was an answer somebody could check, attached to a job somebody needed done. That did not guarantee survival. It gave the work a reason to continue when the larger story lost its audience.
When the Label Disappears
There is a strange lifecycle for computing ideas. At first they are magic. Then they are research. Then they are product. Then they are infrastructure. Then they are so normal that people only notice them when they break.
AI suffers from this more than most fields because the label keeps chasing the frontier. Once something works reliably, it often stops feeling like AI. Optical character recognition becomes document processing. Route planning becomes logistics. Constraint solving becomes scheduling. Knowledge representation becomes data modeling. Structures resembling frames become familiar as schemas, templates, and forms. A neural network becomes "the handwriting feature" or "the check reader," and the word "neural" quietly drops off the packaging.
This can create a historical illusion: AI appears to fail repeatedly, while some of its useful techniques become ordinary computing. The change is partly technical and partly a change in what people expect the label to mean.
The failures remain in the story because they kept the name. The successes disappear because they became normal.
That is why the survivors are so easy to miss. They do not look like monuments. They look like plumbing. They do not announce a new era. They make the old era's software keep running. Nobody thanks a constraint solver when a flight crew schedule works. Nobody sees a knowledge graph when the search box answers correctly. A default value in a form gives its user no reason to think about knowledge representation. A note recognized by a PDA gives its writer no reason to follow the history of neural-network training.
This is unfair, but also a compliment. The highest form of software success is becoming too useful to be interesting.
What This Winter Would Leave
That distinction gives the old winters a present use. A research programme, a business, and a useful technique can have different fates. Losing confidence in the first, or money in the second, does not settle the value of the third.
When people predict another AI winter, they may mean several things: investment retreating, customers declining to pay what services cost, or progress falling short of promises about general intelligence. Any of those could do real damage. Earlier winters interrupted careers and made worthwhile work harder to pursue. Useful ideas did not survive by being immune to economics. They needed people, machines, and institutions willing to keep them working.
The question is what the language-model era has already made useful enough to keep.
One candidate is the instruction field. ChatGPT made a particular encounter familiar: describe what you want, receive an attempt, then explain what needs changing. The exchange can sit inside a writing tool, a search service, or an application somebody already uses. It does not need to remain a separate product with a name that sounds like a research project. Menus still offer precision. Ordinary language offers a way to ask for something before you know which menu contains it.
Another is the cheap first attempt. A translation, an outline, a formula, an explanation of an error: each can be useful without being the final answer. The important condition is that somebody can assess it. A plausible mistake can cost more than a blank page, but an editable draft can save work without taking responsibility for the result. That smaller bargain has a better chance of surviving than the promise of an employee who never needs supervision.
Code makes the change particularly tangible. GitHub Copilot put generated suggestions inside the editor. Conversational tools also let someone who can describe a problem attempt a script they could not have written unaided. The script still needs testing. Explaining what you want has become more useful; knowing whether you got it has become more important. That is a change in access to technical work, even when it does not amount to independent expertise.
There is also a practical difference between financing the next model and running an existing one. llama.cpp helped put language models on ordinary computers. Local deployment does not reproduce every capability of a large hosted service, and it has costs of its own. But where an existing model is adequate, its use need not depend on another company winning the race to build a larger one. A stalled frontier could still leave room for smaller, less expensive applications of what already works.
The inheritance is not entirely welcome. Once convincing prose and images can be generated cheaply, polish becomes weaker evidence of the knowledge or effort behind them. An investment collapse would not restore that evidence. Checking a source, establishing who made something, and deciding whom to trust would remain part of the work. Some things persist because they are useful. Others persist because the difficulty of producing them has already fallen.
None of this makes every deployment inevitable. Prices can rise, services can disappear, and a feature can prove less useful than its demonstration. But the historical test is more demanding than asking whether the boom was justified: which jobs are worth keeping the machinery for, even if the next breakthrough never arrives?
Still There
The old winters offer no guarantee that today's systems will become tomorrow's infrastructure. They offer examples of how that happens: useful work survives when it can be supported, adapted, and judged on a job smaller than the promise that introduced it.
Frames, semantic networks, constraint methods, and neural recognition each followed a different route. The language-model era will leave its own uneven inheritance. Some capabilities may disappear with the services that supply them. Others may become so familiar inside ordinary software that their origin stops being interesting.
A winter could make the next model harder to finance. It would not, by itself, make an existing one forget how to translate a message or help someone write a small program. The company might disappear. The expectation that software should help with those things would be harder to remove.
AI did not only leave behind cautionary tales.
It left studs in the wall.
The next winter would test which of the new ones are carrying weight.
From frames to handwriting recognition, explore the ideas that kept working.