Livewired Technology Design
Build systems that reconfigure around damage, change, and new goals
- Difficulty
- Expert
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 94%
Livewired Technology Design replaces a fixed hardware layer plus static software with a system that continually learns how to operate the body and environment it actually has. The designer supplies durable motivations or goals, feedback on progress, and room for control strategies to reconfigure. Instead of requiring an explicit contingency for every failure, the machine explores alternative ways to reach food, movement, communication, or another objective. Eagleman's contrast is a Mars rover immobilized by one wheel versus a wolf that loses a leg and learns to walk on three. The intended output is technology that becomes more capable with experience, survives unanticipated damage, and adapts to conditions outside a discrete rule-based training set.
Origin
Eagleman extends his livewired brain model into technology, proposing devices and robots that continually reconfigure rather than becoming obsolete from the day they leave the factory.
Core principles
- 01A fixed hardware-plus-software design becomes obsolete
- 02Biological systems learn the body they actually have
- 03Goals can guide reconfiguration when components fail
- 04Real-world flexibility requires learning beyond pre-programmed cases
- 05A system should improve through experience rather than only receive replacements
How to run it
- 1
Set durable motivations
Define the outcomes the system should continue pursuing even when its components or surroundings change. Keep these goals separate from one fixed method of achieving them.
Pro tip Use feedback that measures progress in the environment.
Watch out A narrow proxy can drive adaptation in the wrong direction.
- 2
Expose the actual body
Let the system learn the capabilities and limits of its present hardware rather than assuming a permanently correct body model. Include variation during training.
Pro tip Treat component condition as an input to learning.
Watch out A perfectly simulated body can hide real-world constraints.
- 3
Permit reconfiguration
Allow the control policy to discover new coordination patterns when the old ones fail. Avoid hard-coding every acceptable movement sequence.
Watch out Safety boundaries still need explicit enforcement.
- 4
Introduce unplanned disruption
Test changed terrain, degraded sensors, or failed components that were not represented as one memorized case. Observe whether the system searches for another route to its goal.
Pro tip Test graceful degradation before catastrophic failure.
Watch out Success on a discrete benchmark does not prove real-world adaptability.
- 5
Retain useful adaptation
Preserve strategies that restore performance and continue updating as conditions evolve. Evaluate whether the system improves rather than merely survives one test.
Pro tip Measure recovery time across repeated disruptions.
In the wild
Eagleman describes a Mars rover becoming immobilized after a wheel gets stuck, then contrasts it with a wolf that chews off a trapped leg and figures out how to walk on three legs in pursuit of food, water, and its pack.
→ The contrast shows the value of goal-driven reconfiguration over a fixed body-control program.
Illustrative example: a warehouse robot loses one wheel motor but retains a goal of reaching a safe service bay. Rather than stopping at an unrecognized fault, it tests slower asymmetric movements and adopts the pattern that restores progress within safety limits.
→ The robot degrades gracefully and reaches maintenance without a pre-programmed response to that exact failure.
Common mistakes
Confusing adaptation with a lookup table
A catalog of programmed contingencies remains brittle when the real world produces an unseen case.
Optimizing only a bounded game
Exceptional performance in a discrete rule-based task does not demonstrate flexible behavior in an open environment.
Removing safety constraints
Reconfiguration should change methods within enforced boundaries, not grant unlimited behavior.
Is it for you?
Best for
It is best for robotics and long-lived autonomous systems operating in changing, inaccessible environments.
Not ideal for
It is not ideal for simple, tightly constrained devices where fixed behavior is safer and cheaper.
From the transcript
“What if you could build something like a brain that is constantly reconfiguring and learning and getting better with time?”
“The wolf choose its leg off and then figures out how to walk on three legs.”
“That's the kind of thing we need to do if we want it to be flexible and, and live wired.”
From the episode
David Eagleman: What Neuroscience Reveals About Your Brain and Human Nature
David Eagleman