Azure Logic Apps has become one of the most practical places to run AI agents in an enterprise, for a simple reason: the agent sits next to more than 1,400 connectors, inside a runtime that already does retries, run history and identity. Over 2025 and 2026 Microsoft added a lot around it – the agent loop, AI and RAG connectors, MCP tools, code interpreters, managed knowledge and Foundry agents. This guide sorts those capabilities into a design approach for integration architects, including the controls you need before an agent touches a system of record.

The capabilities at a glance

• Agent loop – an action type in Logic Apps Standard that combines a model, tools (workflow actions and connectors) and knowledge, and iterates until the task is done. It became generally available together with the AI and RAG connectors in December 2025.
• MCP and models – since November 2025 (preview) agent workflows can use MCP servers and tools, bring their own model (including privately hosted models), apply document-level access control to knowledge sources such as Azure AI Search, and publish conversational agents to Microsoft Teams.
• Code interpreters – since May 2026 (preview) agents can generate and run Python, JavaScript, C# and PowerShell in Hyper-V isolated sandboxes, backed by an Azure Container Apps session pool.
• Knowledge as a Service – since June 2026 (preview) you can upload documents into a workflow, have them ingested, chunked and vectorized automatically, and use retrieval as a built-in workflow step.
• Azure Logic Apps Automation – Microsoft’s newer automation environment, where an agent is a workflow action with native or Foundry-backed agents, knowledge bases, sandboxes and Foundry Hosted Agents.

Agent or deterministic workflow?

The first design decision is still the most important. Use an agent where inputs are unstructured or unpredictable and some reasoning is required; use a deterministic workflow where inputs are structured and behaviour must be repeatable, cheap and fast. In integration landscapes the best results come from combining them: a deterministic workflow handles the trigger, validation, writes and error handling, and an agent handles the one step that needs interpretation – classifying an email, extracting fields from a document or deciding which of a few routes applies.

Native agents or Foundry agents

In Logic Apps Automation you choose between a native agent, driven by the built-in agent loop, and a Microsoft Foundry agent driven by Foundry Agent Service:

For integration scenarios I default to native agents, because per-iteration visibility in run history is what operations needs when someone asks why an agent did something.

Code interpreter or sandbox

Agents are poor at arithmetic and data reshaping; code is good at it. Logic Apps Automation offers two execution options:

• Built-in code interpreter – the model writes JavaScript that runs in an isolated process inside your app’s worker. It has its own limited memory, cannot access the host memory, file system or network, and has a short timeout per execution. It is meant for calculations, filtering and reshaping JSON, regular-expression extraction and formatting – not for heavy compute.
• Sandboxes (preview) – an isolated micro virtual machine for Managed Agents that need other runtimes, a file system, cloned repositories or network access.

A useful pattern from Microsoft’s documentation: combine tools as Query_Database → code interpreter (transform) → HTTP_Post. The code interpreter has no network access by design, so any external call happens through a governed connector action, not from generated code.

Grounding with knowledge

Knowledge determines whether an agent gives a correct answer or a confident wrong one. Options range from the managed Knowledge as a Service capability and knowledge bases in Logic Apps Automation to your own Azure AI Search index fed by RAG connectors. Whatever you choose:

• Use curated, owned sources with a clear refresh process, not every SharePoint site the agent can reach.
• Apply document-level access control so an agent cannot surface documents the caller may not see.
• Instruct the agent to prefer tool and knowledge results over its own background knowledge.

Tool design: where most agent quality comes from

1. Keep toolsets small – Microsoft’s guidance is fewer than 10 tools rather than 20; large toolsets confuse models.
2. Verb-centric names such as find_order or get_current_time.
3. Descriptions matter more than names – say what the tool does, when to call it and what each parameter means.
4. Pass arguments explicitly – inside a tool, read the model’s arguments with @agentParameters('orderId') and validate them before use.
5. Use structured outputs in downstream actions instead of parsing the final message text.

Guardrails before production

• Iteration and time limits – set a loop count and timeout per agent so a runaway loop cannot burn budget.
• Secure inputs and outputs – hide sensitive values in run history with the secure input and output settings.
• Human approval – route irreversible actions through an approval step, for example an adaptive card in Teams or Outlook.
• Caller identity – protect conversational agents with Easy Auth and Entra ID; see Logic Apps Standard connections and Easy Auth.
• Governed tools – expose MCP tools through API Management and register them in API Center; see MCP servers in Azure.

Observability: answering “why did the agent do that?”

For native agents, run history shows each iteration as its own entry, and the chat history shows every user message, every tool call with its arguments, each tool’s inputs and outputs, the duration per step and the final answer. Make that part of your support process: when a business user reports a wrong outcome, the first step is to open the agent’s run and read the tool calls, not to tweak the prompt.

Where Logic Apps fits next to other agent platforms

Logic Apps is strongest when the agent’s work is mostly orchestration across enterprise systems – ERP, CRM, databases and APIs – with retries, audit trails and governance built in. Foundry is the better home for agents that are primarily conversational or research-heavy. If your integration estate runs on Boomi, the same design principles apply to the Boomi Agent step; see Boomi AI agents in production.

Sources

• Azure Logic Apps Automation documentation: Agents
• General availability of AI and RAG connectors in Logic Apps (Standard)
• Azure update: new agent loop capabilities in Azure Logic Apps (preview)
• Azure update: Knowledge as a Service with Azure Logic Apps (preview)
• InfoQ: Azure Logic Apps adds sandboxed code interpreters to agent workflows