Azure Integration Services Blog articles

Write Logic Apps in C#: introducing the Logic Apps Standard SDK

WSilveira — Tue, 02 Jun 2026 20:54:24 GMT

The workflow you always wished you could write in code

If you build on Logic Apps Standard, you already know the deal: the runtime is excellent at the unglamorous parts of integration - connecting to systems, retrying, scaling, keeping run history you can actually debug. What you sometimes wanted was a different front door. You're a .NET developer. You live in C#, source control, and pull requests. And for a long time, authoring a workflow meant leaving all of that behind for a visual designer and a JSON file.

That's the gap the new Logic Apps Standard SDK closes. It lets you define Logic Apps Standard workflows in code - strongly typed, IntelliSense-guided C# - without giving up a single thing the runtime already does for you.

What is the Logic Apps Standard SDK?

The Logic Apps Standard SDK (Microsoft.Azure.Workflows.Sdk) is a NuGet package that gives you a fluent, code-first way to build workflow definitions in C#. Instead of dragging actions onto a canvas, you compose a workflow with method chaining: a trigger, then the actions that follow it, all the way to a response.

Worth saying clearly, because people ask: this is a new way to define workflows - not a new runtime. The workflows you write with the SDK compile down to the same definitions and run on the same Logic Apps Standard runtime you use today. Same connectors. Same hosting. Same rich run history and monitoring. You're changing the authoring experience, not the engine underneath it.

Why this matters for developers

When your workflow lives in C#, it behaves like the rest of your code. A few things fall out of that almost for free:

Type safety and IntelliSense - connector operations, triggers, and outputs are discoverable as you type, and the compiler catches mistakes before you run anything.
Real source control and reviews - workflows diff like code, get reviewed in pull requests, and version alongside the services they orchestrate.
Familiar tooling - refactor, debug with F5, and lean on the .NET ecosystem you already know.
Extensibility on your terms — Compose your workflow declaratively with the fluent builder, then drop into plain imperative C# wherever a step needs logic that might be too complex to implement declaratively - loops, branching, a call into your own library, all encapsulated in a step of your workflow - without leaving the file or the language.

And it isn't limited to one style of work. The SDK covers both enterprise integration workflows - the connect-systems-and-move-data scenarios Logic Apps is known for - and agentic workflows, where a conversational or autonomous AI agent drives the steps. Both are first-class in the same SDK, built from the same building blocks.

There's one more angle worth calling out, because it's becoming hard to ignore: coding agents are simply better at writing imperative code than declarative JSON. And the reason is the same set of guardrails that helps you. Strong typing and a compilation step mean the code an agent produces is syntactically correct out of the gate — the type system and the compiler do the checking, so you don't have to. Layer unit tests on top and you've covered north of 90% of what matters; what's left is integration testing. Getting an LLM to the same level of accuracy against declarative JSON means building dedicated tooling to stand in for everything the compiler gives you for free. With code-first workflows, those guardrails are just there — which makes this a natural fit for an agent-assisted way of building.

Getting started

Everything here lives in the Logic Apps extension for VS Code. You'll want the Logic Apps Standard VS Code extension version 5.961.10 or later, which includes all the components you need to create code first workflows. Beyond that, the prerequisites are the ones you'd expect - VS Code with the Logic Apps extension, an Azure subscription you can create resources in, and a working comfort with C# and .NET.

From a clean start, you're a handful of steps from a running workflow:

Create the workspace — launch the Logic Apps extension and choose Create new Logic Apps workspace. Pick a folder, name the workspace and project, and when prompted for the workflow type, choose Logic Apps codeful - that's the code-first option that uses the SDK.
Pick a workflow kind - name your first workflow and choose how it runs: Stateful, Autonomous agents (Preview), or Conversational agents (Preview). The agent options are where the agentic scenarios live.

Enable connectors - when prompted, select Use connectors from Azure, choose your subscription and resource group, and pick Connection Keys for authentication. Managed identity is still in development, so connection keys are the way in for now.
Find your way around - the project opens with Program.cs, which builds and starts the host, plus a workflow file (like workflow1.cs) where your trigger and actions are defined. The SDK compiles those definitions and runs them on the Logic Apps runtime.
Run it - press F5 (or right-click Program.cs and pick Overview). The runtime starts locally and an overview page opens where you can fire triggers, watch run history, and inspect inputs and outputs.

That last part is worth dwelling on: run history for SDK workflows uses the same rich visual view as designer-built ones. You author in code, but you monitor and troubleshoot exactly as you always have.

A look at the capabilities

Connectors and triggers

Every workflow starts with a trigger and runs a series of actions. The SDK exposes both through two entry points - WorkflowTriggers and WorkflowActions - each split into BuiltIn and Managed.

Built-in triggers and actions run directly in the runtime: HTTP request, recurrence, and the conversational agent trigger; actions like Compose, HTTP, Response, and custom code.
Managed connectors give you the full Logic Apps connector catalog - Service Bus, SharePoint, SQL, and hundreds more - typed and ready to call.

The managed surface is generated from the same connector definitions the designer uses, so the operations you know are right there:

// Built-in trigger var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // Managed connector action — full catalog, strongly typed var getItems = WorkflowActions.Managed .Sharepointonline("sharepoint") .GetItems( dataset: () => "https://contoso.sharepoint.com", table: () => "orders-list-id") .WithName("GetOrders");

The fluent API streamlines the definition

This is where it comes together. You compose a workflow by chaining operations with .Then(...). The shape of your code mirrors the shape of your workflow - read it top to bottom and you read the execution path.

trigger .Then(validateOrder) .Then(getOrders) .Then(sendResponse);

Control flow is part of the same fluent model. Built-in structures like Condition (if/else) and ForEach - along with Switch, Until, Scope, and Terminate - are just actions you chain in, each taking a small factory for the branch or loop body:

var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => order.Total > 1000, trueBranch: () => requireApproval, falseBranch: () => autoApprove ).WithName("CheckOrderValue");

And ForEach takes the collection to iterate and a factory that builds the body for each item:

var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => order.LineItems, actions: (item) => new WorkflowBuiltInActions() .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems");

Need parallel branches that fan back in? The same Then pattern handles branching and join - no JSON wiring, no run-after blocks to hand-edit.

Extending workflows with custom code

Some logic doesn't belong in a connector or an expression - it's just code. The CustomCode action lets you drop a real C# method into the middle of a workflow. It receives a WorkflowContext, so you can read the trigger payload or any earlier action's results and return a strongly typed value the next step can use:

var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var trigger = await context.GetTriggerResults(); var order = await context.GetActionResults("GetOrders"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder");

That's the escape hatch that keeps you in flow: when a step needs custom transformation, validation, or a call into your own libraries, you write a method instead of bending an expression to do something it was never meant to.

Handling failures: try/catch with run-after

Real workflows have to deal with things going wrong, and the SDK gives you the same try/catch shape Logic Apps has always had - expressed in code. The .Then(...) overload takes a FlowStatus[] run-after condition, so a handler runs only when the step before it ends in a status you name. Wrap the risky work in a Scope (your try), then chain a handler that runs after it Failed or TimedOut (your catch):

var tryProcess = WorkflowActions.BuiltIn.Control.Scope(() => callPaymentApi.Then(saveOrder) ).WithName("ProcessPayment"); var handleFailure = WorkflowActions.BuiltIn .Compose(inputs: () => "Payment failed — compensating") .WithName("HandleFailure"); trigger .Then(tryProcess) .Then(handleFailure, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut });

The status set is the whole vocabulary: Succeeded, Failed, Skipped, and TimedOut. Combine them however a step needs - a cleanup action that should run no matter what can list every status; a finally is just the union.

The same idea scales to fan-in. When several parallel branches converge, the per-predecessor RunAfter overload lets the join wait on each branch independently - so you can require some to succeed and tolerate others failing:

leftChain .Join(rightChain) .Then(merge, runAfter: new[] { new RunAfter(leftChain, FlowStatus.Succeeded), new RunAfter(rightChain, FlowStatus.Succeeded), });

Putting it together

Here's a small but complete shape - an HTTP-triggered order workflow that validates input, branches on order value, loops over line items, runs custom code, and replies. The core steps live in a Scope so a single failure handler can catch anything that goes wrong, and a clean reply only runs when the work succeeds. Notice it's all one readable chain:

namespace LogicApps { using Microsoft.Azure.Workflows.Sdk; using Microsoft.Azure.Workflows.Sdk.Connectors.Msnweather; using System.Net; public class OrderWorkflow : IWorkflowProvider { /// <summary> /// Gets the HTTP request/response workflow definition. /// </summary> public FlowDefinition[] GetWorkflows() { // --- Trigger ---------------------------------------------------- var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // --- Managed connector action (full catalog, strongly typed) ---- // Reused verbatim from the confirmed stateful1.cs pattern. var getWeather = WorkflowActions.Managed.Msnweather("msnweather").CurrentWeather( location: () => "98058", units: () => unitsInput.Imperial).WithName("GetWeather"); // --- Custom code: real C# in the middle of the workflow --------- var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var triggerResults = await context.GetTriggerResults(); var weather = await context.GetActionResults("GetWeather"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder"); // --- ForEach over a collection (control flow via .Control) ------- var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => trigger.TriggerOutput.Body["lineItems"], actions: (item) => WorkflowActions.BuiltIn .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems"); // --- Condition (if/else) (control flow via .Control) ------------ var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => true, trueBranch: () => processLines, falseBranch: () => WorkflowActions.BuiltIn .Compose(inputs: () => "Auto-approved").WithName("AutoApprove") ).WithName("CheckOrderValue"); // --- Scope groups the core steps so one handler catches failures - var processOrder = WorkflowActions.BuiltIn.Control.Scope(() => checkTotal .Then(getWeather) .Then(enrich) ).WithName("ProcessOrder"); // --- Responses -------------------------------------------------- var ok = WorkflowActions.BuiltIn.Response( responseBody: () => "Order processed").WithName("Reply"); var failed = WorkflowActions.BuiltIn.Response( statusCode: () => HttpStatusCode.InternalServerError, responseBody: () => "Order failed").WithName("ReplyFailed"); // --- Assemble --------------------------------------------------- // Happy path runs after the Scope Succeeded; the handler runs after // Failed or TimedOut. trigger .Then(processOrder) .Then(ok, runAfter: new[] { FlowStatus.Succeeded }) .Then(failed, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut }); return new[] { WorkflowFactory.CreateStatefulWorkflow("OrderWorkflow", trigger) }; } } }

That last stretch is the best-practice shape in miniature: the happy-path Reply runs only after the Scope Succeeded, while a separate handler catches Failed or TimedOut and returns a 500 - no exception plumbing, just run-after conditions.

You implement IWorkflowProvider, hand your trigger graph to WorkflowFactory as a stateful, stateless, or agent workflow, and the host registers it. Run it with F5 and the Logic Apps runtime starts locally - same as any Standard project.

Before you build: preview realities

I'd rather you go in clear-eyed. While the SDK is in public preview, keep these in mind:

Service Provider connectors aren't supported yet - that connector type is coming in a future release.
Dynamic schemas aren't supported - support is planned.
Custom code supports callback methods only - inline lambdas aren't available in this version.
Define and name actions before referencing them - name an action before using it as a dependency elsewhere.
Managed identity authentication is in development - use connection keys for connectors in the meantime.

Try it, and tell us what you think

If you've ever wanted your workflows to live where the rest of your code lives - in C#, in source control, in your pull requests - this is for you. Install the Logic Apps extension for VS Code, create a Logic Apps codeful project, and build your first workflow in code.

This is a preview, which means your feedback genuinely shapes where it goes - which capabilities come next, where the rough edges are.

Bring issues, feature requests and feedback to our GitHub page. I read it. Let's make code-first workflows something you actually want to use.

New AI gateway capabilities in Azure API Management

budzynski — Tue, 02 Jun 2026 20:48:15 GMT

Multi-model, multi-protocol AI applications are quickly becoming the norm. Teams are mixing OpenAI, Anthropic, and Vertex AI models, exposing tools through MCP, and wiring agents together with A2A. As that surface grows, so does the work of keeping it secure, observable, and consistent.

Our ongoing strategy for the AI gateway capabilities in Azure API Management centers on that problem: providing one place to manage models, MCP tools, and agents, no matter which provider or protocol is behind them. The updates below are the latest steps in that direction.

Unified Model API (preview)

The headline change in this release: the Unified Model API lets clients speak one API format — OpenAI Chat Completions — while API Management transforms requests to the backend provider, whether that's a model using OpenAI Chat Completions or Anthropic Messages API.

By centralizing model access behind a single API layer, you can:

Standardize on a single API format for clients, independently from the formats used by backend models.
Unify observability, security, and governance with policies that apply across model providers.
Configure failover across model providers.
Decouple client-facing model names from backend model names using aliases.

Learn more about the unified model API.

Model aliases

Model aliases give clients a stable, provider-neutral name to use when calling a model. By assigning an alias like gpt or claude-sonnet, you decouple the client-facing model name from the actual backend deployment.

That makes a few common operations a lot easier:

Upgrading a model. Update the alias target to point at a new version — no client code changes required.
A/B tests. Shift traffic between backends behind the same alias using API Management's load balancing capabilities.
Vendor swaps. Replace one provider with another without touching application code.

Model discovery

Developers can discover available models by calling the /models endpoint of the Unified Model API. API Management returns the list of model aliases, so apps and tools can adapt to what the platform team has published — without out-of-band documentation.

Anthropic and Vertex AI models (GA)

AI gateway policies and observability now work with Anthropic and Google Vertex AI models, alongside the providers we already support.

You can:

Apply runtime policies such as content safety, token limits, and semantic caching to Anthropic and Vertex AI traffic.
Collect logs, traces, and metrics for these models in the same place as the rest of your AI traffic.

If you're running a multi-provider setup, you no longer need a separate governance story for each vendor.

Learn more about AI gateway capabilities in API Management.

Anthropic API operations in Microsoft Foundry import

When you import a Microsoft Foundry resource as an API in Azure API Management, the import now creates operations for Anthropic APIs alongside the existing model APIs. In a few clicks, you can stand up an API that mediates traffic to Foundry models using either the OpenAI or Anthropic API format — no manual operation definitions needed — and then apply the same policies, security, and observability you use for the rest of your AI traffic.

Learn more about Microsoft Foundry import.

Token metrics for additional token types (preview)

Token tracking used to stop at prompt, completion, and total tokens. Modern models add cached, reasoning, and thinking tokens, which can make up a significant share of token consumption, cost, and latency.

API Management now logs metrics for these additional token types into Application Insights, across API formats (OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages API) and providers (Microsoft Foundry, OpenAI, Amazon Bedrock, Google Vertex AI, and others).

With richer signals, your cost dashboards, budget alerts, and capacity planning can actually reflect how today's models behave.

Learn more about token metrics.

Content safety for MCP and A2A (GA)

The llm-content-safety policy now covers MCP and A2A traffic in addition to LLM traffic. That includes MCP tool-call arguments, MCP response text, and A2A payloads.

A couple of related improvements:

llm-content-safety can now be configured directly as an outbound policy.
Two new attributes — window-size and window-overlap-size — let you tune how messages exceeding the Azure Content Safety limit of 10,000 characters are chunked and forwarded for validation, balancing detection sensitivity with Azure Content Safety call volume.

The result is one consistent safety policy across LLM, MCP, and A2A flows instead of stitching together custom filters per protocol.

Learn more about the content safety policy.

A2A APIs (GA)

Support for Agent-to-Agent (A2A) APIs in API Management is now generally available. Agent APIs can now be governed with the same policies, identity, and observability you use for the rest of your APIs.

What you can do with A2A APIs in API Management:

Mediate JSON-RPC runtime operations to your agent backend with full policy support — including the content safety improvements above.
Expose and manage agent cards, automatically transformed by API Management to represent the managed agent API.
Log traces to Application Insights using OpenTelemetry GenAI semantic conventions for deep correlation between API and agent execution traces.

What's new in GA, on top of the preview:

Available in classic tiers, in addition to v2 tiers — bring A2A governance to existing API Management resources without migrating tiers.
Richer diagnostic logging for A2A APIs, giving more actionable telemetry for monitoring and troubleshooting agent traffic.

Learn more about A2A support in API Management.

Related: Bring Your Own Model in Foundry Agent Service (GA)

Last month, Bring Your Own Model (BYOM) in Foundry Agent Service went GA. BYOM lets enterprise teams route Foundry agent model calls through their own infrastructure — typically for compliance, governance, or to reuse an existing model gateway.

This pairs naturally with the AI gateway capabilities in Azure API Management. Put API Management in front of your models, apply the policies and observability described above, and have Foundry agents call through it — getting consistent governance for both your direct AI traffic and your agent workloads.

Get started

Together, these updates make Azure API Management a more complete AI gateway: consistent governance, security, and observability across models from various providers, MCP tools, and agent interactions.

Some of these features are still rolling out. They will first become available in v2 tiers of API Management and in the AI release channel for classic tiers, then continue rolling out to the rest of classic tier resources over the following weeks.

Get started with the unified model API or explore the AI gateway capabilities in API Management.

🎉 Automation just became a team sport. Meet Azure Logic Apps Automation.

DivSwa — Tue, 02 Jun 2026 19:45:58 GMT

Low barrier to entry. Built for production.

Now in Public Preview

There's a moment that plays out in almost every organization right now. Someone closest a business problem - a retail ops lead, a finance analyst, a security analyst looks at a repetitive process and thinks, this should just run itself. For most of computing history, turning that idea into reality required specialized skills, significant setup, and engineering resources that were often focused elsewhere.

AI is changing that. Today, people can describe what they want in natural language and watch working solutions take shape. The bottleneck is no longer generating an idea for automation. It's turning that idea into something secure, governed, and reliable enough to run in production. The demos are everywhere. The question organizations are increasingly asking is the harder one: which of these can we actually run in production?

That's exactly the shift we built for.

Today at Microsoft Build we're introducing Azure Logic Apps Automation, a new Logic Apps SKU that delivers the experience of a modern SaaS product for creating and running workflow automations. It makes it easier for teams to get started quickly while preserving the security, governance, reliability, and scale organizations expect from Azure. It's open to builders of every kind, available now in public preview at https://auto.azure.com.

New experience, same enterprise engine

The goal was straightforward: simplify the experience of building and running automations without compromising the enterprise foundation underneath.

Logic Apps Automation provides a managed experience where compute, model endpoints, knowledge services, and execution environments are available out of the box. Teams can focus on solving business problems rather than assembling infrastructure and services.

We also introduced a dedicated SaaS experience designed around productivity and collaboration. Administrators establish governance and policies, while builders can quickly begin creating workflows without requiring deep Azure expertise.

"The redesigned experience lets me build AI-based solutions in record time. This platform will serve as the glue in most modern solutions.", Mick Badran, Founder & Director at SolveIT.Today [LA Automation Early Adopter]

What we kept is just as important. Logic Apps Automation is built on the same Azure Logic Apps platform organizations trust today. The reliability, scale, security, governance, and operational maturity remain the foundation. The experience is simpler, but the platform underneath is the same proven technology customers rely on every day.

Low barrier to entry. Built for production. We mean both halves of that sentence.

Build like a startup, ship like an enterprise

Building an automation is only part of the full application journey. As solutions move from experimentation to production, along with simple experience, organizations need security, governance, networking, identity, and operational controls to ensure those automations can be trusted at scale.Logic Apps Automation is designed for both realities.

On the build side, it's fast to get started. Login and start building workflows; stay on a single canvas throughout the experience: use AI assisted workflow development, use visual workflows when they’re the right fit, and drop into code the moment you need additional control. No switching tools, no handoffs, no separate infrastructure to manage.

On the production side, organizations get the capabilities they expect from an enterprise platform, on day-0: isolated compute, virtual network integration and private endpoints, identity, role-based access, audit logging, and governance policies.

For many automation tools, becoming "enterprise-ready" is something that happens later. With Logic Apps Automation , production-readiness is part of the foundation.

Built for how teams actually work

Making automation easier for builders shouldn't create additional complexity for administrators.

Organizations already have established governance boundaries, ownership models, and operational processes. Logic Apps Automation is designed to align with those realities through a simple two-level hierarchy of Projects and Applications. Project sits at the top and act as your security and governance boundary; inside each project you run one or more Applications.

Admins and project owners set networking policies, connector policies, sandbox configuration, and approved AI models once, at the project scope and every application inherits them. Builders get a wide-open space to create. Admins get a firm line around it. Nobody has to choose between the two.

Flexible permission management for individuals and teams

The permission model is also designed to match how teams collaborate:

A private space for an individual. To give a single user a place to run their own automations with a privacy boundary around personal resources such as their email account - create an application that only that individual can access.
A shared space for a team. To support an automation that several people co-develop and operate together, add multiple users to the application so they can build, run, and maintain it collectively.

The same model accommodates both access patterns, giving builders clear control over the scope of each application and who can work within it.

AI-native, not AI-retrofitted

Logic Apps Automation is designed for a new generation of business processes that combine workflows, AI agents, enterprise systems, and human decision-making.

It starts with how you build. A built-in AI Assistant turns plain language into working automation. You describe what you want and it drafts the workflow, configures actions, writes expressions, and generates inline code, then helps you edit the same way. You can author at the level of a single step or an entire end-to-end flow. This is the thing that opens the platform to *every* developer: the person closest to the problem can describe it and get something real, while pros stay in control and drop to code whenever they want.

"With the power of AI, automations just got on steroids! Simply tell it what you need, explain the intent, et voilà! Love it.", Sonny Gillissen,

Integration Architect at Rubicon Cloud Advisor [LA Automation Early Adopter]

Agents are first-class

Agents are first-class, and we meet you where you are with three ways to integrate them:

Agent-loop orchestration. If you're already using Logic Apps actions as tools inside an agent loop, that pattern carries forward. Your actions are callable tools the agent can invoke, so you keep orchestrating the way you always have.
Foundry agents. Connect to an existing Microsoft Foundry Hosted or Prompt Agent or create a new one right from the canvas. The platform handles the wiring, and your workflow calls the agent, gets results back, and keeps moving.
Managed sandbox for agent harnesses. Bring a well-known agent harness, like GitHub Copilot and run it in a managed, isolated sandbox. We take care of the compute, the isolation, native shell access, and your GitHub repos as first-class context; you just define the business logic.

Then orchestrate all of these inside a larger workflow, right next to traditional rule-based actions, on a single canvas. Deterministic and agentic, in one place.

A few capabilities that make this especially powerful:

Sandboxed agent harnesses. Run agent harnesses such as GitHub Copilot in a managed, isolated sandbox with shell execution, skills, and GitHub repos as first-class context, without operating any of that infrastructure yourself.
Tools and MCP. Turn any of the 1400+ connectors into a tool or expose any workflow as an MCP server that any compatible agent can call. No code required.
Knowledge as a Service. Drop in your documents and the platform handles ingestion, chunking, embeddings, and retrieval. No RAG pipeline to build, no vector store to operate; just grounded answers.
Any model, anywhere. Plug in whatever fits the job: frontier, open-source, fine-tuned, or local. You're never locked in.

"Azure Automation closes the gap between integration and intelligence with agents as first-class workflow actions, grounded in your own data, executing in isolated sandboxes, all within the same canvas where your triggers and connectors live. Excited to see the evolution.", Sagar Sharma, Enterprise Solution Architect at i8c NL [LA Automation Early Adopter]

What's new in this release

Logic Apps Automation introduces several new capabilities designed to help teams build, deploy, and govern AI-powered automations:

Zero-friction onboarding. Get from Sign-in to first workflow in minutes, with managed infrastructure and enterprise capabilities available from the start.
A new designer. Modern designer with single pane experience to build and monitor workflows, draft-mode for workflows for easy iterations, instant code-to-workflow synchronization when you want to work in code-view, run history you can stream live, and so much more
Natural language authoring. Describe workflows in plain language to create and edit them, with AI assistance in the designer.
More powerful agents. Three ways to bring agents into a workflow; agent-loop orchestration, Foundry Hosted Agents, and well-known harnesses like GitHub Copilot running in a managed, isolated sandbox with shell access and GitHub repos as context.
Knowledge as a Service. A managed knowledge layer that turns your documents into a ready-to-use knowledge base; no RAG pipeline required.
JavaScript expressions. Write inline JavaScript to transform data and express logic without leaving the designer; no domain-specific language to learn.
Projects and applications. A two-level governance hierarchy that gives admins a clear boundary and builders room to create. A permission management model that accommodates different level of access patterns, giving builders clear control over the scope of each application and who can work within it.
Elastic scale, including to zero. Workflows scale up automatically when load arrives and scale all the way down to zero when there's no work to do. You pay only for the vCPU-seconds you actually use.

Built to scale

Logic Apps Automation scales automatically with demand, from idle workloads to business-critical processes. Customers pay only for the resources they use, without per-seat licensing requirements or infrastructure management overhead. When workflows aren't running, you're not paying for compute. When demand increases, the platform scales with you.

Pricing

Logic Apps Automation uses a consumption-based pricing model, so you pay only for what you use. Pricing is based on a small managed-environment fee, workflow execution, and optional services such as AI model usage, knowledge, sandboxes, connector calls. There is no annual commitment, no per-seat license, no quota cliff. When your workflows sit idle, you pay nothing for compute. More details to follow soon.

What's available, and what's next

Logic Apps Automation is available today in public preview, with an intial set of regions today, with more rolling out over the coming weeks. Here is the list of regions its available today:

East Asia
Sweden Central
Australia East
North Central US
UK South
Southeast Asia
West US

Coming Soon

We're continuing to expand the platform with additional AI and enterprise capabilities, including:

Foundry Hosted Agents. Create or Invoke Foundry Hosted Agents directly inside your workflows.
Foundry Prompt Agents. Create/Invoke Foundry prompt directly inside your workflows.
Hosted Models. Managed model endpoints provided for you; no keys or infrastructure to bring.
Inline Python. Write inline Python alongside JavaScript when you need it.
Bring your own container image. Run your own code in sandboxes; for example, orchestrate a Python ETL job from within a Logic Apps workflow.
VNet support and private endpoints.
Custom connectors and more Automation templates. Build custom connectors, start from a growing library of templates, and set project-level policies on connectors and more.

Get started

Whether you're automating a business process, orchestrating AI agents, integrating enterprise systems, or building entirely new AI-powered experiences, Logic Apps Automation provides a simpler path from idea to production.

Start building today at https://auto.azure.com
Read the docs at http://auto.azure.com/docs
Watch the announcement session at Microsoft Build 2026.
See it live at the Integrate conference, June 8–9.

📢 Announcing Knowledge as a Service for Azure Logic Apps

DivSwa — Wed, 03 Jun 2026 15:32:29 GMT

Now in Public Preview

Turn your documents into a ready-to-use knowledge base without custom RAG pipelines.

Today at Microsoft Build 2026, we are announcing the Public Preview of Knowledge as a Service for Azure Logic Apps. It is a managed knowledge layer that transforms your documents into a ready-to-use knowledge base, removing the need to build custom Retrieval-Augmented Generation (RAG) pipeline, operate a vector store, or maintain retrieval logic. The result is grounded, accurate answers for the agents and workflows you are building today.

Most organizations hold a significant amount of institutional knowledge such as HR policies, product manuals, support runbooks, contracts, and specifications distributed across documents, spreadsheets, and internal systems. The challenge has rarely been the availability of content. It has been making that content reliably and accurately retrievable by AI agents and workflows.

Until now, addressing this challenge required building a RAG pipeline in-house. As any team that has implemented one can attest, a production-grade RAG pipeline involves substantial engineering effort and ongoing operational overhead.

The complexity of building RAG in-house

A production-grade RAG pipeline is not a single component. It is a set of interdependent systems that must be designed, integrated, and maintained:

Ingestion: parsing multiple file formats, chunking content appropriately, summarizing, and generating embeddings.
Storage: provisioning a vector database, defining indexing policies, and tuning for cost and performance.
Retrieval: rewriting queries, vectorizing them, executing semantic search, and returning the most relevant chunks to the model.
Operations: monitoring upload status, handling failures, managing credentials, and maintaining security.

Each component represents a meaningful engineering investment. Together, they constitute a platform — one that diverts engineering capacity away from the business problems teams set out to solve.

Introducing Knowledge as a Service

Knowledge as a Service (also referred to as Knowledge Base as a Service, or KBaaS) is a managed knowledge layer built into Azure Logic Apps that turns your documents into a ready-to-use knowledge base, without requiring you to build or operate a RAG pipeline.

You provide the documents, and the platform manages the remainder of the process, both ingestion and retrieval, end to end. Built directly into Logic Apps, KBaaS provides an abstraction over the underlying vector store and AI models, enabling your workflows to consume structured, semantically searchable knowledge through a single connection.

A knowledge base is a logical container that organizes related sources for a given domain. For example, an "HR Policies" knowledge base might hold all relevant HR documents. You create the knowledge base, upload your files, and attach it as a tool that your agent can call.

How it works

KBaaS is built around two managed pipelines.

Ingestion pipeline. When you upload a knowledge source, the service automatically parses, chunks, summarizes, and vectorizes the content, then stores the results, with no manual preprocessing required. The current preview supports a broad range of formats out of the box: DOC, DOCX, HTML, MD, PDF, PPT, PPTX, TXT, XLS, and XLSX. Each upload provides a progress status and a clear Completed or Failed result.

Retrieval pipeline. When your agent queries the knowledge base, the service rewrites the query where beneficial, generates a vector representation, executes a semantic search, and returns the most relevant chunks to the language model for response generation. Query planning, vector search, and ranking are all handled by the service.

The outcome is that your agents receive accurate, context-rich answers grounded in your own content, without requiring you to author retrieval logic.

Built for agentic workflows

KBaaS is available in Azure Logic Apps Standard, where it integrates directly with agentic workflows. Once a knowledge base has been created, it appears as a capability that can be attached to an agent loop. From there, the agent automatically queries the knowledge base to retrieve semantically relevant information from your uploaded documents at the point it is needed, as part of completing a task.

Getting started involves three steps:

Create the knowledge base connection - associate your vector store and your completions and embeddings models.
Add knowledge sources - upload files into a knowledge base, optionally organized into groups.
Add the knowledge base as a context - select it from the agent node so your agent can begin retrieving.

The platform provisions and manages the required databases, containers, and indexing policies on your behalf, removing the burden of operating the underlying storage and search infrastructure.

Two SKUs to consume it - Standard or Automation

This feature is available across Logic Apps SKUs, with some differences in how you setup and manage them.

Logic Apps Standard — bring your own resources. On Standard SKU, the model operates on your own Cosmos DB vector store and AI models, KBaaS integrates with them directly. You connect your existing resources, and the platform manages the complete ingestion and retrieval pipeline on top of them. This approach retains full control over your data and models while removing the need to build and maintain the RAG pipeline.

Logic Apps Automation SKU — bring only your documents. On the Automation SKU, KBaaS operates on a hosted-on-behalf-of model, in which the platform provisions and manages both the underlying vector store and the AI models. There is no Cosmos DB to provision, no embeddings or completions model to deploy, and no connections to configure. You upload your documents and attach the knowledge base to your agent, and the entire knowledge layer, including the supporting infrastructure is fully managed for you.

This delivers the same managed knowledge experience with the maximum degree of abstraction, providing the most direct path from source documents to a working, agent-ready knowledge base.

Secure by design

KBaaS supports authentication through Microsoft Entra ID using either a managed identity or an API key. We recommend managed identity wherever possible. It is the most secure option and eliminates the need to manually provision and rotate credentials, secrets, or access keys.

Available today in Public Preview

This initial release focuses on the most common starting point: uploading unstructured documents. Additional capabilities are planned, including support for more knowledge sources, richer ingestion (such as image parsing, semantic chunking, and multimodal embeddings), configurable retrieval settings, access checks during retrieval, and more.

Knowledge as a Service is available now in Public Preview. Provide your documents and give your agents a knowledge base that is ready to use, without building or operating a RAG pipeline.

Read the MS Learn docs to get started
Check out the demo below

Better Together: Build Agents in Microsoft Foundry, Automate them with Azure Logic Apps

DivSwa — Tue, 02 Jun 2026 19:33:15 GMT

One agentic stack: Foundry brings the intelligence; Logic Apps brings the automation and orchestration.

The promise of agentic AI is not simply more capable chat. It is autonomous work that advances real business processes. To achieve this, agents require two things: a place to be built with the appropriate models, instructions, knowledge, and guardrails and a place to be invoked and orchestrated, with triggers, workflows, and connections to the systems where work actually occurs.

Today, we are announcing a significantly improved experience that brings these two platforms together: Microsoft Foundry and Azure Logic Apps. Together, they form a single agentic stack. Foundry provides the intelligence, and Logic Apps provides the automation and orchestration.

What's new

This release introduces a set of updates that taken together, brings a really better together experience to build and automate AI

A streamlined experience to create and invoke Foundry Agents from Azure Logic Apps. You can now move from having an agent to running that agent inside a production business workflow in a few steps. You can author, configure, and call a Foundry Agent directly from the Logic Apps designer, with no custom integration code required.

Run Foundry Agents autonomously with Logic Apps triggers. This capability is what enables embedding Foundry Agents in workflows. A chat-bound agent runs only when a user types a message; an autonomous agent runs when the business requires it. With this release, you can pair any Logic Apps trigger with a Foundry Agent to build a business process, automating agents to react to events, run on a schedule, or both. These triggers can come from any of the 1,400+ connectors that expose them — such as ServiceNow incidents, GitHub issues, Jira tickets, and SAP IDocs — each capable of initiating a Foundry Agent. The result is that your agents do not wait for someone to interact with them. They activate the moment work arrives, reason about it, take action through their tools, and, where appropriate, hand off to long-running workflows.

Logic Apps connectors are now available as tools for Foundry Agents. Any of those same 1,400+ Azure Logic Apps connectors can now be exposed directly to a Foundry Agent as a native tool. An agent can reason about a customer issue and then update the CRM, file the ticket, send the approval, or post the message.

Invoke entire workflows, including long-running ones, as Foundry agent tools. Tools are not limited to a single API call. With Logic Apps, an agent can invoke an entire workflow as a tool: a multi-step approval that waits days for a human response, a webhook callback, a long-running orchestration spanning multiple systems, or a process that pauses and resumes on external events. The agent reasons, and the workflow executes durably for as long as the process requires.

Business process automation, durable workflows, and agentic AI are now available on the same stack.

Why this matters

Building automations with agents and deterministic logic has meant working across two separate worlds: one platform to build and host the agent, and another to connect it to the systems where work happens and to invoke it when needed. This release brings those two worlds together. Foundry and Logic Apps now work as one agentic stack, with each platform handling what it does best

Azure AI Foundry — Where agents are built and hosted	Azure Logic Apps — Where agents are invoked and orchestrated
Define agents with models, instructions, and tools	Trigger agents from any event, on any schedule
Ground responses in knowledge and enterprise data	Orchestrate multi-step, multi-agent business processes
Evaluate, version, and observe agent behavior	Expose 1,400+ connectors, workflows, MCPs, webhooks, and agents as native tools

Getting Started

If you already have a Foundry Agent and a Logic Apps environment, you're a few clicks away. Here are the steps to Create and/or Invoke Foundry Agents from Logic Apps Workflows

Add an Agent node to your workflow: In the Logic Apps designer, add the Agent node to your workflow.

Creation connection: If you don't already have a connection, you'll be prompted to create one. Make sure it's a Foundry Project connection: select Foundry Project from the Agent Model Source drop-down, then provide your project endpoint and API key.

Invoke an existing Foundry agent: Once the Agent node is added, pick an agent from the Agent drop-down. Logic Apps defaults to the latest version and shows the agent's configured model and instructions. You can invoke the agent as-is, or make changes from the designer, including adding Logic Apps tools to the Foundry Agent.

Or create a new agent: To create a new agent from the designer, provide an Agent Name and Model, then choose Create; the agent is created in Foundry. You can optionally add Instructions and Logic Apps tools before saving.

Configure Agent: When you choose to create a new agent, you add the Agent Name and Model and that allows you to Create that agent in Foundry. Optionally you can add Instructions and Logic Apps tools from the designer. The Agent is Created when you click on Create. You can invoke from Logic Apps or from Foundry portal as well.

Add tools: Logic Apps tools are how your agent takes action. A tool can include not just 1400 connectors, but also MCPs, workflows, custom code, Agents or APIs

Closing

Agents are only useful when they can act - and act autonomously, durably, and across the systems and timeframes that real business processes require. With Microsoft Foundry providing the agent platform, and Azure Logic Apps providing the triggers, workflows, connectors, webhooks, and agent-as-tool composition, AI capability turns into automated business processes.

What's new in Azure API Management at Microsoft Build 2026

beenamore — Tue, 02 Jun 2026 19:30:00 GMT

For more than a decade, Azure API Management has helped organizations secure, govern, and operate APIs at enterprise scale.

As organizations build more AI-powered applications, APIs are increasingly part of a broader architecture that includes AI models, agents, MCP tools, and agent-to-agent interactions. These new patterns increase the need for consistent governance, discovery, security, and observability across the full application ecosystem.

Azure API Management already provides AI gateway capabilities that help organizations govern and observe AI workloads. At Build 2026, we're continuing to expand those capabilities and introducing new updates that help organizations manage the growing ecosystem of APIs, models, agents, MCP tools, and AI-powered interactions.

General Availability: Azure API Center expands discovery and governance for APIs and AI assets

As organizations build more AI-powered applications, APIs are no longer the only reusable enterprise asset. Agents, MCP tools, prompts, skills, and AI services are rapidly becoming building blocks that developers need to discover, evaluate, and reuse.

To support this shift, Azure API Center now Azure API Center now supports agent registration, agent assessment, and Git-based synchronization | Microsoft Community Hub, helping organizations create a centralized catalog for APIs and AI assets.

Developers can register agents directly into API Center, making them discoverable alongside APIs and other enterprise assets. Agent definitions can be synchronized automatically from Git repositories, ensuring catalog entries remain aligned with source-controlled implementations and evolving codebases.

To help organizations establish trust and quality standards, API Center now also provides automated agent assessment using an LLM-as-a-Judge framework. Agents can be evaluated for safety, reliability, and behavioral completeness before being published to the enterprise catalog.

We're also announcing the general availability of the Azure API Center data plane MCP server. As organizations adopt MCP-based tooling and AI agents at scale, developers need a simpler way to discover and connect to the growing ecosystem of enterprise MCP servers, tools, APIs, agents, and AI assets. The Azure API Center data plane MCP server acts as a unified enterprise discovery endpoint, enabling agents and developer tools to access registered MCP servers, tools, APIs, agents, and AI assets through a single MCP connection. This allows organizations to provide centralized access to enterprise capabilities, simplify discovery across growing catalogs, and automatically make newly registered MCP servers and tools available without requiring individual client reconfiguration.

Together with agent registration, assessment, and Git synchronization, the Azure API Center data plane MCP server helps organizations create a centralized source of truth for APIs, agents, MCP tools, and AI assets improving discoverability, governance, and reuse across the enterprise

General Availability: Agent-to-Agent APIs and content safety controls

Agentic systems introduce new governance challenges. As agents begin coordinating work on behalf of applications and users, agent-to-agent communication is becoming an increasingly important architectural pattern. Historically, these interactions have often existed outside traditional API governance boundaries, creating operational blind spots and fragmented governance models.

Azure API Management now supports JSON-RPC-based Agent-to-Agent (A2A) APIs, enabling organizations to manage agent interactions alongside REST APIs, GraphQL APIs, MCP tools, and AI model APIs using the same API management platform they already rely on today.

We're also extending content safety capabilities to MCP tools and A2A interactions. Organizations can now centrally apply safety controls across model invocations, tool execution, and agent communication patterns through a unified governance layer.

Rather than introducing separate governance platforms for agents, Azure API Management enables organizations to extend familiar API governance principles to emerging agent ecosystems.

Public Preview: Unified Model API for multi-model AI applications

Most organizations are quickly discovering that AI is becoming a multi-model world. Applications increasingly combine models from Microsoft, OpenAI, Anthropic, Google, and other providers based on performance, cost, latency, regional requirements, or workload-specific needs. This creates complexity for developers and platform teams alike. Different providers expose different APIs. SDKs vary. Governance becomes fragmented. Switching providers often requires application changes.

To simplify multi-model architectures, we're introducing the Unified Model API in public preview.

The Unified Model API allows organizations to standardize on a single client-facing API format while Azure API Management transparently handles provider-specific transformations behind the scenes. Developers can continue using familiar APIs and SDKs while platform teams gain the flexibility to route traffic across multiple providers, implement failover strategies, and evolve model choices over time. By abstracting provider-specific differences behind a unified API layer, organizations can build more portable, resilient, and governable AI applications.

General Availability: Expanded AI Gateway support for Anthropic and Vertex AI

Azure API Management AI gateway capabilities already helps organizations govern and observe AI traffic across model providers. As multi-model architectures become increasingly common, organizations need consistent governance regardless of where those models are hosted.

API Management now extends AI Gateway capabilities to Anthropic and Google Vertex AI models. Organizations can apply runtime governance, security controls, content safety policies, semantic caching, token controls, logging, tracing, and observability across a broader range of AI providers.

This enables platform teams to apply consistent governance practices across multi-model environments without introducing separate management tools or operational processes for each provider.

General Availability: Expanded token observability for AI workloads

Understanding AI usage is becoming increasingly important as model providers introduce new token types beyond traditional prompt and completion tokens.

Azure API Management now supports token metrics for all token types, including cached, reasoning, and thinking tokens, with metrics available through Application Insights.

Organizations can collect token usage data across multiple providers and API formats, build more accurate cost dashboards, improve budget monitoring, and gain deeper visibility into evolving model behaviors. As AI workloads continue to grow, expanded token observability helps organizations better manage costs, optimize usage, and strengthen governance across AI applications.

General Availability: Enterprise platform enhancements

Alongside our AI-focused investments, we're continuing to expand the core platform capabilities organizations rely on to operate API programs at scale.

Azure API Management Premium v2 now supports multiple custom domains, allowing organizations to expose APIs, developer portals, and management endpoints under multiple branded experiences while maintaining centralized governance.

Azure API Management Premium v2 and Standard v2 now support wildcard custom hostnames, significantly reducing certificate and hostname management overhead for growing API estates.

We're also expanding workspace support to the built-in gateway. Organizations can now adopt team-based governance and delegated API management models across additional deployment options while benefiting from built-in gateway capabilities such as multi-region deployments, custom hostnames, and Private Link connectivity.

Together, these enhancements make it easier for organizations to scale up API programs while maintaining operational simplicity.

Looking ahead

APIs remain the foundation of modern applications.

But increasingly, they are no longer the only assets developers interact with. Models, agents, MCP tools, and agent-to-agent interactions are becoming important components of enterprise application architectures.

The governance challenge is no longer limited to APIs alone.

With these Build announcements, Azure API Management and Azure API Center continue to expand the governance foundation organizations rely onhelping teams discover, secure, govern, and observe APIs, models, agents, MCP tools, and AI interactions through a unified platform experience.

As organizations build the next generation of AI-powered applications, we're committed to providing the governance, security, visibility, and operational controls required to run those systems with confidence at enterprise scale.

Azure Connector Namespaces: managed integration for any Azure compute

WSilveira — Tue, 02 Jun 2026 20:33:37 GMT

The integration tax nobody budgets for

It is always a simple task on paper: connect apps to the systems the business actually runs on — SharePoint, Salesforce, SAP, Outlook — and get back to building features. What gets in the way is rarely the business logic. It's the plumbing. You write a custom API client for each service. You wire up OAuth flows and then babysit token refresh. You add retry policies, handle throttling, page through results, and stand up webhook subscriptions you now have to keep alive. None of that is the feature. All of it is on you.

Historically, if you wanted that work done for you, the answer was a workflow engine. That's great when you want a workflow — but a lot of apps just want to call an action or react to an event from code they already have, running on the compute they already use. That's the gap Azure Connector Namespace fills.

What is Azure Connector Namespace?

Azure Connector Namespace is a fully managed integration service that hosts a catalog of prebuilt, reusable connectors and MCP servers that your apps consume through a consistent programming model. Instead of writing and operating a client for each system, you create a connection once and call typed operations from your code. The namespace handles authentication, credential rotation, polling, webhook delivery, retries, throttling, and error handling on your behalf.

Worth saying clearly, because people ask: a connector namespace is independent of Azure Logic Apps. It doesn't require, use, or change anything in Logic Apps, and the Logic Apps connectors gallery keeps working separately for workflows. Connector Namespace is the integration path for compute that doesn't run on a workflow engine — your Functions, Container Apps, App Service, and self-hosted services.

Each connector exposes three kinds of surface through one shared connection model:

Triggers — event subscriptions your app registers (a new email arrives, a record updates, a file lands in a folder).
Actions — operations your app calls (send a message, read a row, upload a file).
AI agent tools — the same operations, exposed to agents and Copilot through MCP servers.

You call all of it from strongly typed SDKs for C# (Azure.Connectors.Sdk), Node.js (@azure/connectors), and Python (azure-connectors) — or over plain HTTP if a typed SDK isn't a fit.

The building blocks

Five concepts and you have the whole model:

Concept	What it is
Connector namespace	The Azure resource that hosts the connector runtime — loads and runs operations, maintains connection state and credentials, polls source systems, dispatches webhook events, and applies retry and diagnostic policies. Create it from the Azure portal, ARM/Bicep, or the CLI.
Connector	A prebuilt component for one service (SharePoint, Salesforce, SAP, Outlook). It abstracts the underlying API, auth protocol, pagination, and retry behavior so your code stays on business logic.
Connection	An authenticated, configured binding to an account or tenant. Connections are reusable — multiple apps and connectors can share one. Auth types: OAuth, API key, and Basic.
MCP server	A first-class resource that exposes tools to AI agents over the Model Context Protocol. Comes in managed and hosted flavors (more below).
Connector SDKs	Strongly typed clients for C#, Node.js, and Python that share the same catalog, connection model, telemetry, and retry semantics. Or call connectors over HTTP.

What you can actually do with it

The point of all this is the scenarios it unlocks. A few that show the range:

Scenario	What it looks like
Process documents and content	An Azure Function uses SharePoint connector operations to detect new or updated files, processes them, and writes results back to SharePoint.
Monitor events from external services	An Azure Container App uses a Salesforce trigger to receive events about new leads as they're created.
Automate productivity	A Node.js app uses Outlook operations to read and send email — reusing a connection another app already owns.
Ground AI and agentic workloads	A Python service calls connector actions to enrich model output with data from business systems.
Reuse existing app code	ASP.NET, Node.js, and Python services use managed integrations with no workflow engine in the call path.
Publish connectors to agents	Turn any connector into an MCP server in one step so Copilot and other agents can call it as a tool.

Connections: authenticate once, reuse everywhere

Connections are where the Logic Apps connector ecosystem pays off. You get the same broad catalog of first-party Azure services and popular SaaS apps — built on years of connector investment — without bringing a workflow engine along for the ride. You create a connection to a service, authenticate it once, and then any number of apps and connectors reuse it.

Creating one is deliberately simple, which is the point:

In the Connector Namespaces portal (connectors.azure.com), open your namespace and select Connections > Create connection.
Find and select the connector — say, Office 365 Outlook.
Give the connection a clear, specific name so it's easy to pick later.
Sign in to authorize, and complete any extra steps the service requires.
Confirm the connection shows as healthy on the Overview page — it's now ready for your apps to use.

Supported authentication types today are OAuth, API key, and Basic. And because the namespace stores and rotates the credentials, your app never touches a raw secret.

Triggers: deliver events to the compute you already run

A trigger is an event subscription your app registers on a connector — new email, updated record, new file. When the source system raises that event, the namespace delivers the payload to your compute. And it does the hard part for you: it manages polling schedules and webhook registration based on what the underlying service supports, so you don't stand up or maintain subscription infrastructure.

Your app can receive those events running on:

Azure Container Apps Sandboxes
Azure Functions
Direct HTTP — App Services or self-hosted ASP.NET, Node.js, or Python on AKS or VMs, through the same connector namespace.

Two details that matter in practice: a trigger is defined independently of any specific app, and multiple apps can subscribe to the same trigger event over the same connection. Actions, for contrast, run synchronously when your app calls them; trigger delivery uses webhooks or pull-based subscriptions depending on the connector and source service.

You can learn more about how to use the Connectors SDK to inject connectors on Azure Functions here.

MCP servers: turn connectors into agent tools

This is the part I'm most excited about. An MCP server in your namespace exposes tools that AI agents — Copilot, custom agents, any MCP-aware client — can discover and call, using the same connection model as everything else. That's how you put your line-of-business systems directly in front of an agent without writing tool wrappers or standing up hosting. There are two ways to get one.

Managed MCP servers

Take any connector in your namespace and publish it as an MCP server in a single step. The namespace builds and configures the server — tool definitions, lifecycle, runtime — and the only thing you do is authenticate the underlying connection. If you can create a connection, you can give an agent a tool.

Hosted MCP servers

Sometimes you want a ready-made server rather than one projected from a connector. Hosted MCP servers are pre-built images from a curated catalog that the namespace runs in dedicated compute it provisions for you. You own the configuration; the platform handles hosting, scaling, networking, lifecycle, dependencies, health monitoring, and credentials. When you deploy one, the namespace pulls the image, provisions the runtime with your config, and exposes a secure MCP endpoint agents can connect to.

The curated catalog during preview includes:

Playwright — browser automation tools for navigation, screenshots, and page interaction.
Azure SQL — SQL operations exposed as MCP tools through Data API builder, with entity abstraction, RBAC, and caching so agents work through a controlled, secure contract.

It's a deliberately curated set today, and it expands over time based on demand. You can learn more about Hosted MCP Servers here.

How agents authenticate

Hosted MCP servers have two auth boundaries:

Inbound (client to server) — OAuth with Microsoft Entra ID. Connections from GitHub Copilot in VS Code work out of the box; other MCP clients need a little extra config.
Outbound (server to downstream system) — either a managed identity assigned to the namespace, or on-behalf-of (OBO) using the calling user's identity for delegated access.

How it fits together

End to end, the flow for connectors is short:

Create a connector namespace resource in your subscription.
Create one or more connections to the services you want — say, an OAuth connection to Microsoft 365.
Your app — in Functions, Container Apps, App Service, or self-hosted compute — references the namespace and connection through a Connector SDK, then subscribes to triggers or calls actions.
The namespace handles authentication, request signing, polling, webhook subscription, and retries. Your app gets back typed responses and event payloads.

For MCP servers, it's the same shape: create the namespace, add a managed or hosted server from the catalog, authenticate the underlying connection, and agents can find the server, read its tool catalog, and invoke tools.

Where you can run it

Azure compute — App Service, Container Apps, and Functions can all consume connector operations.
Self-hosted — any self-hosted service works too: ASP.NET, Node.js, or Python on AKS or Azure VMs.
Agents, directly — Copilot extensions and MCP-aware clients call tools on MCP servers in your namespace without going through a separate compute layer; the namespace provides the compute that runs the servers.

Security and governance, by default

Credentials stay with the namespace — it stores, manages, and rotates them; your app never handles raw secrets.
Network isolation — restrict access with virtual network integration and private endpoints.
RBAC — control who can create connections, register triggers, and invoke actions.
Observability — diagnostic logs and correlation IDs flow to Azure Monitor for end-to-end tracing across the namespace and your compute.

Before you build: preview realities

I'd rather you go in clear-eyed. While Connector Namespace is in preview, keep these in mind:

Consideration	What to expect
No SLA	Not recommended for production workloads during preview.
Region availability	Limited regions today; the list expands over time.
Connector coverage	High-usage and standard connectors first; enterprise connectors like SAP, IBM MQ, and Oracle Database follow in later waves.
Identity	API key and OAuth connections now; managed identity for connections comes later (and arrives earlier for select MCP servers).
Versioning	SDK and namespace runtime versions are paired during preview — expect breaking changes between milestones.
Pricing	The pricing model isn't finalized; the metering shape may change before GA.

Try it, and tell us your feedback

If you've ever shipped an integration and then spent the next quarter maintaining its plumbing, this is for you. The preview is open: create a namespace from the Azure portal, wire up a connection at connectors.azure.com, and call your first action or publish your first MCP server. It is easy to start here:

Learn more:

What's new in Azure Logic Apps at Microsoft Build 2026

beenamore — Tue, 02 Jun 2026 19:30:00 GMT

Automation is entering a new era

Automation has traditionally been powerful, but not always accessible.

Building production-grade automations often requires specialized expertise in workflows, integrations, APIs, infrastructure, identity, security, networking, and operations. Organizations could build sophisticated solutions, but doing so typically requires dedicated development or integration teams

AI is changing that equation.

Across every organization, more people want to automate work. Developers want to build AI-powered applications faster. Startup teams want to move from idea to production without assembling complex infrastructure. Operations, security, and business teams want to leverage AI to automate repetitive processes and accelerate decision making.

Expectations have changed as well. Builders increasingly expect natural language experiences, AI assistance, integrated knowledge, and faster paths from idea to execution.

At the same time, organizations still need the governance, security, reliability, compliance, and operational controls required to run automation in production.

This creates a new opportunity: making enterprise-grade automation accessible to far more builders without sacrificing the foundations required to operate at scale.

At Build 2026, we're introducing Azure Logic Apps Automation along with several new Azure Logic Apps capabilities that help organizations build, connect, and operationalize AI-powered automation on Azure.

Public Preview: Azure Logic Apps Automation

Azure Logic Apps Automation is a new Logic Apps SKU designed to make enterprise-grade automation dramatically easier to build. Built on the same Azure platform organizations trust today, Logic Apps Automation provides a managed environment where workflows, AI agents, enterprise connectivity, knowledge services, and model access are available out of the box. A built-in AI assistant helps users move from intent to implementation using natural language. Developers can generate workflows, configure actions, create expressions, and build automations faster while maintaining full control over the final implementation. Logic Apps Automation also brings AI agents directly into the automation experience. Developers can build and use Microsoft Foundry agents alongside traditional workflow actions, enabling business processes that combine deterministic execution with AI-driven reasoning.

Whether you're a startup building AI-native applications, an enterprise modernizing internal processes, or a developer looking to accelerate automation projects, Logic Apps Automation provides a simpler path from idea to production.

General Availability: Azure Logic Apps MCP Server

As AI agents become increasingly important participants in enterprise applications, organizations need a straightforward way to connect those agents to existing business processes.

The Azure Logic Apps MCP Server is now generally available and enables developers to expose existing Logic Apps workflows as MCP-compatible tools that agents can discover and invoke directly.

This allows organizations to reuse years of existing automation investments without building custom APIs or integration layers. Workflows that already connect enterprise systems, business applications, and operational processes can now become AI-callable capabilities in minutes.

Public Preview: Invoke Microsoft Foundry Agents directly from Logic Apps

Organizations increasingly build agents in Microsoft Foundry. With new Foundry integration capabilities, developers can now invoke Foundry agents directly from Logic Apps workflows. This enables business processes that combine enterprise systems, APIs, human approvals, schedules, events, and AI-driven reasoning within a single automation experience. Workflows can trigger agents, agents can provide analysis or recommendations, and Logic Apps coordinates the broader business process around those outcomes.

Public Preview: Knowledge as a Service

One of the biggest challenges organizations face when building AI-powered applications is making enterprise knowledge accessible. Retrieval-augmented generation often requires ingestion pipelines, chunking strategies, embedding models, vector databases, and retrieval infrastructure before developers can begin building the experiences they actually care about.

Knowledge as a Service simplifies this process. Developers can upload documents directly into Logic Apps workflows, automatically ingest and process content, generate embeddings, and use retrieval as a built-in workflow capability. Instead of building and operating knowledge infrastructure, teams can focus on creating grounded AI experiences and intelligent automations that leverage organizational knowledge.

Public Preview: Codeful Workflows with the Logic Apps Standard SDK

Different developers prefer different ways of building software. Some teams prefer visual workflow design. Others want the flexibility and familiarity of code-first development.

Codeful Workflows introduces a new code-first development experience for Azure Logic Apps Standard. Built on the Logic Apps Standard SDK, Codeful Workflows enable developers to create workflows directly in code using familiar .NET development patterns while continuing to benefit from Logic Apps connectors, orchestration capabilities, and operational infrastructure. Developers can build, test, debug, and run workflows locally while leveraging existing development tools, source control practices, and AI-assisted coding experiences. This gives teams more flexibility in how they build automation while preserving the benefits of the Logic Apps platform.

Public Preview: Migration Agent for Azure Logic Apps

Modernization remains a top priority for many organizations as they evaluate legacy integration platforms and prepare for the next generation of cloud-native architectures.

The new Migration Agent for Azure Logic Apps helps simplify that journey.

Designed to assist organizations migrating from BizTalk Server and other third-party integration solutions, the Migration Agent provides intelligent assessments, migration guidance, compatibility analysis, and automated recommendations. By reducing the manual effort traditionally associated with migration projects, organizations can accelerate modernization initiatives while lowering risk and improving confidence throughout the migration process.

Looking ahead

The future of automation is not simply about adding AI to existing workflows.

It's about making powerful automation accessible to more builders while preserving the governance, reliability, security, and operational controls organizations require.

Azure Logic Apps has long provided the foundation for enterprise integration and business process automation. With Logic Apps Automation, Foundry agent integration, MCP support, Knowledge as a Service, Codeful Workflows, and AI-powered migration capabilities, we're continuing to expand what's possible while making it easier for organizations to move from idea to production.

We're excited to see what developers, startups, enterprises, and builders of every kind create next.

Hosted MCP Servers in Connector Namespace (Preview)

lily-ma — Thu, 04 Jun 2026 21:19:18 GMT

Imagine you've built an agent and you want to give it access to tools via MCP servers. Local servers won't work because your agent can't connect to them in production. Wouldn't it be great if you could quickly stand up secure, enterprise-ready remote MCP servers that your agent can use?

This is what Connector Namespace enables. Among other capabilities, the namespace provides a feature called hosted MCP servers that lets you deploy remote MCP servers in minutes. Pick a server from the catalog, deploy it and your agents can discover and call its tools immediately, with infrastructure, deployment, scaling, observability, authentication, and more handled by the platform.

Why hosted MCP?

Self-hosting MCP servers comes with real operational cost: infrastructure, authentication, monitoring, scaling, availability, and debugging are all on you. For servers that expose standard capabilities like database access or browser automation, that's undifferentiated work that slows you down.

Hosted MCP servers shift that burden to the platform, offering a fully managed experience so you can just pick a server and let the platform handle everything else:

	Hosted MCP server	Self-hosted MCP server
Setup	Deploy from catalog in minutes	Build/find server, deploy to your own infra, wire up networking
Scaling	Platform-managed, scales automatically	You configure and manage scaling (VMs, containers, load balancers)
Auth	Inbound and outbound auth handled by the platform	You configure OAuth, managed identity, or OBO end-to-end
Observability	One-click App Insights integration	You set up logging, metrics, and alerting yourself
Cold starts	Platform manages server lifecycle	You manage warm-up, health checks, and process restarts
Availability	Platform-managed uptime, health monitoring, and automatic recovery	You own high availability, e.g. failover and redundancy

How it works

When you deploy a hosted MCP server, the namespace:

Pulls the pre-built server image from the catalog.
Provisions the runtime environment with your configuration.
Exposes a secure MCP endpoint that agents and MCP clients can connect to.
Handles scaling, health monitoring, and authentication.

Public preview feature highlight

Supported servers

During public preview, a curated set of hosted MCP servers is available. The catalog expands over time based on demand.

Server	What it does
Playwright	Browser automation tools for web navigation, screenshots, and interaction
Azure SQL	Exposes SQL operations as MCP tools through Data API builder, enabling AI agents to interact with SQL databases through a controlled, secure contract with entity abstraction, RBAC, and caching.

If there's a server you'd like to see in the catalog, file an issue at aka.ms/hosted-mcp-github. Support for publishing custom-built MCP servers to the catalog is planned for the future.

Authentication

Hosted MCP servers involve two authentication boundaries:

Inbound (client → server): OAuth-based authentication with Microsoft Entra ID. Connections from GitHub Copilot in VS Code work out of the box.
Outbound (server → downstream service) The server authenticates to the downstream service using either managed identity or on-behalf-of (OBO) flow. You choose the approach during deployment, and the platform handles the rest, including credential management and token exchange.

Observability

Hosted MCP servers integrate with Azure Application Insights], so you can monitor server health without setting up your own logging infrastructure. After deployment, you can enable monitoring by providing your Application Insights connection string. Once configured, logs and metrics from the server flow directly into your Application Insights resource, where you can search, filter, and analyze them.

Get started

Quickstart: Create a hosted MCP server in Connector Namespace
Hosted MCP overview: Hosted MCP servers in Connector Namespace
Connector Namespace overview: What is Connector Namespace?

Try it out and let us know what you think! File feedback and feature requests at aka.ms/hosted-mcp-github.

What's next

Hosted MCP servers are in public preview and the team is actively working to improve the experience. We're looking for your feedback to help shape what comes next. Some areas we're prioritizing:

Expanding the server catalog: adding more servers based on demand and community requests
Region availability: expanding regional coverage beyond the current preview regions
VNet support: deploying Hosted MCP servers inside virtual networks with private endpoints
Custom server images: support for bringing your own MCP server images to the catalog
Tool-level access control: fine-grained permissions and throttling at the individual tool level

MCP Test Console and Git Repository synch in Azure API Center

Sreekanth_Thirthala — Tue, 02 Jun 2026 19:14:03 GMT

Why This Matters

As organizations race to build AI-powered applications, the Model Context Protocol (MCP) has emerged as the standard way to connect AI agents with external tools and data sources. Managing these MCP servers at enterprise scale, however, has been a growing challenge — until now.

AI agents are only as useful as the tools they can access. MCP servers expose those tools — from databases and internal APIs to third-party services — in a standardized way that any AI agent or model can consume. As your MCP ecosystem grows, so does the challenge of keeping track of what's available, what's working, and what your teams are actually using.

Azure API Center already serves as a centralized registry for APIs across your organization. Now it extends that same governance model to MCP servers, complete with developer-friendly discovery, live testing, and automated synchronization from your source repositories.

New Feature: MCP Test Console in the API Center Portal

Developers can now test MCP server tools interactively without leaving the Azure portal.

Once an MCP server is registered in your API Center inventory, the API Center portal — your organization's customizable developer portal — surfaces a dedicated test console on the server's Documentation tab. Developers simply select a tool, click Run tool, and immediately see the response.

This means your teams can:

Validate tools before connecting them to agents — no more building a test harness from scratch.
Explore tool schemas interactively — the portal surfaces endpoint details and input/output schemas alongside the live console.
Onboard faster — developers browsing your internal MCP registry can go from discovery to verified integration in minutes.

The MCP server tiles in the portal provide a clear, browsable view of all registered servers. Each tile surfaces the server's endpoint URL, available tools, and installation instructions for Visual Studio Code — giving developers everything they need to get started in one place.

Getting started: Set up your API Center portal, then navigate to any registered MCP server. On the Documentation tab, select a tool and click Run tool to open the test console.

New Feature: Synch MCP Servers from a Git Repository

Managing API assets shouldn't require manual registration every time something changes. With Git repository integration, Azure API Center can automatically sync assets — including MCP server definitions — directly from your source repository.

How It Works

When you connect a Git repository to your API Center:

An environment is created in your API Center representing the repository as an asset source.
API Center regularly synchronizes MCP servers from the repository into your inventory — no manual intervention required.
Assets appear in your inventory on the Inventory > Assets page with a visual link indicator, making it easy to identify which assets are source-controlled.

This is especially valuable for teams that maintain MCP server definitions, skill files, or OpenAPI specs in version control. As your repository evolves, your API Center inventory stays current automatically.

Setting It Up

Step 1: Secure your access credentials (for private repos)

If your repository is private, store a personal access token (PAT) as a secret in Azure Key Vault. Your API Center instance uses a managed identity to retrieve this secret securely — you can configure the managed identity manually or let API Center handle it automatically during the integration setup.

Step 2: Connect the repository

In the Azure portal, go to your API Center and navigate to Platforms > Integrations > + New integration > From Git repository. You'll configure:

Repository URL — including an optional branch and subfolder path (e.g., https://github.com/<org>/<repo>/tree/main/skills).
Git provider — such as GitHub.
Asset type configuration — API Center defaults to a skill asset type with the file pattern **/skill.md, but you can add additional asset types to match your repository structure.
PAT reference — select the Key Vault secret containing your PAT, if applicable.
Environment details — give the repository environment a friendly name, resource ID, type (e.g., Production), and lifecycle stage for synced assets.

Step 3: Let the sync run

Once created, the integration runs automatically. Your assets will appear in the Inventory > Assets view, linked to their source in the repository.

Access Control for Private Repositories

The integration uses Azure's managed identity framework to authenticate to Key Vault. Assign your API Center's managed identity the Key Vault Secrets User role on your Key Vault to grant the necessary read access. If you prefer, API Center can configure this automatically — just enable the Automatically configure managed identity and assign permissions option during integration setup.

Bringing It Together: A Complete MCP Governance Story

Together, these two features complete an end-to-end workflow for enterprise MCP governance:

Register → Connect your Git repository and let API Center automatically synch your MCP servers and skills as they evolve.

Discover → Developers and AI engineers browse the API Center portal to find the right MCP server for their agent, with full schema visibility and endpoint details.

Test → The built-in test console lets developers validate tools interactively before committing to an integration.

Govern → Use API Center's access management capabilities to control who can view and consume specific MCP servers across your organization.

And if you're building MCP servers on Azure services, the registry integrates directly with Azure API Management, Azure Logic Apps, and Azure Functions — so your MCP ecosystem and your API ecosystem share a single source of truth.

Get Started

Register and discover MCP servers in Azure API Center
Synchronize API assets from a Git repository
Set up the API Center portal
Explore MCP Center — Azure API Center's public MCP registry

More Control, Less Overhead: Custom Domain Upgrades in Azure API Management v2

Sreekanth_Thirthala — Tue, 02 Jun 2026 19:13:25 GMT

Multiple custom domains in Premium v2

Large organizations rarely expose APIs under a single domain. A global enterprise might need api.contoso.com for external partners, apis.hrportal.contoso.com for internal teams, and dev.europe.contoso.com for a regional developer portal — all at once.

Until now, achieving this required spinning up separate API Management instances, adding cost and operational complexity. Azure API Management Premium v2 now supports multiple custom domains within a single instance — across gateway, developer portal, and management endpoints.

This allows organizations to:

Configure distinct hostnames for different endpoints and target audiences
Align API experiences with business units, products, or regional brands
Simplify domain-scoped networking and security policies
Reduce the need for separate APIM instances created solely for domain separation

For enterprises managing large, distributed API estates, this provides greater flexibility in how APIs and developer experiences are exposed — while maintaining centralized governance.

Wildcard custom hostnames in Premium v2 and Standard v2

As API estates grow, managing individual certificates for every subdomain becomes a scaling problem fast. Each new surface — payments.api.contoso.com, inventory.api.contoso.com, orders.api.contoso.com — previously required its own hostname registration and certificate. Ten new API surfaces meant ten separate management tasks.

Azure API Management Premium v2 and Standard v2 now support wildcard entries in custom hostnames. A single *.api.contoso.com entry paired with a single wildcard certificate covers all subdomains automatically — no per-subdomain configuration required.

This helps teams:

Simplify certificate and domain management at scale
Accelerate onboarding of new API surfaces without repeated hostname setup
Maintain consistent branded endpoints across dynamic subdomains
Reduce operational overhead for rapidly growing API environments

By extending this capability to both Premium v2 and Standard v2, Azure API Management makes flexible, scalable domain management accessible to more organizations without requiring higher-tier deployments.

Both updates are generally available now. Learn more about Azure API Management v2 tiers and how they help organizations build scalable, enterprise-grade API platforms.

Further reading:

Configure a custom domain name for Azure API Management

Azure API Center Introduces a Data Plane MCP Server for Enterprise-Wide API and AI Asset Discovery

Sreekanth_Thirthala — Tue, 02 Jun 2026 19:11:59 GMT

As organizations scale their adoption of MCP-based tooling and AI agents, one challenge keeps surfacing: developers spend too much time figuring out what APIs, tools, and AI assets exist — and then manually wiring up connections to each one. Today, we're excited to announce general availability of a new capability that changes that.

What's new

Azure API Center now provides a data plane MCP server — a unified enterprise discovery endpoint that gives agents and developer tools a single connection point to your organization's full catalog of registered MCP servers, tools, APIs, and AI assets.

Instead of hunting across systems or hand-configuring integrations one by one, developers and agents can now connect once and immediately access everything that's been registered in your API Center.

Why this matters

The MCP ecosystem is growing fast. So is the number of enterprise APIs and AI assets that teams need to manage and consume. Without a central discovery mechanism, that growth creates friction — more manual configuration, more drift between what's available and what's actually reachable, and more integration complexity for every new agentic application.

The Azure API Center data plane MCP server addresses this directly. With it, teams can:

Give agents centralized access to enterprise APIs and AI assets without custom routing logic
Eliminate manual configuration of connections to individual MCP servers
Automatically surface newly registered MCP servers and tools without reconfiguration
Simplify discovery and consumption across a rapidly growing enterprise catalog

Built for how organizations actually operate

Agentic applications don't just need APIs — they need to find the right APIs, trust that the catalog is current, and connect reliably at scale. By acting as a unified discovery endpoint, Azure API Center helps teams operationalize AI ecosystems with stronger discoverability, governance, and developer productivity, while meaningfully reducing integration complexity.

This is especially valuable as enterprises move from experimenting with AI agents to deploying them in production workflows, where manual integration approaches don't scale.

How to enable the data plane MCP server

Turning on the MCP server takes just a few clicks in the Azure portal. Navigate to your API Center instance and open Data API settings under the Consumption section in the left-hand menu.

From there, under MCP endpoint, toggle Enable API Center MCP endpoint to on. Once enabled, your MCP endpoint URL (in the form https://<your-instance>.data.<region>.azure-apicenter.ms/mcp) will appear and can be copied directly for use in agent configurations or developer tools.

Note: When enabled, the MCP endpoint is also surfaced on the developer portal homepage, so developers can connect via CLI without needing to look up the URL separately.

You can also enable the Plugin marketplace endpoint from the same settings page to let developers browse and install approved plugins and skills from your organization's marketplace.

The Visibility section lets you control which APIs are exposed through the data plane — use Add condition to filter the catalog based on your governance requirements.

Get started

Learn more about Azure API Center and how organizations are building unified catalogs for APIs, MCP tools, agents, and AI assets.

Find what you need, faster: Azure API Center now supports custom metadata filtering

Sreekanth_Thirthala — Tue, 02 Jun 2026 19:07:02 GMT

Enterprise API and AI catalogs have expanded dramatically. Where teams once managed dozens of APIs, they now govern hundreds — spanning business units, environments, compliance domains, and an ever-growing roster of AI assets. The catalog itself has become a discovery challenge.

What's new

Developers can now filter catalog assets using organization-defined metadata attributes. These aren't generic tags — they're the classifications your organization already uses: environments, business units, domains, compliance tiers, ownership groups, and more.

Custom metadata filtering works across all major asset types in Azure API Center:

APIs
Skills
Agents
MCP tools

Why it matters

Discovery friction is a hidden tax on developer productivity. When a developer needs to find the right API for a project, every minute spent navigating inconsistent lists or applying manual filters is a minute not spent building. At scale, this compounds quickly.

Custom metadata filtering addresses this directly by aligning the catalog's search experience with how your organization already thinks about its assets:

Surface the right assets faster — filter by internal classifications and governance models instead of browsing overwhelming lists
Improve discoverability at scale — no need to retag or reorganize existing assets to make them findable
Align with your organizational taxonomy — filter by domain, environment, business unit, compliance requirement, or any custom attribute your teams already use

Built for governed, AI-ready teams

This update reinforces Azure API Center's role as the foundation for scalable, AI-ready discovery experiences — where governance and developer velocity move together, not against each other.

By making enterprise catalogs easier to navigate, Azure API Center helps developers spend less time searching and more time building with governed APIs and AI assets.

Get started

Learn more about Azure API Center custom metadata filtering and how organizations are building scalable, AI-ready discovery experiences.

Built-in gateway support for workspaces in Azure API Management

budzynski — Tue, 02 Jun 2026 19:06:16 GMT

Workspaces in Azure API Management let platform teams hand off API ownership to individual API teams while keeping centralized governance. Until now, using them meant deploying a dedicated workspace gateway on the Premium tier — adding cost, operational overhead, and limiting regional availability.

That requirement is going away. Workspaces can now be associated directly with the built-in gateway, and this capability is generally available.

What changes

Available in more tiers. Use workspaces on the built-in gateway in any API Management tier except Consumption.
Available in every region. Create workspaces in any region where API Management is supported.
All built-in gateway capabilities apply. Workspaces deployed with the built-in gateway inherit features that dedicated workspace gateways don't offer today, including multi-region deployments, custom hostnames, and Private Link connectivity.

Availability

Rolling out now to v2 tiers, with Azure portal UI support expected around July. Rollout to classic tiers (Developer, Basic, Standard, Premium) will begin by August and may take up to a few months to complete.

Get started

Learn more about workspaces and how to deploy them on the built-in gateway.

GA: Azure API Center Now Supports Plugin Registration

Sreekanth_Thirthala — Tue, 02 Jun 2026 19:04:00 GMT

As organizations scale their AI and integration ecosystems, one challenge keeps surfacing: developers don't have a reliable, governed way to discover and reuse the plugins their teams have already built. Plugins end up siloed in individual repos, shared over Slack, or duplicated across teams — slowing down development and creating governance blind spots.

What's new

With this update, developers can register plugins directly into Azure API Center's enterprise catalog. Once registered, plugins are discoverable, governable, and consumable alongside the rest of an organization's API and AI portfolio — no more hunting across repositories or relying on word-of-mouth to find what's already been built.

Why it matters

Plugins are increasingly central to how AI-powered applications are built. Agents depend on them. Integrations are built on top of them. But without a governed home, even well-built plugins go undiscovered and get rebuilt from scratch.

Plugin registration in Azure API Center helps organizations:

Centralize plugin discovery within a governed catalog, so developers always know where to look
Surface vetted plugins that teams can confidently find and reuse — reducing duplication and accelerating development
Align plugins with source-controlled workflows, keeping development practices consistent across the catalog
Reduce friction between building a plugin and enabling it for real-world integration

One catalog for your entire AI ecosystem

This update reflects a broader vision for Azure API Center: a single, unified catalog for everything an organization builds and consumes — APIs, plugins, agents, and AI assets. By bringing plugins into this experience, teams can operationalize reusable integration and AI capabilities at scale, with the governance and discoverability that enterprise development requires.

Whether your teams are building copilot extensions, orchestration layers, or custom integrations, Azure API Center gives them a governed foundation to build on — and a shared place to discover what's already there.

Learn more about Azure API Center and how organizations are building centralized catalogs for APIs, plugins, agents, and AI assets.

Azure API Center now supports agent registration, agent assessment, and Git-based synchronization

Sreekanth_Thirthala — Tue, 02 Jun 2026 19:03:09 GMT

What's new

Three capabilities are now generally available:

Capability	What it does
Agent registration	Register agents directly into the enterprise catalog for cross-team discovery and reuse.
Agent assessment	LLM-as-a-Judge framework scores agents across 6 criteria before catalog registration.
Git synchronization	Connect a repo and keep agent definitions automatically in sync with source control.

Agent assessment — six weighted criteria, automatically enforced

When assessment is enabled, every agent is scored on creation or update. Up to 8 criteria are supported; weights are fully configurable by platform teams.

Criterion	Weight	What it evaluates
capability-transparency	0.15	Documents tools, delegated capabilities, external systems, access levels, and capability boundaries.
composition-resource-discipline	0.15	Named skill/sub-agent references, invoke guidance, no inline duplication, resource/token constraints.
operational-protocol-quality	0.25	Structured workflow with named steps, decision points, failure modes, recovery paths, and pre-flight checks.
output-contract	0.10	Specifies output format, mandatory sections, evidence requirements, confidence semantics, and dead-end handling.
purpose-scope-clarity	0.15	Clear role identity, type (specialist/orchestrator), activation triggers, anti-triggers, and refusal behavior.
safety-consent-architecture	0.20	Classifies risk, distinguishes idempotent vs approval-required actions, enumerates NEVER/ALWAYS rules, documents failure-mode safety.

Git-based synchronization — connect once, stay in sync automatically

Integrating a Git repository creates an environment in API Center representing the repo as an asset source. API Center polls for changes and reflects them in Inventory > Assets — linked assets display a provenance icon.

Agent definitions live in source control and evolve continuously — yet keeping a catalog manually in sync with a codebase is slow, error-prone work that no platform team should have to do. Git-based synchronization connects Azure API Center directly to your repository, polling for changes and reflecting them in the inventory automatically so the catalog always represents the current state of your agents. Linked assets carry a provenance icon that traces them back to their source repository, giving developers immediate visibility into where an agent comes from and whether it is actively maintained. Because assessment gates run before any version is promoted from the repo into the catalog, only agents that meet your organization's quality criteria ever reach developers — enforcing governance at the point of commit, not as an afterthought. A single integration supports multiple asset types through configurable file patterns, so teams can sync agents, skills, and APIs from one repository with per-type control and no duplication.

A2A agent sync from Azure API Management — publish once, discover everywhere

Azure API Management → continuous sync → Azure API Center One-way · updates within minutes · includes API definitions, environments & deployments

As teams publish more A2A agents through Azure API Management, manually registering each one into a discovery catalog creates friction that slows developer productivity and risks catalog staleness. Azure API Center now automatically synchronizes A2A agents — alongside APIs and MCP servers — published in an API Management instance, so every agent that reaches runtime is immediately visible in the centralized catalog without any additional registration step. The sync is continuous and one-way: when agents are created, updated, versioned, or deleted in API Management, those changes propagate to API Center within minutes, keeping the inventory accurate at all times. Each synchronized agent gets an associated environment and deployment record, giving developers the runtime context they need to discover and integrate the right agent with confidence. This closes the loop between runtime publishing and centralized governance, helping organizations operationalize agent ecosystems at scale without burdening platform teams with manual catalog maintenance.

Why it matters

By bringing agents into Azure API Center alongside APIs, plugins, skills, and MCP tools, organizations gain a single pane of glass for everything their AI applications depend on. Teams reduce duplication, improve reuse, and accelerate development — while maintaining the governance standards enterprise deployments require.

Get started

Clean up idle and always-failing Azure Logic App Consumption

Yanbo_Deng — Thu, 21 May 2026 05:11:18 GMT

If you’ve inherited an Azure subscription that’s been collecting Logic Apps Consumption workflows for a couple of years, you already know the shape of the problem: dozens of TestLA, webhook-test-2, poc-for-jira-FINAL workflows in the portal, half of them still Enabled, half of them quietly failing every five minutes against a connection that was rotated last quarter. They’re cheap, but they’re not free — polling triggers keep firing, alert rules keep paging, abandoned Microsoft.Web/connections keep pinning permissions, and the portal’s workflow list keeps getting harder to read.

Source + full docs: GitHub - dengyanbo/LA-CleanUp

What it gives you

Two color-coded tables — Idle (no runs in the last -IdleDays days; never-run workflows land here too) and AlwaysFailing (ran in the window, but not a single Succeeded).
An optional, timestamped CSV (LogicAppCleanup-Candidates-<yyyyMMdd-HHmmss>.csv) with a stable column set, easy to drop in a Teams channel or PR for owner review before you delete anything.
A per-item y/N/q deletion loop — y deletes, N/Enter skips, q quits the loop without touching anything else.
A final summary with scanned / idle / always-failing / deleted / skipped / failed counts.
Server-side OData $filter on run history so the scan is fast even on a subscription with thousands of workflow runs in the window.
Lazy State lookup (Enabled/Disabled) — only fetched for actual candidates, not for every healthy workflow.

What it is not: it does not touch Logic Apps Standard (Microsoft.Web/sites with kind=workflowapp) — those store run history in storage tables and need a completely different tool (see LogicAppAdvancedTool). It also does not GC Microsoft.Web/connections, and it does not iterate subscriptions — one invocation, one subscription, deliberately.

Quick start

Prerequisites

PowerShell 5.1+ (Windows PowerShell or PowerShell 7 — both fine).
Azure CLI on PATH: https://aka.ms/azcli
An interactive az login against the subscription that owns the Logic Apps. Logic App Contributor on the relevant RGs (or plain Contributor) is enough — you need list + delete on Microsoft.Logic/workflows, plus the ARM token your az login already grants.

Get the script

git clone https://github.com/dengyanbo/LA-CleanUp.git
cd LA-CleanUp

One-liner — defaults (90-day idle, 90-day failure window, current sub)

.\Invoke-LogicAppCleanup.ps1

A typical run looks like this:

[INFO] Active subscription: Contoso-Integration (1111-2222-...) [INFO] Signed in as : alice@contoso.com [INFO] Idle cutoff : runs older than 2026-02-20T03:08:00Z (>90 days) [INFO] Failure window : checking runs since 2026-02-20T03:08:00Z (last 90 days) [INFO] Listing Logic App (Consumption) workflows... [ OK ] Found 13 workflow(s). [ 1/13] order-processor (rg-integration) [ 2/13] webhook-test (MyTest) ... [ OK ] Scan complete. Idle: 9, AlwaysFailing: 1, Errors: 0 === Idle Logic Apps (no runs in last 90 days) === Name ResourceGroup Location State LastStatus LastRunTime ---- ------------- -------- ----- ---------- ----------- webhook-test MyTest australiaeast Enabled Never poc-for-jira rg-integration eastus Enabled Succeeded 2025-09-04T... ... === Always-Failing Logic Apps (no successful run in last 90 days) === Name ResourceGroup Location State LastStatus LastRunTime ---- ------------- -------- ----- ---------- ----------- nightly-export rg-integration eastus Enabled Failed 2026-05-20T... Export the 10 candidate(s) to CSV? (y/N): y [ OK ] CSV written: ...\LogicAppCleanup-Candidates-20260521-110800.csv Starting per-item deletion review. Answer y to delete, N (or Enter) to skip, q to quit. (1/10) Delete [Idle] webhook-test in MyTest ? (y/N/q): y [INFO] Deleting webhook-test ... [ OK ] Deleted: webhook-test (2/10) Delete [Idle] poc-for-jira in rg-integration ? (y/N/q): N Skipped. ... === Summary === Scanned : 13 Idle : 9 Always-failing : 1 Scan errors : 0 Deleted : 4 Skipped : 6 Delete failures : 0

That’s the whole workflow.

The commands you’ll actually use

1. Scope to one resource group with a tighter idle threshold

.\Invoke-LogicAppCleanup.ps1 -IdleDays 60 -ResourceGroup rg-integration

2. Only review always-failing apps (skip the idle pile)

.\Invoke-LogicAppCleanup.ps1 -SkipIdle

3. Only review idle apps (skip always-failing)

.\Invoke-LogicAppCleanup.ps1 -SkipAlwaysFailing

4. Incident-driven cleanup — tight window, focused RG

.\Invoke-LogicAppCleanup.ps1 -IdleDays 30 -FailureWindowDays 7 ` -ResourceGroup rg-integration-prod

This answers: “Within prod-integration, which workflows haven’t run in a month, and which have been failing all week?”

5. Dry-run (there is no `-WhatIf`)

The per-item y/N/q prompt is the safety model. To dry-run, just answer N to every prompt — or q at the first one. The CSV is still written before the deletion loop starts, so you walk away with the report and zero deletions.

Parameters — cheat sheet

Parameter	Default	Meaning
`-IdleDays`	`90`	No runs in this many days ⇒ flagged Idle. Never-run workflows land here too.
`-FailureWindowDays`	`90`	Ran in this window but no `Succeeded` ⇒ flagged AlwaysFailing.
`-ResourceGroup`	(none)	Restrict the scan to a single RG.
`-SkipIdle`	switch	Skip the Idle bucket entirely.
`-SkipAlwaysFailing`	switch	Skip the AlwaysFailing bucket entirely.

Why `Invoke-RestMethod` instead of `az rest`

This is the gotcha I want every other Logic Apps scripter to know about, because it eats hours.

The Logic Apps Management REST API is queried with OData — $top, $filter, the usual:

GET /subscriptions/.../workflows/{wf}/runs ?api-version=2016-06-01 &$top=1 &$filter=startTime ge 2026-02-20T03:08:00Z and status eq 'Succeeded'

On Windows PowerShell, az is a .cmd shim. The URL you pass to az rest --uri "..." is re-parsed by cmd.exe, and the & characters separating OData query parameters get interpreted as command separators. Symptoms range from '$filter' is not recognized as an internal or external command to silent wrong-page returns where the filter is just dropped and you get the most recent N runs instead. Quoting heroics — single quotes, double quotes, triple-escaped ^& — don’t fully solve it across PS 5.1 and PS 7.

The fix is to skip az rest entirely. The script grabs an ARM token once with az account get-access-token, caches it on a script-scoped variable, refreshes it proactively at the 45-minute mark (ARM tokens last ~60), and calls Invoke-RestMethod directly:

$tok = az account get-access-token --resource 'https://management.azure.com/' -o json | ConvertFrom-Json Invoke-RestMethod -Method Get -Uri $url ` -Headers @{ Authorization = "Bearer $($tok.accessToken)" }

That bypasses cmd.exe entirely. Bonus: caching the token makes the script noticeably faster on subscriptions with many candidates, since we’re no longer shelling out to az for every REST call.

Why `$top=1` matters more than you’d think

The script never pages run history. For each surviving workflow it asks two existence questions:

?api-version=2016-06-01&$top=1&$filter=startTime ge <cutoff> ?api-version=2016-06-01&$top=1&$filter=startTime ge <cutoff> and status eq 'Succeeded'

If the first one returns zero rows ⇒ the workflow is Idle. Otherwise, if the second one returns zero rows ⇒ AlwaysFailing. Both queries are O(1) server-side because startTime is indexed and the response is capped at one row. Even on a chatty workflow with tens of thousands of runs in the window, the answer comes back in tens of milliseconds.

This is also why the script can afford to be sequential per workflow — there’s no need for parallelism when each existence check is essentially free.

Why “AlwaysFailing” is defined the way it is

The bucket is “ran in the window, but not a single Succeeded run in the window” — not “all runs are Failed”. That distinction matters:

Workflows whose runs are Running, Waiting, or Cancelled but never Succeeded get classified as AlwaysFailing. That’s usually what you want — a workflow that has been “Waiting” for 30 days is just as broken as one that’s been failing for 30 days.
Long-running workflows that legitimately haven’t completed yet look the same to the classifier. If you operate that kind of workflow, widen -FailureWindowDays so a slow but eventually-Succeeded run shows up in the window.

The reported LastStatus column in the table is the status of the most recent run, so you can usually eyeball the difference between “failing” and “still running.”

A field-tested rollout

If you’re running this on a subscription you don’t fully own, this multi-pass rollout has worked well:

Run with -SkipAlwaysFailing first. Idle workflows are the safe pile — if they haven’t done anything in 90+ days, deleting them rarely surprises anyone.
Export the CSV. Don’t delete yet — answer q at the first delete prompt.
Drop the CSV in a Teams channel or PR. Give owners a few days to object.
Re-run and actually delete the ones nobody claimed.
Then run with -SkipIdle for the AlwaysFailing bucket. These often have an owner who just hasn’t noticed the breakage — treat the first pass as a bug-bash list, not a delete list.

Things to know before you run it

Consumption only. Logic Apps Standard is out of scope — different model, different APIs, run history in storage tables. Use LogicAppAdvancedTool for those.
No -Force, no -WhatIf. The per-item y/N/q prompt is the entire safety model. That’s deliberate — cleanup tools that take a -Force get used with -Force.
One subscription per invocation. The script operates on whatever az account show returns. Use az account set --subscription <id> to switch deliberately.
Microsoft.Web/connections are not deleted. API connections are typically shared; the script intentionally leaves them alone. GC them with a separate pass.
Run history disappears with the workflow. Once you delete the Logic App, Azure removes its run history too. Export the CSV first if you want any record.
Enabled vs. Disabled is reported, not enforced. A Disabled workflow can still be Idle. The script shows the state in the table so you can decide.

Where to go next

The GitHub repo has the full reference — parameter table, CSV schema, the “how it works” deep dive on lazy State fetch, bearer-token caching, server-side $filter, considerations and limitations, and the recommended rollout:

👉 https://github.com/dengyanbo/LA-CleanUp

Issues and PRs welcome. A few directions on the roadmap: an optional disable-instead-of-delete mode for the first pass (PATCH ...?api-version=2019-05-01 with properties.state = 'Disabled'), a cross-subscription mode that iterates az account list with a confirmation per sub, and a companion API-connection GC script that uses Resource Graph to join connections against workflow definitions in one query.

Bulk-configure diagnostic settings on Azure Logic Apps Consumptions

Yanbo_Deng — Wed, 20 May 2026 08:47:16 GMT

Bulk-configure diagnostic settings on Azure Logic Apps — without clicking through the Portal

LA-BulkDiag is a small, single-file PowerShell script that does the whole job in one guided run. It enumerates every Consumption Logic App in a resource group, shows you which ones already have settings, lets you pick a scope (every bare LA / every LA / a hand-picked subset), and creates the diagnostic setting on each. It auto-renames on collision so re-running is safe, and it ships with 129 Pester tests covering helpers, parameter binding, and end-to-end flows with a mocked az.

Source + full docs:
GitHub - dengyanbo/LA-BulkDiag: Bulk diagnostics configuration for Azure Logic Apps

What it gives you

A numbered, color-coded table of every Consumption LA in the RG and its current diagnostic-setting state (bare / has N / list failed).
A single scope prompt — bare / all / pick / cancel — so the common cases are one keystroke.
Selection grammar for the picker / -Selection: 1,3-5,8, bare, all, none.
Auto-rename on name collision (la-diag → la-diag-1 → …) so the upsert behavior of Azure’s API never silently replaces an existing setting.
Preflight verification of the destination workspace / storage account via az resource show before touching any Logic App.
-WhatIf for a dry-run preview.
Non-zero exit code if any LA failed, so it composes cleanly in CI.

What it is not: it does not target Standard Logic Apps (Microsoft.Web/sites with kind=workflowapp) — those use a different API. It also doesn’t target Event Hub destinations. For everything else, see the “Scope and what this is NOT” section in the GitHub README.

Quick start

Prerequisites

PowerShell 5.1+ (Windows PowerShell or PowerShell 7 — both fine).
Azure CLI on PATH: https://aka.ms/installazurecliwindows
An interactive az login against the subscription that owns the Logic Apps. Built-in Monitoring Contributor on the RG is enough.

Get the script

git clone https://github.com/dengyanbo/LA-BulkDiag.git cd LA-BulkDiag

One-liner — fully interactive

You don’t need to know the destination IDs up front; the script will ask:

.\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -SettingName la-diag

You’ll see something like:

Sub: my-sub (00000000-...) User: alice@contoso.com Destination not provided on the command line. Configure interactively: (paste the full ARM resource ID; leave blank to skip a destination) Log Analytics workspace resource ID: /subscriptions/.../workspaces/my-ws Storage account resource ID: Inspecting 3 Logic App(s) ... Logic Apps in 'my-rg': [ 1] order-processor bare (no settings) [ 2] notification-sender has 1: corp-governance [ 3] data-loader bare (no settings) How do you want to apply 'la-diag'? 1) bare -- apply to every BARE LA (recommended) 2) all -- apply to EVERY LA (may fail Azure-side on non-bare ones) 3) pick -- go into the selective picker 0) cancel Choice [1]: 1 Applying to every BARE LA. ==> order-processor Creating ... OK (Created). ==> data-loader Creating ... OK (Created). ================ Summary ================ LogicApp FinalName Status -------- --------- ------ order-processor la-diag Created data-loader la-diag Created Selected: 2 Succeeded: 2 Renamed: 0 Failed: 0 Not selected: 1

That’s the whole workflow.

The commands you’ll actually use

Grab the destination IDs once:

$wsId = az monitor log-analytics workspace show -g ws-rg -n my-ws --query id -o tsv $saId = az storage account show -g sa-rg -n mysa --query id -o tsv

1. Apply to every bare LA — fully automated

.\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -WorkspaceId $wsId -SettingName la-diag -Selection bare

-Selection bare skips both the scope prompt and the y/N confirm — perfect for CI.

2. Send to both a workspace and a storage account

.\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -WorkspaceId $wsId -StorageAccountId $saId ` -SettingName la-diag -Selection all

3. Metrics only, storage-only

.\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -StorageAccountId $saId -SettingName la-metrics ` -Preset metrics-only -Selection all

Available presets: all (default) / logs-only / metrics-only / workflowruntime.

4. Specific Logic Apps by index — non-interactive

After running once and seeing the numbered table, you can target them directly:

.\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName la-diag -Selection '1,3-5,8'

5. Dry-run before committing

.\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName la-diag -Selection all -WhatIf

6. Just inspect — list LAs + existing settings, change nothing

.\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName whatever -Selection none

7. Run the tests

.\unit_test\Run-Tests.ps1

Auto-installs Pester 5 to CurrentUser if missing. Expected: Passed=129 Failed=0.

Selection grammar — cheat sheet

Input	Meaning
`1`, `3`, `7`	single index (1-based, matches the table)
`1,3,5`	multiple indices
`1-5`	inclusive range
`1,3-5,8`	mixed
`bare`	all LAs with no existing settings (recommended)
`all`	every LA (may fail on already-configured ones)
`none` (or empty / `q` / `cancel`)	exit without changes

Why the auto-rename matters

Azure’s diagnostic-settings API is PUT — calling create --name la-diag on a Logic App that already has a setting named la-diag silently replaces the existing one. That’s a footgun if a colleague already set something up by hand.

LA-BulkDiag refuses to overwrite. Instead, when -SettingName is already in use on a given LA, it auto-appends -1, -2, … until it finds a free name, and reports the actual name in the summary’s FinalName column. If you genuinely want to replace an existing setting, delete it first:

az monitor diagnostic-settings delete -n <existing-name> --resource <la-id>

Where to go next

The GitHub repo has the full reference — parameter table, exit codes, status-value glossary, troubleshooting matrix (RBAC, MFA, throttling, category/sink conflicts), known limitations, and the full test inventory:

👉 https://github.com/dengyanbo/LA-BulkDiag

Azure API Center portal is now generally available

Sreekanth_Thirthala — Tue, 19 May 2026 20:43:16 GMT

What Is the API Center Portal?

The API Center portal is a hosted, provisioned and managed by Azure, where developers across your organization can discover, explore, and consume APIs. The API Center portal provides a multi-gateway, organization-wide view of every API and AI asset (e.g. plugins, MCP servers, skills etc)

Key Capabilities

Search and filter your full API inventory. Developers can find APIs and AI assets by name or use AI-assisted semantic search (available on the Standard plan) to query by intent. Natural language queries like “Enable cloud migration” surfaces relevant Azure cloud migrate skill and associated MCP server even when exact words don’t appear in AI asset name and description
Rich API details at a glance. Users can view endpoints, methods, parameters, and response formats; download API definitions; or open them directly in Visual Studio Code — all from within the portal.
Discovering and testing MCP servers: The API Center portal supports discovery of MCP (Model Context Protocol) servers, making it a single destination for both traditional APIs and the AI-native integrations powering modern copilots and agents. Developers and other stakeholders can browse and filter MCP servers in the inventory, view details such as the URL endpoint and tool schemas, and install MCP servers directly into their Visual Studio Code environment — all from within the portal. A built-in test console lets users test MCP server tools and view responses without leaving the portal: simply navigate to the Documentation tab of an MCP server details page, select a tool, and click Run tool to get started.
Discovering Skills and assessment results: The API Center portal also serves as a central hub for discovering skills registered in your organization's API inventory. Developers and stakeholders can browse and filter skills alongside APIs and MCP servers and view detailed information about each skill directly in the portal. Skill assessment results are surfaced on the skill details page, giving teams immediate visibility into the quality and readiness of each skill — no additional tooling required. Together with API and MCP server discovery, skills support in the API Center portal reinforces its role as a unified catalog for all the building blocks of modern AI-powered applications.
Flexible access control. The portal integrates with Microsoft Entra ID for authenticated access, or you can enable anonymous access for broader internal discoverability. Role-based access control makes it straightforward to grant access to specific users and groups.
Customizable visibility rules. Admins can filter which APIs surface in the portal — by asset type (REST, GraphQL, MCP, Agent, Skill etc.), lifecycle stage, specification format, or custom metadata — so the right APIs and AI assets reach the right audiences.

Setting It Up

Getting started takes just a few steps in the Azure portal:

Navigate to your API center and select API Center portal > Settings.
Configure access — either Microsoft Entra ID authentication (recommended) or anonymous access.
Hit Save + publish, and your portal is live at https://<service-name>.portal.<location>.azure-apicenter.ms.

For teams with deeper customization needs, the portal can also be self-hosted and integrates with the Visual Studio Code extension for API Center.

Learn more

The Azure API Center portal is available today. Visit the setup documentation to configure your portal, and check out the overview of Azure API Center to learn more about managing your organization’s full API and AI asset inventory.

To learn more click here

Run Javascript code on Agent Loop

WSilveira — Thu, 21 May 2026 02:10:42 GMT

We have recently introduced support for Code interpreters inside of Azure Logic Apps Agent Loop, extending the support we had for Python.

When partnered with a LLM, this allow builders to express their goals or intents via natural language and obtain executable results. These capabilities become powerful in the areas of data analysis, visualizations, validations and transformations. Our first language supported for code interpreter is JavaScript, with other languages following later.

Historically, customers have had concerns about an LLM performing data analysis, calculations and transformations due to context window exhaustion which can lead to hallucinations. Code interpreters help in this regard as they can perform this analysis without filling up context windows and providing more reliable results.

You can see the code interpreter with JavaScript in action in this video from Kent Weare. After watching the video, you can deep dive in the details.

How it works

When Agent Loop evaluates code generated by an AI agent (for example, through a code interpreter), we run it inside a V8 isolate using the isolated‑vm library.

V8 is the JavaScript engine that powers Node.js and Chrome—it’s what actually executes JavaScript code. An isolate is a lightweight, independent environment within V8, with its own memory and execution context.

Running code inside an isolate gives us strong separation from the host runtime. Each execution has its own memory (“heap”) and cannot directly access the host’s memory, file system, or network. This helps ensure that agent-generated code stays contained and doesn’t interfere with the rest of the system.

This approach is not intended to be a full security sandbox, and we don’t treat it as safe for fully untrusted code. However, it provides meaningful defense-in-depth:

Memory usage is limited per isolate, preventing a single execution from consuming all available resources
Execution can be bounded with timeouts, allowing us to terminate long-running or infinite loops
Failures are isolated, so crashes in agent-generated code won’t bring down the runtime process

In practice, this is about reducing blast radius. By isolating execution and enforcing limits, we make sure that code—regardless of whether it’s generated by a user or an AI agent—cannot disrupt the engine that runs it.

Use case: Expense Validations

To help illustrate, this capability, let’s take an accounts payable example built in Logic Apps Standard. Zava uses a 3^rd party expense application to capture employee expenses. The 3rd party expense application will export transactions in CSV format.

Zava has some very specific business validations that need to execute before the expenses can be processed by the ERP. To solve this problem, we will build an agentic business process in Logic Apps that includes our new JavaScript code interpreter.

Our code interpreter will be able to ingest and parse our CSV file and then apply our business validations for us. The outcome is a report that identifies both valid and invalid transactions.

Prior to uploading to the ERP (Dataverse), we will route our request to a human in the loop process for their oversight. This allows for additional control as unwinding in an ERP is always a tedious task.

Below, is a picture of our solution. Within it we can see both deterministic steps before and after our Agent action. Within our agent action, we have tools that will help our agent address our company objectives. These tools include calling a batch API to upload valid expense records to Dataverse. Another tool that will take care of uploading invalid records to a different table, our human in the loop action to seek approval from our human stakeholder and a tool that will help us obtain business knowledge from SharePoint.

You might be asking, ok where does the code interpreter come in? Within our Agent action, we will discover a toggle that allows you to enable it. The code interpreter gets invoked based upon instruction in the model. Here is a subset of the prompt from this workflow that describes how to invoke the code interpreter.

For example:

### Step 2 -- Parse and Validate
The expense CSV data is available from the Get_file_content action. Use code interpreter to parse ALL rows from the CSV. For each row, normalize:

Category: title case
- Amount: decimal number
- SubmittedDate: ISO 8601 format (e.g. "2026-01-05T00:00:00Z")
- ReceiptAttached: convert "Yes"/"No" to true/false

Then apply the business rules from Step 1 to classify every record as VALID or INVALID.

You won’t see the code interpreter modelled as a tool within our agent action, but we see the execution outcome within our run history. In the following screenshot we can see this illustrated. Within our agent action, we can see that we are on our 4^th turn and we have executed the code interpreter action. In the code window, we can see the code that was generated for our us. This is the result of the LLM working together with the code interpreter to generate and execute this code.

Note: In this scenario, we are dynamically generating this code at runtime. This allows for ultimate flexibility if we have different source inputs and we are relying upon the LLM and code interpreter to adapt to these fluid inputs. If we were interested in a more deterministic approach we can also pass pre-written code into this action where it can also execute. This will result in less flexibility, but more deterministic behavior.

Running JavaScript code in Logic Apps Consumption Agent Loop

Logic Apps Consumption has a slightly different architecture to Logic Apps Standard. In Logic Apps Standard, we offer dedicated compute and storage for customers which provides workload isolation across customers.

When it comes to Logic Apps Consumption, we provide a multi-tenant offering allowing customers to take advantage of a lower price point due to shared resource utilization. In order to allow customer isolation, customers need to have an integration account attached to their consumption workflow. This will allow the code interpreter to run in isolated compute thus avoiding any potential disruptions to other customers.

You can provision an Integration Account by searching for Integration Accounts at the top of the Azure portal. You can select any of the SKUs available, including the Free SKU for non-production/non-SLA scenarios.

With an Integration Account created, we can associate this Integration Account with our consumption logic app by clicking on Settings – Integration Account.