Microsoft Discovery is not just another Azure service. It is a signal that agentic R&D is moving from lab demo to enterprise workload, and most Azure Landing Zones are not ready for it.

I have spent a lot of time inside Landing Zones over the last few years. The pattern is mature for apps, data, and identity. It is not mature for swarms of autonomous agents reasoning over proprietary research data and calling HPC on the other side of the tenant.

That is the gap Discovery is about to expose.

What Microsoft Discovery actually changes

Discovery gives researchers and engineers a way to orchestrate specialised agents across foundational models, reasoning models, internal data, and HPC compute. It is aimed squarely at scientific R&D, but the architecture implications run much wider.

The moment you let an agent plan, call tools, query proprietary datasets, and spin up compute, you are no longer running an application. You are running an operator with intent. Your Landing Zone either has a pattern for that, or it does not.

Most of the Landing Zones I see today do not.

Where the classic CAF pattern starts to leak

The Cloud Adoption Framework Landing Zone assumes a relatively predictable workload shape. Platform subscriptions for connectivity, identity, and management. Application landing zones for workloads. Policy guardrails pushed down through management groups.

Agentic R&D breaks several of these assumptions at once:

• Agents consume tokens and GPU time in bursts that do not match any traditional capacity model.
• The blast radius of a single prompt can cross data domains that were previously isolated by subscription or VNet.
• Model endpoints, vector stores, and tool connectors become first-class dependencies that policy was never written for.
• Researchers move fast and expect self-service. Platform teams are still gatekeeping GPU quota via tickets.

The result is the same pattern I saw in early Kubernetes adoption. Workloads land first, the platform catches up second, and the security model catches up third. That order is expensive.

The agentic R&D pattern I would add today

If I were standing up a Landing Zone this quarter, I would add a dedicated agentic R&D archetype alongside the usual corp and online application landing zones. A few things it needs to get right from day one.

A clean identity boundary for agents. Managed identities per agent, not per application. Entra ID workload identities with conditional access that understands non-human principals. No shared service principals across research domains.

Data zones with enforced egress rules. Research data, model training data, and production data do not mix. Private endpoints for every model, vector store, and storage account. Network policy that assumes agents will try to reach the internet and blocks it unless explicitly allowed.

Capacity governance for tokens and GPUs. Quota, budget alerts, and chargeback at the agent level, not just the subscription level. Without this, one unsupervised agent loop can burn a quarter of R&D budget overnight.

Policy for model and tool onboarding. Azure Policy definitions that restrict which foundation models, which tool connectors, and which data sources an agent archetype can use. Treat model choice the same way you treat SKU choice.

Observability designed for agent traces. Not just logs and metrics. Full prompt, tool call, and decision traces captured to an immutable store, with retention aligned to your research and compliance posture.

Why “now” matters

The reason I think this is urgent is timing. Discovery lowers the bar for business units to stand up agentic R&D workloads without waiting for a platform team to bless the pattern. If the Landing Zone does not have a supported archetype, shadow agent estates will appear inside application landing zones, inside sandbox subscriptions, and increasingly inside Teams.

Retrofitting governance onto an agent estate already touching proprietary data is much harder than designing the archetype in advance. I have watched this movie play out with containers, with Databricks, and with Power Platform. Every time, the teams that defined an archetype early paid a fraction of the cost of the teams that tried to corral workloads after the fact.

What I would ask the platform team this week

Three questions I think every platform and cloud architecture team should be able to answer right now.

One, do we have a named Landing Zone archetype for agentic R&D workloads, or are researchers landing in corp by default.

Two, what is our policy position on foundation model selection, tool connectors, and cross-domain data access for agents.

Three, if Discovery or a similar platform lands in our tenant next month, who owns the reference architecture, and is it written down.

If any of these answers is fuzzy, that is the real work item. Not the next agent demo.

Closing thought

Agentic R&D is not a feature release. It is a new workload class, and workload classes deserve their own Landing Zone archetype. Microsoft Discovery is the forcing function that will make this visible to most enterprises, but the underlying shift was already in motion.

The teams that treat this as an architectural moment, rather than a tooling moment, will spend the next two years building capability. The teams that do not will spend the next two years writing exceptions.