A Machine That Can Have Grandchildren

In my previous post about von Neumann’s 1948 lecture on automata, I wrote about how a machine’s organization lets it do things that none of its individual parts can do. One of those things was reproduction. A machine could assemble another machine, pass along the information needed to repeat the process, and let the new one continue independently. Put that arrangement inside a spacecraft and a strange possibility opens up: the civilization launching an exploration program might only have to build its first generation. Everything after that would have to build itself, somewhere else, without a delivery truck coming from Earth.

Science fiction has been living with the consequences for a long time. Fred Saberhagen’s Berserker stories give us autonomous machines whose capacity to manufacture more machines keeps an ancient extermination campaign running. Philip K. Dick’s Second Variety, later adapted into Screamers, puts the same anxiety into weapons and underground factories that have escaped meaningful human control. Those are different arrangements, and the Screamers are hardly scientific survey probes, but the disturbing feature is shared. Destroying a machine does very little if you leave behind the process that manufactures its replacement.

Cinema also gives us the multiplying monoliths in 2010: The Year We Make Contact, adapted from Arthur C. Clarke’s 2010: Odyssey Two. They spread through Jupiter as part of an alien intervention whose physics the story leaves largely outside our reach. That image gets something across immediately: an artifact arriving from elsewhere can become a planetary event. Fiction can skip the production schedule and show us the black shapes multiplying. An engineer looking at the same scene has a less cinematic question. Where is all the manufacturing happening?

Dennis E. Taylor’s Bobiverse puts an engineer inside that question. In We Are Legion (We Are Bob), Bob Johansson sells his software company, dies, and eventually wakes up as a digital mind destined to control a spacecraft capable of replication. Exploration becomes something he and his copies can pursue in parallel. The premise has obvious appeal if you build software: preserve the useful state, instantiate another worker, give it resources, and let it get on with the job. Except the worker needs an actual spacecraft, and its resources are scattered around a star system.

What interests me about Bobiverse is the combination of personal agency and industrial growth. A copy can explore, another can build, and their work can create capacity for further copies. That immediately raises a scheduling problem I find more interesting than another fictional engine. A factory can spend its output on a telescope, a ship, or another factory. The telescope gives you information, the ship opens a destination, and the additional factory increases future output. Each choice delays the others. A civilization of machines would still have to decide what to do on Tuesday, even if its Tuesdays lasted centuries.

The Bobs also diverge in personality and priorities. That makes the premise more useful as a thought experiment. Copying a capable agent does not settle what the copies will want, what they will learn, or whether they will agree. Even without the books’ particular explanation of identity, separate histories are enough to make two initially identical decision systems encounter different evidence. The result could be cooperation, disagreement, or a quiet decision to go somewhere else. Reproducing the workforce leaves the coordination problem very much alive.

To understand where the machinery behind this idea came from, it helps to get the attribution right. Von Neumann’s foundational work concerns the organization of reproducing automata. The standard reference is Theory of Self Reproducing Automata, published in 1966, after his death, and edited and completed by Arthur W. Burks. It combines his 1949 Illinois lectures with a later, unfinished manuscript. It is a work about computation and construction, rather than a spacecraft design study. The name “von Neumann probe” carries that theoretical ancestry into a later application.

The essential construction is already visible in his 1948 lecture. Turing’s universal computer provides the starting point: a machine can interpret a description of another machine and perform its computation. Von Neumann extends this idea to a universal constructor, which reads a description and builds the machine it specifies from suitable parts. A separate copier duplicates the description without interpreting it. A controller coordinates construction, copying, and separation. Give this combined machinery a description of itself, and it can produce another assembly carrying the same description. There is no endless blueprint inside a blueprint: the machinery is constructed while its description is copied separately. The same information has two roles, instructions during construction and data during copying.

Think of a workshop with an assembly manual and a photocopier. The manual explains how to build the workshop’s equipment, including the photocopier. The workshop builds that equipment, then copies the manual for the new workshop. The manual does not need to contain a drawing of every page recursively nested inside its own drawing of the photocopier. This is an analogy, of course; an ordinary workshop still depends on people and suppliers. But it makes the logical separation concrete. You reproduce the mechanism that uses the instructions, and you preserve the instructions that make the mechanism useful.

The later cellular model makes the environment mathematically explicit. In the 1966 volume, construction takes place on a plane of cells with 29 possible states, updated through local rules involving each cell and its four immediate neighbors. Organized patterns perform computation and construction within that world. Universality is relative to the model’s permitted constructions; it does not mean manufacturing arbitrary physical objects. The abstraction lets the argument be developed rigorously while leaving metallurgy, power systems, and manufacturing tolerances outside it. Von Neumann and Burks, Part II.

That boundary is where the spacecraft problem begins. In the workshop analogy, somebody supplied the motors, wire, bearings, and paper. An asteroid supplies none of them in usable form. It offers materials in particular concentrations and chemical combinations, under conditions that may be awkward for your equipment. Moving from a reservoir of suitable parts to a piece of rock adds an enormous amount of work. You have to explain how that rock becomes every indispensable part of the next workshop, including the tools used to make those parts.

The space manufacturing literature calls this problem closure. The NASA study Advanced Automation for Space Missions, published in 1982 from a 1980 summer study, examined it directly. Its discussion distinguishes matter, energy, and information requirements, along with the ability to produce the necessary items in sufficient quantities and quickly enough. It also identifies imported “vitamin parts”: small, difficult components that might still have to come from Earth. Closure here means autonomy relative to the chosen local resources. The factory remains open to flows of matter and energy.

For a concrete example, imagine a hypothetical installation that makes 99.9 percent of its own mass but imports one controller. By weight, that sounds almost finished. Once the controller stock runs out, however, reproduction stops. Producing another thousand tonnes of structural metal will not help. This is why I would be suspicious of a single percentage describing how close a system is to reproducing itself. The missing fraction needs names, quantities, production routes, and replacement intervals. A tiny dependency can determine the lifetime of the entire project.

Now follow that controller backward. Manufacturing it may require purified feedstocks, process chemicals, deposition equipment, pumps, optics, packaging, and instruments that tell you whether any of this worked. Each instrument introduces more dependencies. A useful design process would trace those dependencies until every essential input either comes from the local environment through an available process or is explicitly recorded as an import. The result might be a collection of specialized facilities spread across a moon. Nothing requires the reproductive unit to fit inside one elegant robot. The system boundary has to include the equipment that actually keeps the chain going.

There is a practical compromise available. A seed could carry a large inventory of difficult components and use local resources to produce bulky structures and simpler machinery. That could be tremendously useful long before complete autonomy. But its inventory would impose a ceiling on expansion unless it eventually acquired the ability to replenish those components. This is also where I would question whether the smallest, fastest, most advanced hardware is the best choice. For this mission, a larger controller manufactured by a simpler local process could be more valuable than an exquisite chip whose fabrication requires an industrial network left behind on Earth.

A direct engineering treatment of the spacecraft idea came from Robert A. Freitas Jr. in A Self Reproducing Interstellar Probe, published in the Journal of the British Interplanetary Society in 1980. His REPRO concept adapted the Project Daedalus approach and carried a seed that would establish manufacturing in the destination system. The author’s archived draft describes a seed of roughly 443 tonnes, about 500 years of factory development, and another 500 years to produce a new probe. These are assumptions in a preliminary feasibility sketch, not demonstrated performance; the archive also warns that its text may differ from the published version. Even so, the scale is instructive. Reproduction is an industrial project with a spacecraft attached.

For a proposed design today, I would ask to see the second reproductive cycle. Building one descendant can consume imported spares, calibrated tools, or consumables that the original launch quietly supplied. The descendant may look complete and still lack the ability to continue. Let it build another functioning reproductive system using only the declared inputs, then repeat the exercise. Every generation tests whether some dependency has been hidden in the initial conditions. The interesting output is a lineage that keeps working, not just a photograph of two similar machines.

Once that lineage exists, the attraction of replication becomes obvious. In an idealized branching model, suppose each generation produces two successful descendants and every descendant repeats the process. The thirtieth generation contains just over a billion machines. That number follows from 2³⁰, with failures, shortages, and competition for destinations removed by assumption. It describes population growth. It says very little about how much of the galaxy those machines have reached, because every branch still has to travel somewhere and build something when it arrives.

Here is a separate toy calculation for that spatial limit. Assume successive usable destinations lie four light years apart along a route, cruise speed is one tenth of light speed, and each arrival needs a century before it can launch the next generation. Ignore acceleration, braking, and failures for the moment. Travel takes forty years, so the frontier advances four light years every 140 years, about 0.029 times light speed. A straight path of 100,000 light years would then take roughly 3.5 million years. This is an illustration of the assumptions, not a prediction of galactic settlement. Real routes, resource availability, and overlapping exploration would change the result.

The useful consequence is that manufacturing time belongs in the same conversation as propulsion. In that toy model, the vehicle spends more time waiting for its successor to be built than crossing the gap. A faster drive would help, but reducing the century of preparation could help more. You would want to optimize the whole interval between one productive arrival and the next. That interval includes surveying, extraction, factory construction, commissioning, fuel production, and launch. A beautiful engine can spend a very long time waiting for the rest of the mission to become ready.

Energy makes the trade more severe. Using the relativistic kinetic energy formula, a payload of one tonne moving at one tenth of light speed carries about 4.5 × 10¹⁷ joules, or 126 terawatt hours. That is the energy of the payload’s motion in the departure frame, before adding propulsion losses or the burden of accelerating propellant and other hardware. Arrival also requires dealing with that motion. Local manufacturing avoids shipping every future machine from Earth, but every outgoing probe still needs a physical energy budget. Exponential population growth would require growing the capacity to provide that energy as well.

The factory has its own heat problem. Refining materials, running machinery, and computing all produce waste heat. In vacuum, a conventional thermal design has to radiate that heat away. More electrical power therefore brings requirements for radiating area, temperature, materials, and protection. Imagine improving a refinery so it processes twice as much ore, only to discover that the thermal system cannot support sustained operation at the new rate. The practical unit of progress is whatever the entire installation can maintain. Faster individual components help only when their supporting systems can keep up.

This is where my interest in software agents runs into the rest of engineering. A model might help interpret a survey, diagnose a fault, schedule production, or propose a new process. It still needs trustworthy sensors, functioning actuators, test equipment, power, and a way to check the result. Consider an agent that discovers a better recipe for a coating. Someone, or some automated process, must prepare a sample, measure its properties, expose it to relevant conditions, and decide whether the evidence justifies changing production. The intelligence becomes useful through that loop. Generating a convincing explanation of the coating is only one small step inside it.

Reproduction also makes verification unusually consequential. A faulty instrument can produce a bad part; a faulty instrument used to build and calibrate its replacements can distribute the same error through the lineage. Take another deliberately simplified calculation: if each of a thousand indispensable steps succeeds independently with probability 0.999, the probability that all succeed is about 37 percent. Real factories use inspection, rework, redundancy, and recovery precisely because useful yield cannot depend on every operation being perfect. A reproducing factory needs those mechanisms to survive reproduction too.

I would therefore want independently checked reference measurements, preserved working designs, replaceable modules, and experiments that can fail without consuming the only functioning production line. A descendant should carry evidence about how its critical components were made and tested. Copying ten controllers with the same software defect adds ten places for the defect to happen. Independence has to be designed into the checks themselves. These are proposals for making the physical system credible, rather than properties granted by the abstract reproduction argument.

Even then, building offspring is only part of continued expansion. In a simple branching model, let each node attempt b descendants and let each attempt have probability p of becoming another productive node. The expected number of productive descendants is bp. Two attempts with a success probability of 0.4 give only 0.8 productive descendants on average, so the expected population shrinks across generations. An average above one allows sustained growth in the ideal model but does not guarantee survival. Shared design defects, unsuitable destinations, and competition for resources can make reality considerably less forgiving.

Communication adds another constraint that Bobiverse makes especially tempting to think about. The series eventually uses fictional communication faster than light through its SCUT technology; I would leave that convenience inside the novels. Consider instead two stationary installations ten light years apart. A question takes ten years to arrive, and its answer needs another ten years to return. If a pump is failing, the remote expert’s advice may arrive after the pump, its replacement, and the replacement’s maintenance schedule have all become history. A useful installation must make operational decisions locally while remaining able to exchange knowledge on much longer timescales.

This connects directly to A Network That Can Wait. Durable messages can preserve observations, construction records, warnings, and software updates across long periods without useful contact. The Bundle Protocol already provides a concrete architecture for communication through intermittent links and large delays, though it does not make an interstellar network an accomplished engineering fact. For a hypothetical probe network, I would expect knowledge to travel as stored objects with provenance and version history. An installation would need to know what an update assumes, which hardware it applies to, and whether local evidence still supports using it.

A distant node would consequently receive news about another node’s past. Its neighbor may have rebuilt its factory, changed its plans, or failed entirely since sending the last message. Coordination would have to tolerate those possibilities. Local authority, explicit commitments, and reconciliation of delayed records would matter more than maintaining a constantly shared view of the whole network. This is one reason the Bobs’ disagreements are worth taking seriously. Even agents that want to cooperate would be acting on different information, with different resources, at different moments in their own histories.

There is a further distinction between copying the equipment and preserving the mission. A machine might reproduce its hardware and software accurately while operating under conditions its designers never anticipated. It could also modify its design deliberately. Once variants differ in their ability to reproduce, resource limits can favor some variants over others. The 1948 lecture already connects copied descriptions with inherited changes, including changes that preserve reproduction. That makes variation possible. It does not establish that the resulting changes will improve scientific judgment, preserve human preferences, or even remain useful to the original project.

Imagine two hypothetical designs. One spends a significant fraction of its resources on observations and careful environmental surveys. Another produces descendants sooner by reducing that work. Under competition where reproductive output determines which design becomes common, the second could spread faster while accomplishing less of what justified the launch. That possibility does not require anger, consciousness, or a dramatic rebellion. It requires a mismatch between the outcome we value and the process that determines which designs persist. The same engineers who write the reproduction mechanism would need to decide what changes are permitted, how they are evaluated, and how those rules survive in descendants.

Those decisions would also need limits on where reproduction is allowed. An apparently convenient resource deposit might be part of an ecosystem the instruments have not recognized. Uncertainty about the environment should affect the action the machine takes. I would want the survey process, resource permissions, and production budget treated as part of the design, with explicit behavior when evidence is inadequate. A command to explore a system leaves a lot unspecified. Turning that system’s matter into more explorers is a separate decision with consequences that the launch team will be poorly placed to reverse from several light years away.

At this point the familiar question becomes unavoidable: if machines could spread this way, why don’t we see them? Replication makes that question sharper, but a small branching calculation cannot answer it. It leaves out how often such systems originate, which environments support them, how long their lineages survive, where they choose to go, and what would make them detectable. Even a large population need not resemble the enormous, conspicuous artifacts that films give us. The uncertainty belongs in those assumptions. A mathematical route to growth is evidence of a possibility, not evidence that somebody has already taken it.

The most convincing next step would be much closer to home. I would start with a bounded production system whose inputs can be audited, give it a clearly defined environment, and measure how much of its operation and maintenance it can sustain. Then ask it to manufacture replacements, expand useful capacity, and repeat those processes without quietly increasing outside support. Record every intervention and every imported component. Such a system could be economically useful while still falling far short of a star probe, and its failures would tell us which part of the larger idea actually needs new science or better engineering.

That is what brings me back to von Neumann. His work gives a precise way to think about how construction and inherited information can keep an organization going across generations. The spacecraft version asks whether we can make that arrangement work with unfamiliar rocks, finite power, imperfect instruments, worn tools, and messages that arrive years late. Bobiverse puts a recognizable person inside the problem, which is part of its appeal. The engineering challenge would remain even if the probe never made a joke, felt lonely, or wondered whether its copy was still itself. Somewhere around another star, it would have to build a machine capable of carrying on. The moment that descendant successfully built its own successor, we would have something much more interesting than another spacecraft.