AI Landing Zone Design: Container and Workbench Patterns

AI Container and AI Workbench: designing AI landing zones for builders and business users

In the first part of this series I looked at how multi-model agent creation platforms, Microsoft Foundry, AWS Bedrock, and Google’s Vertex AI Agent Builder work, and how to choose between them. The next question clients ask is more interesting: once the model and platform are chosen, how do you structure the AI ​​landing zone so that building agents and the people who use it can safely benefit from it?

Recent client engagements illustrate this in useful, concrete terms. They ask for two things: an AI Containerhome to technical pipeline experts and code-first developers and data professionals, and an AI Workbenchwhere non-technical users can safely discover and use approved AI agents and services. I like the language because it forces the design to serve two very different audiences rather than pretending that one environment is suitable for both. This post discusses those designs, in a Microsoft-centric environment, with notes on where the patterns generalize.

What’s wrong without division

When business builders and users share one undifferentiated AI environment, the failure is not abstract ‘governance’. It appears in three lines that the sponsor pays attention to.

• Cost. Every experiment, every abandoned proof of concept, every business user using a raw model endpoint is drawn from the same measured pool. No one can say how much it costs to run an agency, so no one can say which agencies are worth running.
• Risking. Business users just get one misconfigured connection of data they shouldn’t see, and developers end up being delivery agents to coworkers without reviewing what those agents can reach. One data incident early in a rollout will halt adoption for a year. I have watched it happen.
• Adoption. This is what is missed. Faced with raw plumbing, most non-technical users simply disengage, and IT responds to the risk by locking everything behind tickets. You’ll get the worst of both worlds: an expensive platform and a workforce that silently reverts to old habits, or to unapproved tools.

The separation of Container and Workbench was done to protect one outcome: fast, secure, and regulated adoption at the same time, rather than interchangeably with each other.

AI Container: building speed without uncontrolled costs or exposure

Containers are a technical layer. The job is to let builders move quickly and add value in thin layers while the organization keeps control of spend and data. In Azure terms, this is an application’s landing zone, its own subscription or pair of subscriptions under a dedicated management group, containing:

• Model access. The Foundry project hosts implementations of the models selected in the first part, including multi-model routing. All model endpoints are behind private endpoints; nothing is reachable from the public internet.
• Agent creation tools. Foundry Agent Services for code-first jobs, Copilot Studio for low-code developers, with source control and CI/CD pipelines that treat agents as deployable artifacts, not portal experiments. If it’s not in the repo, it won’t be promoted.
• Data connection. Managed and read scoped connections to data platforms via managed identities, cataloged in Microsoft Purview. The builder asked for a connection; they don’t print their own credentials.
• Identity and network limitations. Login ID groups with role-based access control, Privileged Identity Management for everything higher up, and network segmentation that keeps Container virtual networks connected to the platform’s landing zone but invisible to general users.
• Cost control. Per-project budgets and alerts, mandatory tagging (owner, agent, cost center), and deliberate choice between provisioned model capacity and pay-as-you-go model once usage patterns are known.

Access is limited to developers, data engineers, and platform teams. The business rationale for each of the controls above is the same: builders keep pace because the guardrails are in the environment, not in the approval email queue.

AI Workbench: self-service adoption without ticket queues

Workbench is not a second technical environment. This is the consumption layer: a catalog of approved agents and services, appearing where business users already work.

• Curated agent catalogue. Only agents who have passed the promotion gate appear. In Microsoft environments, this usually means agents published to Microsoft 365 Copilot and Teams via the organization’s agent catalog, so ‘discovering AI’ means tapping into tools people already have.
• Simplified access layer. Business users authenticate with their existing Entra ID identity. No Azure portal access, no endpoint URL, no key. Rights are granted based on group membership, so joining a new group is a group change, not a project.
• Guardrail. Data loss prevention policies, Azure Purview sensitivity labels are applied end-to-end, content filtering is configured on the model deployment behind each agent, and conditional access ensures Workbench can only be reached from managed devices when it is critical.

The payoff from this layer is rapid adoption. When a team wants an approved agent, they get it the same day through group assignment, and IT never sees the ticket. That’s what makes a sponsor’s business case work: value comes from usage, and usage comes from removing friction for the vast majority of people who would never touch plumbing.

Promotion path: the place where the two layers meet

The connection between Container and Workbench is the promotion line, and is the part that most designs skip. Agents move through development and test environments within Containers, then pass through approval gates before being published to the Workbench catalog. The gateway checks four things: what data the agent can reach, what actions it can take, how much it costs to run it, and whether the quality of its output has been evaluated based on an agreed-upon rubric and not based on a good demo.

The limits themselves are enforced with familiar Azure mechanisms: separation of management groups with Azure Policies applied at each tier, RBAC that doesn’t give business users persistent access to Container resources, network segmentation between layers, and Azure API Management as a front door to any agents exposed outside the Microsoft 365 surface, which also gives you per-agent usage and cost attribution.

The design tension that must be managed is speed. If the promotion takes six weeks, the builder will sort it out and you’re back in the AI ​​shadows. The gateway should be a checklist that platform owners can complete in a matter of days, protecting the outcomes that matter: nothing unregulated reaches business users, and nothing regulated waits long enough to kill momentum.

The questions clients actually ask

How to stop non-technical users from reaching the plumbing without slowing down self-service access?

Make identity the boundary, not just the network. Business users don’t have Azure portal access and don’t have a route to the model endpoint; their only path to AI is a published catalogue. Because entitlement is based on groups, self-service remains fast-paced: the same mechanisms that block pipelines provide grants to agents.

How do you stop containers from becoming agents of sprawl and shadow costs?

Three controls: mandatory tagging so each resource has an owner and cost center, per-agent cost attribution via API Management subscriptions and Foundry project limits, and experiment time limits, with anything left untouched for sixty days marked for deletion. Sprawl was a visibility issue before it was a disciplinary issue; provides platform owners with a monthly view of agents, owners, and operational costs and largely makes its own corrections.

Does this require two separate Azure landing zones, or one with layered access?

For most organizations, a single application landing zone with layered access is the right decision: separate subscriptions for Container workloads under one management group, with Workbench delivered through the Microsoft 365 platform, not Azure infrastructure. Two full landing zones roughly doubles the platform overhead and slows the promotion path, and is only sustainable if regulations demand strict separation, clear sovereignty requirements, or completely separate operating models. Choose a single landing zone unless regulators provide arguments in your favor.

What is the minimum viable version for a first trial?

One Container subscription, one Foundry project with a single model deployment behind private endpoints, API Management up front, basic source and channel control, and three to five agents built around real use cases, were promoted through a lightweight gateway to an initial group of twenty to fifty business users in Teams. This is enough to prove the results, agents working in production, safely, at known costs, without building a full target state first.

The pattern is not specific to Azure. Swap Foundry for Bedrock or Vertex AI Agent Builder, management groups for AWS Organizations or GCP folders, and Entra IDs for equivalent identity fields, and Containers, Workbenches, and promotion gateways are translated live.

What exactly is the content of the first stage of design?

If I’m doing this scoping for a client, the first phase contains: Container subscription and management group structure with applied policies; one implementation of regulated models and data connection patterns; CI/CD framework for agents; API management with per-agent attribution; promotional checklist agreed with the platform owner; and the first agent to be published on Workbench. Expressed as results: the first agent in production within four to six weeks, the first group of businesses safely onboarded in weeks six to eight, and a cost per agent figure that sponsors can see from day one. It’s the latter that keeps the program funded.

Where to go next

Environmental management is one part of the problem; getting people to use it well is another thing, and this is usually the more difficult part. This is what the AI ​​Enablement Program is all about: readiness, role-based use cases, and governance that makes the value persist after the initial push. If your launch has a license but hasn’t reached the landing zone yet, this is worth discussing.

And if you haven’t yet made the platform and model decisions on which to base this design, start with the first part: choosing a multi-model agency platform.