AI & Cloud Infrastructure

Gemini Enterprise Agent Platform vs Azure AI Foundry

Av Technspire TeamMay 22, 20268 visningar

On 20 May, Google Cloud published its round-up of the enterprise announcements from I/O 2026, and it reads like a direct answer to what Microsoft has been building with Azure AI Foundry Agent Service and Copilot Studio. The headline items: Gemini 3.5 Flash is available immediately across the Gemini Enterprise Agent Platform, Google AI Studio and Antigravity, at what Google says is often less than half the cost of comparable models. Alongside it come a new Managed Agents API that spins up custom agents in Google-hosted secure environments with a single API call, an Antigravity 2.0 desktop app and CLI, the CodeMender security agent, an AI Content Detection API, and Gemini Spark, a 24/7 background agent with connectors into Microsoft SharePoint, OneDrive and ServiceNow. If your organisation runs on Azure and Microsoft 365, that last detail should make you sit up: Google is explicitly building agents that reach into your Microsoft estate. Whether any of it changes your platform strategy depends less on the benchmarks than on the Swedish and EU compliance questions, so those sit front and centre below.

What Google actually announced

Stripping away the keynote gloss, the Google Cloud post contains six enterprise-relevant items. Be precise about what is generally available today versus what is "coming soon", because the two categories got equal billing on stage.

Gemini 3.5 Flash: available now

Gemini 3.5 Flash is live as of 20 May. Developers can build agents with it on the Gemini Enterprise Agent Platform or use it in Google AI Studio and Antigravity; business users get it in the Gemini Enterprise app starting the same day. Google's published benchmark figures position it squarely as an agentic workhorse: 76.2% on Terminal-Bench 2.1 (terminal and CLI task execution), 83.6% on MCP Atlas (multi-step tool orchestration over the Model Context Protocol), 84.2% on CharXiv for multimodal chart understanding, and a 1656 Elo score on GDPval-AA. The cost claim of "often at less than half the cost of comparable models" is Google's own framing and worth validating against your actual token mix, but the direction is clear: aggressive pricing on the model tier most agent workloads actually run on. Gemini 3.5 Pro, meanwhile, is still in testing and slated for next month, so the flagship comparison remains open for now.

The Managed Agents API: Google's answer to Foundry Agent Service

The most strategically significant announcement for platform teams is the Managed Agents API on the Agent Platform. Google's pitch: spin up custom agents that reason, call tools and execute code inside secure, Google-hosted remote environments, using a single API call. Agents created this way inherit the Agent Platform's enterprise data privacy, governance and security protections automatically. This is the same managed-runtime bet Microsoft made with Azure AI Foundry Agent Service: stop asking every team to operate its own orchestration loop, sandbox and state store, and sell the runtime as a service instead.

Gemini Spark: a background agent inside your Microsoft estate

Gemini Spark is described as a 24/7 personal agent in Gemini Enterprise that works in the background across Google Workspace, custom connectors and the open web. The launch connectors named include Microsoft SharePoint, OneDrive and ServiceNow. Architecturally, Google is making security claims that deserve attention: each session runs in a fresh, strictly isolated, ephemeral VM; traffic passes through a secure Agent Gateway that enforces Data Loss Prevention policies; and user credentials remain encrypted and are never exposed directly to the agent. Spark requires explicit approval for high-risk actions and is rolling out to Gemini Enterprise customers "soon" rather than being available today. The SharePoint and OneDrive connectors are the competitive tell: Google is not waiting for you to migrate off Microsoft 365 — it wants its agent sitting on top of your existing document estate.

Antigravity 2.0, CodeMender and the AI Content Detection API

Three further items round out the picture. Antigravity 2.0 is a standalone desktop app for steering, customising and orchestrating agents, now paired with a tightly integrated CLI for developers who want a lightweight interface for building and deploying agents; both inherit Google Cloud data privacy protections when used through the Agent Platform. CodeMender, originally developed by Google DeepMind, is an AI code security agent that autonomously identifies vulnerabilities, recommends fixes, tests them and can apply patches; several Gemini Enterprise customers are already testing it, with broader availability to be announced. And quietly, but perhaps most relevantly for EU readers: an AI Content Detection API is rolling out on the Agent Platform from today, identifying AI-generated content from both Google's models and other popular models. We come back to why that matters for the AI Act below.

Mapping the announcements to your Azure estate

For an Azure-first team, the useful exercise is not "is Google's platform good?" but "what is the counterpart I already have, and where are the genuine gaps?" Here is the mapping as we see it:

  • Managed Agents API ↔ Azure AI Foundry Agent Service. Both are managed agent runtimes: you define the agent, the platform hosts execution, tool calling and state. Foundry Agent Service has been generally available for a year and its differentiators remain the enterprise wiring: Microsoft Entra identities for agents, bring-your-own Azure resources for conversation state and search, virtual network isolation, and tracing into Application Insights. Google's pitch is simplicity ("a single API call"); Microsoft's is control over where everything lives.
  • Gemini Spark ↔ Copilot Studio agents and Microsoft 365 Copilot. A background agent with SharePoint/OneDrive access and DLP enforcement is functionally what Microsoft has been selling into the same tenant. The difference is that Microsoft's version runs inside the tenant's existing compliance boundary, governed by the Purview policies you already administer, rather than reaching in from outside via connectors.
  • Antigravity 2.0 and CLI ↔ VS Code, GitHub Copilot agent workflows and the Foundry portal/SDK. Different shape (Google is shipping a dedicated agent-orchestration desktop app), same job: a builder surface for developing and steering agents.
  • CodeMender ↔ GitHub Advanced Security and Copilot autofix capabilities. Autonomous vulnerability detection and patching is contested ground; CodeMender's DeepMind pedigree is notable but it is still in customer testing, not general availability.
  • AI Content Detection API ↔ no direct Azure equivalent today. Azure AI Content Safety covers harmful-content moderation, and Azure OpenAI applies provenance measures to some generated media, but a general-purpose API for detecting AI-generated content across vendors' models is not something the Azure catalogue offers as a first-class service right now. This is the one announcement where Google has shipped something your Azure estate genuinely lacks.

Architecture: two philosophies of "managed"

Both platforms now converge on the same runtime primitives: sandboxed execution, tool calling, managed state, gateway-level policy enforcement. Where they diverge is a question that matters enormously for EU enterprises. Who owns the perimeter?

Google's model, as described in the announcement, is platform-owned isolation: every Spark session gets a fresh ephemeral VM, the Agent Gateway enforces DLP centrally, credentials are encrypted away from the agent, and agents created via the Managed Agents API inherit the platform's protections. You get strong defaults with minimal configuration, but the security boundary is Google's to define and attest.

Azure AI Foundry Agent Service leans towards customer-owned perimeter: you can bring your own Azure resources (Cosmos DB for conversation threads, Azure AI Search, your own storage), run agents inside your own virtual network, give each agent its own Entra identity with scoped RBAC, and trace every model call and tool invocation into your own Application Insights workspace. More wiring, but the audit trail, the data stores and the network boundary are yours, in your subscription, in your chosen region.

In practice the Foundry setup for a minimal agent is hardly onerous. This is the entire definition in Python:

from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

project = AIProjectClient.from_connection_string(
    conn_str="<your-foundry-project-connection-string>",
    credential=DefaultAzureCredential(),  # Entra ID, no API keys
)

agent = project.agents.create_agent(
    model="gpt-4.1",
    name="invoice-triage-agent",
    instructions="Classify incoming invoices and flag anomalies "
                 "for human review. Never auto-approve payments.",
    tools=[...],  # file search, code interpreter, MCP tools
)

The "single API call" framing of Google's Managed Agents API is a genuine ergonomic win, but it is not an order-of-magnitude difference. On either platform, defining the agent is the easy part. The hard part is everything around it: identity, data governance, evaluation and observability. Which brings us to the decision framework.

A decision framework for Azure-first teams

We would frame the evaluation as four questions, in this order:

1. Where does the data your agents touch already live?

Agents are only as useful as the systems they can act on. If your documents are in SharePoint and OneDrive, your identity is Entra, and your tickets are in Azure DevOps or ServiceNow, an agent platform inside that boundary starts with an enormous head start. Gemini Spark's SharePoint and OneDrive connectors narrow the gap, but a connector-based integration crossing a cloud boundary is never equivalent to native residency inside the tenant, and every cross-boundary connector is a new data flow your DPO must map, assess and defend.

2. Is the price delta real for your workload?

"Less than half the cost of comparable models" is a claim worth testing, not accepting. Run your actual agent traces through both platforms' pricing before drawing conclusions, with your real tool-call ratios, context lengths and retry behaviour. Agentic workloads are dominated by input tokens and repeated tool-call round trips, so headline per-token prices routinely mislead. If Gemini 3.5 Flash's Terminal-Bench and MCP Atlas numbers hold up in your own evaluations, the interesting question becomes whether it can serve as a cheap execution tier, even in an otherwise Azure-centred architecture.

3. Can you meet your audit obligations on the platform?

Under the AI Act and under plain GDPR accountability, you will need to demonstrate what your agents did, with whose data, under which policy. Ask each vendor the same questions: Can I export complete execution traces to my own storage? Can I enforce my own DLP policy, or only the platform's? Where, geographically, does agent execution and state storage happen, and is that contractually committed? Google's announcement describes strong isolation architecture but says nothing about EU data residency for the Agent Platform's execution environments; that is a question to ask before any pilot touching personal data, not after.

4. What does a second platform actually cost you?

A second agent platform means a second identity model, a second observability stack, a second security review, a second vendor DPA, and a second set of skills to maintain. That overhead is justified when the second platform does something the first cannot. A model benchmark that will be leapfrogged within a quarter rarely justifies it.

Our short-form recommendation:

  • Stay on Foundry Agent Service for production agents that touch Microsoft 365 data, need VNet isolation, Entra-governed identity, or auditable state in your own subscription.
  • Evaluate Gemini 3.5 Flash on merit as a model, via API in a contained proof of concept, if the cost claim would materially change your unit economics. Model evaluation does not require platform adoption.
  • Watch the Managed Agents API but do not build production dependencies on day-one announcements; let the residency and compliance documentation catch up first.
  • Look seriously at the AI Content Detection API regardless of your platform allegiance: it addresses a compliance need Azure does not currently cover with a dedicated service.
  • Treat Gemini Spark's Microsoft connectors as a governance event: if business units can point a third-party agent at your SharePoint, your conditional access and app-consent policies need to say something about that before someone tries.

The Swedish and EU angle: Article 50 is fifteen months old news but ten weeks from applying

The most underrated announcement in Google's post, for EU readers, is the AI Content Detection API. From 2 August this year, the AI Act's Article 50 transparency obligations apply: providers of systems that generate synthetic audio, image, video or text must ensure outputs are marked as artificially generated in a machine-readable way, deployers of deepfakes must disclose them, and people interacting with AI systems must be told they are doing so unless it is obvious. Enforcement details are still maturing, but the obligations themselves have a firm date, and most enterprises we speak to have treated content marking and detection as someone else's problem. An API that identifies AI-generated content across multiple vendors' models is precisely the kind of tooling compliance teams will be asking for this autumn. Whether Google's implementation is robust enough to rely on is an open question; detection of AI-generated text in particular has a chequered accuracy history. Still, the product category is now real, and Azure-first teams should be asking Microsoft what the equivalent roadmap looks like.

On data residency, the asymmetry between the two platforms matters for Swedish organisations. On Azure, you can pin Foundry resources to Swedish and EU regions, keep agent state in your own Cosmos DB and storage accounts in-region, and operate within Microsoft's EU Data Boundary commitments. Google Cloud has its own EU sovereignty programme, but the I/O announcements are silent on where Agent Platform execution environments and Gemini Spark's ephemeral VMs actually run. For a public-sector body or a regulated financial firm in Stockholm, that silence is disqualifying for production use until answered contractually. Put it in writing in the DPA, not in a sales deck.

Procurement is the third leg. Most Swedish enterprises already have Microsoft enterprise agreements, completed transfer impact assessments and Purview policies covering the Microsoft estate. Adopting Google's agent platform means a fresh vendor assessment, a fresh DPA negotiation, and, if Spark's connectors touch personal data in SharePoint, an updated record of processing and likely a DPIA for the new cross-cloud flow. None of that is a reason never to adopt; all of it belongs in the cost column of question four above, where it is routinely forgotten.

Conclusion

Google's I/O 2026 enterprise announcements confirm that managed agent runtimes, not models alone, are now the competitive battleground. The Managed Agents API and Gemini Spark are aimed directly at Azure AI Foundry Agent Service and the Copilot ecosystem, right down to the SharePoint connectors. For Azure-first Swedish and EU teams, the rational response is neither panic nor dismissal. Evaluate Gemini 3.5 Flash as a model on your own benchmarks. Note the AI Content Detection API as a genuine gap-filler ahead of Article 50 applying in August. Press Google on residency before any pilot involving personal data, and tighten tenant governance so third-party agents cannot quietly attach to your document estate. Until the residency and audit answers arrive, the sensible default for most of the organisations we work with remains Azure, because it is the platform they already govern well.

Sources