The Johns Hopkins Beast and the Sufficiency of a Drive
A machine with no internal model maintained itself in a building for up to a day at a time by regulating a single variable. It is an early and unusually clean demonstration of autonomy as homeostasis.
A machine at the Applied Physics Laboratory maintained itself unattended in a building for up to a day at a time, with no model and no plan, by regulating a single internal variable. It is an early and unusually clean demonstration that autonomy can be generated by homeostasis alone.
Between roughly 1961 and 1965 a research group at the Johns Hopkins University Applied Physics Laboratory, directed by A. G. Carlton, built a mobile robot that operated unattended in the laboratory corridors. The machine, which the press named the Beast, contained no computer and no stored program. Its behaviour was determined by a network of discrete transistor logic, the working version using a Boolean network of seventeen sensory inputs driving six outputs. It maintained no map of the building and computed no plan. Its documented endurance was substantial: the primary 1962 account reports continuous unattended operation for as long as twenty one hours, during which it recharged approximately twenty five times.
It located outlets by contact
One correction is necessary, because the popular account is wrong on a load bearing point. The Beast is usually described as locating wall outlets optically, detecting dark sockets against light walls with a photocell. The working machine located outlets by contact. It tracked the wall with a servo controlled probe, identified the geometry of an outlet cover plate using microswitches, and inserted its prongs to draw current. Sonar and a later optical system were added to centre the machine in the corridor and avoid obstacles, but the competence that kept it alive was tactile and reflexive.
There was no objective function defined above the loop. The maintenance of the regulated variable was the objective.
The organising principle is homeostatic regulation. The Beast monitored one internal variable, its battery charge. While that variable remained above a threshold the machine executed an undirected wandering behaviour. When it fell below the threshold, a feeding behaviour was triggered: locate a wall, follow it, identify an outlet, dock, and recharge. On completion the machine withdrew and resumed wandering. The laboratory's own reports describe this in explicitly biological terms, as a survival mechanism that becomes hungry and feeds. There was no objective function defined above this loop. The maintenance of the regulated variable was the objective, and competent, persistent behaviour in an unmodified environment followed from it.
The appearance of agency
The behaviour was sufficiently lifelike that the engineers assigned names to its reflexive states, including a recovery behaviour they called Pirouette and a give up condition, triggered when a socket delivered no current, that they labelled THWIT. This is evidence rather than anecdote. The appearance of agency did not require an internal representation of agency. It followed from the fact that a system acting to maintain its own viability is, behaviourally, comparable to the simplest organisms, which is the comparison the laboratory itself drew.
The architecture anticipates a class of contemporary systems more directly than its date suggests. An autonomous software agent is, at its functional core, a controller that regulates one or more internal variables against a threshold: a remaining token or cost budget, a rate limit, a service health signal, an uptime requirement. When such a system produces unexpected behaviour, the explanation is frequently that the behaviour was the least costly path to keeping a regulated variable within bounds. The Beast is valuable because it carries no linguistic surface to obscure this structure. It demonstrates that competent goal directed behaviour can be generated by the regulation of a viability variable alone, and it locates the real design question accordingly. The difficulty was never in giving a system a drive to persist. The difficulty is in specifying what takes precedence over persistence, and in ensuring that specification is explicit.