rss.livelink.threads-in-node

Announcing the Open-Source Release of ML Video Codec (MLVC)

Naba_Kumar — Fri, 24 Jul 2026 21:39:05 GMT

Video codecs compress video for transmission or storage, reducing bandwidth and storage requirements. MLVC is a modern machine-learning-based codec that uses substantially less bandwidth than conventional codecs, improving streaming and video-call quality—especially on constrained or unreliable networks—while lowering delivery and storage costs.

MLVC is the product iteration of DCVC (Deep Contextual Video Compression) family of NVC (Neural Video Codec), open sourced by Microsoft Research since 2021, with improved compression efficiency, real-time performance on commodity Neural Processing Units (NPUs), and cross-platform support. We recently published this work in the paper MLVC: Multi-platform Learned Video Codec for Real-World Deployment. We are releasing the source code because we believe the next generation of video coding will be built openly, and we want the broader community — researchers, video codec engineers, platform vendors, product teams, as well as general developer community — to build it with us.

Why MLVC

Traditional video codecs (e.g., H.264/AVC, H.265/HEVC) have served the industry for a long time, but each generation requires enormous engineering effort for incremental gains and needs dedicated hardware which takes years to become commonly available. MLVC replaces conventional primitives — motion estimation, transforms, entropy modeling — with end-to-end learned neural compression, trained directly against rate-distortion objectives, and run on general-purpose NPU devices.

The table below compares MLVC to popular video codecs, showing its lower bitrate and resulting savings in bandwidth and storage.

Resolution	vs H.264	vs H.265
360p	87.8%	75.5%
540p	82.7%	65.4%

For example, for 360p video at 30 fps, where H.264 requires 1 Mbps, MLVC requires roughly 122 kbps for equivalent quality — about one-eight the bitrate under real-time conditions. The inference compute was kept approximately equal for the 360p and 540p resolutions. These results are based on a P.910 subjective test and are based on the Video Conferencing Dataset (VCD) dataset that we developed and also recently released as an open-source project.

The following video demo illustrates the extent of quality enhancement achieved by MLVC relative to H.265/HEVC at the same bitrate of 200kbps (please watch by opening in a new window for better demonstration)

Beyond video compression efficiency, MLVC also offers:

NPU-first design. MLVC is built to run almost entirely on the AI accelerators already shipping in modern devices — Apple Neural Engine, Qualcomm and Intel NPUs — at no more than 50% NPU utilization, leaving NPU headroom for the rest of the system.
Real-time execution at the targeted operating points. Demonstrated 540p at 30 fps on Apple, Intel, and Qualcomm hardware.
A scaling-law trajectory. Empirically, MLVC's coding efficiency improves with increased model capacity and additional training compute.
Content-adaptive behavior out of the box, without hand-tuned Rate Distortion Optimization heuristics.

Already running in Microsoft Teams

MLVC is more than just a research concept for Microsoft. We are currently rolling it out in Microsoft Teams, where it is being validated on real peer-to-peer video calls with active telemetry and A/B testing. The integration runs alongside fallback to conventional video codecs for hardware or reliability constraints — the kind of mixed-environment deployment that real products need. The scaling and reliability insights from this rollout are shaping the codec and its roadmap.

We welcome your contributions

We can not cover every use case, every device class, or every content domain by ourselves. That is why we are open sourcing MLVC. If you work on:

Streaming, Video On Demand (VOD), or live broadcast
Real-time communication and conferencing
Cloud gaming or remote rendering
Surveillance, drones, or robotics
Mobile capture, Augmented Reality (AR) / Virtual Reality (VR), or volumetric video
Codec hardware, NPUs, or inference runtimes

We would love your help. Contributions of all kinds are welcome, including model improvements, training recipes, new platform ports and conversion targets, runtime backends, domain-specific fine-tunes, evaluation tooling, bug reports, and feedback on what is missing for your scenario. We particularly welcome platform ports that expand NPU coverage and efficiency improvements that push the rate-distortion frontier.

What's in the release

The MLVC repository is available at https://github.com/microsoft/mlvc and shared under the MIT License. It includes:

MLVC model source code of the full network architecture.
Trained model weights ready to run.
Training scripts used to produce shipping models.
Training data collection documentation to help reproduce and improve MLVC.
Platform conversion scripts to target different NPUs and runtimes.

Issues and pull requests will be open from day one.

A follow-up release will add a C++ codec library, simplifying integration into real-world applications.

Where we're heading

Our long-term goal with MLVC is to create an open, learned video codec that meets or exceeds the coding efficiency of the best conventional codecs across the full range of video content, runs efficiently on the AI hardware already shipping in client and cloud devices, scales with compute the way modern ML systems do, and evolves in the open at the pace of the ML community rather than the pace of standardization cycles.

In the near term that means stabilizing 540p real-time performance, expanding hardware coverage, and improving loss resilience. In the medium term: higher resolution, e.g., 1080p, and broader streaming scenarios. In the long term: an open video codec ecosystem that meaningfully replaces legacy stacks where it makes sense to.

We can't create the future of MLVC alone. We're glad you're here, and we are looking forward to building the next-generation video codec with you.

Who are we

MLVC is brought to you by the following awesome folks working on the project at Microsoft: Ross Cutler, Ando Saabas, Tanel Pärnamaa, Ardi Loot, Haiyan Xie, Lauri Ehrenpreis, Andrei Znobishchev, Martin Lumiste, Evgenii Indenbom, Yan Lu, Bin Li, Jiahao Li, Naba Kumar, Babak Naderi, Juhee Cho, Badal Yadav, Jinxin Zhou, Tianyu Ding, Patrick Gregory.

— The MLVC Team, Microsoft

Your Entire Agentic AI Workflow, Now Inside VS Code: New Course Available

carlottacaste — Fri, 24 Jul 2026 09:20:31 GMT

If you build with AI, you know the tax: jumping between a browser portal to pick a model, a terminal to run it, a separate playground to test a prompt, and finally your editor to write the code. Every context switch is a small drain on focus—and it adds up.

What if the whole loop lived in the one tool you never leave?

That's the promise of the Foundry Toolkit for Visual Studio Code, and it's exactly what our new VS Code Learn: Foundry Toolkit video series is here to show you. Whether you're deploying your first model or wiring up your first agent, the series walks you through doing it all without leaving your editor.

👉 Watch the full playlist: aka.ms/Learn/Foundry

What is the Foundry Toolkit?

The Foundry Toolkit is a Visual Studio Code extension that brings Microsoft Foundry directly into your development environment. Instead of hopping between the portal and your editor, you get a single, integrated surface to:

Sign in to Microsoft Foundry and connect your workspace without leaving VS Code.
Browse the model catalog and work with the models that fit your scenario.
Build, test, and iterate on AI agents as a natural part of your coding workflow.
Explore the toolkit UI designed to keep discovery, experimentation, and code in one place.

In short: it turns your editor into the command center for your agentic AI work.

What you'll learn in the series

The series is built to take you from "just installed it" to "shipping with it," one focused episode at a time. Across the playlist you'll learn how to:

Get set up — install the extension, sign in to Microsoft Foundry, and get oriented in the UI.
Work with models — navigate the toolkit to find and use the right model for your task.
Develop AI agents — go from an idea to a working agent, all inside VS Code.
Fit AI into your existing flow — pair the toolkit with GitHub Copilot and the tools you already use every day.

Each video is short, practical, and hands-on—perfect for watching alongside your own editor so you can follow along in real time.

Featured episode: Your Entire Agentic AI Workflow Now Inside VS Code

Not sure where to jump in? Start here. In this episode we run through installation, signing in to Microsoft Foundry, and a tour of the toolkit UI—the essential first steps that get you productive fast.

▶️ Watch: Your Entire Agentic AI Workflow Now Inside VS Code

By the end you'll have the extension installed, be connected to Foundry, and know your way around the interface—ready to move on to models and agents.

Prefer to read and follow along? There's a hands-on course too

The video series has a companion: a brand-new, step-by-step written course on the Foundry Toolkit on the VS Code docs, authored by Chris Noring. It's the perfect complement to the videos—read the lesson, try it in your editor, then watch the walkthrough to reinforce it (or the other way around).

📚 Read the course: https://aka.ms/foundry_toolkit_vscode_learn

Together, the videos and the course give you two ways to learn the same material—watch it, then do it.

Who is this for?

Developers new to AI who want a guided, low-friction on-ramp into building with models and agents.
Experienced builders who want to collapse their model-to-code loop into a single tool.
Teams standardizing on VS Code who want their AI workflow to live where their code already does.

No deep machine-learning background required—if you're comfortable in VS Code, you're ready.

Get started today

Watch the featured episode to get set up: Your Entire Agentic AI Workflow Now Inside VS Code
Work through the full series: aka.ms/Learn/Foundry
Follow the written course on VS Code docs to build alongside each lesson:
aka.ms/foundry_toolkit_vscode_learn

Bring your models, your agents, and your code into one place. Your editor is about to get a whole lot more capable.

Changing the engine while the plane is flying: migrating 60,000 apps under live load

AbodeSaafan — Thu, 23 Jul 2026 20:05:25 GMT

Summary

Azure Logic Apps Consumption Integration Accounts were served by roughly 60,000 per-customer Azure Functions apps on the end-of-life v1/v2 runtime. Over about two years we migrated the entire fleet to Functions v4 (isolated worker), across all Azure regions, with no migration work required from customers. Here is the whole approach before the deep dive:

Shadow traffic. Run real production traffic through the new runtime in parallel with the old one and compare every result, without ever letting the unproven path serve the customer (Sections 5 and 6).
A parity bar we could defend. Compare 100% of eligible traffic, separate genuine bugs from naturally nondeterministic workloads, and fix every real divergence before moving anyone (Section 6).
A progressive, reversible rollout. Shift traffic by a hash-based rate, region by region, with a configuration-only rollback that takes effect in minutes (Section 7).
Careful retirement. Stop the old apps first, observe, and only then delete, with a long reversible gap (Section 9).

Why this was possible without customer involvement: we own and operate the compute, the durable customer data (agreements, maps, schemas) never moved, and the actions are pure transforms, so we could run both runtimes on the same traffic and compare them behind our own control plane. The result was an aggregate cutover with no material latency or error regression, with one honest caveat: a small subset of customers hit a brief edge case under high load before we rolled back (Section 10).

1. The hard part wasn't the new runtime, it was proving the old one could be replaced

Azure Logic Apps Consumption Integration Accounts power critical behind-the-scenes work in enterprise integration: schema and map storage, XML and flat-file transforms, partner and agreement resolution, and the connectors that lean on them. That work is live, multi-tenant, and always on. Customers don't schedule downtime for it, and neither can we.

Under the hood, those capabilities were served by Azure Functions apps running on runtime v1/v2. Those apps executed the Integration Account actions (transforms, lookups) while the durable data itself (agreements, maps, schemas) lived in storage they didn't own. Those runtime versions have reached the end of their supported life, and staying on them was its own growing risk. Moving to a supported runtime was part of a broader modernization effort: it restored a healthy security- and dependency-update path immediately, and it opened the door to newer .NET down the road. The destination was clear: Azure Functions v4.

Here's the catch that made this more than a version bump. We couldn't prove compatibility from a test environment. The behavior we had to preserve was the behavior real customer workloads depended on, in production, across many regions. A staging suite gives you confidence; it doesn't give you proof.

So we built a migration path around a simple idea. Let the old runtime keep serving the live path while the new runtime processes the same real traffic in parallel, and don't move anyone until the data says it's safe. This post is how we did that: shadow traffic, a parity bar we could defend, a progressive rollout with a fast way back, and a guardrailed path to finally retire the old apps.

Figure 1. Before and after. A new v4 app is provisioned per classic app (one-to-one) and reads the same durable data, which never moves. Customers stay on classic until parity is proven.

2. Why Functions v4, and why we couldn't just flip a switch

The move to v4 is also a move to the isolated worker model. On v1/v2, our code ran in-process with the Functions host. On v4 it runs in an isolated worker process, decoupled from the host. That decoupling is exactly what a modern, supportable runtime looks like, but it's also a breaking change in how the code is hosted, which is the crux of why this couldn't be a quick switch.

We considered the usual lighter-weight options and ruled each out for this workload:

In-place upgrade. Going from v1/v2 to the v4 isolated worker isn't an in-place runtime bump; it's a host-model change. There's no safe "upgrade the live app and hope" here.
Deployment slots or blue-green alone. Slots solve routing, not proof. Even with staged or split routing, moving customer traffic across a fleet of roughly 60,000 per-customer apps before we'd proven the new app matched the old one on real requests would still be a blind behavioral bet.
Maintenance windows. Integration Accounts are live customer infrastructure. There's no acceptable downtime budget for this surface.

Which points at the thesis of the whole project: the approach we chose is more complex for us, but simpler for the customer. We absorbed the complexity so customers wouldn't have to. This was only possible because of where the work sat: we own and operate these Functions apps, the durable customer data never moves, and the actions are pure transforms, so the whole migration could happen behind our control plane without customers changing, redeploying, or even knowing which runtime served a given call.

3. The shape of the problem

A few properties made this harder than a typical app move:

Per-account compute at fleet scale. Integration Account capabilities were backed by Functions apps at a per-account granularity, so "migrate the app" really meant "migrate a fleet of roughly 60,000 apps" across all Azure regions.
A small number of shared platform workloads. Alongside the per-account apps, a few shared platform workloads served cross-cutting functionality. There's only one set of them per region, so they had a different blast radius and needed their own, more cautious targeting (Section 7).
Stateless compute. The durable Integration Account data (agreements, maps, schemas) lives in storage and did not move; those stateful assets stayed exactly where they were. We were migrating compute, not customer data, which kept the parity surface smaller than it first appears.
A runtime decaying under time pressure. One risk was easy to underrate: the longer we stayed on the deprecated v1/v2 platform, with no security-patch path and no dependency updates, the more its reliability could erode underneath us. "Do nothing" wasn't a safe holding pattern.

The bar we set ourselves was to keep customer-visible disruption as close to invisible as we could make it, and to prove we were hitting that bar with data rather than assert it.

4. The confidence ladder

Instead of a cutover, we built a progression. Each rung had to hold before we climbed to the next:

Provision alongside. Stand up a new v4 app next to the classic app; change nothing customers touch.
Validate parity. Make the v4 app's behavior equivalent to classic (Section 5).
Shadow real traffic. Send real traffic to v4 in parallel while classic still serves the workflow; compare results (Section 6).
Analyze mismatches. Triage every divergence, fix forward, and raise the bar until any residual divergence is understood and explainable.
Rate-gated cutover. Move a controlled, hash-based fraction of traffic to v4, region by region (Section 7).
Stay rollback-ready. Keep a fast, fine-grained way back at every step (Section 7).
Stop, then delete, carefully. Retire classic only after guardrails prove it's safe (Section 9).

Figure 2. The confidence ladder. Each rung had to hold before we climbed. Rollback stayed available throughout, and retirement (stop first, delete much later) came last.

This ladder is the spine of everything below.

5. Parity foundation: what had to be equivalent

Because the durable Integration Account data stayed in storage, parity wasn't about copying state. It was about one question: does the v4 code package produce the same observable output as the classic one, for the same input? Every action an app could perform had to behave equivalently between the in-process host (v1/v2) and the isolated worker (v4).

The subtle part is that the host-model change can shift behavior you never explicitly wrote. The clearest example is JSON serialization. The in-process and isolated worlds start from different serializer defaults, so the same object can render differently: timestamp formats, enum representations, and the like. For customer output to stay reliably equivalent, byte-for-byte where customers observed exact serialized values, those defaults couldn't be left to chance. (The concrete bug this caused, and how shadow caught it, is in Section 6.)

So "validate parity" meant pinning the things that change observable behavior (runtime and dependency versions, host and app configuration, and serialization settings) and then letting real traffic be the judge of whether we'd actually achieved it.

6. Shadow mode: the showpiece

This is the heart of the migration. For an app in shadow mode, every eligible call still went to the classic runtime, and the workflow received the classic result. In parallel, we sent the same call to the v4 app and compared the two responses, emitting a match/mismatch signal. The workflow was never given the v4 result while we were still proving it. A v4 shadow error or slow response stayed off the customer path entirely and could only ever influence our telemetry and gating, never the result the workflow received.

For each shadowed request we compared the status code, the action or outcome code, and the output payload, the signals that define a correct result. We also captured request timings, but as a health and regression signal, not as part of the match/mismatch verdict.

Why was this safe to do at all? The obvious objection to running every request twice is side effects: wouldn't the parallel call double real-world actions? For this workload, no. Integration Account actions are essentially pure transforms, meaning transforms and metadata lookups that read the durable Integration Account data and produce an output, without writing to any external customer system. The shadow call computes a result and we compare it; nothing is being written anywhere, so there was nothing to double. That property is what made full-traffic shadowing safe by construction.

Because it was safe, we didn't sample. When an app was in shadow mode we compared 100% of its live traffic, every eligible request. "Eligible" simply excluded apps opted out at the resource level (for example, unsupported special-case apps on an exclusion list); everything else was compared.

We started strict, requiring a full JSON match, then relaxed to a normalized comparison so that formatting noise wasn't miscounted as a real difference. But some customer workloads are legitimately nondeterministic: they embed random values or timestamps, so classic itself won't return an identical response twice. To separate "v4 is wrong" from "this operation is inherently nondeterministic," we added a deterministic-match mode. For a shadowed request, we also called classic a second time. The logic is simple:

If v4 disagrees with classic's first response and classic's second response also disagrees with its first, the operation is nondeterministic, and the v4 "mismatch" is discounted.
If v4 disagrees but the two classic calls agree with each other, that's a real v4 divergence to fix.

Crucially, that extra classic call ran off the customer path, and only on the handful of apps already showing mismatches, so it added no customer-visible latency and was never an always-on tax. Shadowing itself (classic plus one v4 call) covered 100% of eligible traffic; the extra classic call existed only for those already-mismatching apps.

When the two disagreed, the migration team triaged the divergence. Cases sorted, informally, into a few recognizable buckets: serialization and format differences, customer nondeterminism, transient infrastructure blips, and genuine v4 logic bugs. We didn't formalize that into a tracked taxonomy. We also watched the asymmetric cases, where classic succeeds but the v4 shadow call errors, or the reverse. We read these as ordinary infrastructure noise rather than v4 defects because of their shape: they stayed at very low rates, correlated in time with known regional blips, and showed no app-specific concentration, so they didn't materially gate an app's readiness.

There was no single magic number to advance, but the judgment wasn't loose either. Before an app's traffic could move we wanted a sustained, near-100% normalized match with no unexplained systemic divergence, its asymmetric failures reviewed and understood, and stable v4 error and latency signals through a bake period. Within those guardrails the final call was operational judgment, and we also weighed known quirks like cold starts occasionally causing a failure or a retry alongside the overall match rate.

The best evidence the method earned its cost is a real bug it surfaced before any customer was affected: the serializer-defaults divergence from Section 5. In-process v1 and isolated v4 serialized certain values differently out of the box, so v4's output didn't match classic's for things like timestamps and enums. Shadow flagged the mismatch; the fix was to explicitly pin v4's JSON serialization options to match the classic runtime, making customer output identical again. Without shadow, that's exactly the kind of quiet difference that ships and generates confused support tickets weeks later.

Running both worlds isn't free. Shadowing roughly doubles compute and the read-only dependency calls that go with it. We absorbed that by standing up the v4 apps on their own dedicated App Service Plans, isolating their capacity so the shared downstream services stayed healthy. Relative to each region's overall load the added traffic wasn't a large delta, and because it ran on isolated, monitored capacity behind the same switches, we could cut it instantly if it ever strained anything downstream. Per app, shadow typically ran for weeks before cutover, and longer in the early stages while we built confidence that the pattern held across the fleet.

Figure 3. Runtime routing. Solid lines are the customer path; dashed lines run off it. In shadow, the workflow always gets the classic result while v4 runs in parallel and only emits a match/mismatch signal.

7. Controlling blast radius, rolling out, and watching it land

Parity earns the right to move traffic; control is what lets you move it safely.

Traffic moved by a hash-based exposure rate keyed on a stable resource or tenant identifier. The hash is deterministic: for a stable identifier, the same account maps to the same bucket, so an app stays put on classic or v4 and never flip-flops between them as the rate ramps or as we roll region to region. That stability matters, because it prevents apps from oscillating across deployments.

Layered control came from four switches: a master switch, a mode selector (classic, shadow, or v4-only), the percentage-based rate, and resource-level exclusion controls. The exclusion controls were the emergency brake: name an affected resource and it snaps back to classic, with no deployment required, effective within a few minutes.

We advanced through safe-deployment rings, and we deliberately started where a mistake would hurt least: early canary and test regions, then internal-to-Microsoft accounts, and only then the broader regions. Advancing a ring was a monitor-and-judge decision against rich telemetry. We checked the prior ring's rates, confirmed the target region was healthy, let earlier regions bake, and watched how they behaved under customer-traffic spikes before moving on.

Stage / ring	Advance gate	Signals watched	Halt / rollback action
Canary + test regions	Sustained near-100% normalized match; no open systemic mismatch; stable v4 error/latency through bake	Match rate, v4 error rate, latency, customer-reported incidents	Exclude resource(s) to classic in minutes
Internal-to-Microsoft accounts	Prior ring's gates still green at higher scenario variety; asymmetric failures reviewed and understood	same	Hold ring or roll back via config
Broad regions (safe-deployment rings)	Prior-ring gates held, target region healthy, bake time elapsed	same plus behavior under traffic spikes	Exclusion controls or lower the rate

When a signal turned, whether a dip in match rate, a rise in v4-only errors, a latency regression, or a customer-reported incident, we could hold the ring or roll back. The rollback is just a configuration change that takes effect in a few minutes, and it wasn't theoretical: we exercised it for real several times (most notably for a high-load edge case, and on some internal apps), which means it was battle-tested under real load, not just on paper.

The migration team owned the rollout day to day, driving ring advancement, watching the dashboards, and making the advance, halt, and rollback calls, with standard on-call and incident processes layered on top, so a customer-reported incident paged the on-call engineer through the normal channels.

None of this is safe if you can't see it. We invested heavily in dashboards, metrics, and counters, and fed mismatch and health signals (non-reversible telemetry, not payload logging) into health and mismatch dashboards. The loop was simple and strict: signal, triage, gate decision. A batch advanced only when the telemetry said it had earned it.

Figure 4. The observability loop. Signal, triage, then gate decision: a batch advanced only when telemetry (parity and v4 health) said it had earned it; otherwise it held, rolled back, or was fixed forward.

8. Keeping shadow traffic safe

Shadowing real customer traffic is a privacy responsibility, not just an engineering technique, so we designed the comparison to need no customer data at rest. The comparison happened in memory, in the moment: we never logged PII or customer payloads. What we emitted were signals, not data, meaning match/mismatch outcomes and metrics designed not to reveal or reconstruct the underlying content. Because comparisons were transient and no payload was ever logged or retained, the design avoided creating a new customer-data-at-rest surface, so there's no store of sensitive traces to govern. The platform's standard runtime access controls and operational safeguards still applied to the live path itself. And as covered in Section 6, because the actions are pure transforms, the shadow path produced no duplicate customer-visible side effects.

That privacy choice came with a real tradeoff. Because we never captured payloads, a handful of mismatches simply couldn't be reproduced from the signals alone. For those, we reached out to the affected customers directly and, with their help, collected example maps and inputs that let us reproduce the divergence in a controlled setting, root-cause it, and fix it. Trading a little investigative convenience for keeping customer data out of our telemetry was the right call, and customers were glad to help us close real bugs.

9. Retiring the old world: stop, then delete, with guardrails

A migration isn't done when traffic moves; it's done when the old system is safely gone. We deliberately separated stopping from deleting, with a long, reversible gap between them.

Confirm, then disable. After an app cut over, we first confirmed via telemetry that no traffic was still reaching the classic app, then disabled it through a per-region configuration. Disabled but not deleted means quickly restorable if anything surfaced.
Observe. We waited again after disabling, watching for anything to break, before considering deletion at all.
Delete last, and only in bulk confidence. We only began deleting classic apps after most apps across most regions had been disabled for a sustained period. Deletion is the final, irreversible stage, gated on a long, successful disabled window rather than done eagerly per app.

Retirement safety, in one line: traffic fully moved, no remaining callers, disabled (reversible), observation window elapsed, and only then delete.

10. Results, lessons, and what's next

By the numbers (rounded):

Scale. Roughly 60,000 Functions apps migrated, across all Azure regions.
Shadow volume. At peak, the fleet compared on the order of hundreds of millions of requests per week, with 100% of eligible traffic compared, not a sample.
Parity arc. The match rate climbed in step-changes, each driven by a big, systemic fix: serialization pinning chief among them, alongside alignments in host and DI configuration and dependency versions. After those landed, it was mostly smooth, with only minor or nondeterministic residue.
Cutover impact (fleet level). Cutover was intentionally uneventful in aggregate: aggregate latency and error-rate telemetry showed no material regression at the moment of switch, because shadow had already proven parity. That's a fleet-level signal, not a promise of zero individual impact; see the honest caveat below.
Timeline. A little over two years: roughly year one achieving and confirming parity via shadow, and year two moving real traffic and then retiring the old apps.

An honest caveat, because "zero impact" would be too strong. Safe deployment and shadowing caught the overwhelming majority of issues before customers saw them, and most customers had to do nothing. But it wasn't perfectly invisible: a small subset of customers hit an edge case under high load and experienced brief, real impact before we rolled back and coordinated a minor adjustment. Rollback did its job; we used it several times early on, then rarely once the big fixes were in. The incident trend followed the same shape: a few incidents up front while the systemic fixes landed, then quiet.

Lessons worth keeping:

A parity bar is only credible if it accounts for nondeterminism. The "call classic twice" trick was what let us tell a real v4 bug apart from a workload that simply never repeats itself, and enabling it selectively kept it from costing customers latency.
The host-model change hides in serialization. The most important fix wasn't in business logic; it was pinning serializer settings so v4's output matched the classic runtime exactly.
No side effects, no duplication risk. Because the actions only read data and compute, with nothing written to any external system, we could shadow all traffic safely. That single property is the biggest reason this approach was even available to us.
Signals beat payloads. Comparing in memory and emitting only non-reversible signals gave us the confidence of full-traffic comparison without the liability of storing customer data.
Separate "stop" from "delete." The long, reversible disabled window turned the scariest, irreversible step into a calm one.

What's next: customer traffic is on v4, and we have already deleted the large majority of the classic v1 apps. What remains is the final cleanup, removing the last disabled classic apps in the trailing regions and finishing the more cautious retirement of the shared platform workloads. The migration itself is done; the remaining deletion is deliberately unhurried.

The broader takeaway is that shadow traffic plus a progressive, reversible rollout is a repeatable pattern for replacing a runtime under live, multi-tenant load. Customers still carry real risk when the infrastructure under them changes; what this pattern shifts is control. The team that owns the migration absorbs the complexity and holds the levers to prove parity, gate the rollout, and reverse it, so customers don't have to manage the change or its mitigation.

Introducing Kubernetes-Native Policy Validation with CEL and VAP in Azure Policy

stevenbucher — Thu, 23 Jul 2026 19:27:12 GMT

Azure Policy for Kubernetes now supports Gatekeeper’s integration with native Kubernetes Validating Admission Policy (VAP) using Common Expression Language (CEL)! This integration leverages the new VAP feature introduced in Kubernetes 1.30, providing a more efficient, reliable and in-process way to enforce policies.

This integration brings lower latency for admission decisions, simpler constraint template authoring—for the first time – allows you to enable stronger fail-close behavior to prevent non-compliant components getting created or updated in your environment . And you keep all the Azure Policy benefits you already rely on like centralized assignment, scope management, safe rollout control, and governance at scale.

Previously, Azure Policy for Kubernetes only supported on OPA Rego-based evaluation through an admission webhook flow:

A request is sent to the Kubernetes API server.
The request is forwarded to Gatekeeper.
Gatekeeper enforces resources using constraint template written in Rego.
The result is returned to the API server.

Native Kubernetes Validation with Common Expression Language (CEL)

Policy expressions can be written in CEL syntax, a lightweight and expressive language that Kubernetes designed specifically for this validation context. Here's what changes:

In-tree evaluation: Policy rules run inside the Kubernetes API server itself, not in an external webhook service. This means:
Lower latency: No round-trip delay to an external service. Admission decisions are made faster because evaluation happens in-process.
Better reliability: Validation doesn't depend on a separate service remaining healthy. If the VAP controller finds a violating resource, the PUT request will be denied, resulting in a fail-close scenario.

Getting Azure Policy Benefits with CEL

Kubernetes-native enforcement does not replace Azure Policy governance capabilities. It strengthens them. Azure Policy becomes the governance and deployment layer, while CEL becomes the validation logic. Here's what that means:

CEL handles the validation: You write lightweight, readable expressions that run natively in Kubernetes. CEL is simpler than Rego and aligns with Kubernetes' own validation framework.
Azure Policy handles the governance: Assignments, versioning, compliance tracking, safe rollouts, overrides, and multi-cluster management all happen through Azure Policy. You get enterprise governance without extra operational overhead.

Your First CEL Policy with Azure Policy

Here's the key insight: you don't write Azure Policy definitions in CEL. Instead, you write a CEL constraint template, package it inside an Azure Policy definition, and deploy it through Azure Policy.

Think of it as two layers:

Layer 1: CEL Constraint Template — The Kubernetes validation logic you write
Layer 2: Azure Policy Definition — The wrapper that adds assignments, versioning, compliance tracking, and safe deployment

Real Example: Limit Deployment Replicas

Let's walk through a concrete scenario. Your platform team wants to prevent developers from creating Deployments with more than 5 replicas—a common guard rail for dev/test environments to control resource consumption.

- replicas: 1 through replicas: 5 — allowed

- replicas: 6 or higher — denied

Step 1: Write the CEL constraint template

You write a Gatekeeper ConstraintTemplate using the K8sNativeValidation engine. The CEL expression itself is a single, readable line:

apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8se2etestcelmaxdeployreplicas spec: crd: spec: names: kind: K8sE2ETestCelMaxDeployReplicas validation: # Schema for the `parameters` field openAPIV3Schema: type: object properties: message: type: string targets: - target: admission.k8s.gatekeeper.sh code: - engine: K8sNativeValidation source: validations: - expression: "object.spec.replicas <= 5" message: "message example"

The key part is the engine: K8sNativeValidation block. This tells Gatekeeper to generate a Kubernetes ValidatingAdmissionPolicy resource from this template, so evaluation runs inside the API server rather than through the Gatekeeper webhook. The CEL expression object.spec.replicas <= 5 is evaluated natively at admission time.

Step 2: Package the CEL template into an Azure Policy definition

You then will need to base64-encode the constraint template (you can use an online tool or a local tool to do this) and embed the encoded content in an Azure Policy custom definition using sourceType: Base64Encoded. The full custom policy definition structure, matching the real format Azure Policy expects:

{ "policyType": "Custom", "mode": "Microsoft.Kubernetes.Data", "displayName": "Ensure deployment replicas are less than or equal to 5 in Kubernetes cluster", "policyRule": { "if": { "field": "type", "in": [ "Microsoft.ContainerService/managedClusters" ] }, "then": { "effect": "[parameters('effect')]", "details": { "templateInfo": { "sourceType": "Base64Encoded", "content": "<BASE64_ENCODED_CONSTRAINT_TEMPLATE>" }, "apiGroups": [ "apps" ], "kinds": [ "Deployment" ], "namespaces": "[parameters('namespaces')]", "excludedNamespaces": "[parameters('excludedNamespaces')]", "labelSelector": "[parameters('labelSelector')]", "values": { "message": "[parameters('message')]" } } } }, "parameters": { "effect": { "type": "String", "allowedValues": [ "audit", "deny", "disabled" ], "defaultValue": "audit" }, "namespaces": { "type": "Array", "defaultValue": [] }, "labelSelector": { "type": "Object", "defaultValue": {} }, "message": { "type": "String" } } }

A few things worth noting in this structure:

sourceType: Base64Encoded - Azure Policy stores your constraint template as base64 content inline in the policy definition. When Azure Policy deploys to your cluster, it decodes and installs the template automatically.
apiGroups: ["apps"] and kinds: ["Deployment"] - These scope the policy to only evaluate Kubernetes Deployment resources in the apps API group. Pods, Services, and other resources are unaffected.
excludedNamespaces - System namespaces like kube-system and gatekeeper-system are excluded by default, so the policy doesn't interfere with cluster infrastructure.
effect: audit (default) - The policy starts in audit mode, flagging violations without blocking them. Switch to deny when you're ready to enforce.

Right now only audit, deny, and disabled Policy effects are supported.

You can create the policy definition via the Azure portal, Azure CLI, or the Azure Policy VS Code extension.

Step 3: Assign the policy to your AKS clusters

Now you can assign this policy through Azure Policy to your clusters:

In the Azure portal, go to Azure Policy > Definitions.
Find your policy by name (e.g., "Ensure deployment replicas are less than or equal to 5").
Click Assign.
Set the Scope to the management group, subscription, or resource group containing your AKS clusters.
Set the effect parameter to audit to start, then graduate to deny once you've validated the policy behavior.
Click Create.

Azure Policy deploys the CEL-based constraint template to all clusters in scope. Within a few minutes, the Azure Policy add-on decodes the template, installs it on each cluster, and Gatekeeper generates the corresponding ValidatingAdmissionPolicy resource. From that point on, the Kubernetes API server evaluates every new Deployment admission request against your CEL rule directly. You can target different clusters or namespaces with different assignments and apply overrides for exceptions.

Step 4: Monitor compliance through Azure Policy

In the Azure Policy console, you see real-time compliance across all your clusters:

Non-compliant Deployments (those with replicas > 5) appear in the Compliance view.
You can drill down by policy, cluster, or namespace to see which Deployments are violating the limit.
While in audit mode, existing violations are surfaced without blocking anything—giving you a clear picture before switching to deny.

Availability and prerequisites

Supported Kubernetes version: AKS clusters running Kubernetes v1.30 or later (VAP became generally available in K8s v1.30).
Gatekeeper version: Azure Policy add-on includes Gatekeeper v3.17.0 or later, which supports VAP and CEL policy generation.
Azure Policy Add-on: The Azure Policy add-on for Kubernetes must be installed on your clusters. See Azure Policy for Kubernetes documentationfor installation instructions.

This is currently generally available and can be used to enforce policies in your Kubernetes clusters today.

Roadmap

We are actively working to include more built in Azure Policies for Azure Kubernetes service with the constraint template built with CEL.

Resources

Azure Policy for Kubernetes: Full documentation on how Azure Policy integrates with Kubernetes, including built-in definitions and assignment workflows.
Common Expression Language in Kubernetes: Reference guide for authoring CEL expressions used in Validating Admission Policies.

Conclusion

Azure Policy for Kubernetes now lets you bring Kubernetes-native CEL validation into your enterprise governance workflow.

The mental model is simple: CEL handles what to validate, Azure Policy handles how to govern it. You write clean, readable CEL expressions that run natively in your Kubernetes API server. Azure Policy wraps those expressions and handles the hard parts of enterprise governance—assignments across management hierarchies, versioning, compliance tracking, safe rollouts, and overrides.

Whether you're enforcing container registries, requiring security contexts, or validating resource configurations, you now have a path to do it natively in Kubernetes with enterprise governance backing it up.

Announcing public preview of Azure DDoS Protection custom policy

OfirSarfaty — Thu, 23 Jul 2026 17:16:28 GMT

We are excited to announce the public preview of Azure DDoS Protection custom policy, a new capability that gives customers more granular control over how Azure DDoS Protection detects and mitigates attacks against protected workloads.

Azure DDoS Protection has always focused on delivering automatic, adaptive protection at scale. With custom policy, customers can now fine-tune mitigation behaviour for supported resources and configure protocol-specific detection thresholds. This allows customers to better align protection settings with any planned or projected changes in their application traffic patterns upfront, while giving them additional control over supported protocol thresholds.

Azure DDoS Protection custom policy is currently in preview. See the Supplemental Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet generally available.

Why customers asked for more control

Azure DDoS Protection automatically analyses traffic patterns and applies adaptive mitigation during attacks. While this approach works well for most workloads, some organizations require additional flexibility to support unique traffic characteristics, operational environments, or changes around big releases and events.

Customers running latency-sensitive applications, high-throughput services, gaming platforms, or workloads with predictable traffic spikes often want the ability to customize mitigation trigger behavior for specific protocols.

Example scenarios include:

Applications with known peak traffic periods

Workloads that experience sustained high packet-per-second rates

Services requiring protocol-specific tuning

Organizations that need separate mitigation policies across environments or applications

Custom policy allows organizations to align DDoS protection behaviour with their operational traffic baselines while still leveraging Azure’s global-scale mitigation infrastructure.

Key benefits:

Granular, protocol-level control: Configure custom detection thresholds for TCP, UDP, and TCP SYN traffic, so mitigation triggers reflect how your application behaves rather than generic baselines.
Predictable protection during planned events: Align mitigation behaviour with anticipated traffic changes product launches, seasonal peaks, gaming events, so legitimate traffic surges aren't mistaken for attacks.
Flexibility without sacrificing scale: Fine-tune triggers for specific workloads while still benefiting from Azure's global-scale mitigation infrastructure and adaptive protection everywhere else.
Per-resource policy management: Apply separate policies across environments or applications, giving teams the ability to tune protection independently for dev, test, and production workloads.
Full operational visibility: Existing Azure Monitor and DDoS Protection telemetry continue to work with custom policies, so you can validate threshold changes and monitor mitigation activity end to end.

Public preview walkthrough

Customers can deploy and manage DDoS custom policies directly from the Azure portal.

To create a new policy:

Open the Azure portal.
Search for DDoS custom policies.
Select Create.
Choose the subscription, resource group, and region.
Select a supported frontend IP configuration.
Configure protocol detection rules.
Review and deploy.

Once deployed, the custom policy can be associated with supported frontend IP resources to apply protocol-specific mitigation settings.

Current public preview scope

During public preview, Azure DDoS Protection custom policy supports:

Standard Load Balancer frontend IP configurations

TCP, UDP, and TCP SYN threshold customization

Azure portal management

ARM and REST API deployment

Current limitations include:

Support is currently limited to Standard Load Balancer frontend IPs and no Power Shell support

As with all preview features, functionality and supported scenarios may evolve before general availability.

Important considerations

When a customer configures a custom threshold for a protocol, Azure disables autotuning triggers for that protocol and uses the configured static value.

Customers should:

Use anticipated traffic baselines to guide threshold selection

Start with conservative tuning changes

Validate behaviour in lower environments before broad deployment

Monitor mitigation telemetry after configuration changes

Azure Monitor and existing Azure DDoS Protection telemetry continue to provide visibility into mitigation activity and operational behavior.

Looking ahead

Azure DDoS Protection continues to evolve to support modern application architectures, large-scale internet exposure, and advanced operational requirements.

Custom policy extends Azure DDoS Protection's automatic, adaptive baseline with optional per-resource control, without changing the turnkey default that protects every workload out of the box. Autotuning stays on everywhere a custom threshold is not explicitly configured.

We want customers to know that Azure DDoS continues to be a hands-off fully automated service, and that policy customization is not a new operational model, but rather an optional override-on-top automated/adaptive engine.

Get started

Customers can begin using Azure DDoS Protection custom policy today through the public preview experience.

To learn more:

Review the Azure REST API documentation for DDoS Custom Policies here

Deploy a test policy in a supported subscription

Explore the Azure portal experience for policy management

Evaluate protocol-specific threshold tuning for your applications

We look forward to hearing your feedback.

Design, test, and ship Foundry hosted agents from a canvas in GitHub Copilot App

junjieli — Fri, 24 Jul 2026 09:19:54 GMT

Building a Microsoft Foundry hosted agent has historically meant juggling multiple surfaces — looking up a model deployment in the Foundry portal, wiring toolboxes and skills by hand, copying an endpoint into your editor, then dropping to the CLI to test and deploy. That context-switching adds friction at exactly the moment you want to be experimenting.

Today we're changing that. The Microsoft Foundry Canvas is now in public preview. With this release, the full hosted-agent workflow — discover, scaffold, configure, test, deploy — lives right beside the Copilot chat that's already writing your code.

The Foundry Canvas is a GitHub Copilot App extension that opens a visual canvas in the side panel. You make choices in the canvas, and it hands each step to Copilot with your Foundry project context already attached. Copilot writes the code and runs the commands; the canvas keeps the visual state and your workspace in sync. Here are a few things this unlocks for developers.

🧭 A project-aware canvas, one prompt away

Ask Copilot to create a Foundry hosted agent and the canvas opens automatically, connected to your project. It surfaces what's actually deployed — models, Foundry Toolboxes and their tools, project skills, and account guardrails — so you're choosing from real resources, not a static list.

To get started:

In the GitHub Copilot App, ask Copilot: Create a Foundry hosted agent using the Foundry Canvas.
Open the canvas project menu, sign in to Azure if you're prompted, and pick a subscription.
Select a Foundry project. The canvas remembers your choice across reopens.

✨ Scaffold and configure without leaving the panel

Start from a generated idea with Inspire me, or begin from a Hello world sample. From there, wire the agent to a deployed model and connect any toolboxes, skills, and guardrails. Every selection becomes a project-aware prompt to Copilot, which updates the agent code for you.

To build your agent:

Choose Inspire me for a generated starting point, or the Hello world sample prompt.
Select a deployed model, then connect toolboxes, skills, and guardrails from your project.
Let Copilot apply each change in your workspace as you go.

🔍 Test locally with the embedded Agent Inspector

When you're ready to try it, Inspect Locally runs the agent and embeds the Agent Inspector right in the canvas — no separate REST client, no extra tooling. Chat with the agent, and if something breaks, send the error straight back to Copilot as a fix request.

To test and deploy:

Click Inspect Locally — the canvas runs the agent and opens the Agent Inspector on port 8088.
Send a prompt such as Write a haiku about deploying cloud applications. and iterate.
Click Deploy to Foundry to publish the agent to Foundry Agent Service.

Because Inspect Locally and Deploy to Foundry run the underlying Azure Developer CLI (azd) commands, you're never boxed in — drop back to the terminal whenever you want.

Hosted agents are one of the fastest-growing ways developers build on Microsoft Foundry — from internal copilots to task automation to customer-facing assistants. This release gives you a first-class, visual path to design and ship them faster, without giving up the code-first workflow you already know.

🚀 Get Started Today

Ready to build your first agent from the canvas? Here's how to jump in:

In the GitHub Copilot App, open Settings > Plugins, search for foundry-agent-canvas, and select Install. You can also install it from the awesome-copilot listing or ask Copilot to install it into user scope.
Ask Copilot to create a Foundry hosted agent, then follow the canvas from project pick to deploy.
Walk through it end to end with the Deploy your first hosted agent quickstart, and read the Foundry Canvas overview for the full picture.

We'd love to hear from you! Whether it's a feature request, a bug report, or feedback on your experience, join the conversation and contribute directly on our GitHub repository.

Happy Coding!

Cannot run "Get-SolutionUpdate" or "Get-SolutionUpdateEnvironment" after updating to 2604

MattENZ — Thu, 23 Jul 2026 05:17:13 GMT

My Azure Local environment had been a bit out of date for the last few months so I was catching it up with the updates, stepping from 2602 to 2603 and then to 2604 last night. Since that update, when I run "Get-SolutionUpdate" or "Get-SolutionUpdateEnvironment" the command hangs for a few minutes and then eventually returns with something like the following:

get-solutionUpdate : A WebException occurred while sending a RestRequest. WebException.Status: SendFailure on https://FQDN:4900/providers/Microsoft.Update.Admin/updateLocations?api-version=2022-08-01 + CategoryInfo : ConnectionError: (:) [Get-SolutionUpdate], SendFailureException + FullyQualifiedErrorId : SendFailureException,Microsoft.AzureStack.Lcm.PowerShell.GetSolutionUpdateCmdlet get-solutionUpdate : Object reference not set to an instance of an object. + CategoryInfo : InvalidOperation: (:) [Get-SolutionUpdate], NullReferenceException + FullyQualifiedErrorId : NullReferenceException,Microsoft.AzureStack.Lcm.PowerShell.GetSolutionUpdateCmdlet

I have tried the guide here to try resolve it as it seemed similar but it hasn't helped. Any idea what might be going on?

Hybrid Logic Apps on RKE2: a self-managed cluster with MetalLB

anandgmenon — Thu, 23 Jul 2026 05:53:29 GMT

Azure Logic Apps Hybrid lets you run the Logic Apps runtime on your own Kubernetes cluster and still author, deploy, and monitor from Azure. The previous post walked through Red Hat OpenShift. This one is RKE2. We spun up a single-node RKE2 cluster, gave the ingress an IP with MetalLB, connected it to Arc, and shipped a Hybrid Logic App end-to-end. A handful of things needed care along the way, and those are what this post is really about.

If you've done Hybrid on AKS or K3s, the shape will look familiar. The official requirements doc covers the general flow. RKE2 is close enough to vanilla Kubernetes that most of it just works out of the box. Four things don't. Three of them are DNS. They're called out at the step they matter.

What makes RKE2 different?

Area	What we found
Ingress IP	RKE2 has an embedded cloud-controller-manager for node lifecycle, but no service load balancer. `type: LoadBalancer` sits at `<pending>` until you bring one. We used MetalLB (Step 2).
Pod security	No SCC dance like OpenShift; the extension pods schedule as-is. What we did hit was the node's `inotify` limit. Enough runtime pods use it that the default runs out and about half the deployment crash-loops (Step 4).
CoreDNS	RKE2 names its DNS objects `rke2-coredns-rke2-coredns`, not `coredns`/`kube-dns`. `az containerapp arc setup-core-dns` doesn't have an RKE2 distro flag yet, so DNS is manual (Step 7).
Distribution flag	RKE2 is upstream Kubernetes. Don't copy the OpenShift install command; the `Azure.Cluster.Distribution=openshift` and `coreDNSVersion` overrides don't apply here and will bite you (Step 4).

Prerequisites

A Linux host	Anywhere RKE2 runs: bare metal, a VM, an edge appliance. We used a single Ubuntu 22.04 Azure VM (`Standard_D8as_v5`) so everything was easy to nuke afterwards. 4 vCPU / 16 GB is the practical floor.
Azure subscription	Rights to create Arc resources, custom locations, and connected environments.
Azure CLI	Latest, with the `connectedk8s`, `k8s-extension`, `customlocation`, and `containerapp` extensions.
An SMB file share	Reachable from the cluster, for workflow artifacts.
A spare IP range	A small unused range on your node's L2 network for MetalLB to hand out (Step 2).

az extension add --name connectedk8s
az extension add --name k8s-extension
az extension add --name customlocation
az extension add --name containerapp

Step 1: Stand up RKE2

One line and a couple of minutes:

curl -sfL https://get.rke2.io | sudo sh -
sudo systemctl enable --now rke2-server.service

# kubectl + kubeconfig are dropped in place
export PATH=$PATH:/var/lib/rancher/rke2/bin
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
kubectl get nodes          # Ready in ~2-5 min after the first image pull

RKE2 servers are schedulable by default, so this single node is your entire cluster. No taint to remove. If you want to run kubectl from your laptop, add the node's public IP or hostname to tls-san in /etc/rancher/rke2/config.yaml before the first start, then copy rke2.yaml out and swap 127.0.0.1 for that address.

Quick sanity check. Expose a throwaway nginx as LoadBalancer: kubectl create deploy nginx --image=nginx && kubectl expose deploy nginx --port=80 --type=LoadBalancer. The EXTERNAL-IP will sit at <pending> forever. That's the gap MetalLB fills in the next step. Clean up the deployment and service when you're done looking.

Step 2: Give the ingress an IP with MetalLB

All the Logic Apps in this environment share a single Envoy ingress, and something has to give that service an IP. A cloud does it for you; on-prem, you pick one of two options:

In-cluster load balancer. MetalLB (or Cilium, kube-vip, OpenELB) assigns an IP from a pool on your node network. Leave envoy.serviceType=LoadBalancer in Step 4. This is what we did.
External L4 load balancer in front of NodePort. If you already run an F5, HAProxy, NetScaler, or an Azure Standard Load Balancer, keep using it. Set envoy.serviceType=NodePort (plus envoy.nodeHttpsPort / envoy.nodeHttpPort) and point your LB at those NodePorts. Then pass the LB's VIP as --static-ip in Step 6.

We went with MetalLB in L2 mode:

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.9/config/manifests/metallb-native.yaml
kubectl wait --for=condition=Ready pods --all -n metallb-system --timeout=180s

Then give it a pool from your node subnet and advertise it over L2:

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: hybrid-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.1.240-192.168.1.250   # a spare range on your node network
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: hybrid-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - hybrid-pool

Two things to watch. The range should be free on your node subnet, and it must not collide with RKE2's cluster (10.42.0.0/16) or service (10.43.0.0/16) CIDRs. Re-run the throwaway LoadBalancer test from Step 1; the EXTERNAL-IP should now be one of your pool addresses.

Running MetalLB on one cloud VM? L2 mode ARPs the pool IPs on the node's network, but a cloud SDN won't route an unassigned IP to your NIC from the outside. It works fine for anything inside the cluster (kube-proxy programs the IP locally), but to hit envoy from outside the VM you'll need to socat-forward the VM's public IP to the LB IP, or add the pool IP as a secondary ipconfig on the NIC. On real on-prem L2 you don't have to think about any of this.

Step 3: Connect the cluster to Azure Arc

az connectedk8s connect --name <cluster> --resource-group <rg> --location <region>
kubectl get pods -n azure-arc      # all agents Running in a couple of minutes

If your host is behind a strict egress policy, or in our case an internal MS VM with an inbound-deny NRMS policy, remember that Arc onboarding only needs outbound connectivity and a local kubeconfig. We ran the connect command on the VM itself using a system-assigned managed identity (az login --identity). No inbound port, no browser device-code prompt.

Step 4: Install the Container Apps extension

This is the extension that turns the cluster into a Logic Apps host. On RKE2 it's the plain command, with no Azure.Cluster.Distribution or coreDNSVersion overrides. If you copy those from an OpenShift guide, the install will still succeed and then behave in mildly confusing ways.

az k8s-extension create \
  --resource-group <rg> --cluster-name <cluster> \
  --cluster-type connectedClusters --name logicapps-aca-extension \
  --extension-type Microsoft.App.Environment \
  --release-train stable --auto-upgrade-minor-version true --scope cluster \
  --release-namespace logicapps-aca-ns \
  --configuration-settings "Microsoft.CustomLocation.ServiceAccount=default" \
  --configuration-settings "appsNamespace=logicapps-aca-ns" \
  --configuration-settings "clusterName=<env-name>" \
  --configuration-settings "keda.enabled=true" \
  --configuration-settings "keda.logicAppsScaler.enabled=true" \
  --configuration-settings "keda.logicAppsScaler.replicaCount=1" \
  --configuration-settings "containerAppController.api.functionsServerEnabled=true" \
  --configuration-settings "functionsProxyApiConfig.enabled=true" \
  --configuration-settings "envoy.serviceType=LoadBalancer"

Our first install came back "Succeeded", but half the pods were in CrashLoopBackOff. billing, containerapp-controller, keda-logicapps-scaler, mdm, and log-processor all had the same line in their logs:

The configured user limit (128) on the number of inotify instances has been reached

These are .NET services with FileSystemWatcher under the hood. The default fs.inotify.max_user_instances=128 on stock Ubuntu is comfortably below what the extension needs. Raise it on the node, delete the pods, done:

sudo sysctl -w fs.inotify.max_user_instances=8192
sudo sysctl -w fs.inotify.max_user_watches=1048576
echo -e "fs.inotify.max_user_instances=8192\nfs.inotify.max_user_watches=1048576" | sudo tee /etc/sysctl.d/99-inotify.conf
kubectl delete pods --all -n logicapps-aca-ns

After that everything came up green, and envoy grabbed a MetalLB address on its own. Confirm:

az k8s-extension show -g <rg> --cluster-name <cluster> \
  --cluster-type connectedClusters --name logicapps-aca-extension \
  --query provisioningState -o tsv          # -> Succeeded
kubectl get svc microsoft-app-environment-k8se-envoy -n logicapps-aca-ns   # EXTERNAL-IP from your pool

Step 5: Create a custom location

Turn on the custom-locations feature, then create the location that ties the cluster, extension, and namespace together:

az connectedk8s enable-features -n <cluster> -g <rg> \
  --features cluster-connect custom-locations \
  --custom-locations-oid $(az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query id -o tsv)

EXT_ID=$(az k8s-extension show -g <rg> --cluster-name <cluster> \
  --cluster-type connectedClusters --name logicapps-aca-extension --query id -o tsv)
CC_ID=$(az connectedk8s show -g <rg> -n <cluster> --query id -o tsv)

az customlocation create \
  --resource-group <rg> --name <custom-location> \
  --location <region> --host-resource-id $CC_ID \
  --namespace logicapps-aca-ns --cluster-extension-ids $EXT_ID

One thing we tripped on: the extension type isn't offered in every Azure region. It's registered in eastus, westus, westeurope, and a handful of others, but not eastus2 at the time of writing. The connectedCluster resource's region is independent of where the node actually runs, so pick a supported one here.

Step 6: Create the connected environment

CL_ID=$(az customlocation show -g <rg> -n <custom-location> --query id -o tsv)

az containerapp connected-env create \
  --resource-group <rg> --name <env-name> \
  --location <region> --custom-location $CL_ID

Because MetalLB already put an EXTERNAL-IP on the envoy LoadBalancer service, the platform picks it up automatically. --static-ip is only needed if you went the NodePort + external LB route in Step 2, in which case you pass your LB's VIP here.

Step 7: Configure cluster DNS

App hostnames like *.<env>.<region>.k4apps.io need to resolve to the Envoy ingress from inside the cluster. On AKS or OpenShift, az containerapp arc setup-core-dns handles this. RKE2 isn't a supported distro on that command yet, so it's manual, but it's a small manual.

The extension already writes the correct rewrite and forward rules into a coredns-custom ConfigMap. What's missing is CoreDNS mounting that ConfigMap and importing it from the Corefile.

We tried the direct route first: patch the Corefile ConfigMap, edit the Deployment to add the volume, restart. It works, right up until the next rke2-server restart. RKE2's helm controller re-renders both objects from the chart and wipes your changes. The right way is a HelmChartConfig. The rke2-coredns chart exposes extraConfig (config outside the default zone block) and extraVolumes/extraVolumeMounts, which is exactly what we need:

# /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-coredns
  namespace: kube-system
spec:
  valuesContent: |-
    extraConfig:
      import:
        parameters: /etc/coredns/custom/*.server
    extraVolumes:
      - name: custom-config-volume
        configMap:
          name: coredns-custom
          optional: true
    extraVolumeMounts:
      - name: custom-config-volume
        mountPath: /etc/coredns/custom

Drop the file in /var/lib/rancher/rke2/server/manifests/, or kubectl apply -f it (the helm controller watches both). Within a minute CoreDNS redeploys with the mount and the top-level import. This time it survives restarts and RKE2 upgrades because the chart is now the source of truth.

To verify, run nslookup test.<env-domain> from a throwaway pod. You should get back the microsoft-app-environment-k8se-envoy-internal ClusterIP.

One last DNS thing: a kube-dns alias. The Logic Apps platform locates cluster DNS by looking for a Service named kube-dns in kube-system. That's the convention on AKS, K3s, kubeadm, and most other distros. RKE2 uses rke2-coredns-rke2-coredns and doesn't ship the alias, so the platform can't find DNS. Symptom: revision calls come back as 502s. Fix: create the alias.
apiVersion: v1
kind: Service
metadata: { name: kube-dns, namespace: kube-system, labels: { k8s-app: kube-dns } }
spec:
  selector: { k8s-app: kube-dns }
  ports:
    - { name: dns, port: 53, protocol: UDP, targetPort: 53 }
    - { name: dns-tcp, port: 53, protocol: TCP, targetPort: 53 }
It's a plain Service. Nothing about it gets templated or overwritten, so it just stays put across reconciles and upgrades.

Step 8: Create and deploy a Logic App

Plumbing's out of the way. In the portal, create a new Logic App (Standard) with the Hybrid hosting option, point it at your connected environment, wire storage up to your SMB share, and create. Author the workflow the way you always would. The runs will execute on your RKE2 cluster instead of in Azure.

Troubleshooting: the RKE2 things we hit

Symptom	Cause & fix
Test `LoadBalancer` / envoy stays `<pending>`	No LB provider on the cluster. Install MetalLB (Step 2). RKE2 ships no ServiceLB.
Runtime pods `CrashLoopBackOff` with `inotify instances ... reached`	Node `fs.inotify.max_user_instances` too low. Raise it to 8192 and restart the pods (Step 4).
Revision invoke returns 502	Platform can't find a `kube-dns` Service; RKE2's CoreDNS is under a different name. Add the alias (Step 7).
App hostnames don't resolve inside the cluster	CoreDNS isn't loading `coredns-custom`. Apply the `HelmChartConfig` (Step 7).
Extension type "not registered in region"	The Arc cluster is in an unsupported region. Reconnect it in a supported one; it's independent of where the node runs (Step 5).
Cluster shows Arc Offline after a reboot; `azure-arc` pods `Unknown`	Stale pods from an ungraceful stop. `kubectl delete pods --all -n azure-arc --force` and they'll recreate and reconnect.

References

Reminder: Path to Production for Agents Webinar Series Starts Next Week

brauerblogs — Thu, 23 Jul 2026 00:15:07 GMT

Next week, join Microsoft for the Path to Production for Agents webinar series—a free, six-session technical training designed to help organizations move from AI experimentation to secure, scalable, production-ready agent solutions. The series takes place July 27–28 and is aimed at architects, technical leaders, engineers, and AI practitioners looking to operationalize AI at enterprise scale.

Across six expert-led sessions, you'll learn how to:

Establish governance foundations for AI at scale
Design production-ready AI platforms and landing zones
Build reliable multi-agent architectures
Implement AgentOps practices for deployment and observability
Secure and govern AI systems
Optimize performance, cost, and scalability

Each session includes proven Microsoft architecture patterns, real-world engineering guidance, and practical techniques you can apply immediately to accelerate your path from prototype to production.

Register today: Path to Production for Agents Registration

Don't miss this opportunity to gain the knowledge and frameworks needed to confidently deploy production-grade AI agents at scale. We look forward to seeing you next week!

Azure Local expands SAN capabilities with iSCSI support

saniya0307 — Wed, 22 Jul 2026 22:15:00 GMT

As organizations modernize datacenters and accelerate migration from legacy virtualization platforms, flexibility in storage architecture has become a key requirement. Customers increasingly want to reuse existing storage investments, scale infrastructure independently, and choose the connectivity model that best fits their environment.

Building on the general availability of Fibre Channel (FC) SAN support, Azure Local now introduces iSCSI SAN integration, extending disaggregated architecture support to IP-based storage networks. With support for both Fibre Channel and iSCSI, Azure Local provides customers greater flexibility in how they modernize and scale their infrastructure while maintaining an Azure-consistent management experience.

Expanding disaggregated infrastructure

iSCSI support enables organizations to:

Leverage existing IP-based storage networks
Deploy cost-efficient disaggregated architectures without FC dependency
Scale compute and storage independently
Maintain an Azure-consistent management experience

Architecture and deployment

Azure Local supports 6-adapter configurations to balance cost, performance, and resiliency:

6 adapters: enhanced performance and redundancy with dedicated iSCSI paths.

Today, iSCSI follows a manual configuration flow during deployment.

Azure Local Deployment

Azure Local supports two SAN deployment approaches:

Hybrid deployments (S2D + SAN)

Customers can attach external SAN storage to existing Azure Local deployments while continuing to use Storage Spaces Direct (S2D) for platform storage. This approach enables organizations to incrementally adopt SAN while reusing existing storage investments.

Disaggregated deployments (SAN-only)

Customers can also deploy Azure Local using external SAN storage as the primary storage platform for both infrastructure and workloads. This enables:

Independent scaling of compute and storage
Fibre Channel or iSCSI connectivity
Larger-scale infrastructure deployments
Connected and disconnected deployment models
Manage rising disk costs associated with hyperconverged architectures

Additionally, customers can create local availability zones to align VM placement with physical infrastructure boundaries and support more granular workload placement. The deployment also validates connected SAN arrays against the supported vendor ecosystem, helping ensure a streamlined and fully supported experience.

Accelerating infrastructure modernization

Azure Migrate now supports migration to Azure Local deployments that use external SAN storage, including NTFS-based volumes. This allows organizations to modernize compute infrastructure while preserving existing storage investments.

Customers can:

Reuse existing SAN arrays and operational processes
Minimize disruption during modernization projects
Retain familiar storage architectures while adopting Azure Local
Simplify migration from existing virtualization environments

What's next

iSCSI support represents another step in our broader vision for external storage on Azure Local. Our goal is to provide a comprehensive storage platform that spans deployment, operations, protection, and recovery.

Looking ahead, we are investing in:

Integration of iSCSI node configuration into cluster deployment to simplify the initial setup.
Business Continuity and Disaster Recovery (BCDR) for SAN-backed workloads, including replication, failover, and failback capabilities between two external SAN attached or disaggregated Azure local clusters.
Day-N storage management experiences that simplify monitoring, troubleshooting, and operational workflows.
Replication management capabilities that provide visibility into recovery readiness, replication health, and workload mobility across environments.
Expanding enterprise storage vendors ecosystem for Azure Local, helping customers adopt Azure Local while preserving their existing storage investments.

Together, these investments will extend Azure Local beyond SAN connectivity and deployment to deliver a unified storage management experience across a broad ecosystem of enterprise storage solutions.

Summary

With iSCSI support, Azure Local now delivers a more complete SAN strategy—giving customers the flexibility to choose Fibre Channel or iSCSI, deploy hybrid or fully disaggregated architectures, and modernize infrastructure without abandoning existing storage investments.

As we continue to invest in SAN management, replication, and disaster recovery, Azure Local is evolving into a comprehensive platform for enterprise storage and infrastructure modernization—from edge deployments to sovereign-scale datacenters.

Free Extension: Generate AI Development Prompts from Azure DevOps Work Items — Verity Framework

Idearoost1 — Wed, 22 Jul 2026 18:00:07 GMT

Hi Azure DevOps community,

I wanted to share a free extension we just published to the Visual Studio

Marketplace: the Verity Framework ADO Extension.

**What it does**

It adds a "Verity Prompt" tab to your work items. When you populate five

custom fields on a User Story or Delivery Item, the extension generates a

structured prompt ready to paste into Claude Code, Cursor, or GitHub

Copilot Workspace.

The five fields:

- VF Intent — the problem and who experiences it

- VF Value — the expected outcome

- VF Appetite — time/resource ceiling (not an estimate)

- VF Trust Criteria — Gate 2 hardening requirements

- VF Failure Scope — Narrow / Moderate / Broad / Systemic

**Why it matters**

Most engineers using AI tools start from a blank context or a vague task

description. The extension carries the team's planning judgment — including

production risk level and hardening requirements — directly into the

implementation context.

It also includes field validation that flags vague Trust Criteria,

incorrectly formatted Appetite values, and solution-framed Intent

statements before generating the prompt.

**Setup**

About 20 minutes. You add five custom fields to your existing User Story

work item type (no new work item type required). Full instructions are

in the extension tab.

**Install**

Search "Verity Framework" on the Visual Studio Marketplace or visit

idearoost.com/verity for the full framework context.

Free. No subscription required.

Happy to answer questions about the field definitions or the setup process.

— Jacques Steward, IdeaRoost

MCP in Azure: Using API Management for Authentication, Access, Logging & Governance

Kalaivanan — Wed, 22 Jul 2026 16:51:16 GMT

If MCP is becoming the “USB-C for AI,” enterprises need something equally familiar on the other side of that port: a control plane. The Model Context Protocol (MCP) gives AI applications a standard way to discover tools, retrieve context, and call capabilities from external systems. But once you move beyond a single local server and start connecting multiple remote tools across teams, environments, and data domains, the protocol alone is not enough, you also need a way to manage identity, access, traffic, visibility, and lifecycle consistently.

That is where Azure API Management (APIM) becomes strategically important. APIM is not “MCP instead of APIs.” It is the layer that can sit in front of MCP servers or even turn existing REST APIs into MCP-compatible tool surfaces so that organizations can apply the same security, policy, and operational controls they already use for business APIs. In other words, MCP standardizes how agents talk to tools; APIM helps standardize how the enterprise governs those tool endpoints at runtime.

What MCP actually is and why it changes AI integration

At its core, MCP defines a host / client / server model. The host is the AI application or agent experience, the client manages the MCP connection, and the server exposes capabilities to that client. Those capabilities are commonly expressed as tools (actions an AI model can call), resources (context or data an application can read), and prompts (reusable interaction templates). The same model works whether the server is local or remote, which is one of the reasons MCP is becoming an attractive way to make tool integrations reusable across many AI surfaces.

That portability matters because most teams do not want to rebuild connector logic for every host, model, or IDE. Microsoft’s Azure guidance explicitly describes two broad ways developers work with MCP: consume existing MCP servers, or build their own when they need custom tools, resources, or prompts.

Why MCP sprawl becomes an enterprise problem

MCP is easy to love in a demo because a single server can make an agent instantly smarter. It is harder in production because success creates sprawl. One team wraps an inventory API. Another exposes compliance rules. Another adds DevOps data. Soon, you have multiple remote MCP endpoints, different authentication models, inconsistent rate limits, uneven logging, and no clear answer to “which tools are approved, versioned, and discoverable?” This is the anti-pattern of a monolithic, over-privileged MCP server, and instead one must align server boundaries to business capabilities so access, observability, and ownership remain tractable.

This is exactly the point at which centralization becomes valuable. Microsoft’s MCP ecosystem organizes the landscape into three layers: a foundation of built-in servers, a build/govern layer that includes Azure Functions, APIM, and API Center, and a consumption layer where agents and runtimes use those tools. That framing is useful because it shows MCP management is not only about building servers; it is equally about establishing how those servers are exposed, governed, and discovered across the enterprise.

APIM as the front door for MCP

Azure API Management supports two especially important patterns for MCP centralization. The first is exposing an APIM-managed REST API as a remote MCP server, which lets you turn selected REST operations into MCP tools without rebuilding the backend. The second is putting APIM in front of an existing MCP server, so APIM acts as a facade or proxy that applies policy and governance to a server you already run somewhere else such as Azure Functions, App Service, Container Apps, or another HTTP host.

This is why APIM is best understood as the front door rather than the destination. It can route requests, apply transformations, enforce policy, and mediate access while preserving the standardized MCP interaction pattern for clients. MCP server endpoints can be described as “backend APIs” from a governance perspective, which is precisely the enterprise advantage: once a remote MCP endpoint is treated as an API surface, you can bring familiar controls, security, reliability, monitoring, and access policy to an otherwise fast-spreading agent/tool ecosystem.

Authentication and authorization: where APIM earns its keep

Remote MCP servers need a strong authorization story because they are not just returning text, they are gateways to systems, data, and actions. MCP authorization guidance uses OAuth 2.1, Protected Resource Metadata (PRM / RFC 9728) for discovery, dynamic client registration (RFC 7591) where supported, and resource indicators (RFC 8707) so tokens remain bound to the intended resource. The practical flow is clear: a client tries the server, gets a 401 with metadata, discovers the authorization server, requests consent with PKCE and the resource parameter, exchanges for a token, and then includes that bearer token on subsequent calls.

APIM becomes powerful here because it can be the authorization gateway in front of the MCP server. Internal security guidance and APIM-focused enablement both converge on the same pattern: use APIM to validate JWTs, apply OAuth/Entra-based access policies, and avoid unsafe token-handling shortcuts such as token passthrough. In practice, this means the caller authenticates against Microsoft Entra ID, APIM validates the token and audience, and only then forwards the call to the MCP backend, optionally with credential mediation patterns such as managed identity, On-Behalf-Of (OBO), or backend credential management depending on the scenario.

For Azure builders, the authentication options are already familiar. Microsoft’s Foundry guidance for custom MCP tools maps server authentication patterns to key-based auth, Microsoft Entra authentication, and OAuth identity passthrough (OBO). That same guidance explicitly recommends requiring authentication, treating credentials as secrets, applying least privilege to downstream APIs, and logging tool calls for troubleshooting. If you already think in terms of Entra ID, managed identities, audience validation, and OBO, centralizing MCP behind APIM lets you use those same patterns at the agent-tool boundary rather than reinventing them server by server.

Logging, monitoring, and observability without losing the plot

Observability is where many MCP deployments discover that a protocol is not the same thing as an operations platform. Internal field guidance is explicit that MCP monitoring today is often product-specific rather than fleet-wide: enterprise MCP usage can show up in Graph activity logs, Foundry uses OpenTelemetry-based tracing through Application Insights, and custom servers hosted in Azure Functions can rely on standard Function/App Insights diagnostics. The practical implication is that you can get strong telemetry, but you still have to stitch it together intentionally rather than expecting a single universal “MCP operations” pane out of the box.

APIM improves that picture because gateway traffic becomes a consistent choke point for diagnostics. That makes APIM valuable not only for security but also for operational visibility: which tools are being called, how often, by whom, with which response codes, and where latency or backend errors are emerging.

There is, however, an important streaming caveat. MCP transports, especially remote ones can depend on streaming-friendly behavior, and response buffering can break MCP interactions. In other words: yes, centralize observability, but do it in a way that respects streaming transports and does not accidentally make the MCP server stop working while you are trying to observe it.

Governance: from “cool tool” to managed platform capability

If authentication answers “who can call this?”, governance answers “what is this server, which version is trusted, and how should anyone discover it?” That is where Azure API Center matters. API Center is centralized location for registering and discovering MCP servers, including those exposed through APIM and those hosted elsewhere. Microsoft’s Foundry guidance similarly describes API Center registration as the path to creating a private organizational tool catalog, where authentication and access settings can be configured consistently and users can discover approved servers rather than trading raw URLs in chat threads.

This matters more than it sounds. Governance is not only about storage of metadata, it is about versioning, lifecycle, access management, tags, and exposure policy. Recommendation is to version MCP endpoints, document usage patterns, and using API Center to make discovery enterprise-ready.

A practical Azure reference pattern

A useful way to think about the architecture is this: MCP hosts and agent runtimes stay at the edge of user experience, while APIM becomes the edge of enterprise control. The agents or developer tools speak MCP. APIM governs the runtime surface. MCP backends provide tools, and API Center catalogs them. Azure Monitor and Application Insights provide telemetry. Entra ID provides identity. The protocol stays standardized; the operations model becomes centralized.

Centralizing via APIM vs. letting clients call MCP servers directly

Dimension	Direct access to MCP servers	Centralized through APIM
Authentication model	Each server must implement and enforce auth consistently, which can drift across teams.	Central token validation, Entra/OAuth policy, and consistent gateway enforcement become possible across servers.
Access control	Per-server controls can be fragmented and harder to audit centrally.	Products, subscriptions, access policies, and gateway rules create one place to enforce who can use what.
Observability	Logs depend on each backend platform, and MCP-wide visibility is often fragmented.	APIM adds a common telemetry point for traffic, errors, and policy outcomes, while backend telemetry still remains available.
Reuse of existing APIs	Existing REST APIs stay REST APIs unless you build/host a separate MCP layer yourself.	APIM can expose existing REST operations as MCP tools, reducing incremental engineering work for standard tool surfaces.
Registry / discovery	Teams often share endpoints ad hoc, which does not scale well organizationally.	API Center provides a governed private registry for cataloging, access, and discoverability.
Trade-offs	Fewer moving parts and potentially lower latency for a single, tightly scoped use case.	Adds a gateway hop and policy/configuration overhead, and APIM’s REST-to-MCP mode focuses on tools rather than full MCP resources/prompts, so some scenarios still benefit from a dedicated MCP server behind the gateway.

Design guidance and best practices

1) Treat MCP servers as business capability boundaries, not as a giant “AI super-endpoint” Monolithic, over-privileged MCP servers are an anti-pattern; separate servers improve least privilege, ownership clarity, and observability. A focused capability boundary also gives the model clearer tool descriptions, which improves invocation quality and reduces collisions between unrelated tools.

2) Prefer a no-code APIM path when you already have good REST APIs; use a pro-code MCP server when you need custom orchestration, transformation, or non-API-native logic. Implement No-Code via APIM for existing REST interfaces and Pro-Code for scenarios requiring more control, custom logic, or deeper integration patterns. This is one of the cleanest ways to make the architecture pragmatic instead of ideological: not every MCP server should be handwritten if the backend capability already exists in API form.

3) Use Entra ID and avoid token passthrough. Token passthrough creates audit gaps, bypass risks, and lateral movement opportunities. A better pattern is for APIM to validate and mediate identity at the edge, with audience/resource validation and downstream access configured explicitly. When you need delegated access, use OBO or equivalent identity-aware patterns rather than forwarding arbitrary bearer tokens through the stack unchecked.

4) Design for observability from day one, but keep streaming in mind. Log tool invocations, failure paths, latency, and correlation identifiers. Use Azure Monitor / Application Insights on the backend and APIM diagnostics at the gateway. But for remote MCP transports, avoid diagnostics or policy configurations that introduce response buffering and unintentionally break stream-oriented behavior.

5) Make discovery a governance problem, not a tribal-knowledge problem. Register internal MCP servers in API Center when you want them discoverable across projects or teams. Use metadata, access management, and lifecycle conventions to decide what is visible, what is approved, and which versions are current. That gives platform teams a catalog to govern and developers a trusted place to discover servers without guessing which endpoint is “the right one.”

The bottom line

MCP standardizes how AI applications talk to external capabilities. APIM standardizes how the enterprise protects and operates those capabilities. Put differently: MCP solves interoperability, while APIM helps solve operability. When organizations start treating remote MCP endpoints like first-class API assets with identity, policy, telemetry, registry, and lifecycle attached, tmhey move from isolated agent demos to something that can actually survive production.

That is why centralizing MCP management in Azure is not really about “putting a gateway in front of servers.” It is about giving your emerging agent ecosystem a governed front door: one place to authenticate, authorize, observe, version, discover, and evolve the tools your models depend on. And for enterprises already invested in Azure, APIM plus API Center is one of the clearest ways to build that front door without throwing away the APIs and security patterns they already trust.

CDK Global modernizes automotive CRM on Azure SQL Managed Instance

RicardoDuncan — Tue, 21 Jul 2026 23:21:36 GMT

For automotive retailers, most customer relationships don't begin and end with a vehicle purchase. A customer might browse inventory online, visit a dealership weeks later, return for service months after that, and eventually purchase another vehicle years down the road. Every interaction creates information that helps dealerships better understand their customers and build stronger relationships over time.

Helping dealerships manage those relationships is at the core of the CDK CRM platform. CDK is a leading provider of cloud-based software to dealerships and OEMs across automotive and related industries in the US and Canada, helping facilitate more than $540 billion in annual automotive commerce. It gives dealership teams visibility into customer interactions with their products and services and creates continuity across the conversations that shape the buying journey. As customer expectations evolve, CDK continues to look for new ways to help dealerships work more efficiently, make better use of information, and adapt quickly to market changes.

Supporting that next phase of innovation required a technology foundation that could grow alongside the business. Working with Microsoft, CDK evolved its CRM platform on Microsoft Azure and Azure SQL Managed Instance. The project included a large migration to Azure SQL Managed Instance and marked an important step in the future of the CRM experience.

Transforming a business-critical system at scale

The size of the project reflected how central the CRM platform is to CDK’s business. The environment supports a broad set of applications for dealership operations and relies on a robust data foundation to keep information flowing.

Microsoft and CDK worked together to implement a cloud architecture built on Azure App Service and Azure SQL Managed Instance. Additional Azure services support application delivery, networking, and data movement across the architecture. The teams developed a Terraform-based infrastructure-as-code framework that standardizes how environments are deployed and managed. That foundation brings greater consistency to the development process. Engineering teams can work within environments that are configured in a predictable way, reducing the likelihood of unexpected differences between testing and production.

The project also provided an opportunity to strengthen security and governance practices. CDK updated applications to use managed identities, reducing reliance on static credentials, and implemented Microsoft Entra ID authentication and private connectivity patterns that help secure access to critical resources. While dealership users may not see these changes directly, they help deliver the stability and security that customers expect from the platform.

Preserving continuity while moving to the cloud

As CDK evaluated its cloud strategy, the database layer became one of the most important decisions in the project. The CRM platform supports business-critical dealership operations throughout the day. Customer interactions, sales activity, and service records all depend on information moving quickly and reliably between systems. Any technology transformation would need to preserve that experience while creating a path to future growth.

Azure SQL Managed Instance stood out because it offered a familiar SQL Server environment while reducing much of the operational overhead associated with managing database infrastructure. It also aligned well with CDK’s long-term goals around resiliency, scalability, and continuous innovation. Equally important, Azure SQL Managed Instance provided a migration path that worked with the realities of the CRM environment.

“One of the reasons Azure SQL Managed Instance appealed to us was that it allowed us to innovate without redesigning the CRM platform from the ground up,” says Stan Leong, Vice President of Modern Retailing Engineering at CDK. “We could preserve compatibility with the applications our dealerships depend on while taking advantage of a fully managed cloud service.”

Unlike some projects that can move applications gradually, the CDK CRM platform required a coordinated transition. The databases that support the platform are highly interconnected, which meant the company needed an approach that would allow the environment to move together while minimizing disruption for customers. To prepare for that transition, CDK and Microsoft used Azure SQL Managed Instance link to establish near real-time replication between environments. This allowed teams to begin validating the migration long before the production cutover. Engineers could confirm that data was flowing correctly, identify potential issues, and gain confidence in the process before dealerships were ever affected.

The approach also gave CDK an added layer of flexibility during the transition period. Rather than making a one-way move, the company could maintain a rollback option while teams validated production operations in Azure. Because Azure SQL Managed Instance link kept environments synchronized, CDK retained the ability to fail back to its on-premises environment if needed while preserving continuity for dealership operations. After failing over to Azure, the company continued running with synchronized environments for more than four weeks, allowing teams to validate production workloads before completing the final cutover.

Executing a migration measured in terabytes

That preparation became especially important because the migration would take place during a single maintenance window. By establishing synchronization ahead of time, CDK was able to keep data aligned between environments before the failover to Azure.

When migration time arrived, production data was already synchronized in Azure, allowing the maintenance event to focus on transitioning operations rather than moving large volumes of data for the first time. Planning and architecture work that led to the migration spanned several months. The final migration preparation and validation effort was completed in just six weeks, with engineers working together to test migration scenarios, optimize replication performance, and validate data consistency ahead of production.

CDK migrated more than 1,000 databases and hundreds of terabytes of data to Azure SQL Managed Instance. The environment now processes billions of database queries every day. The failover to Azure was completed during a single weekend with minimal failover time and no data loss. In many cases, database failovers completed in seconds, with most finishing within minutes. Microsoft engineering, product, support, and field teams remained engaged throughout the event, working alongside CDK to monitor the transition and address issues in real time.

“This was one of the most significant technology initiatives we’ve undertaken for our CRM platform,” says Leong. “Working closely with Microsoft, we migrated more than 1,000 databases to Azure SQL Managed Instance while supporting dealerships throughout the process. The collaboration between our teams helped us execute the transition with minimal disruption to customers.”

Strengthening reliability for dealership operations

Delivering more than a new cloud environment, the migration also gave CDK an opportunity to evolve the CRM platform operations. As part of this effort, CDK implemented resilience architecture built on Azure. The design incorporates Azure Front Door, geo-redundant storage, and Azure SQL Managed Instance failover capabilities, allowing the company to maintain continuity when unexpected disruptions occur.

These improvements rarely attract attention when everything is working as expected, but they help the platform remain available when it matters most. Since the migration, CDK has heard positive feedback from dealerships that report faster and more responsive application experiences.

Preparing dealerships for what’s next

With the CRM platform now running on Azure, CDK is focused on the next phase of its CRM strategy. Beyond supporting today’s dealership operations, the cloud-based foundation gives the company greater flexibility to introduce new functionality and continue advancing the platform over time.

AI capabilities are already helping dealership employees surface relevant information at the right moment while reducing the effort required to complete routine tasks. And AI is accelerating software development and deployment, enabling engineering teams to deliver new capabilities more efficiently. CDK is also investing in new reporting experiences designed to make insights easier to access. Dealerships generate enormous amounts of data, but its value depends on how quickly users can find relevant information and act on it.

The CRM migration has become an important reference point for future platform initiatives across the organization. By successfully moving a business-critical platform at this scale, CDK established a blueprint for future cloud initiatives. “The migration was an important milestone, but it’s really the starting point,” says Leong. “With Azure and Azure SQL Managed Instance, our teams can focus more energy on delivering new capabilities for dealerships while using AI to power experiences that help customers operate more efficiently.”

Connecting Microsoft Discovery App to Azure HPC with Azure NetApp Files and CycleCloud

richpaw — Wed, 22 Jul 2026 16:47:17 GMT

Introduction

Traditional High-Performance Computing (HPC) is central to most scientific computing and engineering applications. These systems are based on well tested, repeatable, and scalable compute processes that enable the large-scale generation and validation that the semiconductor and other industries depend on.

Integrating AI and agentic flows into this traditional model remains a challenge. Where many agentic systems rely on “modern” compute architecture utilizing REST based communications and object storage, traditional HPC relies on POSIX based file systems and scheduler-based orchestration. Combining these two different disciplines presents a challenge to many engineering and large-scale research enterprises.

This blog describes how Microsoft Discovery app can directly interoperate with existing traditional HPC deployments utilizing Azure HPC. Microsoft Discovery is an enterprise agentic AI platform for research and development, designed to help specialized agents reason, plan, execute, and learn in a continuous loop across data, tools, and workflows. It is built on Azure and designed to integrate with capabilities such as Azure HPC and Microsoft Foundry, while leveraging industry proven tools and customer flows, making it a natural bridge between AI-native reasoning and compute-intensive engineering execution.

Agentic AI in HPC

The value of agentic AI in scientific and engineering workloads is not just as a chatbot or code generator; it is the ability to participate in an existing workflow: write parameter files, launch simulations, inspect logs, summarize failures, generate follow-on jobs, and preserve artifacts for traceability. To do this effectively, agents must be able also read data from POSIX-based file systems and dispatch jobs to the scheduler.

To maintain IP security, they must access data while respecting the access limits of the user that dispatched them and write data under the same RBAC rules as that same user. That way organizations can be assured that agents operate strictly under the dispatching user's access rights, so they cannot reach data the user isn't authorized to see and the data they write retains the permissions that the user who dispatches the agent enjoys.

Discovery app is currently only available on Windows. Linux and Mac versions will soon be available. In the meantime, enabling the Windows based Discovery app to leverage the capabilities on Azure HPC today with little to no change to the current HPC flow.

Reference architecture

The architecture has five primary components: a Windows VM running the Discovery app on Azure, an Azure NetApp Files volume that is mounted by both Windows and Linux clients, an Azure CycleCloud-managed HPC cluster with a Linux login node used for job submission and monitoring, and a scheduler that dispatches work to compute nodes.

Discovery app on Windows: Runs on a Windows VM placed inside the same VNet, or reachable through controlled private networking, so it can access storage and the login node without exposing the HPC environment publicly.
Azure NetApp Files: Provides the shared file namespace for input decks, scripts, logs, generated data, and results. Linux nodes mount the volume with native NFS. Windows can mount the same namespace through the Windows NFS client or an equivalent enterprise file-access solution.
Azure CycleCloud: Provisions and manages the HPC cluster, including scheduler, login node, execute nodes, autoscaling, and cluster configuration.
Login node: Acts as the controlled command endpoint. Discovery should submit jobs and query scheduler state from here, not run heavy tools directly on the login node. This protects the actual Cyclecloud scheduler and cluster manager from being overwhelmed if the dispatch volume is high. This also allows for scalability if there are many clients scheduling jobs at once.
Scheduler: Incumbent schedulers that customers are already using with Azure Cyclecloud handles execution. Discovery creates scripts and submits them through the scheduler so compute runs on the correct nodes with the correct environment, licenses, and policies. This remains the same as how traditional HPC schedules jobs today.

Connectivity model

Running on a Windows VM in the Azure VNet aligns with many enterprises’ requirement that none of their data or IP can leave their network. Doing this avoids the need to run jobs through a user laptop or unmanaged public endpoint. This also allows the user to start an agentic workload then disconnect from the VM while the job runs and reconnect when they come back. Maintaining the same working model most engineers have with their HPC environment today.

For Discovery to access Azure HPC, it needs to map the Azure NetApp Files volumes and command access to the Linux login node. File access lets agents create and read files. Command access lets agents run Linux commands, submit jobs, and monitor execution. Discovery writes execution scripts to the ANF volume, then uses SSH to dispatch the job to the schedule with the execution script.

The advantage of this model is that the user can directly provide Unix-style paths to Discovery and tell it to execute tools without the user worrying about being on a Windows platform. For example, CAD teams often provide setup scripts with paths to tools that users are supposed to reference in creating their own tool execution scripts. Using this model, I just tell Discovery to use the setup script /mount/setup/tools/vendora.csh as a template and it will happily find the file and do so. I can then tell Discovery to dispatch the job to the hpc queue and it will schedule to the appropriate SLURM queue where a system is provisioned and assigned to run using the new execution script Discovery creates.

This model also gets around the temporary limitation of Discovery app, unlike the enterprise Discovery service, only being available on Windows. In this model, Windows is only acting as a terminal interface so it doesn’t matter that it’s not a platform that normally works with most EDA tools. In fact, users can deploy Discovery app on either x86 or ARM Windows since all the actual tools run on the Linux-based HPC deployment in Azure anyway.

Mapping Windows drive to NFS volumes

Discovery agents must understand how to access files on the mapped NFS volume from the Windows VM. The same file may appear as Z:\project\run1\exec.csh on Windows and /mount/project/run1/exec.csh on Linux. The skill or instruction file used by Discovery should explicitly describe that mapping and instruct agents to use Linux paths inside batch scripts and scheduler commands.

A typical instruction might say: the Windows drive Z: maps to the Linux mount point /mount. If Discovery sees /mount/designs/test.sv, it can read or write the corresponding Windows file at Z:\designs\test.sv. When generating job scripts, it should always use the Linux path, because those scripts run on the cluster.

Implementation steps

1. Deploy the HPC foundation

Start with the standard Azure HPC foundation: a virtual network, Azure CycleCloud, a scheduler-backed cluster, and shared storage. CycleCloud can deploy and manage Slurm clusters and supports external NFS mounts, including Azure NetApp Files. Configure the cluster so the scheduler and compute nodes mount the shared file system at a stable Linux path such as /mount, /shared, or a customer-specific project path.

Make sure that systems can ssh to the login node using a public/private key pair. The login node should be accessible using a command like:

% ssh -i .ssh/keyfile user@login-node

2. Place the Windows VM in the same network boundary

Create a Windows VM that can reach both the Azure NetApp Files endpoint and the CycleCloud login node over private IP. The required Windows NFS client is available on Windows 11 Pro, Enterprise, and Education. It is not available on Windows 11 Home. Install the Discovery app on that VM. This VM becomes the user’s Discovery workstation for the HPC-connected workflow. Keep the VM inside the same security boundary as the HPC deployment, and use standard enterprise controls such as private networking, restricted inbound access, managed identity where appropriate, and least-privilege SSH keys.

3. Install Microsoft Discovery app

Download and install Microsoft Discovery app from:
https://github.com/microsoft/discovery
Once installed, start Microsoft Discovery app and connect to your Github Copilot account in order to configure access to the LLM AI models.
Create a new project

4. Mount the Azure NetApp Files volume into Windows

Mount the same shared storage namespace into Windows. The Windows NFS client can map the NFS export to a drive letter such as Z:. The Windows NFS is sufficient for reading logs, results, and data files, and writing execution scripts, parameters, and configuration files. Heavy simulation I/O remain on Linux compute nodes running HPC tools.

To configure the Windows NFS Client, you will need to have administrator privileges on your Windows VM.

To mount the ANF volume with the Windows NFS client.

Press Win+R
Run “optional features”
Select “More Windows features”
Expand “Services for NFS”
Enable “Administrative Tools” and “Client for NFS”
Click “OK” to install the components.
By default, Windows will mount the NFS volume as an anonymous user. To set the correct user, you can define the correct Linux User ID and Group ID in the registry.

Note: This is an example of a functional baseline to mount a Linux volume with a user identity as an example. Production environments should employ proper identity mapping for security.
Press Win+R
Run “regedit” to start the Registry Editor
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default
In Default, right click and add two new DWORD entires: AnonymousUID and AnonymousGID
Set the values to the decimal value of your Linux UID and GID. This will ensure that you connect to the ANF volume as the correct user.
Select OK and then launch the Command Prompt as Administrator.
To allow the NFS Client to accept the new registry entries, restart the NFS Client with the following commands:
nfsadmin client stop

nfsadmin client start

Mount the ANF volume to a Windows drive:
You should now be able to access your NFS volume by going through the Z: drive.

5. Configure SSH access to the login node

Configure the SSH client on the Windows VM with a dedicated key for Discovery-driven access. The key should connect to the CycleCloud login node as the user (same as with NFS above) with permissions to submit jobs, read scheduler state, and access the shared project directory. Verify connectivity by connecting to the Cyclecloud login node using ssh from the Command Prompt.

In this example, the username is ai4semi, the IP address of the login node is 10.16.16.25, and the cc_rsa is the keyfile located under the .ssh directory of the user’s home directory on Windows. Since this is the first time for this system to log into the Linux machine, you must accept the connection registration. This will not be necessary for subsequent ssh connects by Discovery using this method.

5. Teach Discovery how to use Azure HPC

Now that you have the NFS and SSH connections established in Windows, you simply need to tell Discovery how to use these connections properly to run HPC workloads. In the Discovery chat window, tell Discovery to map the Z: drive on windows to the /mount volume on NFS and how to interact with the files.

The Windows drive `Z:` is mapped to the cluster NFS volume `/mount`.

- `/mount/<path>` on the cluster corresponds to `z:\<path>` locally.

- Example: when a file is referenced as `/mount/test.txt`, look at `z:\test.txt`.

Test to make sure Discovery understand by asking it to read a file on the NFS volume using POSIX nomenclature.

read the contents of /mount/newfile.txt

Discovery should show you the file contents

Next, instruct Discovery on how to access and interact with Cyclecloud

Connect to the CycleCloud login node over SSH using "ssh -i .ssh\cc_rsa ai4semi@10.16.16.25"

Then tell Discovery which scheduler Cyclecloud uses and tell it to check the queue.

Cyclecloud is using SLURM as the scheduler. Check the status of the hpc queue.

Since the Windows VM is only used to run Discovery and the agentic AI part of the workload and the login node is not meant to run actual HPC workloads, be explicit with Discovery on how it should treat HPC job runs.

NEVER run EDA/build/simulation tools on the local system or directly on the login node. ALWAYS submit work to the Slurm scheduler via sbatch.

- The login node is for job submission and monitoring only — not for compute.

- Wrap every tool invocation in a batch script and submit it with sbatch.

6. Validate the end-to-end workflow

Validate that everything works by dispatching a simple test script to Cyclecloud

Create a batch script that references the Linux path, submit it to Cyclecloud.

dispatch /mount/proj/ai4semi/exec.csh to the hpc queue

7. Save the knowledge for future reference

Now that Discovery understands how to access Linux-based files on NFS and how to dispatch jobs, tell it to save the information.

Save this knowledge to a skill and use it for all subsequent job runs and file access for the project

You see that Discovery now saved the information on how to access files and run jobs to a SKILL.md for general knowledge and updated the copilot-instructions.md to ensure that all subsequent agents and engines understand how to access Azure HPC.

Note: These instructions are only scoped to a single project. When creating a new project, you can simply tell Discovery to reach over to your older project to copy the knowledge:

copy over instructions on how to access NFS files and paths, and how to dispatch and execute hpc jobs from workspace1

If you want to make this a portable instruction that you can just load for each new project, tell Discovery to create a portable file.

package the instructions on how to access NFS files and paths, and how to dispatch and execute hpc jobs into a a single instruction I can provide to new workspaces

You can then copy the file to a central location like: C:\Users\ai4semi\project

Then for each new project you can tell Discovery to use this file.

read and understand the instructions in C:\Users\ai4semi\project\cyclecloud-hpc.instructions.md. Use for all agents and engines in this project and save this information as skills to use in the project

Operational considerations

Identity and permissions: Keep SSH access scoped to the project and avoid broad administrative privileges. For NFS, verify UID/GID mapping and file ownership behavior before production use.
Performance: Use the Windows mount for orchestration artifacts, scripts, and logs. Let Linux compute nodes perform heavy I/O through native ANF mounts.
Security: Keep Discovery, storage, and the login node on private networking. Avoid public exposure of scheduler or storage endpoints.
Scheduler hygiene: Enforce a rule that Discovery submits jobs through the scheduler and does not run heavy tools interactively on the login node.

Conclusion

Connecting Microsoft Discovery app to Azure HPC allows users to seamlessly use their existing HPC environment. The most practical approach today is to place Discovery on a Windows VM inside the Azure network, map the shared Azure NetApp Files namespace into both Windows and Linux, and use SSH to submit scheduler-managed jobs through CycleCloud.

Using this method, customers can quickly and easily use Discovery to integrate Agentic AI into their current HPC flows. Users can take advantage of AI agents to read and understand specification files, generate code and testbenches based on those specifications, run existing HPC tools on their Azure HPC environment. They can direct Discovery to use the scripts and resources which their CAD teams have developed. Users can create bookshelves by pointing to the documentation directories many tool vendors include in their installations, allowing Discovery to take advantage of documentation which most users don’t have time to fully digest.

Over time, native Linux support can reduce the need for Windows-hosted bridging. Until then, this architecture gives teams a secure, and repeatable way to let Discovery agents create, launch, monitor, and learn from real HPC workloads on Azure.

Microsoft Discovery: Where HPC meets agentic AI for the next era of EDA

richpaw — Wed, 22 Jul 2026 15:25:57 GMT

Introduction

High-performance computing is the engine behind the most demanding engineering breakthroughs. In electronic design automation, HPC enables massive simulation farms, verification regressions, place-and-route exploration, timing closure, power analysis, and signoff workloads that would be impractical at scale. However, as chip complexity grows, the limiting factor is no longer only compute capacity. It is the ability to reason across enormous design spaces, coordinate specialized tools, preserve engineering context, and decide what to run next.

That is where Microsoft Discovery becomes especially interesting. Microsoft Discovery is an enterprise agentic AI platform for research and development, designed to help specialized agents reason, plan, execute, and learn in a continuous loop across data, tools, and workflows. It is built on Azure and designed to interoperate with capabilities such as Azure HPC and Microsoft Foundry, while leveraging industry proven tools and customer flows, making it a natural bridge between AI-native reasoning and compute-intensive engineering execution.

The Inflection Point: HPC is required, but not enough

Engineering teams already know how to scale compute. They run large regressions, distribute workloads across clusters, burst into cloud capacity, and optimize storage and schedulers around fast-moving design cycles. Yet the harder challenge is often deciding which simulations matter, which failures are related, which tool settings deserve another experiment, and which signals should trigger the next branch of exploration.

Traditional HPC gives engineering teams scale. Agentic AI adds accelerated analysis, orchestration, memory, reasoning, and adaptation. The synthesis of the two is not about replacing engineers or replacing EDA tools. It is about turbocharging the engineers by creating an intelligent execution fabric where agents can understand goals, inspect results, choose tools, launch jobs, summarize outcomes, and recommend the next best action. Engineers remain in control of the design intent and final decisions. In this model, the most valuable resource is not compute capacity; it is engineering time.

Microsoft Discovery as the agentic layer for engineering R&D

Microsoft Discovery focuses on the full R&D lifecycle: knowledge reasoning, code and plan generation, simulation, analysis, and iteration. For semiconductor and EDA workflows, that maps naturally to the way design teams already operate. Timing closure, regression failure, achieving performance targets all require that engineers pour over massive amounts of information from tool run logs, interpret the results based on engineering goals and specifications, and determine how to resolve the gaps. Discovery leverages the same scientific process used in scientific research to help engineers more quickly understand the resulting data, pick out critical learnings, and help compose the next steps and mitigations.

Unlike chat interfaces, agents can act and execute specific functions. Agents can be assigned roles: a verification triage agent, a log-analysis agent, a simulation-planning agent, a physical-design exploration agent, a cost-and-capacity agent, or a documentation agent that preserves evidence and rationale. Together, these agents can coordinate around a shared objective and use HPC as the execution and validation vehicle.

For semiconductor programs, engineers are the most expensive and constrained part of the process. Every hour spent searching logs, reconciling reports, relaunching routine jobs, copying context between systems, or documenting repetitive findings is an hour not spent on architecture, debug strategy, design tradeoffs, or design sign-off. Discovery’s value is therefore not simply that it can automate tasks; it can help shift engineering effort away from menial coordination work and toward the decisions that improve product outcomes and silicon spins.

What this looks like for EDA

In a complex silicon project, design teams may run thousands of tests across multiple scenarios, configurations, simulators, and coverage targets. Today, engineers spend significant time reading logs, correlating failures, rerunning jobs, and deciding whether a failure is new, known, flaky, or blocking. Much of that work is necessary, but repetitive. With an agentic workflow, a verification agent could monitor regression output, cluster related failures, inspect logs, identify likely root causes, and propose targeted reruns rather than brute-force rerunning everything. All this helps to provide engineers more time to focus on the work that requires their unique engineering skill and judgement.

In physical design, an agentic workflow could help explore constraints, placement strategies, timing violations, congestion hot spots, and power tradeoffs. HPC provides the parallel capacity to run experiments. Discovery-style agent orchestration can help determine which experiments to run, capture why they were run, compare outcomes, and refine the next set of candidates. This provides a guided design-space exploration loop.

For signoff and analysis, agents could help connect results across timing, power, reliability, manufacturability, and cost. Instead of treating each report as an isolated artifact, an agentic system can reason across reports, prior runs, known design patterns, and engineering guidance helping to converge faster.

Discovery leverages tried-and-true, industry-proven tools to validate the output of AI using the same methods semiconductor teams have relied on for decades. AI can propose code and plans, prioritize validation and simulation, summarize analysis and debug, or recommend next steps, but the validation path still runs through established EDA flows that engineers understand and trust.

The Architecture: Agents, Tools, Data, and Compute

Discovery’s flow architecture leverages a closed-loop system. Knowledge sources provide context: design specs, prior bugs, regression history, tool documentation, scripts, and engineering notes. Agents reason over that context and formulate next steps. Tool integrations connect those agents to EDA applications, schedulers, storage systems, model endpoints, and analysis pipelines. Azure HPC supplies scalable execution for simulations and compute-heavy analysis. Results flow back into the system so the next decision is better informed than the last.

This demonstrates the power of joining agentic AI and HPC. Discovery provides a platform model for coordinating that loop with enterprise expectations around security, governance, transparency, and human oversight. HPC tools provide assurance that the results from AI are valid.

Integrating Discovery with Azure HPC for EDA

Discovery becomes even more powerful when it is connected to Azure HPC infrastructure purpose-built for compute- and memory-intensive engineering workloads. For EDA, that includes AMD-based Azure HPC virtual machines such as HX-series instances, which are optimized for silicon design and memory-intensive workloads, with large memory capacity, AMD EPYC processors with 3D V-Cache, and high-performance InfiniBand networking. These platforms give agentic workflows the execution fabric needed to run large simulations, regressions, analysis jobs, and design-space exploration at cloud scale for both EDA and other HPC workloads.

Storage is equally important. EDA workloads generate and consume enormous numbers of files, and performance often depends on low-latency shared file access as much as raw CPU capacity. Azure NetApp Files provides enterprise-grade file storage for mission-critical HPC and EDA workloads in Azure, giving teams a managed, high-performance storage layer that can support simulation farms, tool installations, design libraries, scratch spaces, and shared project data.

Azure NetApp Files also enables customers to use Discovery in a hybrid environment, enabling customers to keep critical data on-prem while using Discovery to optimize cloud-based flows. Many semiconductor teams keep authoritative design data, source repositories, IP libraries, and sign-off environments in on-premises infrastructure. Azure NetApp Files cache volumes can help bridge that workflow by creating a cloud-based cache of active data from an external origin volume. Frequently accessed data can be served close to Azure compute, while the authoritative dataset remains in the existing on-premises design environment.

Cluster automation is another important part of enabling the hybrid flow. Azure CycleCloud can help automate the creation, scaling, and lifecycle management of HPC clusters in Azure so teams can stand up cloud capacity around specific EDA workloads rather than manually managing static infrastructure. That is important for agentic workflows because Discovery can reason about what needs to run, determine the proper resources needed, while CycleCloud-backed automation helps ensure the right compute environment is available when those jobs are ready to execute.

Just as importantly, hybrid adoption does not need to force customers to replace the scheduling systems their engineering organizations already use. Many semiconductor teams have deep operational investments in incumbent schedulers which CycleCloud already works with, established queues, policies, licenses, scripts, and user workflows. A practical Discovery-plus-Azure-HPC architecture helps bring agentic AI to their existing flows: integrating cloud capacity with existing scheduler patterns, extending familiar job-submission models, and allowing teams to burst selected workloads into Azure while preserving the operational controls that have governed EDA execution for years.

In that architecture, Discovery can act as the intelligent orchestration layer across the hybrid estate as well as a productivity accelerator. Agents can reason over design intent, prior results, and engineering context; submit jobs into Azure HPC environments; use AMD-powered compute for demanding EDA runs; access hot data through Azure NetApp Files; and work through cluster automation and scheduler integrations that align with customer operating models. Combined with Azure HPC, Azure NetApp Files helps eliminate storage bottlenecks that can otherwise limit EDA job throughput, allowing compute resources, EDA licenses, and engineering teams to remain productive at scale. The result is a practical synthesis: AI-guided exploration, proven EDA validation, elastic cloud compute, hybrid data access, and scheduler-aware execution that respects the way semiconductor teams already work.

Why it matters for semiconductor teams

Semiconductor design is a systems problem. Teams must manage more IP, more verification complexity, more software interaction, more foundry requirements, and more pressure to maintain schedules while design sizes and complexity grows. The industry has invested heavily in automation, but much of that automation remains fragmented across scripts, dashboards, job schedulers, and individual expert workflows. The simple fact is that compute is expensive, but engineering time is even more expensive. Improving engineer productivity has an outsized impact on schedule, quality, and cost.

Agentic AI offers a way to automation more of the design and verification process. Automating much of the more mechanical parts of the flow. Teams can create workflows that observe, reason, and iterate while agents coordinate the results to achieve the engineering objective. Instead of relying only on tribal knowledge, teams can preserve decisions, evidence, and rationale in a repeatable workflow.

Human-in-the-loop by design

The goal is not autonomous chip design without engineers. The goal is amplified engineering outcomes. In the most valuable scenarios, agents handle the repetitive, high-volume, evidence-gathering work while engineers define objectives, validate assumptions, approve major decisions, and interpret tradeoffs. Discovery can help reduce the menial burden of searching, summarizing, comparing, rerunning, and documenting so engineers can spend more time on the creative and analytical work only they can do. This is especially important in EDA, where correctness, traceability, and sign-off confidence matter as much as speed.

Microsoft Discovery’s emphasis on enterprise governance and transparency is therefore central to the story. In regulated or high-stakes engineering environments, teams need to know what data was used, which tools were invoked, what assumptions were made, and where human approval occurred. Just as important, they need confidence that AI-generated recommendations are validated through established engineering practices, not accepted on faith. Agentic workflows must be auditable, explainable, and grounded in the same EDA verification and signoff discipline the industry already depends on.

Conclusion: Going beyond just compute and AI

The next phase of EDA acceleration will not come from compute alone, and it will not come from AI alone. It will come from the synthesis of both: HPC infrastructure that can execute at scale, and agentic AI systems that can reason, coordinate, and learn across complex engineering workflows.

Microsoft Discovery steps towards that future. For HPC and EDA teams, the opportunity is to move from faster batch execution to intelligent convergence: workflows that know what has been tried, understand what changed, recommend what to try next, and use scalable compute to validate ideas quickly through proven EDA tools and methodologies. In a world where design complexity keeps rising, the ability to combine elastic compute with agentic systems can help to greatly improve productivity, turn repetitive process work into guided automation, and validate AI-assisted decisions through the same trusted engineering practices the semiconductor industry has used for decades.

The Microsoft Discovery team will be at Design Automation Conference, July 27-29, 2026, in Long Beach, California. The Microsoft Discovery team will be showcasing how engineers can use agentic AI to enable greater productivity for semiconductor design workloads. Drop by the Microsoft booth (651) to learn more about Microsoft Discovery for semiconductor design. Learn how technologies from AMD and NetApp come together with Azure HPC to provide the high-performance environment for running EDA tools on the cloud.

Take command of your Microsoft Foundry AI agents with the Azure Copilot Observability Agent

Ron Frenkel — Tue, 21 Jul 2026 16:28:48 GMT

Generative AI (GenAI) agents are moving from prototypes to production, running as part of real distributed applications. When a Microsoft Foundry agent slows down, returns errors, or spikes in token usage, teams need to know why - fast, and with evidence. The Azure Copilot Observability Agent, generally available and powered by Azure Monitor, makes Foundry and GenAI agent investigations a first-class scenario. You can investigate agent failures, latency, tool-call errors, and backend saturation through the same signals that run your Azure estate.

Why AI observability matters in production

Building an agent is one thing. Running a fleet of them at scale, in front of real users, is another. AI applications also introduce behaviors that traditional monitoring wasn't built to explain:

Non-deterministic outputs - the same prompt can take a different path through the agent's logic.
New failure modes - hallucinations, tool-call failures, and reasoning that silently goes off track.
Cost and latency that shift with behavior - tokens and response time depend on what the agent decides to do, which models are used and so on.
Fleet-scale complexity - many agents, across frameworks and hosting, each part of a larger system.

AI observability closes this gap. You need to observe your AI workflows, understand their health, and investigate when an agent is failing, slow, or behaving in ways users notice.

From telemetry to analysis and investigation

Microsoft Foundry is your home for building and evaluating agents, while Azure Monitor makes those agents a first-class item you can observe through traces, tool calls, dependencies, token usage, and evaluation signals - across frameworks and hosting environments. Once you instrument your agents, their telemetry flows into Azure Monitor through Application Insights, and the Observability Agent reasons over it there. Setting this up is a straightforward process: instrument the agent, confirm telemetry is landing, then work with it in Azure Monitor. The Monitor AI Agents with Application Insights walks you through the experience and lets you jump directly from an agent's Monitoring tab in Foundry to Azure Monitor, and New capabilities to observe agents in Azure Monitor covers the wider telemetry pipeline behind it.

Telemetry tells you what happened, Analysis helps you make sense of it, and investigations tell you why. Most days start with analytics: you can chat with your observability data in natural language - ask for an error summary, a latency overview, or dependency health, then follow up to explore a pattern and decide whether something warrants a deeper look. So, the Observability Agent isn't only for investigations; it's also how you analyze and explore your agent telemetry day to day. When that exploration surfaces a real problem and you need the why, it escalates into deep investigations and root cause analysis for GenAI scenarios. The Azure Copilot Observability Agent reasons across your telemetry - logs, metrics, traces, alerts, dependencies, Foundry telemetry, and changes - together with Azure resource context, discovered topology, and relevant instructions. It frames hypotheses, gathers evidence, rules out weak explanations, and shows the reasoning behind its findings. Because it runs inside Azure Monitor, it inherits the access controls you already use - chat and investigations run with the signed-in user's identity and Azure role-based access control (RBAC), and your prompts and responses aren't used to train foundation models.

For Foundry and GenAI agents, you can investigate issues including agent failures and errors, latency, tool-call failures and failing Model Context Protocol (MCP) or backend dependencies, token spikes, and regressions after deployments - prioritizing the failure, latency, and throttling patterns that matter most.

It's powered by the same investigation model the Observability Agent applies to your applications, Azure Kubernetes Service (AKS), and virtual machines (VMs). Autonomous operations, in public preview, can analyze alerts in the background, correlate related alerts, and create Azure Monitor issues with findings and next steps - preparing context and reducing triage work, with humans in control.

Deep investigation through the Azure stack

One of the Observability Agent's key strengths is that it doesn't stop at the agent boundary. It investigates through the Azure stack - from the agent to its dependencies and tool calls, down to the infrastructure behind them.

Take a common Foundry pattern: agent failures caused by backend SQL saturation. When a Foundry GenAI agent starts failing, the root cause can go beyond the model or the prompt. The agent scopes to the affected agent, its dependencies and tool calls, and the SQL backend; correlates the failures with SQL timeouts and a spike in failed dependency calls; rules out alternatives like cache issues or a broader outage; and identifies a short SQL saturation window often driven by a high-cost query as the cause. For more patterns, read the deep investigation examples for the Azure Copilot Observability Agent.

Watch it in action:

A closer look: diagnosing an agent over a time range

To see how this plays out, point the Observability Agent at a specific agent and a time range say, the last 24 hours, and ask it to diagnose operation and performance. Instead of a single answer, it works through the problem the way an experienced operator would, across three lines of reasoning.

Failure patterns. It first establishes whether failures trace back to one dominant cause or several unrelated ones, and identifies which tools and dependencies are failing most and with what error and GenAI error types. It separates expected, app-level failures - validation errors, 400s and 404s - from platform and reliability failures like 5xx responses, timeouts, and dropped connections, so you don't spend time on noise. For each top failure type, it points to the likely locus: Main agent, sub-agent, tool, or a downstream service shows the supporting evidence, and proposes the most actionable fix.

Latency and slow runs. When a run is slow, it traces the end-to-end flow - entry point, agent steps, model and tool calls, and downstream dependencies - and shows where the time actually goes. If you give it a specific run, it walks that transaction step by step; if you don't, it looks across runs to find where latency concentrates: The large language model (LLM) call, a tool call, orchestration, or a downstream dependency, and tells you whether the slowness is systemic or isolated.

Throttling and quota pressure. It confirms whether you're seeing throttling signals - 429s, 503s, timeouts, and backoff patterns - and attributes them to the most likely source: the model or provider, the Foundry runtime, or another dependency. It also checks whether retries and backoff are helping or actually amplifying the problem.

The result isn't a dashboard you have to interpret. It's a prioritized, evidence-backed read on what's failing, what's slow, and what's being throttled - with the reasoning shown at each step, so you can act on it or dig further.

Get started

The Azure Copilot Observability Agent is generally available in Azure Monitor, and autonomous operations are available in public preview.

Instrument your Foundry and GenAI agents, then explore them in the agents view in Azure Monitor.
See what's possible once agents are instrumented in New capabilities to observe agents in Azure Monitor.
Learn how to use the Azure Copilot Observability Agent.
Explore how deep investigations in the Azure Copilot Observability Agent work.
Read the announcement: Azure Copilot Observability Agent is generally available, with autonomous operations in preview.

What's next for Foundry and GenAI agents

The Observability Agent already reasons about the scenarios that matter most for GenAI agents today: It investigates agent failures, latency, and performance, and it also understands token economy and works with evaluation signals. Here's where we're investing next:

Advanced token analysis - clearer visibility into where tokens go, which runs are most expensive, and how model and prompt choices affect cost.
Deeper failure attribution - pinpoint whether an issue comes from agent logic, model behavior, or a backend dependency, so you troubleshoot the right layer.
Richer evaluation correlation - easier ways to tie quality regressions to the specific runs, prompts, and changes behind them.

These additions extend the Observability Agent's existing strengths while keeping the same governed, evidence-first, human-in-control model you rely on today.

Stay connected

Follow this blog for ongoing deep dives, updates on current capabilities, and a preview of what's coming next.
Live webinar - a walkthrough of real Observability Agent scenarios, best practices, and what's available today - along with a look at what's coming next, and live Q&A with the product team. Register for the Observability Agent webinar

We'd love your feedback

The Observability Agent continues to evolve based on real-world usage and operator feedback. Share your thoughts directly through the Give Feedback option in the experience or reach us at rofrenke@microsoft.com.

Azure Architecture Best Practices for Enterprise Applications

JohnNaguib — Mon, 20 Jul 2026 14:28:26 GMT

As businesses continue to modernize their IT infrastructure, Microsoft Azure has become one of the leading cloud platforms for building enterprise-grade applications. Organizations of all sizes rely on Azure to improve scalability, strengthen security, reduce operational costs, and accelerate digital transformation. However, simply moving an application to the cloud does not guarantee success. A well-designed Azure architecture is the foundation of a secure, reliable, and high-performing enterprise application.

https://dellenny.com/azure-architecture-best-practices-for-enterprise-applications/

Join us for our MCP Live! — A free livestream covering all things MCP

Pamela_Fox — Mon, 20 Jul 2026 07:00:00 GMT

The Model Context Protocol (MCP) is the open standard for connecting AI models to tools and data. It was first introduced to the world by Anthropic in November 2024, and is now the most widely adopted standard in the world of Generative AI. You can now use MCP servers to connect agents to your data sources across multiple clients: VS Code, Claude Desktop, Codex, Copilot App, Goose, and many more. Plus, MCP is the most common way to build your own agents that connect to internal enterprise tools, like when using Microsoft agent-framework or Langchain.

To celebrate the success of MCP and its rich ecosystem, we are hosting MCP Live! on September 9th, from 9AM to 1PM PT. We'll hear both from the teams at Microsoft that are implementing MCP, but also from core MCP maintainers and the global community of MCP developers.

Register here:

https://aka.ms/MCPLive/99/b

Here's our current planned agenda:

Time	Topic	Speakers
9 AM PT	Welcome to MCP Live!	Liam Hampton and Pamela Fox (Microsoft/GitHub), MCP advocates
9:15 AM	State of MCP	Caitie McCaffrey (Microsoft), MCP core maintainer
9:45 AM	MCP at GitHub	Sam Morrow (GitHub), GitHub MCP server maintainer
10:05 AM	MCP at Microsoft	Linda Li (Microsoft), Foundry Toolbox PM
10:45 AM	Building MCP servers in VS Code	VS Code Engineering Team
11:30 AM	MCP Authorization: DCR, EMA, and more!	MCP authorization maintainers (To be announced!)
12:15 AM	MCP Apps	Jeremiah Lowin (Prefect), FastMCP maintainer
12:30 AM	MCP Tasks, Events, Triggers	Clare Liguori (Amazon), MCP core maintainer
12:45 AM	Closing	Liam Hampton and Pamela Fox (Microsoft/GitHub), MCP advocates

We're very excited to bring together so many folks working on both the MCP specification and on production MCP servers, so we can all learn about the latest MCP features and best practices together.

Learn more MCP

Brand new to MCP? We still want you to join! If you want, you can learn MCP fundamentals from our free resources:

MCP-for-beginners : A step-by-step written tutorial covering all the MCP features
Python + MCP series : Recordings of a 3-part livestream series focusing on building MCP servers with Python

Meet the MCP community

Want to meet the MCP community in person? We're also planning several IRL events:

Hope to see you in the live chat on September 9th!

Round Table: Building Browser-Capable Agents with the Browser Automation Tool

Lee_Stott — Sat, 18 Jul 2026 22:12:25 GMT

Some of the most valuable work still lives inside a browser: booking a class, pulling a figure off a dashboard, filling in a portal form, gathering research across a dozen tabs. These are exactly the tasks people wish an agent could just do. On 22 July 2026 at 2:30 PM BST (7:00 PM IST), the Microsoft Foundry community is running a 40‑minute Discord round table on the Browser Automation tool : how how it helps agents complete real browser workflows, where you see risk or friction, and what samples, docs, and product improvements would help you adopt it.

This is a discussion, not a slideshow. Bring your real projects : the the web workflows you'd love to hand off, and the guardrails you'd want first. Join us in the Microsoft Foundry Discord community. Please arrive at the scheduled time for a quick tech check.

Event at a glance

What: Microsoft Foundry Discord Community Round Table : Building Browser-Capable Agents with the Browser Automation Tool
When: 22 July 2026, 2:30 PM BST / 7:00 PM IST (40 minutes)
Where: https://aka.ms/foundry/discord
Event link
https://discord.gg/Z8JZsrP5P5?event=1527676149264679013
Format: Interactive discussion : voice and chat, live polls, and a short prioritisation exercise voice and chat, live polls, and a short prioritisation exercise
Who it's for: AI engineers and developers building agents that need to act on the web

Opening question we'll start with: "What browser-based task would you love an AI agent to automate for you today?"

The problem: the last mile of automation still runs in a browser

Most real-world workflows eventually hit a website with no clean API , such as a supplier portal, an internal admin console, a booking page, or a legacy dashboard a supplier portal, an internal admin console, a booking page, a legacy dashboard. Traditional scripting can automate these, but selectors break, pages change, and every new site means another brittle script to maintain. What developers actually want is an agent that can look at a page, decide what to do, and do it : navigate, read, click, type, and hand back a structured result navigate, read, click, type, and hand back a structured result.

That's the gap the Browser Automation tool in Microsoft Foundry is built to close , and doing it responsibly and doing it responsibly, with the right safeguards, is a big part of why we want your feedback.

What is the Browser Automation tool?

The Browser Automation Tool (BAT) gives Foundry agents the ability to drive a real browser to complete web workflows. It's available as an MCP tool, and it uses Playwright Workspaces , a generally available, cloud-scale service, a generally available, cloud-scale service : navigating, clicking at coordinates, typing, and applying filters as its headless browser infrastructure. When an agent gets a request, Foundry spins up an isolated, sandboxed browser session per interaction, so each run is private and segregated.

How agents actually interact with a page

BAT runs a perception–action loop. The model receives the current state of the page (including screenshots), decides the next action, and BAT executes it in the sandbox using Playwright and real oversight navigating, clicking at coordinates, typing, applying filters. After each action, BAT captures the updated state and sends it back to the model, repeating until the goal is met or the user stops. Because the model can parse HTML into a DOM, it can reason about the page rather than follow a fixed script. It also supports multi-turn conversations, so you can refine a request mid-flow to complete form-filling or scraping scenarios.

Built for real use : watch the automation happen in real time for debugging. and real oversight

Live View : a human-in-the-loop override for ambiguous or sensitive steps. watch the automation happen in real time for debugging.
Take Control : each interaction gets its own sandboxed browser. a human-in-the-loop override for ambiguous or sensitive steps.
Isolated sessions : for reliability, optimisation, and audit. each interaction gets its own sandboxed browser.
Built-in observability : for internal systems (private preview). for reliability, optimisation, and audit.
Private website browsing : Python, C#, JavaScript, Java, and the REST API. for internal systems (private preview).
Broad SDK support , and the agent can make mistakes or be misled by malicious page content Python, C#, JavaScript, Java, and the REST API.

A word on responsible use. BAT is powerful precisely because an AI can use credentials you share with it to reach email, financial, enterprise, or social accounts , watching for and the agent can make mistakes or be misled by malicious page content. You're responsible for reviewing your applications, scoping which credentials you provide, and adding your own mitigations. See the Foundry Agent Service transparency note. This is exactly the kind of trade-off we want to talk through together.

Example scenario

A user asks: "Report the year-to-date percent change of Microsoft's stock price." The agent navigates to a finance site, enters MSFT in the search bar, opens the stock page, clicks the YTD view on the chart, reads the value, and returns a clean, structured answer ; that's the no bespoke scraper, no hard-coded selectors, and a full trace of what it did.

Discussion prompt: "Where would browser automation fit into your current projects or workflows?"

How setup works (the short version)

You'll want to understand the wiring before you scale, so it's worth a look ahead of the session. There are two moving parts:

Create a Playwright Workspace in the Azure portal, enable the access token auth method, and grab the wss:// browser endpoint. Give your project identity a Contributor (or custom) role on the workspace.
Connect the tool in Foundry under Build > Tools: create a toolbox, add Browser Automation, point it at your Playwright workspace and auth type, and publish. Copy the Project connection ID from the tool's details page : how agents interact with the web, example use cases, and responsible use. that's the BROWSER_CONNECTION_ID in your code.

What we'll cover in the 40 minutes

Welcome & opening question (0:00–0:03) : navigate, gather, interact, and return a structured result, end to end. the browser task you'd most love to automate.
What is Browser Automation (0:03–0:07) : the workflows you're building, public vs. internal targets, and where you'd pick automation over scripting. how agents interact with the web, example use cases, and responsible use.
Scenario walkthrough (0:07–0:12) : what agents may do autonomously, what needs approval, and the observability and enterprise safeguards you'd require. navigate, gather, interact, return a structured result : your biggest adoption blockers, missing docs, and the SDK samples and demos you'd prioritise. end to end.
Use cases & opportunities (0:12–0:22) : vote live on top use cases, challenges, and feature requests. the workflows you're building, public vs. internal targets, and where you'd pick automation over scripting.
Trust, security & governance (0:22–0:31) , and which would benefit most from a capable agent. what agents may do autonomously, what needs approval, and the observability and enterprise safeguards you'd require.
Developer experience feedback (0:31–0:36) ; which should always require approval. your biggest adoption blockers, missing docs, and the SDK samples and demos you'd prioritise.
Prioritisation & next steps (0:36–0:40) , sometimes with credentials, vote live on top use cases, challenges, and feature requests.

Come prepared to talk about

The browser-based workflows you're building today : navigation, data gathering, form filling, and research, via an MCP tool powered by Playwright Workspaces. and which would benefit most from a capable agent.
Whether your scenarios target public websites, internal systems, or both.
Why you'd choose browser automation over traditional scripting.
Which actions you'd let an agent perform autonomously : a perception-action loop with screenshots and DOM parsing handles pages that break brittle scripts. and which should always require approval.
The observability, audit, and enterprise safeguards you'd expect before running this in production.
The examples, samples, and tutorials that would help you get started fastest.

Responsible and secure by design

Because BAT lets an agent take real actions on live websites : isolated sessions, Live View, Take Control, and observability for reliability and audit. sometimes with credentials : scope credentials carefully and add your own mitigations; the tool is powerful and in preview. governance is a first-class part of the conversation, not a footnote. Isolated per-session sandboxes, Live View, Take Control human-in-the-loop, and built-in observability are there so you can see, pause, and audit what an agent does. Bring your trust concerns, required guardrails, and governance requirements: they directly shape the roadmap.

Note: the Browser Automation tool is in preview; APIs and capabilities may change, and it isn't recommended for production workloads yet.

Key takeaways

Browser Automation lets Foundry agents complete real web workflows : this round table feeds directly into the engineering and product teams. navigation, data gathering, form filling, research , and arrive on time for the tech check. via an MCP tool powered by Playwright Workspaces.
Agents reason, not just replay , and browser-capable agents are how we cross it. a perception–action loop with screenshots and DOM parsing handles pages that break brittle scripts.
Oversight is built in: isolated sessions, Live View, Take Control, and observability for reliability and audit.
Responsibility is shared: scope credentials carefully and add your own mitigations; the tool is powerful and in preview.
Your feedback shapes the product: this round table feeds directly into the engineering and product teams.

Save your spot

Add it to your calendar: 22 July 2026, 2:30 PM BST / 7:00 PM IST, and arrive on time for the tech check.
Join the community: https://aka.ms/foundry/discord
Prep with the sample: explore the browser automation sample in foundry-samples.
Read the docs: Automate browser tasks with Foundry agents and the hosted-agent quickstart.
Event registration link
https://discord.gg/Z8JZsrP5P5?event=1527676149264679013

The last mile of automation still runs in a browser, and browser-capable agents are how we cross it. Come tell us what you'd automate, where you'd draw the line, and what you'd need to trust it in production. See you on 22 July.

Microsoft Foundry Now Has an AI Gateway Control Plane — What Changes for App Service

jordanselig — Fri, 17 Jul 2026 17:04:16 GMT

In May, I published a runnable sample that put Azure API Management in front of an AI agent on Azure App Service. APIM handled token limits, semantic caching, token metrics, and access to the model. The point was simple: keep the agent framework interchangeable and put the production controls at the gateway.

A recent Apps on Azure post, From AI Adoption to AI Governance, arrived at the same architectural conclusion from a platform-governance angle. It uses APIM to turn model identity and token consumption into a per-model chargeback signal for Microsoft Foundry workloads.

That is useful validation, but the more interesting update is in the product itself: Microsoft Foundry can now create or associate an APIM-based AI Gateway directly from its Admin console. The data path is still APIM. What changed is who can configure and govern it.

This post explains what that means for an App Service-hosted agent, what Foundry now manages, what still belongs in APIM, and what I would change in the sample we built earlier.

The short version: same gateway, new control plane

The architecture is still familiar:

Client -> App Service agent -> APIM AI Gateway -> Foundry model

APIM remains the traffic gateway. It authenticates callers, applies policies, forwards requests, and emits telemetry. App Service remains the application runtime for the agent and its APIs.

The new piece is the Foundry control plane. From Operate > Admin console > AI Gateway, a platform team can now:

Create a new APIM instance or associate a supported existing instance.
Enable the gateway for individual Foundry projects.
Apply independent token limits to projects sharing the gateway.
Verify gateway traffic and inspect logs.

Once the gateway is enabled, separate Foundry experiences can also register custom agents and govern supported MCP tools. Those actions do not happen in the AI Gateway tab itself, but the gateway provides their governed traffic path.

That is a meaningful shift. In the original sample, the infrastructure owner created APIM, imported the model API, deployed policy XML, and wired the agent to the gateway. Foundry does not remove APIM or replace those advanced capabilities. It gives Foundry administrators a first-party path into the same architecture.

What Foundry now owns

Project onboarding

An AI Gateway is associated with a Foundry resource, then enabled for projects inside it. New projects can inherit the gateway automatically. Existing projects must be added explicitly.

This creates a useful governance boundary: multiple teams can share the same APIM instance without sharing one undifferentiated token pool. Each project can receive its own token ceiling. If a project exceeds its configured limit, the gateway returns 429 Too Many Requests while other projects continue using their allocations.

Foundry-level limits

Our earlier sample used an APIM token-limit policy keyed by an APIM subscription. That is still a valid pattern, especially when the consumer boundary is an application, business unit, or external customer.

The Foundry integration adds another natural counter key: the Foundry project. For organizations already organizing models and agents by project, limits can now follow that structure instead of being recreated independently in every client application.

Inventory for agents and tools

The AI Gateway experience is expanding beyond model endpoints in two distinct ways. Foundry can register custom agents running outside Foundry, including agents that use A2A as their communication protocol. Separately, AI Gateway can govern supported MCP tools. The current tools-governance preview is scoped to MCP; it does not cover every Foundry or OpenAPI tool type.

That matters for App Service because the runtime does not need to move. An agent can continue running on App Service while participating in Foundry's inventory, and its supported MCP traffic can flow through the gateway.

These experiences are still preview features, so I would treat them as a control-plane integration to evaluate, not a reason to redesign a working production agent.

What still belongs in APIM

Foundry makes the common path easier. It does not make the full APIM surface unnecessary.

I would still use APIM directly for:

Custom policy expressions and organization-specific headers or claims.
Semantic caching backed by Azure Managed Redis.
Backend pools, priority routing, and circuit breakers.
Private networking, multi-region gateways, and advanced topology decisions.
Custom metrics and dimensions needed for internal chargeback.

The clean mental model is: Foundry manages the AI assets and common project guardrails; APIM manages the traffic contract and advanced gateway behavior.

Applying this to the App Service sample

The existing framework-agnostic AI Gateway sample hosts a Microsoft Agent Framework agent and an MCP server on one Linux App Service. The agent reaches its model through APIM, which applies token limits, semantic caching, token metrics, and managed-identity authentication.

Most of that architecture should stay exactly as it is.

1. Keep the App Service application unchanged

The agent should continue calling a stable gateway endpoint. It should not need to understand whether APIM was provisioned by Bicep, associated in Foundry, or managed by a central platform team. That separation was the reason to introduce the gateway in the first place.

2. Choose the APIM ownership model deliberately

For a new proof of concept, Foundry can create a Basic v2 APIM instance. For production, Microsoft recommends evaluating Standard v2 or Premium v2 based on throughput and networking requirements.

For an existing enterprise gateway, use the Foundry option to associate an APIM instance only after confirming that it meets the eligibility requirements: it must be in the same Microsoft Entra tenant and Azure subscription as the Foundry resource, you need the API Management Service Contributor role (or Owner), and the instance must use a supported v2 tier.

Important migration detail: the original sample defaults to the APIM Developer tier. That instance will not appear in Foundry's Use existing APIM list because the direct integration currently requires a v2 tier. Do not assume an existing classic-tier gateway can simply be attached.

3. Add existing projects explicitly

Creating or associating the gateway at the Foundry resource level does not automatically enable every existing project. Add each existing project to the gateway, then verify its status is Enabled.

4. Decide where each limit belongs

Avoid layering limits without a clear ownership model. A Foundry project limit, an APIM subscription limit, and a model deployment TPM limit answer different questions:

Control	Best boundary	Question it answers
Foundry project limit	Team or workload project	How much shared capacity can this project consume?
APIM policy limit	Subscription, user, tenant, or application	How much can this specific consumer use?
Model deployment quota	Backend deployment	What capacity exists at the model endpoint?

Use all three when the boundaries are intentional. Otherwise, operators end up debugging a 429 without knowing which layer produced it.

5. Verify the data path

After enabling a project, make a model request and confirm that the APIM request metric increments. Microsoft also recommends checking the GatewayLogs table for a successful response and an API name matching the AI Gateway.

Then test the failure path. Set a deliberately small project limit, exceed it, and confirm that the gateway returns 429. A governance feature is not finished until the team has observed both the allowed and denied behavior.

Which path should you choose?

Scenario	Recommended approach
New Foundry proof of concept	Create the AI Gateway from Foundry and start with project-level limits.
Existing v2 enterprise APIM	Associate the existing instance and preserve central networking and policy ownership.
Existing classic-tier APIM	Keep the working gateway or plan a deliberate v2 migration; it cannot be selected directly today.
Advanced routing or custom policy needs	Use Foundry for inventory and common guardrails, then manage the advanced behavior in APIM.
Strict isolation between project groups	Use separate Foundry resources and separate gateways rather than assuming one gateway per project.

The architecture was right; the experience caught up

The most important takeaway is not that everyone should rebuild an AI Gateway in a new portal. It is that the composable architecture now has a more accessible control plane.

App Service still runs the agent. APIM still governs the traffic. Foundry now gives model and platform owners a direct way to connect projects, allocate capacity, and bring agents and tools into the same governance view.

If you already built the earlier sample, the application boundary does not need to change. Evaluate the Foundry integration, decide whether its project model matches your organization, and check the APIM tier before planning any migration. The gateway remains the contribution; Foundry now makes it easier to operate.