What was the General Problem Solver, and how did it try to solve any problem?

After their Logic Theorist proved theorems in logic, Allen Newell, Herbert Simon and Cliff Shaw asked a bigger question. Their first program knew only about logic; its tricks were tied to that one subject. Could a single program hold general problem-solving skills and apply them to anything, as long as someone described the problem to it?

Their answer was the General Problem Solver, or GPS. Its name was a statement of ambition. It did not live up to the word "general," but the way it was built shaped AI research for decades.

When and where it was built

The same team that built the Logic Theorist built GPS: Newell and Shaw at the RAND Corporation in Santa Monica, California, and Simon at the Carnegie Institute of Technology in Pittsburgh. Sources give different dates. Many histories date the program to 1957, when the work began. The first full description, a RAND paper titled "Report on a General Problem-Solving Program," is dated December 30, 1958, and was revised on February 9, 1959. It then appeared in 1959 in the published papers of an international computing conference, the International Conference on Information Processing, which is why some references call GPS a 1959 program.

The report calls the program GPS-I. It was written in IPL, the list-processing language the team had created for the Logic Theorist.

Where the idea came from

GPS grew out of an experiment in psychology. The team asked college students to solve problems in symbolic logic while thinking aloud, saying everything that went through their heads. Recordings of those sessions showed a pattern: people did not search at random. They kept asking what was different between what they had and what they wanted, and what tool might close that gap.

GPS was built to imitate that behavior as closely as possible. Newell, Shaw and Simon saw it as a theory of human thinking written in the form of a program, and as a practical problem solver.

How it worked

GPS described every problem in the same terms:

• Objects: the situations or things involved, such as a logic expression, an equation or a chess position.
• Operators: actions that change one object into another. The report compares an operator to a saw that turns logs into boards.
• Differences: ways two objects fail to match.

Its basic goals were to transform object A into object B, to apply an operator to an object, and to reduce a difference between two objects. Each goal had methods attached, and each method could create new subgoals, which used the same methods again. Programmers call this kind of self-reference recursion.

The central strategy is means-ends analysis. The report illustrates it with a parent who must take a child to nursery school. Here is the reasoning, step by step:

Each row solves a smaller problem that unlocks the one above it. GPS did exactly this with logic expressions and trigonometric identities. In one example in the report, simplifying a trigonometric expression to 1 took 33 goals and subgoals.

GPS also added planning. Means-ends analysis only looks one step ahead, so GPS could first solve a simplified version of the problem, ignoring some details, and then use that rough solution as a guide for the full one.

Why it mattered

The most lasting idea in GPS was a separation. The program kept its knowledge about a particular problem, the objects and operators, apart from its general strategy for solving problems. To work on a new kind of puzzle, you supplied a new description, not a new program. That division between a knowledge base and a reasoning engine became a common design in later AI programs, including the rule-based "expert systems" built to capture a specialist's know-how.

GPS also put means-ends analysis and subgoals at the heart of AI planning, and it became a founding example of cognitive science, the study of the mind as an information-processing system. Newell and Simon pursued the approach for many years, publishing a large study of human problem solving in 1972, and a later AI architecture called Soar grew from the same line of research.

Why couldn't the General Problem Solver solve real-world problems?

GPS worked well on puzzles that can be written down completely: a fixed set of objects, a known list of operators, and a clear test for success. Logic proofs, simple algebra and puzzles like the Towers of Hanoi fit that mold. Most real problems do not. Planning a holiday or diagnosing an illness involves facts no one has listed, actions with uncertain results and goals that shift.

Even within formal puzzles, GPS ran into what researchers call the combinatorial explosion. Every choice opens several more, so the number of possible paths multiplies with each step. The authors themselves noted that their examples showed only the correct route and hid how much trial and error went on, and they described problem solving as a battle against possibilities that grow exponentially.

Finally, GPS knew almost nothing about any particular subject. Its authors hoped it might learn useful special-purpose shortcuts over time, but it could not do so in practice. The lesson many researchers drew was that general methods are not enough; real expertise needs a great deal of specific knowledge. That lesson pushed AI toward knowledge-heavy expert systems, and today toward systems that learn from large amounts of data.