# How can a single brain control multiple separate bodies simultaneously?

All work and all play makes Jack a distributed boy: Jack is at the hotel reception with his wife. Jack is also in the office, meeting with unspecified forces for inscrutable purposes. Jack is also in his smithy, forging a perfect Damascus-carbonite blade. All at the same time.

The basic question here is simple. I have successfully digitized a mind, now I want to give it the ability to control multiple instances of bodies in multiple physical locations simultaneously. I don't care whether the bodies are flesh or robotic. What I care is to hear some plausible explanation of how the brain architecture would have to be restructured to enable one entity to be successfully active in multiple locations simultaneously.

I think this would involve, at the very least:

• allow a person to focus on dozens of things at the same time, instead of just one or two;
• allow for balance and proper orientation of multiple bodies simultaneously;
• enable coordinated movement and speech by multiple bodies in multiple places;
• enable the person to remain(/appear?) recognizably human to the subjects of its flesh-based interactions; and
• the same entity must maintain control of all these instances at the same time, in a relatively synchronized fashion (i.e. no running separate un-synced instances).

In a recent question, I brought up the idea of markets for digital uploads, so feel free to visit that question for more details on how I envision the process of digital uploading working.

• So you want the same datastore (brain) networked to multiple, different, peripherals? – dot_Sp0T Apr 6 '16 at 14:28
• @dot_Sp0T, you could read it that way, yes. I'd think of it as a datastore + highly parallel self-re-wiring CPU/GPU, but why quibble over details. – Serban Tanasa Apr 6 '16 at 14:30
• Sort of the opposite of What are the conditions in which a creature would evolve more than one brain?, I take it? – a CVn Apr 6 '16 at 14:35
• @SerbanTanasa the comment was mostly intended to highlight if you require it to be the same person; because if not, then we can just start up Jack on multiple mainframes (though it would be different Jack's by definition, even if it was the same Jack at the start – dot_Sp0T Apr 6 '16 at 14:37
• @dot_Sp0T, yes, we want the instances to be in-sync, i.e. Jack3 is instantly aware of everything Jack2 is doing with his spouse -- however distracting that may or may not be. – Serban Tanasa Apr 6 '16 at 14:40

What we're looking at is a computer architecture that is derived from the architecture of the brain. Since it is a computer architecture, it could take advantage of all kinds of optimizations and extensions that computer architecture does.

Given that, let's take a look at how real low-level computer networks work. In a modern automobile, for example, there are dozens of computers that have a specialized task. One might control the seatbelt light. If the seatbelt isn't buckled and there is someone sitting in the seat, illuminate the seatbelt light. May not sound like much, but consider that there are plenty of microcontrollers on the market meant for embedded applications that can be purchased for pennies to a few dollars in bulk, and what's the downside?

Other systems make use of a variety of processors that all work toward the same goal, sometimes with specialized purposes and other times just to achieve concurrency. One example is the common CPU/GPU setup. But looking more closely, both a GPU and a modern CPU are designed for concurrency via parallel processing. I'm no expert on the human brain but from what I do know, it seems like it functions--at least on some level--similarly. There is a basal ganglia which offloads commonly-repeated tasks from the conscious mind, hence the famous human ability to walk while chewing bubble gum. Even though consciously doing more than one thing at a time is often difficult, it becomes "mindless" (so to speak) to perform common tasks like walking, so these can be performed concurrently with other tasks.

My thought would be to give each body its own equivalent to a basal ganglia loaded with many routines--even some complex ones such as speaking--and have the conscious part of the brain control it remotely, giving it tasks in much the same manner that the human brains relegates tasks to its own basal ganglia.

Another problem would be input. At a certain level, we humans seem to have the ability to process input sub/unconsciously, such as when something is so ordinary that you don't even take notice. But this only proves the idea that our ability to focus on input is limited. This can be easily observed anyway by trying to read a book with too much background noise. This matter of unconsciously filtering out unimportant input can be relegated to the bodies too in order to offset the load to the conscious brain, but...

The problem with all of this is that this is what our brains do anyway. They already offset these tasks to the sub/unconscious, which means that they only deal with what requires conscious attention for one body. So even by doing all of the above, the bottleneck would still appear to be one body. Beyond that number, we would have the same problems we already have with multitasking, only now the problem is even greater since we have multiple bodies. Simple things like deciding where to walk next would have to wait in queue while we tell a different body where to walk next. We would need to handle each task in rotation. This is actually exactly the function of an Operating System.

I think it would be too much of a stretch to introduce parallel processing to the conscious mind, as that would bring into question whether or not the individual really has one mind or several (actually, this could be an interesting philosophical direction to take your story if you wanted), so the only real solutions are either to increase the threshold for consciousness or to increase the processing power of the brain.

In the first case, your drone bodies would handle much more on their own. This means things that would have otherwise grabbed your attention will now escape your detection and your basal ganglias will just autopilot through them, for better or worse. An increased incidence of "brainfarts" will occur.

In the second case, the already massive processing power required to simulate a human mind in a single thread has to be increased further, leading to astronomical clock rates, which raises a whole new set of problems with computer engineering, including cooling (fast clock rates cause lots of heat; see this article) and relativity (light itself only travels 1 foot per nanosecond; the physical size of these processors will have to be tiny).

## Entirely plausible and this is a well understood problem

As of 2016, humanity has a long history of distributed computing. MMORPGs, Hadoop clusters, thin clients, and thick clients are all examples of where control of a distributed system system is spread across multiple locations then synthesized into a coherent whole. Sometimes this occurs on very long time frames such as days, sometimes it happens in millisecond long slices. Humans are getting very very good at this kind of problem. Working with brain meat as the computer adds additional complexity but doesn't change the fundamentals of distributed control.

## Thin Client Approach

If you have sufficient bandwidth to transmit back visual, audio, and tactile information back to the central brain, then that brain should be able to control all those bodies at the same time. This assumes that the central brain is a super brain capable of processing that much information and returning the appropriate instructions in a hard real-time way. Personally, I think that's a crazy way to run this because if you have any significant break in transmission, in either direction, something is going to fail and fail hard. You wouldn't want to have a transmission glitch that causes you to fall into your forge when the command to stop yourself as you walk up to the forge fails to arrive or arrives a 1/2 second too late.

Typically, a thin client approach is used when you have a single high powered, expensive brain and lots of cheap low power brains.

## Thick Client Approach

In contrast to the thin client where all processing happens at a central location, a thick client maintains a considerable amount of local processing power to maintain functionality. In this scenario, a thick client would maintain local visual, audio and tactile processing and go back to the central brain only for questions like "I've finished making the sword, what should I do now?". Short term planning of where to put the next hammer blow stays local.

Thick client architectures are used when there is no central brain and/or all the brains are roughly equal to each other in terms of processing/storage power.

## How thick should the client be?

It depends on a couple of things: - How powerful is the primary brain? Is it capable of synthesizing the sensory input and sending out commands to all the other brains? Is there a central brain at all or are all the brains equal peers? - How often do all the brains need to synchronize themselves? If it's every 1ms then that will have some severe limitations on how far apart the brains can be and the methods by which they can synchronize themselves. At 1 second intervals, synchronizing can happen over the open internet (though that's a security nightmare if one of your brains gets hacked). If it's every day, then a distributed version control system like Git would work perfectly.

## Why Git

Git is a distributed version control system. It is wildly popular because of its ability to maintain many separate versions of a data structure (usually text files) then efficiently merge changes back into a single cohesive document. In addition, it is very cheap to make "branches" from a base-line copy.

For example if you have document A and give it to persons X, Y and Z, Git will allow you to merge the changes made by X, Y and Z back into a single version of document A. How this magic is performed is both beyond the scope of this answer and plentifully documented else where. For our purposes, we will assume that Git is able to magically merge multiple competing versions of a data structure back into a single data structure.

## How it all goes together

Let's assume that the various bodies only need to fully synchronize their data sets once a day in a thick client model. If more timely information is needed, then they can push and pull data at will. This approach supports when the clients are working in close proximity to each other but also supports bulk data exchange when new data can wait.

1. Assume that there's a magical translator that takes human brain function and creates a high resolution simulacrum implemented in BrainLang (a computer language I just invented that executes on commodity x86 hardware as well as typical human brain matter. Yeah, it's indistinguishable from magic). This program will be known as MeOS. The combination of the executable code in MeOS and all the things this person knows are known as Me(TM).
2. In the thick client model, the current version of Me(TM) is distributed to the various bodies to be used that day.
3. Throughout the day, small update messages are sent between the various bodies.
4. At the end of the day, each body uploads its current data set and whatever new code they added to MeOS. (During the day, a person will pick up new capabilities or refinement to capabilities in addition to all the things they know.)
5. Git merges all the datasets and MeOS code together (this may take a while) to formulate a new Me(TM).
6. Next morning (or whenever) the new Me is uploaded to the various bodies and they go out to do their thing.

Since each version of the Me(TM) running right now is functionally identical to "You", you are in multiple places at the same time.

Have each version operate independently, and only send updates to the main consciousness when either:

A) That thread has run its course

B) Something completely unexpected and off-script occurs.


For example, the Jack at the reception is a thread of the main consciousness. He chit-chats with his wife, signs into the hotel, etc. - nothing special. Eventually that thread will merge back into the main consciousness and update it on what's been happening.

Another version of Jack meets with his mysterious associates. It's only a routine meeting, so Jack sends a thread in his stead. However, a snag happens. These guys reveal a major threat to your plans. Uh, oh! This thread instantly alerts Jack that something's wrong, and that the primary consciousness should get involved, which he then seamlessly does, quickly reviewing the meeting data and taking the thread over.

His blacksmithing operation can then be relegated to a thread or abandoned altogether.

In John Ringo's Council War series he explores a similar concept where the "Councilors" need to be in many places so they send out holographic Avatars to collect information and meet with people, and then "merge" the information back into their main consciousness when each Avatar returns.

There are several ways you could go about this, depending how autonomous you want the bodies to be. You'll probably be using distributed or parallel computing of some sort.

1. (a/b in the diagram) Bodies can think for themselves and share information as requested. Basically you have Jack clones with a telepathic connection. Each clone could request and receive information from every other one, but it would be done on demand. Each clone also thinks "independently", though using the same process as every other clone. This could potentially be the "simplest" solution as you don't have the input overload that occurs in other scenarios. This would also be the most optimum if there any significant delay between bodies. A disadvantage would be if any body was damaged, their memories would not be recoverable by the other bodies.

2. (c in the diagram) There is one centralized memory location, either JackPrime or a server box somewhere. In this solution, every body has access to the experiences of every other directly. However, each body processes the data independently. This is how most multi-processor machines work.

3. All (or most) processing is done by a centralized CPU. In this solution, the bodies act strictly as input/output devices (think computer terminals). This has the advantage of housing most of the hardware in a stationary location, leaving the bodies potentially more optimized for movement and interaction. Another advantage is that the "brain" doesn't have to expend resources on bodies that are idle. The disadvantage is that any telepathic delay means the bodies with have a delayed reaction to everything, as they can't "think" for themselves.