Bain: rent the model, own the orchestration layer

Decision 4 in Bain's How to Win with AI series, Technology Architecture, opens by demoting the question every AI program starts with: "the most important technology decision you will make in your AI transformation is not which model to use." Models rotate too fast to be a foundation, "models are changing so rapidly that any specific choice will be obsolete within months," so the durable decision is what you build around them. Bain's answer is the enterprise orchestration layer: the place where a company manages its agents, its encoded know-how, and their access to data and systems as a single, governed enterprise asset. Owning it is "the technology equivalent of owning your supply chain." These are my notes on it.

Rent the engine, own the vehicle

Most of the AI stack can and should be bought, the piece says; advantage concentrates in three places you cannot outsource. Where your operational know-how gets encoded into skills, tools, and agents. Where access boundaries are controlled, the seam at which agents touch systems and data. And where governance discipline lives as the agent estate grows. The memorable compression is automotive: "the model is the engine, but the harness is the vehicle." You rent the engine from whichever frontier lab is ahead this quarter and swap it freely, precisely because everything that makes it useful and safe, the harness, the registries, the vocabulary, the permissions, is yours.

Put simply: buy most of the stack, swap models freely, and own three things without exception: the encoded know-how, the access boundaries, and the governance. The model is the engine; the harness you build around it is the vehicle.

Agents break the old governance assumptions

The middle of the piece explains why this layer needs building at all: agentic systems violate the three assumptions enterprise software governance was built on. Agents are probabilistic rather than deterministic, the same input can produce different outputs depending on context, memory, and model state. They are stateful, carrying memory and reasoning across interactions. And they are continuous, acting toward goals rather than returning and stopping. The consequence lands in five words: "traditional software fails safely; agents don't." A wrong answer does not sit in a log waiting to be noticed; it becomes an action, and in multi-agent chains it becomes several, which is why the piece calls cascade risk "among the most underappreciated challenges in enterprise AI."

Put simply: agents are probabilistic, stateful, and continuous, and they do not fail safely. Governance built for deterministic, stateless, discrete software will not notice an agent going wrong until several downstream actions have already happened.

Evals are the job, and you cannot govern what you cannot list

The operational core is a management discipline the piece calls treating agents, tools, and skills as first-class assets: codified, registered, versioned, and tested, "rather than buried in prompts." Three mechanisms do the governing: registries recording every agent, tool, and skill with its purpose, owner, and permissions; a governed gateway that every tool call routes through, for policy, telemetry, and audit; and promotion gates, automated checks between development and production, backed by golden test suites and shadow-mode runs. The test the piece offers is blunt: "if you cannot inventory it, you cannot govern it." And the effort math inverts the usual instinct: "building the agent is roughly 20% of the work; evals are 60%; ongoing monitoring is the remaining 20%," and the monitoring never stops.

Put simply: register everything, route every tool call through one gateway, and gate promotion on evals. Budget honestly: the build is a fifth of the work, evals are three-fifths, and monitoring is the fifth that never ends.

The obsolescence rebuttal, and what you keep

The obvious objection is that building in a field moving this fast means building things that will be thrown away, and the piece's answer is its best strategic point: yes, the code is disposable, and it does not matter. AI-native development, agents generating the code, tests, and documentation while engineers set architecture and direction, makes rebuilding cheap, "achieving five to ten times the productivity of traditional development." What survives the rewrites is everything the building created: the semantic layer, the registries, the encoded workflows, the engineering capability, and the operational learning. "The tech is what you ship today; the proprietary intelligence is what you keep." Ramp's Glass reprises as the worked example, the internal layer built on the conviction that internal productivity is a moat you do not hand to a vendor. It is the same sequencing this site keeps arriving at: the governed layer, the warehouse between the AI and your systems, and the fit you own around a model you rent, built before the agents and kept after them.

Put simply: build even though the code is disposable, because rebuild costs are collapsing and the durable assets, semantic layer, registries, capability, learning, survive every rewrite. Rent the model. Keep the intelligence.