Three practical chokepoints give ordinary towns a near veto over large scale AI projects. Ben Thompson argues that because modern AI depends on compute heavy models running in data centres, the land use approvals, grid access and local permits required to build them hand real power to municipal and regional authorities. That diagnosis reframes local resistance and permitting delays as structural constraints on deployment, not merely communication failures. Read Ben Thompson’s extended Update and Parag Agarwal’s interview at Stratechery for the operational checklist that follows.
1. Why the Data Centre Veto matters
Data centre infrastructure is where advanced AI lives. Ben Thompson lays out a blunt premise: the capabilities that draw attention and anxiety are concentrated in compute heavy models that must be sited, permitted and physically connected to power and networks. Those aren't decisions made by distant regulators alone, they're decided at municipal and regional planning tables. The result is a practical veto. Local governments and ordinary citizens can block, delay or condition projects in ways that can't be solved by better PR or a national policy paper.
Thompson treats local backlash and permitting hurdles as a root cause of visible misinformation and public anxiety about AI, rather than as symptoms to be corrected. That's a different posture from the usual technology industry playbook. It means you can't simply explain your way out of opposition. The physical plant has to be approved first, and planning processes hand communities a real lever.
Worked example. Imagine a firm planning a training campus for large models. First, it must secure land use approvals. Second, it needs grid interconnection agreements. Third, it must pass environmental and construction permitting. Any one of those steps, if delayed or conditioned by local actors, changes the project timetable and economics. That sequence is the veto in practice.
2. Treat permitting as product strategy
Permitting and community engagement must move from compliance tickbox to central product and rollout strategy. Thompson lays out three practical moves for firms and investors. First, map the full dependency chain: identify where models will be trained or hosted, estimate the footprint required, and document the local regulatory pathways for siting, environmental review and grid interconnection. Second, treat community engagement and permitting strategy as part of your product timeline, not an afterthought.
Third, bake timeline uncertainty from local approvals into capacity planning and financial forecasts.
Put differently, don't assume a single approval path or timing. Local approvals can alter project economics and operational footprints. That changes how you think about capital allocation, lease terms and the sequencing of rollouts. Plan as if permitting could add months or years to deployment, because in many jurisdictions it will.
Scenario example. A developer models three scenarios. Scenario A assumes smooth approvals and full grid access, Scenario B assumes conditional approvals with mitigation obligations and staged occupancy, Scenario C assumes major local opposition leading to relocation or cancellation. Financial forecasts must show the impact of moving between these scenarios, including stranded capital in the worst case. That's the only honest way to price permitting risk into investor returns.
3. Agent economics and where demand will land
Agent economics changes who consumes content and what infrastructure they need. Stratechery pairs Thompson’s permitting analysis with a conversation with Parag Agarwal about the economics of an agentic web. Agarwal, the former chief executive of Twitter and now focused at Parallel, argues that incentives which sustained human attention based ad markets don't map cleanly to a world where autonomous agents request and consume content on behalf of users.
Point is, the operational implication is simple. Demand side forecasting should include not only human users but projected agent driven compute and bandwidth loads. If agents generate high volumes of automated queries, that will change where value accrues on the network. Parallel’s emphasis, as discussed on Stratechery, points to a strategic shift in how content and services may be monetised and routed. If monetisation moves toward subscription models, payment for API access or agent specific micropayments, revenue linked to particular geographies and facilities will shift too.
Technical divergence matters here. Thompson contrasts different engineering strategies inside the AI field. He highlights DeepMind’s approach as distinct from the paths pursued by OpenAI and Anthropic. The practical takeaway is that compute needs won't be uniform across research and product tracks. Some architectures demand bursts of very high intensity training compute. Others favour lower steady state usage for inference at the edge. Siting decisions, energy planning and network topology should therefore be sensitive to which technical approaches your organisation uses or expects to use.
Short scenario. A service that relies on agent traffic for automated travel bookings may favour regional, low latency inference nodes close to payment processors and local content caches. A research lab doing large scale reinforcement learning may need large contiguous training campuses with very high density power. Treat both as distinct classes of physical planning, not interchangeable loads.
4. Policy engagement and an operational checklist
Two track policy engagement is what Thompson recommends. Track one is local. Build community facing strategies that directly address land use concerns, environmental impacts, job creation promises and visible benefits. Track two is systemic. Engage grid planners, regional transmission operators and national regulators to align long range capacity and permitting frameworks with predictable demand. National AI governance or centralised rhetoric can't substitute for local approvals and infrastructure coordination.
Here is a pragmatic sequence of actions drawn from Thompson’s framing, designed to be operational for teams that will site or host AI infrastructure. Each step must be done in order, because later steps depend on earlier conclusions.
1. Due diligence. Produce a political regulatory map for each candidate site, paired with technical workload profiles that identify peak power, sustained power and network latency requirements. Identify the specific municipal departments and approvals required.
2. Scenario modelling. Couple different agent economics outcomes with permitting timelines. Model revenue and operational outcomes if agent demand materialises, and compare that to slower human only adoption patterns.
3. Community engagement.
Design a public programme that ties technical mitigations to visible benefits. Offer tangible local outcomes such as workforce training plans, local procurement commitments or environmental monitoring that maps to community concerns.
4. Energy and connectivity planning. Align with grid operators early. Secure provisional interconnection studies, and understand the timeline and cost for upgrades to substations and transmission. Factor those timelines into your financial model.
5. Technology portfolio flexibility. Maintain options to shift compute loads between different architectures as research paths evolve. That could mean running initial inference workloads on regional nodes while reserving flexible training capacity in modular facilities.
Worked checklist example. A mid sized cloud customer might: first map three candidate regions, second secure preliminary interconnection studies for each, third run two demand scenarios that include agent traffic, fourth present a community benefits package to the local authority tied to staged job creation targets, and fifth build contracts with modular data centre providers to allow quick scaling or pausing according to permitting outcomes.
Andrew Sharp’s highlights at Stratechery point readers to the recurring themes and to Thompson’s interview subjects. Those summaries are useful because they show how these operational steps map to real conversations with the people running and evaluating infrastructure in 2026.
1. Municipal and regional approvals control the physical pace of AI deployment, and they act as a practical veto.
2. Treat permitting and community engagement as central to product strategy, not downstream compliance.
3. Factor agent driven demand into capacity planning, because monetisation and query patterns will shift where value and load concentrate.
4. Use a two track policy approach: local community programmes and systemic engagement with grid and transmission authorities.
These aren't abstract suggestions. Thompson’s package for the week pairs a structural diagnosis with precise operational steps, and Parag Agarwal’s work at Parallel offers a model for how agent economics will rewire incentives on the internet. Together they move the conversation from theory to an actionable plan for teams that must site facilities and forecast demand.
Related Articles
- Free 32-inch Samsung Odyssey monitor returns, how to qualify
- How to tell if an image is AI-made: 6 practical checks
- 3 upgrades to make a Weber or Kamado Joe smart
If you need one next step, read Ben Thompson’s Update on data centre discontent and Parag Agarwal’s Stratechery interview on agent economics. Their reading is simple and practical: local permitting is the effective chokepoint for large-scale AI; agent-driven traffic and differing technical approaches will reshape where demand, value and infrastructure land.
This article was created with AI assistance.