GGoldwater.dev
All articles
Pragmatic AI6 min read·

Foundry vs. Gemini Enterprise: Choosing an Agent Platform Without Betting the Farm

Two rebrands in eight months tell you the abstractions aren't stable yet. Why 'Foundry or Gemini Enterprise?' is the wrong question — and how to get value now while keeping your switching costs low.

In the last eight months, both major cloud AI platforms changed their names. Azure AI Foundry became Microsoft Foundry in January. Vertex AI became the Gemini Enterprise Agent Platform in April, with Google stating that all future Vertex AI capabilities will ship exclusively through the new platform. Two rebrands, same story: the hyperscalers have decided the enterprise AI platform war will be fought over agents, not models.

I've sat in several client meetings this quarter where the question was some version of "which one do we standardize on?" I think that's the wrong question — and the rebrands themselves are the evidence.

What actually changed (beyond the names)

Strip away the branding and both moves are substantive. Microsoft Foundry positions its Agent Service as the center of gravity: a managed lifecycle for building, deploying, and governing agents, with access to a catalog of thousands of models from OpenAI, Meta, Cohere, and others under one set of security and policy controls. Dropping "Azure" from the name was deliberate — agents are being promoted from "an Azure service" to a first-class Microsoft product line.

Google's move is arguably bigger. The Gemini Enterprise Agent Platform bundles a code-first Agent Development Kit, a low-code Agent Studio, a managed runtime (Agent Engine), persistent memory, and 200+ models — including Anthropic's Claude alongside Gemini. Folding Vertex AI entirely into an agent platform, rather than running them side by side, tells you where Google believes the money is.

So both platforms are genuinely capable, converging on similar shapes, and evolving fast. Which brings me to the actual point.

The rebrand churn is the signal

When a platform renames and restructures itself twice in three years, it's telling you something useful: the abstractions aren't stable yet. APIs are consolidating, services are merging, and the primitives you build against today may be repositioned next spring. That's not a criticism of Microsoft or Google — it's what a market looks like mid-formation.

The practical consequence for engineering leaders: any decision that assumes today's platform shape persists for five years is a bad decision, no matter which platform you pick. The question isn't "Foundry or Gemini Enterprise?" It's "how do we get value now while keeping our switching costs low?"

How I'd actually decide

For most organizations, the honest first-pass answer is boring: follow your existing cloud gravity. If your workloads, identity, and data governance live in Azure, Foundry's integration with Entra, Purview, and your existing compliance posture will save you months. If you're a GCP shop, the same logic applies to Gemini Enterprise. The platforms' capability gap is smaller than the integration tax of going cross-cloud.

But cloud gravity settles maybe 70% of the decision. The rest is a handful of questions worth asking concretely:

Model flexibility, verified — not from the slide deck. Both platforms advertise multi-model catalogs. Test the models you actually intend to use, at the latency and rate limits you'll actually get, in the region you actually deploy in. Catalog breadth means nothing if your primary model is throttled or missing in your geography.

Where does agent state live? Persistent memory, conversation history, tool-call logs — this is the data that accumulates and creates real lock-in. Ask how you'd export it. If the answer is a shrug, that's your five-year cost hiding in plain sight.

Governance that matches your audit reality. If you're in a regulated industry, the deciding factor may be which platform's audit trails, data residency, and policy controls map to frameworks your compliance team already speaks.

What does the escape hatch cost? Price the migration before you commit, not after. If moving your agents out would take two quarters, factor that in as real risk.

Architect for portability, cheaply

You don't need a heroic abstraction layer over both platforms — I've watched teams burn six months building a "cloud-agnostic agent framework" that delivered nothing. Portability comes from cheaper habits: keep your prompts, evals, and tool definitions in your own repos rather than the platform's console; prefer open interoperability standards (both platforms are converging on things like MCP for tool integration) over proprietary connectors when the choice is close; and keep your orchestration logic — the business rules about what agents may do — in your code, not in platform-specific configuration.

Do those three things and a future migration is a project, not a rewrite. Skip them and you've made the platform decision permanent by accident.

Takeaway

Pick the platform your cloud gravity already points to, validate the specific models and governance features you need rather than trusting the catalog, and spend your architectural effort on the cheap portability habits — own your prompts, prefer open standards, keep orchestration in your code. Both Foundry and Gemini Enterprise will look different again in eighteen months. Your job isn't to predict the winner; it's to make sure you don't care who wins.

WG

Wes Goldwater

Director of Engineering at Prosigliere · writing the no-hype playbook for cloud & AI.

Keep reading