How can AI agents trigger automated workflows using external APIs?

Hi @CodeAutomation

Yes, this is a common pattern for building agentic applications on Azure. Generally, separate the AI decision layer from the workflow/execution layer, rather than letting the model own the entire business process.

A typical architecture would look like:

User / Application > Microsoft Foundry Agent > Intent + tool selection > OpenAPI / MCP / Function tool > Workflow / execution layer > Enterprise APIs / databases / SaaS systems > Result returned to Agent

Microsoft Foundry Agent Service supports external actions through OpenAPI tools, Azure Functions, and MCP servers. For an existing REST API, OpenAPI is particularly useful because the agent can understand the available operations and parameters from the API specification and invoke the appropriate operation.

For the orchestration layer, the choice depends on the workflow:

• Azure Logic Apps - a strong fit for business workflows involving multiple systems, approvals, connectors, schedules, and long-running processes. Microsoft now supports exposing Logic App workflows and connector actions directly as tools for Foundry agents.
• Azure Functions - useful when the action requires custom code, validation, transformations, or a relatively focused API operation. Functions can be exposed to Foundry agents through MCP, queues, or OpenAPI.
• Durable Functions - better when custom-code orchestration needs state, retries, checkpoints, parallel execution, or long-running processing.
• Power Automate - makes sense primarily when the workflow is centered on Microsoft 365/Power Platform and citizen-development scenarios. For an Azure-hosted backend integration architecture, normally look at Logic Apps first.

One design principle I'd strongly recommend is not letting the LLM perform unrestricted business operations directly. Give the agent narrowly defined tools such as CreateTicket, GetOrderStatus, or RequestRefund, and keep authorization, input validation, business rules, retries, and auditing in the API/workflow layer. Foundry also supports controlling tool invocation and recommends clearly defining when to use individual tools.

For sensitive or irreversible actions, such as financial transactions, deleting data, or changing production resources, consider adding a deterministic validation or human-approval step before execution.

So for a typical enterprise implementation, start with:

Foundry Agent → OpenAPI/MCP tools → Logic Apps or Azure Functions → backend APIs

and introduce Durable Functions or a custom orchestration service only when the workflow complexity requires it.

References:

Connect OpenAPI tools to Foundry agents

Integrate Azure Functions with Foundry Agents

Automate Foundry Agents with Logic Apps workflows

Durable Functions overview

Foundry Agent tool best practices

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.