ai infra · dispatch 001

What Enterprise Revenue Systems Teach Us About AI Ecosystem Architecture

The AI infrastructure stack in 2026 looks to me a lot like enterprise software did in 1998. Providers are fragmenting faster than anyone can integrate them. Every product team is hard-coding vendor logic into clients that will need rewriting in six months. Observability is bolted on. Audit trails are an afterthought. Agents and humans are managed by separate, inconsistent tooling.

I've been building in this space for some time now, most recently a portfolio project called Switchmaxxer (a local-first LLM gateway), and the more time I spend in it, the more I'm convinced we're rediscovering lessons that enterprise revenue systems learned the hard way over the past thirty years. Salesforce, Zuora, NetSuite, SAP, Stripe, and the CPQ and billing tools that grew up alongside them solved problems of scale, trust, and interoperability long before AI was a category. Their patterns are now invisible because they won.

Architects who recognize those patterns will build the durable layer of the AI ecosystem. Architects who don't will rebuild Salesforce circa 2003, albeit badly. Here are five lessons worth carrying forward.

1. The system of record wins

Revenue platforms became gravitational by owning canonical data. Once your Accounts & Opportunities lived in Salesforce, every other tool in your stack had to negotiate with it. Once your CPQ, billing, and accounting systems are integrated then everything else will be forced to align. The system of record wasn't the smartest piece of software in the company; it was the one everything else deferred to.

The AI equivalent isn't the model. Models are interchangeable and getting more commodified every day. The canonical record that matters is the layer beneath them: routes, policies, observability traces, benchmark history, audit logs. Whoever owns that layer becomes the gravitational center of an AI deployment, in the same way Salesforce became the center of revenue operations. The right architectural question isn't "which model should we use?" It's "where does the canonical record of model behavior live, and who controls it?"

2. Protocols beat platforms

Revenue stacks didn't succeed because one vendor won. They succeeded because the industry standardized on objects and APIs. Standard business objects like Account, Contact, Opportunity, Order, Subscription, and Invoice let the ecosystem stay heterogeneous. Integration was the product.

AI is converging on the same kind of primitives. OpenAI-compatible and Anthropic-compatible API shapes are becoming de facto contracts across the industry. MCP is doing for agent control what webhooks did for event-driven integration. Tool-call schemas are the new canonical objects.

The practical consequence: translation belongs in infrastructure, not in clients. A gateway that speaks both OpenAI and Anthropic dialects on a single port, letting operators swap upstream providers without touching application code, is a small instance of the pattern, but the pattern is the point. Every team currently writing provider-specific branches into their client SDKs is building technical debt that the next architectural generation will refactor away.

3. Auditability is substrate, not a feature

Revenue systems handle money, which means mistakes are immediately visible and legally consequential. SOX-grade traceability didn't get bolted onto these platforms after the fact. It shaped their data models from the beginning. Every mutation has an actor, a timestamp, a before-state, and a recovery path.

AI systems are headed for the same constraint, faster than most teams realize. The moment an agent starts taking real actions on behalf of a user the audit question stops being theoretical. Who did these routing requests? When did we apply optimizations? How did the configuration mutate? Who changed this route? Why does this benchmark exist? Can we restore the previous policy if the new one regresses?

Architectures that treat audit as substrate (immutable ledgers, mutation event tracking, snapshots, restore paths) will be the ones enterprises actually deploy. Architectures that treat it as a logging concern will get filtered out at the procurement stage.

4. Two operators, one control plane

Here's where the revenue-systems analogy ends and AI architecture has to invent something genuinely new.

Revenue systems were designed for human operators, with scheduled jobs and integrations as background helpers. The humans drove; everything else followed. AI systems have a constraint that older enterprise software never faced: agents are first-class operators, not just consumers. They need to read state, mutate configuration, run benchmarks, apply optimizations, and roll back changes through interfaces that are as legitimate and as auditable as anything a human does.

The architectural pattern that works is symmetry: humans and agents drive the same control plane through aligned contracts. A CLI for the human hand, an MCP surface for the agent. Same state, same mutations, same audit ledger underneath. This is the bet I'm making with my own work, and I think it's the architectural primitive the next decade of AI infrastructure gets built on. Tools that maintain this symmetry will scale into agentic deployments. Tools that bolt agent interfaces on top of human-only systems will fracture under the weight of inconsistent state.

5. Workflow is the moat

CPQ tools and billing platforms didn't win on raw computational capability. They won by encoding domain workflows that competitors couldn't shortcut: quote approvals, revenue recognition rules, dunning logic, tax jurisdictions. The workflow was the product.

Model quality is plateauing. The durable moat in AI infrastructure is orchestration: routing logic, benchmark runtimes, cost and latency optimization, retention policy, recovery paths. The ecosystem layer will be won by tools that treat these as first-class control-plane concerns rather than features tacked onto a chat completion endpoint. Every one of these surfaces, looked at closely, is a workflow problem dressed up as an infrastructure problem.

Build the boring parts well

The AI infrastructure layer doesn't need reinvention from scratch. It needs architects who've internalized what enterprise software already figured out, and who can extend those lessons where AI introduces genuinely new constraints, like the operator/agent symmetry problem.

The winners in this layer will look unglamorous from the outside. Gateways. Ledgers. Route catalogs. Observability stores. Snapshot and restore. Exactly the shape of what revenue systems eventually became, and exactly the kind of infrastructure that becomes load-bearing once a category matures.

That's the layer I'm building toward. More on that soon.