Who Has Enough Power to Say No?
Who has enough power to say no when AI, compute, energy, and autonomy become infrastructure?
Published September 7, 2026 · 13:13
View the original production thumbnail
Chapters from the published video
- Who stops it — and do we want them to? ↗
- Dependencies become infrastructure ↗
- Pulling dependencies inside ↗
- Every dependency is also a veto ↗
- When the regulator is inside the stack ↗
- Competition as a veto ↗
- Cybercab shows up before the argument finishes ↗
- You cannot vertically integrate consent ↗
- Both things are true ↗
- Which vetoes can we afford to eliminate? ↗
- Door to 006 — when work winds down ↗
Full transcript.
Recording-derived automatic transcript. Original wording and transcription errors are preserved.
Transcript integrity
3e9b25b6cda01c8f3dd8c0f4bfcb34e67eb1a4b87484e38353d4a90deb8f2e1bSHA-256 of the downloadable source artifact. Text is never silently corrected or rewritten.
Read the full transcript
Welcome. I think it's time to question everything. Welcome back. You know, I ended the last memo with a question. Who stops it and ultimately do we even really want it to be stopped? And I've been thinking about that question all week because my first reaction is I don't think we do. I think we have to keep moving and that's where this gets complicated because there's this idea that somewhere above all, there's this somebody in charge, some regulator, some government agency, some big daddy, somewhere that's eventually gonna step in and say, nope, that's enough, you can't do that. And the more I looked at it, the less convinced I became that person actually exists or maybe more importantly, the less convinced I became that we actually want them to because we kinda need this stuff. Look at where we are right now. AI, compute, energy, semiconductor, space, communications, autonomous vehicles, robots, these aren't little consumer products anymore. They're all capabilities and capabilities become infrastructure. And when something becomes infrastructure, the relationship changes. We talk all the time about wanting semiconductor manufacturing here in the United States. Why? Because look at Taiwan. We've got an enormous amount of semiconductor capability concentrated on a relatively small island sitting in the middle of one of the biggest geopolitical tensions on Earth. So of course, we want chips here. Of course, we want compute here. Of course, we want energy here and of course, we want launch capability here because dependencies are vulnerabilities. That's not controversial. If there's something your entire country needs and somebody else can turn it off, that's a fucking problem. You start bringing those dependencies inside. You build the chip, you build the data center, you build the energy, you build the rocket, you build the network, you build the software and that's basically what we're looking at in the last memo, the yarn. All those companies, all those connections. One capability solving the bottleneck of another capability and every time you remove one dependency, the system gets stronger, it gets faster. It gets harder to interrupt, it can move and when you're competing against another country that's trying to do the exact same thing, that's important because history has been full of races like this. Space races, technology races, industrial races, military races, and usually the country that reaches the capability first gets an enormous advantage. So what are we supposed to do? Slow down, tell our companies, they're becoming too capable. Tell them not to vertically integrate because it makes us uncomfortable. Meanwhile, somebody else keeps going. That's not a very satisfying answer either and that's why I started this memo thinking, no, I don't think we want to stop it. I think we need to keep moving. I also started thinking about what we're actually removing when we remove a dependency because every dependency is a vulnerability because every dependency is also potentially a place where somebody can say no. Think about that. A supplier can say no, a competitor can force you to behave differently, a regulator can say no, a customer can say no, a government can say no, a community can say no, the electrical grid can effectively say no, the physical world can say no, and suddenly the thing I was calling a dependency might also have been a veto. And some vetoes are probably stupid, some are outdated and some exist because the rules were written for a world that doesn't exist anymore. Some people do nothing except slow the train down, fine. Get rid of them, but some of them. Some of them might be the only reason nobody controls the entire train. That's where the question changed for me. It stopped being who stops it and became who's left that can say no. And this keeps even a little stranger when the regulator becomes the customer. That's the one that really keeps bothering you. What happens when the government is supposed to regulate a capability while simultaneously depending on that same capability? Defense needs AI, defense needs crowd-cloud infrastructure, government needs launch capability, government needs communications, semiconductors, and cybersecurity, at what point does the relationship change? Because it's one thing to regulate somebody selling an optional product. It's another thing entirely when the thing you're regulating is part of how you function. Now you're not standing outside the system looking in, you're in the stack. And we've watched versions of this tension play out already. Government wants powerful AI. Government also wants control over powerful AI. Government wants companies that can compete globally. Government also worries those companies are becoming too powerful. Government wants domestic infrastructure. Government also has to regulate the company's building that infrastructure. These aren't necessarily contradictions because everybody involved is stupid. They're contradictions because the bridge itself is complicated. We want these systems strong enough that nobody else can beat them, but apparently not so strong that we can't control them. Okay, where exactly is that line? Because I sure as hell haven't figured it out. And I'm not convinced anybody else has either. And then there's another check on power that I think gets ignored in this whole conversation, competition. What if the thing that stops one powerful system is another powerful system? I mean, you can see that argument starting to form in autonomous vehicles. Different companies are solving the problems in completely different ways. Different sensors, different software, different assumptions, different philosophies about what safety even means. And that's important because it means there's still another answer. There's still somebody standing there saying, no, we think your way is wrong. Here's ours, and that's a VDO too. Not a government VDO, a market VDO, a technological VDO, a competing idea. And maybe sometimes that's actually more effective than regulation because a regulator can tell you what you can't do. A competitor can prove that there was a better way to do it. And that is completely different, which brings me to the cyber cap. And I know I really don't want every one of these memos to somehow end up talking about Elon Musk, but it's almost impossible to talk about this particular transition without him showing up somewhere in the middle of it. Because just think about the idea for a second. Not that long ago, somebody standing on a stage says, we're going to build a car with no steering wheel, no pedals, you're going to get in and tell it where you want to go, and the car's just going to take you there. That's it. You don't drive if you're just a passenger. And when somebody first says that, it's easy to treat it like another presentation, another future thing, another promise. And then one day, the thing exists. There it is, a physical object on a road moving through the world. And that moment is fascinating to me because the technology can cross a bridge incredibly fast. The rest of society doesn't, the laws don't, insurance doesn't, cities don't, workers don't, regulators don't, people don't. The machine can show up before we've even finished arguing about whether the machine should be allowed to show up. And then everybody starts asking their own version of the same question. The regulator asks, what rules apply to this thing? The city asks, where can it operate? The passenger asks, do I trust it? The competing company asks, is this actually safer than what we're doing? And the person driving Uber asks, what the hell am I supposed to do now? And there it is again, the bridge. Because while we're sitting here debating whether somebody should stop the technology, somebody else is standing on the bridge that the thing is replacing. That's a much bigger conversation. And I'm not gonna open that whole thing today. But remember that because we are definitely coming back to that one. There's another part of this that I didn't appreciate until recently. A company can eliminate a lot of dependencies. It cannot eliminate all of them. You can own the software. You can own the compute. You can own the data center. Maybe you can make your own chips. Maybe you can generate some of your own electricity. Maybe you can build a network. Maybe you can build a vehicle. Maybe you own the platform, people interact with. And you can keep pulling things inside, but eventually something touches the real world. Land, water, electricity, communities, permits, roads, airspace, people. In the physical world doesn't care how vertically integrated your company is. You still have to land somewhere. You still have to plug into something. And you still have to exist around human beings. And we've started seeing tension around that too. Data centers need enormous amounts of power. Communities have their own concerns. States have their own concerns. Grid operators have their own concerns. Nationally, we might say we need more AI infrastructure. Locally, somebody might say cool. Who's paying for that electricity? Who's using the water? Where are you building it? What happens to us? That's not necessarily anti-technology. That's a different level of the system exercising veto. You can vertically integrate almost everything. You cannot vertically integrate consent. And maybe that's one of the most important remaining pieces of yarn on the board. Which is why I don't think the answer to this memo is stop the companies. I also don't think the answer is to let them do whatever the hell they want. Those are easy answers. And easy answers are usually where I start getting suspicious. Because this is simultaneously true. We need the capabilities and this is also true. Concentrating capabilities concentrates power. And then removing dependencies make systems more resilient. Some dependencies are checks on power. All of those things can be true at the same time. That's the uncomfortable part. We're worried these companies are becoming too powerful at the exact same moment our government worries that they might not be powerful enough. Think about that. We want American companies capable of competing with the entire, with the entire countries. And then we're surprised when those companies start looking a little bit like countries themselves. That's a weird place to be. So I don't think I'm asking anymore who stops it. I'm asking something slightly different. Which independent vetoes can we afford to eliminate? And which ones do we absolutely need to keep? Competition is important. Government oversight, probably important. Local control sometimes, probably incredibly important. Independent suppliers, maybe open systems, maybe the customer's ability to leave? Absolutely. Because once nobody can say no, you've built something different. That's no longer just efficiency, that's control. But if everybody can say no, nothing gets built. That's the bridge. That's the tension. How do you build systems powerful enough to get us where we're going without removing every hand capable of pulling the emergency brake? I don't know the answer. And maybe that's the point of this one. Because I came into this thinking who stops it? Probably nobody. And maybe that's OK. Now I'm thinking somebody probably should be able to. I just don't know who. There's one more problem. Let's say we get this right. Let's say we don't stop it. Let's say AI gets better, the robots get better, transportation gets cheaper. All of this stuff comes to fruition. Everything scales out. Energy gets cheaper, manufacturing gets cheaper. And all of these vertically integrated systems actually work. They scale, they remove the friction, they remove the costs, they remove the dependencies. They do exactly what we're asking them to do. Then what? Because every time we remove one of those bridges, there's usually somebody standing on it. And eventually we're going to have to talk about what happens when there aren't that many bridges left. What happens to work? What happens to the price of things? What happens to the value of human labor? And maybe the bigger question, what the hell do we do with ourselves when the system doesn't need nearly as much from us? I don't know where this bridge ends, but I think it's worth finding out. Goodbye.
The need.
The mechanism.
What comes next.
An editorial reading guide to the original recording.
- Human need
- Capability, accountability, and a say in what changes our lives.
- Current solution
- Independent institutions and suppliers can slow or stop a system.
- The bridge
- Vertical integration brings more of those dependencies inside one organization.
- Better / next solution
- Which checks must remain independent as capability becomes infrastructure?
Sources & evidence.
- Original public video and publication metadata ↗
Primary publication record.
How this became
a Memo.
The public artifacts behind the finished record. Private drafts and conversations stay private.
- published video
Published on unZappedTV
Public video verified on the unZappedTV channel. Publication timestamp is from the publishing receipt.
VIEW PUBLICATION ↗ - transcript
The recorded words
Recording-derived transcript from the publishing package. Automatic transcription is preserved, including its errors; it is not a corrected script.
VIEW ARTIFACT ↗SHA-256 · verify this artifact
3e9b25b6cda01c8f3dd8c0f4bfcb34e67eb1a4b87484e38353d4a90deb8f2e1bThis checksum identifies these exact bytes. A source timestamp alone does not independently prove when an artifact first existed.
- thumbnail
The release image
Original production thumbnail, retained without alteration.
VIEW ARTIFACT ↗SHA-256 · verify this artifact
7a885a072636026a620d09c5401d23935b1a60779150819e6985823758f13e7dThis checksum identifies these exact bytes. A source timestamp alone does not independently prove when an artifact first existed.
What happened next.
No later updates have been added to this Memo.
If the world changes the answer, we’ll add a dated entry here. The original record will stay.
