Tag Archives: Agents

Azure Functions Hosted Skills: When to Use It

Posted on by
2

Editor’s note (September 2026): Microsoft has renamed this feature from “Azure Functions serverless agents runtime” to “Azure Functions hosted skills.” The content below has been updated to reflect the new name. The URL remains unchanged.

Most conversations about agent runtimes on Azure land on Azure AI Foundry Agent Service. That is the right starting point for teams that want a fully managed, enterprise-grade agent host. But it is not the only option and for event-driven scenarios, it is often not the best one.

The Azure Functions hosted skills is a preview programming model that lets you define agents as function apps. Agents are triggered by events, schedules, messages, or HTTP requests. They run on Flex Consumption with scale-to-zero, managed identity, and Application Insights. And they are deployed with azd like any other function app.

This post explains what the runtime actually is, how its three configuration files work together, and where it fits relative to Foundry Agent Service and Durable Functions. If you are new to Azure Functions as an AI platform, start with Azure Functions AI Integration: The Quiet Powerhouse which maps all four AI-enabled patterns. If you are looking specifically at MCP server hosting, Hosting MCP Servers on Azure Functions covers the three hosting options in detail.

How Azure Functions hosted skills work

The runtime is a programming model built on top of Azure Functions. When an event fires — a timer, an HTTP request, a queue message — the runtime starts the agent, runs it through Microsoft Agent Framework, and handles the trigger registration and endpoint wiring automatically.

You do not write trigger code, and do not implement an agent loop, and define three files, deploy a function app, and the runtime does the rest.

The core project files are:

  • .agent.md — defines the hosted skill: its instructions, its trigger, and the tools it can use
  • agents.config.yaml — app-wide runtime defaults, including the model deployment and any shared infrastructure (such as an Azure Container Apps dynamic session pool for sandboxed code execution)
  • mcp.json — lists the remote MCP servers available to hosted skills in the app
  • tools/ — optional folder containing custom Python tool functions decorated with @tool for app-specific logic
  • skills/ — optional folder containing reusable SKILL.md prompt assets that hosted skills can load on demand

The runtime discovers these files at startup, registers the required triggers and endpoints, and wires the agent to Microsoft Agent Framework. You can have multiple hosted skills in a single function app each defined in its own .agent.md file, all sharing the app-wide configuration.

What Azure Functions hosted skills deploy

The Microsoft Learn quickstart deploys two agents from a single function app:

Chat agent (main.agent.md) — an HTTP-triggered agent that exposes a debug chat UI in the browser. It can execute sandboxed Python code via an Azure Container Apps dynamic session pool and browse the web. No email tooling.

Blog summary agent (daily_microsoft_blog_summary.agent.md) — a timer-triggered agent. The YAML front matter in the file declares the schedule; the markdown body contains the agent instructions. On each timer fire, the agent gathers recent Microsoft blog posts, summarises them, and emails the digest via a managed MCP server connected to Microsoft 365 Outlook.

What gets provisioned by azd up for this template:

ResourcePurpose
Flex Consumption function appHosts the agents
Azure AI Foundry project + model deploymentLLM for agent reasoning
Azure Container Apps dynamic session poolSandboxed Python code execution
Storage accountFunction app state
Application InsightsMonitoring
Connector Namespace + M365 Outlook connectionEmail delivery (optional)
Managed MCP serverExposes the Outlook connector to agents

The provisioning is handled entirely by Bicep via azd you do not configure any of this manually.

How the agent definition files work

.agent.md is a markdown file with YAML front matter. The front matter declares the trigger and any agent-level configuration. The markdown body is the system prompt — the instructions the agent follows when it runs.

The timer-triggered blog summary agent front matter looks roughly like:

---
trigger:
  type: timer
  schedule: "0 0 8 * * *"  # timer_trigger uses underscore in type field
tools:
  - mcp_server: outlook
---

The markdown body below that is the agent’s instruction set what to gather, how to summarise it, how to format the email. You write it in plain English.

agents.config.yaml sets defaults that apply across all agents in the app. The model deployment is set here, so every agent uses the same Azure AI Foundry model unless overridden. The session pool endpoint for sandboxed code execution is also set here.

mcp.json lists the remote MCP servers the agents can call. In the quickstart template, this includes the managed MCP server for the Microsoft 365 Outlook connector when email delivery is enabled. The runtime reads this file at startup and makes those servers available to all hosted skills in the app.

How Azure Functions hosted skills differ from Foundry Agent Service

The distinction matters for architecture decisions.

Foundry Agent Service is a fully managed service. Microsoft operates the agent host. You configure agents through the Foundry portal or SDK, connect tools, and the service handles orchestration, state, and scaling. It has enterprise SLAs, built-in tooling, and a managed lifecycle.

Azure Functions hosted skills is a programming model you deploy yourself. You own the function app. You manage the deployment, the model connection, and the infrastructure. In return, you get the full Azure Functions hosting model — event-driven triggers, Flex Consumption billing, VNet integration, managed identity, and azd-based deployment pipelines.

The decision table:

SituationUse
Event-driven triggers, AI reasoning, scale-to-zero, VNet integrationAzure Functions hosted skills
Expose deterministic functions as tools for another AI clientAzure Functions MCP extension
Long-running, multi-step orchestration with human-in-the-loop approvalsDurable Functions
Create and manage AI agents without custom hostingMicrosoft Foundry or Copilot Studio

These are not mutually exclusive. Azure Functions hosted skills can call tools hosted in Foundry via MCP servers, and Foundry agents can call tools hosted in Azure Functions. The two can coexist in the same architecture.

How Azure Functions hosted skills differ from Durable Functions

Post 4 in this series covers Durable Functions for directed agentic workflows in detail, but the short version is:

Durable Functions is for directed, deterministic workflows — you define the steps, the model executes them in order, and Durable Functions handles state, retry, and fault tolerance. The workflow is predictable.

Azure Functions hosted skills is for autonomous agents — you give the agent instructions and tools, and Microsoft Agent Framework determines how to use them to accomplish the goal. The execution path is not predetermined.

If your AI-driven process has fixed, ordered steps and you need auditability, use Durable Functions. If you want the agent to figure out the steps, use Azure Functions hosted skills.

What to know before you build

It is preview. The programming model, file format, and configuration details are subject to change. Do not build production-critical workloads on this today without a plan for the preview-to-GA migration.

It requires a Foundry project and model deployment. The azd template provisions both automatically, but you need an Azure subscription with permissions to create Foundry resources and model deployments. Some organisations have restrictions on which model deployments are permitted.

The azd template provisions real Azure resources with real costs. The Flex Consumption plan itself is very low cost for low-traffic agents, but the Foundry model deployment, Container Apps session pool, and Connector Namespace resources all have associated costs. Review the Bicep templates in infra/ before running azd up in a production subscription.

Custom Python tools are how you add app-specific logic. Azure Functions hosted skills provides the agent loop and the MCP connections. For anything that requires your own code — calling internal APIs, reading proprietary data sources, applying business rules — you write Python tool functions and register them in the agent definition.

Getting started

The quickstart template is the right starting point:

azd init --template Azure-Samples/functions-quickstart-serverless-agents-azd -e serverless-agents
azd env set TO_EMAIL <your-email>
azd up

Review the three configuration files in src/ before deploying. They are short and readable, and understanding them before the first deployment saves debugging time later.

The email delivery step (setting TO_EMAIL and authorizing the Microsoft 365 Outlook connection) is optional. If you skip it, the timer agent still runs and returns its digest in the final response, which you can verify in Application Insights logs.

Try it with a weather sample.

If you want to see the runtime in action with a minimal, self-contained example before committing to the full quickstart, I built a companion sample: a weather chat agent that fetches live conditions and 3-day forecasts for any location using Open-Meteo, no API key, no M365 connector, no email setup required.

The agent is defined in a single main.agent.md file. It uses Python code execution via the Container Apps session pool to call the Open-Meteo API and returns structured weather data in the chat UI. Deploy it in three commands:

git clone https://github.com/steefjan1/weather-agents
cd weather-agents
azd up

Select Central US when prompted for location — the runtime is in preview and region availability is limited. The chat UI is at https://<function-app-name>.azurewebsites.net/api/agents/main/ once deployment completes.

Agent Chat UI showing a response to "What is the weather in Amsterdam?" — current temperature 19°C (66°F), relative humidity 54%, wind speed 8.3 km/h, and a 3-day forecast showing today's high of 22.4°C with 2% precipitation chance, tomorrow's high of 19.7°C with 67% precipitation chance, and the day after at 19.7°C with 2% precipitation chance.
The weather agent runs on the Azure Functions serverless agents runtime, pulling live conditions and a 3-day forecast for Amsterdam from Open-Meteo via sandboxed Python code execution in an Azure Container Apps dynamic session. The agent is defined in a single main.agent.md file.

The README documents two known issues you will hit if you try to build from scratch rather than the official quickstart: a broken transitive dependency in azurefunctions-agents-runtime that pins a yanked version of github-copilot-sdk, and the region constraint. Both are worth knowing before you invest time in a custom deployment.

Up next: Durable Functions as the Orchestration Layer for Directed Agentic Workflows

Building Azure Logic Apps Agent Tools: Connectors and MCP

Posted on by
4

Part 4 of 7 in the Logic Apps Agent Loop series

Part 3 covered the two agentic workflow patterns in Azure Logic Apps, autonomous and conversational, and how to choose between them. Both patterns rely on the same mechanism for getting work done: tools. An Azure Logic Apps agent loop tool is the means by which the model reaches out to the world to query a database, send an email, call an API, or retrieve a document. Without tools, the agent can only reason over what the model already knows.

This post is the most hands-on in the series. It covers the three layers of the Azure Logic Apps tooling model, built-in connectors, custom connectors, and MCP servers. Moreover, it includes a demo showing how to expose a Logic Apps workflow as a tool provider that can be called by an external agent in Azure AI Foundry.

Choosing the right Azure Logic Apps agent tools layer

Before building anything, it is important first to understand what a tool actually is in Logic Apps terms. Specifically, a tool is defined as a sequence of one or more connector actions that the agent can choose to invoke during a loop iteration. Consequently, the model decides which tool to call based on the tool’s name and description. Therefore, naming and describing tools clearly is one of the most crucial decisions you will make when building an agentic workflow.

Logic Apps offers three layers of tooling, each adding capability and complexity.

Layer 1: Built-in and managed connectors

The foundation layer is the 1,400+ connector library that Logic Apps has always offered. For agent tools, the most relevant connectors are those that give the agent access to data and services: Azure OpenAI, Azure AI Search, Azure Blob Storage, Office 365 Outlook, SharePoint, SQL Server, HTTP, and Service Bus among them.

You build a tool by adding one or more of these connector actions inside the tool container within the agent action. Each tool gets a name and a description. The model reads these at runtime to decide whether to invoke the tool and what arguments to pass. You then create agent parameters for any action inputs that the model should supply dynamically: a city name for a weather lookup, a query string for a search, a recipient address for an email.

Agent parameters differ from standard Logic Apps parameters importantly. They are scoped to the tool where you define them; they cannot be shared across tools. They also receive their values only when the agent invokes the tool, not at workflow start time. You can call the same tool multiple times in a single loop using different parameter values: for example, you could invoke a weather tool for both Amsterdam and London in the same run.

Layer 2: Custom connectors

Where the built-in connector library has gaps, custom connectors fill them. A custom connector in Logic Apps is an OpenAPI-described wrapper around any REST API, internal or external. Furthermore, once you register it, it appears in the connector gallery just like a managed connector, and you can use it inside a tool in the same way.

For enterprise integration architects, custom connectors are the bridge between the agent loop and any internal system that does not have a first-party Logic Apps connector: an internal HR system, a legacy claims processing API, a proprietary data platform. The investment in defining the OpenAPI specification pays off because the connector becomes reusable across all workflows in the tenant, not just the agentic ones.

Building a custom connector for use in an agent tool follows the standard Logic Apps custom connector creation process:: define the API, specify authentication, and configure the operations, with one addition: write clear operation descriptions, because the model uses these descriptions to decide when to invoke the connector.

Layer 3: MCP servers

The third layer is the newest and the most architecturally significant. Azure Logic Apps can serve as the backend for a Model Context Protocol (MCP) server exposing connector actions as a structured, discoverable toolset that external agents and models can call over a standard protocol.

MCP is an open standard that defines how AI components discover and invoke tools. Moreover, an MCP server acts as a bridge between an AI agent and the tools it can use. This is a significant shift from the previous two layers. Built-in and custom connectors are tools that the agent in your Logic Apps workflow invokes. An MCP server inverts the relationship: your Logic Apps workflow becomes the tool provider, and the calling agent lives somewhere else entirely.

Structural diagram showing three tooling layers for Azure Logic Apps agentic workflows. Layer 1 contains built-in and managed connectors including Azure OpenAI, Azure AI Search, Office 365, HTTP, and 1,400 more. Layer 2 shows custom connectors wrapping internal REST APIs such as HR, claims, and ERP systems. Both layers sit inside the Logic App boundary with an agent parameters note. Layer 3 sits below as a separate MCP server section, showing an external agent connecting via Azure API Center to MCP tools backed by Logic Apps connectors.
Figure 1 — The three tooling layers available to an Azure Logic Apps agent. Layer 1 (purple) covers the 1,400+ built-in and managed connectors packaged as tools directly inside the agent action. Layer 2 (coral) adds custom connectors that wrap internal REST APIs not covered by first-party connectors, reusable across the tenant. Both layers follow the same pattern: the agent in your workflow calls the tool. Layer 3 (purple, below) inverts the relationship — your Standard logic app becomes the tool provider, registered through Azure API Center and callable by any external MCP-compatible agent. Agent parameters apply across all three layers: the model supplies tool input values at runtime, scoped per tool.

A note on the demo: real-world limitations of the tooling preview

For this post I set out to build a working end-to-end demo showing a Logic Apps workflow exposed as an MCP tool provider callable by an Azure AI Foundry agent. The concept is sound and the architecture is correct, but two practical blockers prevented a clean demo at the time of writing.

API Center MCP wizard limitations. The registration wizard in Azure API Center is in active preview. The connector picker surfaces only managed connectors, so the built-in HTTP action from Part 2 is unavailable. The logic app dropdown is also filtered by region, a logic app in West Europe will not appear in an API Center resource deployed to a different region.

Foundry OpenAPI tool network restrictions. Azure AI Foundry’s OpenAPI tool sandbox cannot reach azurewebsites.net endpoints directly. Calls from the Foundry playground return an Unknown error regardless of the spec configuration. The workaround is to front the Logic Apps endpoint with Azure API Management, which Foundry can reach however that adds infrastructure complexity beyond the scope of this post.

Both limitations are preview-stage issues that Microsoft will likely resolve. The OpenAPI spec, the Foundry agent configuration, and the mcp-research workflow pattern described above are all correct and will work once network access between Foundry and Logic Apps endpoints is available or via an APIM gateway.

The Layer 3 pattern of your Logic App as a tool provider for any external MCP-compatible agent remains the most architecturally significant development in this series. In addition, Part 6 picks up the security implications of that expanded caller surface.

Choosing the right tooling layer

The table below summarises how Azure Logic Apps agentic workflows differ across the three tooling layers.

Built-in connectorsCustom connectorsMCP server
Who calls the toolAgent in your workflowAgent in your workflowAny external MCP-compatible agent
Setup complexityLowMediumMedium–high
ReusabilityWithin the workflowAcross the tenantAcross agents and platforms
Best forStandard integrationsInternal APIs without a connectorMulti-agent, cross-platform tooling

The three layers are not mutually exclusive. A production agentic workflow will typically use built-in connectors for standard integrations, custom connectors for internal systems, and an MCP server where the toolset needs to be shared across multiple agents or platforms.

What comes next

The next post moves from individual tools to multi-agent composition. Part 5 covers orchestrator-worker topologies, agent handoffs, and how to build sequential agent loops.

Autonomous vs Conversational Agentic Workflows in Logic Apps

Posted on by
3

Part 3 of 7 in the Logic Apps Agent Loop series

Part 2 walked through the anatomy of an Azure Logic Apps agent loop and built a minimal autonomous agent from scratch. Before opening the designer, though, there is a design decision to make as Azure Logic Apps agentic workflows come in two patterns: autonomous and conversational, and choosing the right one shapes the trigger, the prompt source, the output destination, and the authentication you need before going to production. This post covers both patterns and helps you decide which fits your scenario.

Two Azure Logic Apps agentic workflow patterns, one agent loop

Both autonomous and conversational agentic workflows use the same Azure Logic Apps agent loop under the hood, the same Think, Act, Observe cycle from Post 2, the same connected model, the same tools built from connector actions. The differences arise from how the workflow starts, who supplies the prompts, and how the results get delivered.

Autonomous agentic workflows

Supported Logic Apps triggers include an HTTP request, a timer, a Service Bus message, a new file in Blob Storage, and an email arriving in an inbox. The trigger fires, outputs the agent’s prompt, runs the loop, and then returns the result to the caller or forwards it to a downstream system. No human is in the loop during execution.

This is the pattern from Post 2. It works well in scenarios where the input is clear, and the agent’s task is specific: summarize this document, classify this support ticket, extract these fields from this invoice, and route this order based on its contents. The workflow runs unattended, potentially thousands of times a day, without any human interaction between trigger and result.

The key design characteristic of an autonomous workflow is that the prompt comes from the system, not from a person. The trigger outputs a message body, a file name, and a queue payload, which is what the agent reasons over. The instructions you write in the agent’s configuration pane define the agent’s role for every run.

Conversational agentic workflows

A conversational agentic workflow introduces a human in the loop. Instead of firing from a system trigger, it always starts with the “When a chat session starts” trigger the only trigger supported for this pattern. From there, the agent receives prompts through an integrated chat interface: a person types a message, the agent reasons over it, invokes tools if needed, and responds. The conversation continues turn by turn until the session ends.

This pattern suits scenarios that require dialogue: a support agent that asks clarifying questions, a guided data-entry flow, a research assistant that refines its output based on feedback, or any situation where the right response depends on what the user says next. The agent maintains session state across turns, so each prompt it receives includes the history of the conversation so far.

The integrated chat interface is accessible directly from the Logic Apps designer in the Azure portal during development. For production use, conversational workflows also support an external chat client that people outside the portal can access, which introduces authentication requirements covered later in this post.

Choosing the right Azure Logic Apps agentic workflow pattern

The decision comes down to one question: does the workflow need a human in the loop during execution?

If the input is fully available at trigger time and the task can be completed without further human input, use the autonomous pattern. If the workflow needs to ask questions, receive feedback, or maintain a conversation across multiple turns, use the conversational pattern.

A few other factors are worth considering:

Trigger flexibility. Autonomous workflows support any Logic Apps trigger, the full library of 1,400+ connectors. Conversational workflows are locked to the When a chat session starts trigger. If your scenario requires a scheduled run, a queue-based trigger, or any event-driven start, autonomous is your only option.

Output destination. Autonomous agents return results to the workflow caller or pass them to a downstream action, an email, a queue message, or a database write. Conversational agents respond through the chat interface. If the output needs to go somewhere other than a chat window, autonomous is the right fit.

Authentication complexity. Autonomous workflows authenticate using the same patterns as any other Logic Apps workflow, Managed Identity, SAS tokens, and Easy Auth. Conversational workflows that expose an external chat client face a broader authentication challenge: callers can come from dynamic, unknown, or untrusted networks, and every external caller must be authenticated and authorized before going to production. During development, the Azure portal provides a developer key for quick testing in the designer, but this key is explicitly not suitable for production use.

State management. Conversational workflows maintain conversation history across turns automatically. Autonomous workflows have no concept of a session — each run is independent. If your scenario needs memory across multiple interactions, the conversational pattern handles this natively.

What changes in the designer for Logic Apps

Setting up Azure Logic Apps agentic workflows in the designer follows the same steps for both patterns, with two key differences.

When you create a new workflow, select Conversational Agents instead of Autonomous Agents as the workflow type. Logic Apps creates the workflow with the When a chat session starts trigger already in place and an empty agent action connected to it.

The second difference is the chat interface itself. Once the workflow is saved, a chat panel is accessible from the designer toolbar. During development, this is where you test the agent interactively, type a prompt, read the response, andcontinue the conversation. The run history records each turn as a separate agent iteration, giving you the same visibility into the loop’s behaviour as in an autonomous workflow.

Authentication for conversational workflows in production

The developer key that the Azure portal uses during design and testing is a convenience mechanism tied to your portal session. It is not a substitute for production authentication. The developer key is not designed for large or untrusted caller populations, is not governed by Conditional Access policies at the request execution layer, and cannot be distributed externally.

For production conversational agentic workflows, you need to set up Easy Auth on the Logic App.This section addresses external callers, who include individuals or agents accessing the chat endpoint from outside the Azure portal. It emphasizes the need to use proper identity-based authentication for this access. In Post 6 of this series, we will delve deeper into the complete security landscape concerning agentic workflows. This includes a detailed discussion on setting up Easy Auth, utilizing Managed Identity for backend connections, and evaluating the broader threat model associated with conversational workflows.

Choosing the right pattern: a quick reference

AutonomousConversational
TriggerAny supported triggerWhen a chat session starts only
Human interactionNone during executionTurn-by-turn via chat interface
Prompt sourceTrigger or preceding action outputHuman input through chat
Output destinationCaller, downstream action, or systemChat interface response
Session stateNone — each run is independentMaintained across turns
External accessStandard Logic Apps authRequires Easy Auth for production
Best forUnattended, event-driven tasksDialogue, guided flows, multi-turn tasks
Azure Logic Apps supports two agentic workflow patterns: autonomous and conversational. This post explains how they differ in trigger, prompt source, output, and authentication and helps you decide which pattern fits your scenario.
Figure 1 — Autonomous agentic workflows (left) accept input from any supported Logic Apps trigger and run without human interaction, returning results to a caller or downstream system. Conversational agentic workflows (right) always start with the When a chat session starts trigger, receive prompts from a human through the integrated chat interface, and maintain session state across turns. Both patterns use the same agent loop mechanics: Think, Act, Observe, but differ in trigger flexibility, prompt source, output destination, and production authentication requirements.

What comes next

The next post moves from pattern selection to tooling. The upcoming part 4 covers how to build tools for the agent, from built-in and custom connectors to MCP servers as tool providers, and includes the most hands-on demo in the series.