Governed Growth, Part 4: Multi-Model, Governed, and Boring

Here is a scene that only happens in a cloud estate that got this right. A new team walks up and asks for Claude with web search, in production, this quarter. The architect doesn’t schedule a review. She opens a spreadsheet, reads three cells—which deployment tier the model runs on, whether the partner-feature toggle is set at the folder, which contract covers the search data path—and says yes before lunch. Nothing about that answer was brave. It was a lookup.

That is where this series has been heading the whole time, and it’s the least dramatic destination imaginable. Part 1 argued that a capability’s trust boundary is a separate decision from the model’s. Part 2 made that concrete with the sharpest example—the retention terms that just shifted under everyone. The default Gemini search path keeps short-lived debug logs, not your prompts and output, with a zero-retention alternative you can opt into, whether or not anyone decided that. Part 3 turned the argument into a runbook: the org-policy toggles, at the right scope, that make the safe answer the default. This post is what all of that adds up to. Not a new mechanism. A new posture—the one where governance has stopped being the thing that slows expansion down and become the thing that lets it happen.

The word for that end-state is boring, and I mean it as the highest praise.

The Good Kind of Boring

Boring gets a bad reputation it doesn’t deserve. In a running system, boring is what competence looks like from the outside. The pager doesn’t go off. The audit finds what the diagram said it would find. A capability arrives switched off, and when someone switches it on, their name is on the change. No surprises is not the absence of ambition; it’s the presence of decisions that were made on purpose, in advance, and written down.

The opposite of this boring is not excitement. It’s the 2 a.m. incident where a server-side search fired against a data path nobody chose, in a model nobody audited for that capability, under contract terms nobody read. That is exciting, in the way a house fire is exciting. The whole series has been an argument for trading that excitement away.

So the question this post answers is: what is actually true of a cloud estate where the trade is complete? Three things, and they map exactly onto the three foundations the earlier parts laid down. Every server-side capability sits on a deployment tier you chose on purpose. Every capability is gated by a toggle you set on purpose. And every capability is bound by a contract you signed on purpose. Three registers—tier, toggle, contract—and when all three are on record, saying yes to the next team is safe by construction.

First Register: The Tier Is a Decision on Record

Start with the piece most estates never make explicit. When you enable a model, you’re also—silently—choosing how it runs, and that choice decides how much of its governance you actually own. Google Cloud’s Model Garden on the Gemini Enterprise Agent Platform offers models in four distinct deployment tiers, and the tier is not a performance detail. It’s the first governance decision, and a mature estate knows which tier every one of its models is on. The specific models named in each tier below are current as of this writing and will change as the catalog grows—what stays fixed is the four-tier taxonomy and which governance lever each tier hands you.

• Managed-partner, enable-to-access. Claude, Grok, and Mistral. You toggle them on; Google runs the endpoint. You don’t manage infrastructure, and you cannot reach into the endpoint to disable a server-side tool—so your governance lever is org policy, not the box.
• Dual-mode. Llama and Google’s own Gemma. Available both as a managed API and as something you self-deploy. You pick per deployment, and each pick has a different data path.
• Self-deploy, bring-your-own-weights. Open models deployed into your own project and VPC, giving you—Google’s own phrase, from its open-model serving guidance—“complete control over the data path.” The least reliance on policy, the most direct control.
• First-party. Gemini itself, running inside the same trust boundary you already accepted when you chose the platform.

The elegant part is that the platform encodes this taxonomy into the very constraint you govern with. The vertexai.allowedModels org-policy constraint gates model actions, and its three actions are predict, deploy, and tune. Read them again: predict is the managed-API path, deploy is the self-deployed path. The policy language itself distinguishes enable-to-access from bring-your-own-weights. So when you write an allow-list, each entry records its tier in the action suffix—

1
# The suffix is the tier: :predict is a managed API you gate but don't run,
2
# :deploy is an endpoint you stand up and own.
3
- publishers/anthropic/models/claude-opus-4-5:predict # managed-partner
4
- publishers/google/models/gemma-3-27b:deploy # self-deployed into your VPC

—and Part 3 is where the full policy file, the gcloud org-policies set-policy command, and the Terraform form live. The point for this register is only that the allow-list is the estate’s memory: a model that is not on the list cannot be called, and a model that is on it carries, in the suffix, the record of how its data path runs.

The tier decides how much of the governance you can even exercise. For an enable-to-access model, the org-policy constraint is the only place you can say “yes to the model, no to its web search,” because the endpoint isn’t yours to configure. For a self-deployed model, you own the data path directly and the constraint matters less. Google says as much in its own guidance—choose self-deployment for workloads under “stringent regulations that prohibit using a multi-tenant managed service.” The deployment tier is a governance decision, not an operations one. A team that knows its tiers can answer “where does this model’s data actually go” without a meeting.

Second Register: The Toggle Is a Decision on Record

Part 3 was the how-to for setting these toggles. Here is what it buys you, stated as the property that matters: in a mature estate, every server-side capability’s on/off state is a policy you can read, at a tier you chose, with an owner attached. The capability is not on because nobody turned it off. It is on—or off—because a named person decided, and the platform enforces the decision.

The single fact that makes this achievable rather than aspirational is the default: for any project that belongs to an organization, the partner features governed by vertexai.allowedPartnerModelFeatures—Claude’s web_search and structured_outputs—arrive denied. Part 3 has the runbook and the reasoning; here it’s enough to know that the boring estate is the default estate, because you have to opt into exposure rather than remember to opt out.

What matters for saying yes to more teams is that the toggle is not one decision but a stack of independent ones, each recordable on its own. “We approved Claude” is one trust decision. “We approved Claude with web search” is a second, gated by the partner-feature constraint. “We approved Claude with web search and request-response logging to our own BigQuery” is a third, set through a different mechanism entirely. Three decisions, three mechanisms, three separate rows in the record. A mature estate doesn’t collapse them into a single “we use Claude” and hope. It grants each one deliberately, at the tier it belongs, and can show you which is which.

And because the scope model is a hierarchy where deny-wins, one decision covers the whole estate. Set the restrictive policy at the organization or folder node and every current and future project inherits it; a stray project that tries to loosen production can’t, as long as the deny lives above it and nobody handed that project the right to override its parent. This is what “govern outcomes, not steps” looks like when it’s real. The outcome—no partner web search in prod—is set once as infrastructure. Nobody is asked to remember.

graph TD
  org["Organization policy<br/>partner web search denied by default"]
  prodFolder["Prod folder<br/>deny stands, inherited"]
  devFolder["Dev folder<br/>allow web search for experimentation"]
  newTeam["New team, new project<br/>inherits the tier it lands in"]

  subgraph estate["Say yes by placing the project, not by re-deciding"]
    org --> prodFolder
    org --> devFolder
    prodFolder --> newTeam
  end

Read that diagram as the operating model for expansion. When the next team arrives, you don’t re-run the risk assessment. You place their project under the folder whose posture matches their need—prod under the restrictive folder, an experiment under the permissive one—and inheritance does the rest. The decision was made once, high in the tree.

Onboarding is placement, not deliberation. You scale access without scaling exposure because the guardrails were set before the team showed up.

Third Register: The Contract Is a Decision on Record

The first two registers live inside Google Cloud. The third lives in your contracts, and it’s the one that generalizes the series past a single platform. Part 1 laid out the contract family in full—a governance guarantee is opt-in, per-vendor, and capability-scoped, and some instruments are gated to a defined class of party. The register’s new claim is narrower and sharper: that contract is the third on-record decision, and the question that puts it on record is not “is there a contract?” but “who is allowed to sign it?”

That question is the one that turns the contract from prose into a lookup. The US HIPAA Business Associate Agreement (BAA) is eligibility-gated—only a covered entity or business associate may enter one—and asking “who may sign it?” across domains sorts every instrument into two columns: gated to a defined class of party, or open to anyone who processes personal data.

The workhorse in that table is the Data Processing Agreement, open to any customer and the one most of the world will actually use; Part 1 has the tour of where it recurs. For the register, the procurement action is the whole point: “execute the vendor’s DPA,” singular, is a row you can fill without a meeting.

Two facts inside this register bite the architect who assumes the contract does more than it does, and both are capability-scoped in exactly the way the toggle register is. First, a DPA gives you the contractual commitment but does not pin where your data physically lives—residency is a separate setting, governed on Google Cloud by the Service Specific Terms and a per-service residency list, so “we signed the DPA” and “our data stays in the EU” are two rows, not one. Second, these instruments cover generally available services, not experiments: Google’s Pre-GA Offerings Terms (in the Service Specific Terms, §5(b)) put anything labeled Preview, Alpha, Beta, or Experimental outside the data-location commitment, and Anthropic’s BAA likewise excludes beta features. The contract you signed may not cover the preview capability you’re about to switch on—the same capability-scoped lesson as the toggle register, one level up in the stack.

The Three Registers, Composed

Put the registers side by side and the estate’s whole governance posture is a short, readable answer to a single question for any capability: where does this run, is it switched on, and what covers it?

graph LR
  cap["A server-side capability<br/>e.g. Claude web search in prod"]

  subgraph record["Three decisions, all on record"]
    tier["Tier<br/>which deployment path"]
    toggle["Toggle<br/>allowed at this scope?"]
    contract["Contract<br/>which instrument covers it"]
  end

  cap --> tier
  cap --> toggle
  cap --> contract

None of these three replaces the others. The tier tells you whose infrastructure the data path runs on. The toggle tells you whether the capability is switched on at this project’s scope. The contract tells you what the vendor is obliged to do with the data and whether your organization is even allowed to hold that obligation.

Answer all three and you’ve described a governed capability. Leave any one blank and you have found the gap the whole series told you to look for: a data path that arrived instead of one you chose.

This is also why the series has been “better together, governed apart” from the first page, and never a case for one vendor over another. A mature estate runs more than one model—for example, both Gemini and Claude: Gemini where a search path inside the already-accepted Google trust boundary matters, a partner model like Claude where its particular strengths matter, and often both in the same application. Gemini and Claude are the pair I’ve used throughout, but the registers don’t care how many models you run or which ones; they apply to any first-party or partner model on the platform, the ones here today and the ones that land next quarter. The multi-model conversation gets tribal fast, and tribalism is a poor substitute for a control mechanism. The three registers are that mechanism. They let you say yes to the best model for each job because you can govern each model’s capabilities separately, on record, without the yes to one becoming an accidental yes to all of them.

I’ve paid for the version of this that isn’t on record. On one engagement, the multi-model routing proxy—LiteLLM—was the real blocker: every model reachable, none of them governed from one place. My team’s fix was to standardize on a single agent framework and handle the safety tooling centrally instead of per model. That’s the same instinct I’m hands-on with in 2026, building the enterprise agent-platform control plane—identity, registry, runtime, observability—which is exactly Part 4’s “one boring, governed control plane” described from the inside. The registers aren’t a theory I like; they’re the pattern the working systems keep converging on.

Maturity, Not Lock-In

This posture invites one objection above all others. Doesn’t all this governance lock you in? Isn’t a wall of org-policy constraints and signed DPAs just a golden cage that makes it harder to move, harder to experiment, harder to adopt the next model that comes along?

It’s exactly backwards, and the reason is the scene this post opened with. The estate with no registers—no explicit tiers, no policy defaults, no read of the contract per capability—is the one that can’t move. Every new model is a fresh risk assessment from zero. Every new team is a negotiation. Every “can we turn on web search” is a meeting, because nobody can say what turning it on would actually expose. That estate says no by default, not out of discipline but out of fear, because yes is unbounded. Its governance is a bottleneck precisely because it lives in people’s heads instead of in the record.

The estate with the three registers says yes cheaply, because yes is bounded. The tiers are known, the defaults are safe, the contracts are read. Adopting a new model is placing it in a tier and writing one allow-list line. Onboarding a new team is dropping their project under the folder whose posture fits.

The registers deliberately leave out cost and latency. They govern whether a model is safe to say yes to; they say nothing about whether it’s cheap or fast. Those questions still matter, and the numbers behind an actual model choice (grounding quality, citation fidelity, latency, and what each costs) are exactly what the developer companion measures head-to-head. Governance tells you a model is allowed; the eval tells you which allowed model to reach for.

Fine-grained capability governance is the mechanism of expansion, and the maturity is what buys the speed. Lock-in is what you get from the absence of this, when the only thing holding your data governance together is that no one has changed anything yet.

You don’t earn the freedom to say yes to more models and more teams until you can govern their capabilities separately. Once you can, yes gets cheap—and safe—at the same time.

Boring, on Purpose

So here is the mature end-state, and it’s deliberately unremarkable. Every server-side capability in the estate sits on a deployment tier someone chose. Its on/off state is a policy someone set, at a scope someone picked, with a name on the change. Its data path is bound by a contract someone read, whose scope someone verified down to the preview-feature line. When the next team arrives wanting the newest model with the sharpest capability, the answer is a lookup, not a leap—and the answer is usually yes, arrived at safely, before lunch.

Nothing trips in the night. The audit finds what the diagram promised. A capability is never on by accident, because the switches all start in the safe position and every exception has a name attached. That is the good kind of boring—the kind that is indistinguishable, from the outside, from a team that simply has its act together. Governed growth was about making yes so well-understood that you could afford to say it more, to more teams, without ever losing track of what you opened.

Keep the List on Record

Part 1 asked you to make a list—one Monday morning with a spreadsheet, every server-side capability your teams can reach, one row each. This is the same list, one column wider and kept where a policy engine can read it. For each capability you run, fill three cells:

• Tier—which deployment path the model runs on (:predict managed API, :deploy your own VPC, first-party, dual-mode).
• Toggle—is the partner feature allowed at this scope, and who set it?
• Contract—which instrument covers the data path, and is your org even eligible to sign it?

A filled row is a governed capability. A blank cell is the gap the whole series told you to look for—a data path that arrived instead of one you chose. That’s the work: not a one-time audit, but a record you keep, because the estate’s memory should live in policy and contracts, not in the head of whoever set it up.

From here the series forks, depending on which chair you’re in.

If you govern it, go set the record straight. Run the Part 3 runbook against a production project—describe the effective partner-feature policy first, confirm the default-deny is actually in force, then write the allow-list that names your tiers—and fill the three-register table for every capability you found. An hour of gcloud org-policies describe will tell you how many of your rows are already blank.

If you build it, the companion is waiting. Building gemini-search-mcp: Grounding, Citations, and Choosing a Gemini Model takes the governed-capability idea down to running code: a real grounding server, how citation extraction works against the Gemini API, and the head-to-head model evaluation that tells you which allowed model to actually reach for. go install and you’re holding the thing this series has been governing.

Either way, the destination is the same boring estate: every yes bounded, every capability on record, and room to grow into.

This is the final part of the Governed Growth series. Read it from the top: Part 1 sets the frame, Part 2 makes the finding concrete, and Part 3 is the runbook. Every fact above—the deployment-tier taxonomy, the org-policy default-deny, and the contractual scope of the DPA and BAA families—is drawn from Google Cloud’s and Anthropic’s own documentation and terms, and from the primary text of the privacy and sector regulations named across the series.