Every few years, the computing industry rediscovers a fight it had in the 1970s. Mainframes versus PCs. Thin clients versus workstations. Browser apps versus native. SaaS versus on-prem. Now it's cloud agents versus local agents. Jensen Huang's AI factories on one side, OpenClaw and the local-first developer crowd on the other. Apple holding a hardware-centric line, Perplexity reaching for the agent-as-OS bet.

I've watched this pattern recur across three decades of enterprise software, mostly from inside revenue systems: quoting, billing, contracts. These are the places where architectural decisions show up as line items on someone's invoice. And I want to argue something that will sound contrarian to both camps: the cloud-versus-local framing is the wrong axis. It was wrong in 1998, and it's wrong now. The interesting question isn't where computation runs. It's who controls the contract between the parts.

The pattern, briefly

Each cycle of this debate has the same shape. Compute is scarce, so it centralizes. Users get tired of the friction, so it personalizes. Networks improve, so it recentralizes. But there is always a different vendor with a different abstraction so the pattern shifts around but never disappears. The thin client comes back wearing better clothes. The PC era turned into the SaaS era turned into the cloud era turned into whatever era this is.

What's different about agents isn't the location debate. The location debate is the boring part. What's different is that agents act under delegated authority. They don't just fetch data or render UI. They send emails, modify configurations, invoke tools, move money. Software stopped being a thing the user operates and became a thing that operates for the user.

That changes the architectural question entirely. The old question was: where does this code execute? The new question is: who governs what this agent is allowed to do, on whose behalf, with what audit trail, with what reversibility?

The revenue-systems reframe

Here's where my background pushes me toward a different conclusion than most people writing about this.

Enterprise revenue systems (Salesforce, NetSuite, the CPQ and billing tools that grew up around them) solved a version of this problem in the 1990s and 2000s. They weren't debating "should the customer record live on a local machine or a remote server." That was a deployment detail. The actual fight was over who owns the canonical contract between systems: which fields are authoritative, who can mutate them, what gets audited, what gets reversed, what gets recognized as revenue.

The systems that won didn't win on local-versus-cloud. They won by making themselves the system of record: the constitutional layer underneath whatever interface the user happened to be touching that day. Sales reps used the desktop client; finance used the API; partners used the portal; jobs ran in the background. Same canonical record underneath. Same audit ledger. Same reversibility guarantees.

That's the pattern AI architecture is groping toward, and most of the cloud-vs-local discourse is missing it.

The actual architecture question

The real question isn't where the agent runs. It's whether the system maintains a coherent, auditable, reversible control plane regardless of where any individual computation happens.

A few concrete consequences of taking this seriously:

Memory is the new system of record. Whoever owns agent memory (the long-running personal context, the route catalog, the policy decisions, the mutation history, etc.) owns the gravitational center. Cloud or local is downstream of that. A cloud agent with portable, exportable, user-controlled memory is more sovereign than a local agent whose memory format is undocumented and tied to one runtime.

Operator symmetry is the new constitutional bet. Revenue systems were built for human operators with scheduled jobs as background helpers. AI infrastructure has a genuinely new constraint: agents are first-class operators, not just consumers. The architectures that maintain symmetry between human and agent control planes (same state, same mutations, same audit ledger, accessed through aligned contracts) will scale into agentic deployments. The architectures that bolt agent interfaces on top of human-only systems will fracture.

This is the bet I'm making with my own portfolio work, a local-first LLM gateway called Switchmaxxer. Not because local is virtuous (it always depends on the use case) but because building operator/agent symmetry is hard enough without also fighting a vendor's cloud lock-in. Local-first is a forcing function for getting the contracts right. Once they're right, the cloud/local question becomes a deployment decision, not an architectural one.

Auditability is substrate, not feature. Revenue systems learned this through SOX. AI systems will learn it through the first major agent-action incident that ends up in court. Mutation events, snapshots, restore paths, provenance for every routing decision: these need to be in the data model from day one, not added later. Architectures that treat audit logs as a compliance afterthought will get filtered out at procurement the moment any of this touches regulated industries.

What this means for the next architectural generation

The cloud-versus-local framing tells you to pick a side. That's exactly the wrong move. Both sides will be wrong about specific deployment choices five years from now, and both sides are right about specific deployment choices today. Hardware costs, model capability, latency requirements, regulatory constraints, and user expectations are all moving fast enough that any architecture optimized for one pole will be misaligned with reality before it ships.

The architectures that survive will be the ones that treat cloud-versus-local as a runtime policy decision sitting on top of a stable control plane and not as the fundamental architectural choice. They'll own the canonical record of agent behavior. They'll maintain operator symmetry between humans and agents. They'll bake auditability into the substrate. And they'll let the cloud/local boundary be tunable based on the actual constraints of the deployment, not the philosophical preferences of the architect.

That's the real fight. Not where the computation runs, but who owns the contract underneath.

More on the contract layer soon.