Workflows with AI agents and models in Azure Logic Apps (Preview)

Applies to: Azure Logic Apps (Standard)

Azure Logic Apps supports workflows that complete tasks by using agents with large language models (LLMs). An agent uses an iterative looped process to solve complex, multi-step problems. An LLM is a trained program that recognizes patterns and performs jobs without human interaction, for example:

• Analyze, interpret, and reason about information such as instructions, prompts, inputs, and other data.
• Make decisions, based on results and available data.
• Formulate and return answers back to the prompter, based on the agent's instructions.

You can build workflows that use autonomous or conversational agents. The agent uses natural language to communicate with you and the connected model. The agent also uses model-generated outputs to do work either with or without human interaction. The model helps the agent provide the following capabilities:

• Accept information about the agent's role, how to operate, and how to respond.
• Receive and respond to instructions and requests, or prompts.
• Process inputs, analyze data, and make choices, based on available information.
• Choose tools to complete the tasks necessary to fulfill requests. A tool is basically a sequence with one or more actions that complete a task.
• Adapt to environments that require flexibility and are fluid, dynamic, unpredictable, or unstable.

With 1,400+ connectors that you can use to build tools for an agent to use, agent workflows support a vast range of scenarios that greatly benefit from agent and model capabilities. Based on your scenario, create either an autonomous agent workflow without human interaction or a conversational agent workflow with human interaction to best suit your solution's needs.

This conceptual guide describes key concepts, differences between autonomous and conversational agent workflows, differences between agent workflows and nonagent workflows, agent structure, other example scenarios, and basic billing information.

Key concepts

The following table provides basic introductions to key concepts:

Autonomous versus conversational agent workflows

To help you better understand how these agent workflow types differ, the following sections describe and show examples for each agent workflow type. Both workflow types use an agent and tools to get the current weather and send that information in email. All agents have an information pane where you set up the agent with the model you want and provide instructions about the agent's roles, its functions, and the way to respond.

Autonomous agent workflow

The following high-level steps describe the behavior for a basic autonomous agent workflow:

1. The workflow starts with any available supported trigger.

   Optionally, zero or more actions might run between the trigger and the agent.

2. The agent accepts system instructions and nonhuman prompts or inputs, for example, outputs from the trigger or a preceding action.

3. The agent uses the deployed model in Azure OpenAI Service or the deployed model in an Azure AI Foundry project to interpret and understand the instructions and request. The agent also uses the model to process and analyze the provided inputs.

4. Based on the agent instructions, the model helps plan which tools that the agent needs to invoke to perform the necessary tasks.

5. The agent returns the tool results and responds to the workflow caller or the specified recipient.

The following screenshot shows a basic example autonomous agent workflow:

Conversational agent workflow

The following high-level steps describe the behavior for a basic conversational workflow:

1. The workflow always starts with the trigger named When a chat session starts.

   Optionally, zero or more actions might run between the trigger and the agent.

2. The agent accepts system instructions and human-provided prompts or inputs through the integrated chat interface, for example, What is the weather in Seattle?

3. The agent uses the deployed model in Azure OpenAI Service to interpret and understand the instructions and request. The agent also uses the model to process and analyze the provided inputs.

4. Based on the agent instructions, the model helps plan which tools that the agent invokes for the necessary tasks.

5. The agent returns the tool results and responds through the chat interface to the human prompter.

The following screenshot shows a basic example conversational agent workflow:

The following screenshot shows the integrated chat interface that you can access from the designer toolbar or the workflow sidebar menu under Tools in the Azure portal:

Conversational agent workflows also support a chat client outside the Azure portal that others can use. To provide and secure access for this external chat client, you need to set up Easy Auth on your logic app to authenticate and authorize users.

Agent versus nonagent workflows

Workflows that use agents can evolve beyond the limits imposed on nonagent workflows. Agent workflows can adapt to environments where unexpected events happen, choose which tools to use based on prompts, inputs, and available data, continuously improve their performance, handle unstructured data, support complex scenarios, and provide a higher level of adaptability and flexibility. Nonagent workflows function best in stable environments, follow predefined rules, and perform tasks that are static, predictable, and repetitive.

The following table provides more comparisons between agent workflows and nonagent workflows:

Explore agent workflow structure

To build a new agent workflow in single-tenant Azure Logic Apps for your AI automation and integration solutions, you create a Standard logic app resource and add a workflow that has one of the following workflow types:

• Autonomous Agents
• Conversational Agents

These workflow types include all the capabilities in Standard stateful workflows plus agent capabilities and are specifically designed to work with agents. These workflow types automatically include an empty agent.

For example, the following screenshot shows a new autonomous agent workflow:

The following screenshot shows a new conversational agent workflow:

If you have an existing Stateful workflow, the following screenshot shows how you can add an Agent action to include autonomous agent and LLM capabilities:

The following screenshot shows the agent's connection pane where you specify information about the deployed model that you want to use:

After you create a connection to the model, the agent requires that you provide instructions that describe the roles that the agent can play, tasks that the agent can perform, and other specific prescriptive information that helps the agent respond to prompts, answer questions, and perform requested tasks, for example:

An empty agent connected to a model can respond to prompts that only use the model's capabilities, so an agent doesn't have to include tools. However, for the agent to use actions available in Azure Logic Apps, the agent needs you to create tools. You can start creating a tool by first adding an action from the connectors gallery.

The following diagram shows the gallery where you can browse and select actions to build tools:

The following diagram shows a weather agent that can get the weather forecast and send that forecast in email:

More example scenarios

The following section describes a few more ways that an agent can complete tasks in a workflow:

Mortgage loan agent

Imagine that your bank uses a mortgage loan agent that processes loans autonomously or with human intervention when necessary by performing the following tasks in a single orchestrated loop:

• Converse with customers to answer questions.
• Review loan applications.
• Collect financial information to assess loan eligibility.
• Retrieve and analyze risk data.
• Request and summarize real estate appraisals when submitted.
• Include human reviewers for edge cases.
• Approve or decline applications.
• Communicate decisions to relevant parties.

Order fulfillment agent

Suppose your business uses an order fulfillment agent to perform the following tasks:

• Engage with customers to answer product questions, based on enterprise knowledge.
• Create orders but pass them on to humans when necessary.
• Provide 24/7 support with intelligent escalation.

You can also have an agent that orchestrates work across other agents. For example, you might have a team of agents, such as a writer, reviewer, and publisher, that work together to create and distribute sales reports.

Facilities work order agent

To support an internal facilities team, a work order agent performs the following tasks:

• Converse with employees and provide options for service requests.
• Open work orders based on employee selections.
• Send work orders to the corresponding service teams.
• Update work orders with jobs progress and status.
• Close work orders when jobs are complete.
• Notify the appropriate parties about completed jobs.

Authentication and authorization

Nonagent workflows usually interact with a small, known, and predictable set of callers. However, agent workflows communicate with broader range of callers, such as people, agents, Model Context Protocol (MCP) servers, tool brokers, and external services. This wider reach increases integration options but introduces different security challenges because callers can originate from dynamic, unknown, or untrusted networks. When callers come from networks you don't control, or when identities are external or unbounded identities, you must authenticate and authorize each caller so you can protect your agent workflows, specifically conversational agent workflows because they provide an external chat client to interact with people.

For nonproduction activities, the Azure portal uses a developer key for authentication and authorization. When you're ready to run conversational agent workflows in production, make sure to set up Easy Auth, also known as App Service Authentication For conversational agent workflows, this protection enables an external chat client outside the Azure portal that others can use after you finish Easy Auth.

The following sections describe and compare options for authenticating callers and authorizing their access to agent workflows.

Developer key authentication and authorization

For nonproduction activities only, such as design, development, and quick validation, the Azure portal provides, manages, and uses a developer key to run your workflow on your behalf.

What is a developer key?

A developer key is a convenience authentication mechanism used only by the Azure portal to run your workflow during the design, development, and quick testing stages in the Azure portal. During these stages, the developer key lets you skip the need to manually set up Easy Auth or copy trigger callback URLs with shared access signatures (SAS). The key is linked to a specific user and tenant based only on an Azure Resource Manager bearer token, which is an access token that authenticates requests to the Azure Resource Manager REST API.

The portal automatically injects the developer key when you use built‑in test experiences in the workflow designer like running a workflow, calling the Request trigger, or interacting with a conversational agent workflow in the internal chat interface. The key is implicitly bound to a tenant session and a signed-in portal user, so you can't distribute the key externally due to this binding, which is based only on the ARM bearer token.

Developer key limitations

The following list describes the developer key's usage and design limitations:

• The key isn't a substitute for Easy Auth, managed identity, federated credentials, or signed callback URLs in production scenarios.
• The key isn't designed for large or untrusted caller populations, agent tools, or automation clients.
• The key isn't a per-user authorization mechanism due to lack of granular scopes and roles.
• The key isn't governed by Conditional Access policies at the request execution layer, only at the portal sign‑in layer.
• The key isn't intended for programmatic or CI/CD usage.

For a comparison between developer key and Easy Auth, see Easy Auth versus developer key.

Developer key use cases

The following table describes appropriate and inappropriate scenarios for using the developer key:

Easy Auth built-in authentication and authorization

For production, protect access to conversational agent workflows and external chat client access by setting up Easy Auth on your logic app resource with a dedicated Microsoft Entra app registration. Easy Auth authenticates and authorizes only people who have the correct permissions to interact with your conversational agent workflow. This approach isolates tokens, enforces least privilege, and avoids reusing broad multi-application registrations. After you set up Easy Auth for your logic app resource, your workflow provides a URL to an external chat client outside the Azure portal that people can use to interact with your conversational agent.

Easy Auth provides a built‑in enforcement layer that lets you focus more on building your workflow's business logic and offers the following benefits:

• Handles sign-in, authentication, and authorization for Microsoft Entra without custom code.

• Keeps secrets, long-lived Shared Access Signature (SAS) URLs, and access keys out of workflows, reducing secrets sprawl, rotation overhead, and exposure risk.

• Enables least-privilege design by mapping access to roles and scopes rather than IP ranges or static keys.

• Validates access tokens before the workflow runs. Injects a validated identity into each caller request so workflows can make per‑request, least-privilege authorization decisions.

• Provides a validated identity for each request sent to your workflow so you can enforce least‑privilege decisions inside workflows.

• Centralizes Conditional Access policies, tenant restrictions, role-based access control (RBAC), and permission scopes for consistent policy application and enforcement.

• Injects normalized identity claims such as X-MS-CLIENT-PRINCIPAL, groups, roles, scopes, and tenant into each caller request. Eliminates custom middleware and lets downstream workflow actions like Compose or Parse JSON apply fine-grained authorization against claims and scopes.

• Produces consistent authentication and authorization logs for debugging, anomaly detection, diagnostic activities, auditing, and governance.

The following process describes how Easy Auth authenticates and authorizes a client to access your logic app:

1. When a client tries to authenticate its identity to access your Easy Auth-protected logic app, Azure redirects the request to Microsoft Entra ID.

2. If the client successfully authenticates, Microsoft Entra ID issues an access token to the client.

   These tokens are signed by Microsoft Entra ID and include details like the audience (aud) claim, subject (sub), and expiration (exp). The aud claim specifies the intended token recipient and is later used to automatically populate the application ID URI for the recipient logic app. This URI is a unique identifier that represents your logic app as the audience in access tokens and uses the following format:

   api://<application-client-ID>

3. The client sends a request with the token to your logic app.

4. Easy Auth intercepts the request, extracts the token, and runs the following checks:

   • Compare the aud claim with the allowed token audience.
   • Compare the aud claim with the expected application ID URI.

5. If the values match, authorization continues. If not, Easy Auth denies the request with an HTTP 401 Unauthorized error.

For more information, see the following articles:

• Secure agent workflows with Easy Auth in Azure Logic Apps
• Authentication and authorization in Azure App Service and Azure Functions

Easy Auth versus developer key

Billing

Although agent workflows don't incur extra charges in Azure Logic Apps, model usage in Azure OpenAI Service and Azure AI Foundry projects incur charges. For more information, see the following pages:

• Azure OpenAI Service pricing
• Azure AI Foundry pricing

Related content

• Create autonomous agent workflows in Azure Logic Apps
• Create conversational agent workflows in Azure Logic Apps
• Labs: Overview for building agentic workflows with Azure Logic Apps