Standing Up a Governed Agentic AI Platform

Like the legacy modernization pattern elsewhere on this site, this is a pattern I saw repeatedly across oil & gas customers during my years at Microsoft — the shape of the problem recurring across companies, not a single client's story. The technology and approach below describe the pattern; the specifics of any one company's environment are deliberately left out.

The Problem: Everyone Wants to Build an Agent, Nobody Has a Foundation

Once an organization's leadership decides agentic AI is worth pursuing, the requests start coming from everywhere — a team wants a Copilot-style assistant over internal documentation, another wants an agent that automates a compliance check, a third wants to experiment with retrieval-augmented generation over operational data. Every one of those is a reasonable idea. The problem is what happens when there's no shared platform to build them on: each team stands up its own resource group, its own identity configuration, its own idea of what "secure" means, and the organization ends up with as many different security postures as it has agent projects — none of them audited, none of them consistent, and all of them somebody's problem the day a security review asks who approved what.

That's the same failure mode described in running agentic AI at enterprise scale: governance that isn't built in from the first deployment doesn't survive contact with the second team. In oil & gas specifically, where operational technology, safety compliance, and vendor data-sharing agreements are already a serious governance surface, letting that sprawl happen with AI workloads on top isn't a risk worth taking.

The Approach: A Reference Architecture, Not a Bespoke Build

Azure AI Landing Zones as the Starting Point

Azure AI Landing Zones is Microsoft's own open-source reference architecture for exactly this problem — an application landing zone purpose-built for deploying AI apps and agents securely, rather than a generic cloud landing zone stretched to fit. It offers two patterns that can be deployed independently or together:

• Agent Landing Zone — built around Microsoft Foundry for the AI apps and agents workload itself, the pattern that matters most when the immediate goal is getting one team's agent into production safely.
• AI Gateway Landing Zone — uses Azure API Management as a centralized gateway for Foundry models, the pattern that matters once more than one team needs controlled, policy-enforced access to the same underlying models.

Both ship as Infrastructure as Code — Bicep and Terraform, built on Azure Verified Modules — and both align to Microsoft's Cloud Adoption Framework AI Scenario and Well-Architected Framework guidance, backed by a published design checklist covering identity, networking, and policy. Starting from that checklist instead of a blank whiteboard is most of the value: the network segmentation and identity boundary decisions a team would otherwise spend weeks debating have already been designed, reviewed, and published.

Worth being direct about status: this is currently a preview project, not a long-settled GA product. That's a reason to build and test it thoroughly before it's load-bearing for production traffic, not a reason to avoid it — it's still Microsoft's own published direction for this exact problem.

Agentic DevOps to Build, Test, and Deploy the Platform Itself

The landing zone is infrastructure, and infrastructure gets the same CI/CD discipline as application code: GitHub Actions pipelines that plan and apply the Bicep or Terraform changes, GitHub Advanced Security scanning the IaC itself for misconfigurations before it ships, and GitHub Copilot's agentic tooling doing the drudgery of iterating on module configuration and checklist compliance — the same agentic DevOps discipline applied to the platform layer instead of just the application layer sitting on top of it.

The Result: A Platform the Next Use Case Doesn't Have to Rebuild

Once the landing zone is live, the first real agentic AI use case — and every one after it — deploys onto an already-governed foundation: identity boundaries already defined, network segmentation already in place, policy enforcement already active. The second team's project doesn't require re-litigating what "secure" means; it inherits the answer the platform already gave the first team. That's the actual payoff of building the platform before the use case instead of alongside it — the organization gets to say yes to the next AI idea quickly, because the hard governance decisions were made once, centrally, and reused.

What We'd Tell Any Team Facing This Today

• Stand up the governed platform before the first agent workload, not in parallel with it — retrofitting governance onto three already-live, inconsistent deployments is much harder than building it in from zero
• Start from a published reference architecture and its design checklist instead of designing network and identity boundaries from scratch — Azure AI Landing Zones' own checklist exists precisely so a team doesn't have to rediscover these decisions
• Treat the landing zone's Infrastructure as Code with the same CI/CD and security-scanning rigor as application code, since misconfigured infrastructure is exactly where a governance gap actually shows up
• Say plainly when a component is still in preview — it changes how much production traffic should depend on it today, not whether it's worth adopting

If your organization is trying to move past ad-hoc pilots toward a platform the whole business can build on, see our Agentic DevOps work, or book a discovery call to talk through where your environment stands today.

Frequently Asked Questions

What is the Azure AI Landing Zones project?

An open-source reference architecture and implementation, published by Microsoft, for deploying secure, resilient AI apps and agents on Azure. It ships as Portal, Bicep, and Terraform deployments built on Azure Verified Modules, and is currently in preview — worth stating plainly rather than implying it's a long-settled GA product.

What's the difference between the Agent Landing Zone and the AI Gateway Landing Zone?

The Agent Landing Zone pattern is built around Microsoft Foundry for the AI apps and agents workload itself. The AI Gateway Landing Zone pattern uses Azure API Management as a centralized gateway for controlling and serving Foundry models across an organization. They can be deployed independently or together, depending on whether the immediate need is one team's agent workload or org-wide model access control.

Why build the platform before the first agentic AI use case, instead of alongside it?

Because the alternative is every team that wants to build an agent standing up its own ad-hoc identity, networking, and policy configuration — the same "governance doesn't survive contact with a second team" problem we've written about elsewhere. Standing up the governed platform first means the first real use case, and every one after it, inherits the same foundation instead of each one improvising its own.

Does using a Microsoft-published reference architecture mean less customization for the client's environment?

No — it means less time spent reinventing network segmentation, identity boundaries, and policy enforcement that a published, checklist-driven reference architecture already solves well, freeing the actual engineering time for the customization that's genuinely specific to the client's environment and compliance requirements.

Is this the same story as Code To Cloud's other Energy & Resources use case?

No — the legacy modernization use case is about transforming a decade-old existing application. This one is about standing up new agentic AI platform infrastructure from scratch, using Azure AI Landing Zones as the reference architecture, before any agent workload gets built on top of it. Different problem, same industry pattern Kevin saw repeatedly during his Microsoft years.