Every AI kickoff I join seems to open the same way. “We want AI.” For what? “We don’t know yet.” When? “Right now.” It sounds like a joke, but it is the most common starting point I see for AI in enterprise integration, and it is exactly how teams end up with agents nobody owns, MCP tools nobody can find, and token bills nobody predicted.
Most of the AI integration problems I run into are not model problems. They are architecture problems. This post collects the six anti-patterns I see most often when teams add AI to Azure integration, the one principle that prevents most of them, and the five patterns I reach for instead.
Start with the capability, not the tool
The question “How do I automate this workflow?” is fine for a one-off integration. It focuses on steps, connectors and retries. With AI in the picture, I ask a different one: “How do I design a governed business capability that people, systems, events and AI-assisted processes can all use?” That question forces ownership, decision rights, identity and audit onto the table before anyone opens the designer.
Before picking any Azure service, I want answers to six questions:
- What business outcome is needed, in business terms?
- What decisions are involved, and are they rules or judgement?
- What systems are touched, and what is the blast radius of a wrong action?
- What risks exist: financial, regulatory, reputational?
- What needs human approval?
- What must be observable and auditable?
If you cannot answer one of them, that is your first design task. I worked with a team that wanted an agent in their invoice exception process. We spent the first design session on these questions instead of the agent, and found that nobody actually owned the exception decision. Adding an agent would have automated a broken accountability model.
The principle: choose the least autonomous pattern that works
Using an agent where a workflow would do is like using a flamethrower to light a candle. It works, but at what cost? Autonomy is not a maturity level. It is a design trade-off. Every step up the ladder buys flexibility and pays for it in governance overhead, observability, cost control and risk.
At every design decision, ask one question: is there a lower-autonomy pattern that solves this? If yes, use it. Anthropic’s guidance on building effective agents makes the same point: use the simplest approach that works and add agentic behaviour only when the flexibility justifies the latency, cost and complexity. Most processes need a workflow, not an agent.
Six anti-patterns, and what to do instead
Discipline is part of architecture. I have seen every one of these in real engagements.
1. Using AI to replace deterministic business rules
If you trust a rule, keep it as a rule. A model adds ambiguity, audit burden and cost that an IF-statement does not. Instead: keep the workflow deterministic and let AI enrich exactly one step where judgement genuinely helps, such as classifying, extracting or summarising. Gate its output with a confidence threshold before anything acts on it.
2. Letting agents directly mutate critical systems
An agent with write access to your ERP and no gate in between is an incident waiting for a date. Instead: run the agent loop inside a Logic Apps workflow. The agent reasons (think, act, observe) with a scoped tool allowlist, often read-only. When it has a recommendation, control returns to the workflow boundary, where a human approval or a deterministic gate decides before the workflow writes to the system of record.
3. Exposing every API as an MCP tool
MCP makes it easy to turn Logic Apps workflows and REST APIs into tools that AI clients can discover. That ease is the risk. A catalog of hundreds of loosely scoped tools is a security surface and a confusion engine for the agent. Instead: treat the tool catalog like a product catalog, curated rather than open enrolment. Only stable, owned, well-scoped business capabilities belong in it.
4. Treating workflow internals as business capabilities
“Map customer XML to canonical” is a step, not a capability. Publishing internal steps creates coupling nobody intended and breaks the moment you refactor. Instead: define the capability contract first (“check order status”, “raise credit note”) and publish that. The contract is what will still be reused in five years; the connector behind it might change.
5. Ignoring ownership and lifecycle of MCP tools
An unowned tool is a future incident. When something goes wrong at 2 a.m., “who owns this tool?” should not be a research project. Instead: register every tool in Azure API Center as the private registry, with a named owner, a lifecycle stage and a governed access path through API Management. No owner, no tool. This is also your best defence against Shadow AI.
6. Adding governance only after go-live
Retrofitting governance is significantly harder and more expensive than designing it in. Instead: route every AI-enabled call to a business capability through a policy-enforced gateway from day one. API Management as an AI gateway gives you authentication at the edge, rate limits, token budgets per model or consumer, content safety and telemetry, depending on tier and configuration. If you are carving exceptions before production, governance is already eroding.
The five patterns at a glance
Each anti-pattern above has a pattern that answers it. This is the decision table I use in design reviews.
| Pattern | Use when | Core idea | Key controls |
|---|---|---|---|
| 1. Workflow with AI enrichment | Steps are known; auditability and predictable cost matter | Logic Apps drives the flow; AI enriches one step | Confidence threshold, approval before high-impact actions, dead-letter queue |
| 2. Agent loop in a governed process | The path depends on what the process discovers | Agent reasons inside the workflow boundary | Tool allowlist, scoped identity, approvals at the boundary, full run history |
| 3. MCP-powered enterprise tools | A capability should be reusable and discoverable by AI clients | Workflows and APIs exposed as curated MCP tools | API Center registry, named owner and lifecycle per tool |
| 4. Governed API and tool gateway | AI callers need controlled, auditable, cost-capped access | API Management as the AI gateway | Auth at the edge, rate limits, token budgets, content safety, telemetry |
| 5. Modernisation into reusable capabilities | A BizTalk, SSIS or point-to-point estate exists | Inventory, decompose, rebuild as capabilities | Owner before rebuild, contract first, retire what nobody owns |
Pattern 5 carries its own anti-pattern: one-to-one migration is not modernisation. Replicating a BizTalk orchestration step for step in Logic Apps gives you a newer runtime with exactly the same architectural debt. And don’t migrate what you don’t own; I have seen teams spend months rebuilding processes nobody had used in two years.
Patterns applied
| Scenario | Pattern | What happens |
|---|---|---|
| Contract review | 2 | The agent reasons over clauses and drafts redlines with read-only tools; the contract system is updated only after a human approves. |
| Order exception handling | 1 + 4 | One AI step synthesises multi-system context and recommends an action. It proposes, never auto-executes. |
| Enterprise tool catalog | 3 + 4 | Teams publish capabilities through API Center; AI clients discover governed tools, each with a named owner. |
| Legacy modernisation | 5 | Inventory, decompose, rebuild as Logic Apps; expose selected capabilities and register them. |
A design-review checklist: every risk gets a home
The enterprise reaction to any AI demo is “Impressive. Now show me how to control it.” People accept AI when they can see, control and audit what it does. For every automation candidate, I walk these seven risks and ask where the control lives in our design. If nobody can answer, the gap goes on the backlog before go-live.
| Risk | Control | Where it lives |
|---|---|---|
| Wrong AI recommendation | Confidence threshold + human approval | Logic Apps + Teams |
| Uncontrolled tool invocation | Tool allowlists + scoped identity | Agent loop config + API Center |
| Excessive cost / token use | Rate limits, token budgets, semantic cache | API Management AI gateway |
| Poor traceability | Run history, correlation IDs, telemetry | Logic Apps + Log Analytics |
| Tool sprawl (Shadow AI) | Central registry, ownership, lifecycle | Azure API Center |
| Data leakage to the model | ACL-trimmed retrieval, content filtering, redaction | AI Search + API Management + Purview |
| Prompt / tool injection | Allowlists, confirmation gates, least privilege, audit logging | Agent loop + gateway content safety + design |
Underneath all of it sits a shared plane: Entra ID and managed identities so every call has a verified caller, end-to-end correlation so every action is traceable, and private networking so boundaries are enforced by default. Skip one pillar and the weakest link defines your architecture.
A note on availability. Capabilities such as agent loops in Logic Apps, MCP support, OBO identity passthrough and the AI gateway policies vary by SKU, tier and region and are evolving quickly. Check Microsoft Learn before you commit a design to a specific feature. The patterns hold regardless of where each feature sits today.
My take: three lines
- Start with the business capability.
- Choose the right architecture pattern, the least autonomous one that works.
- Govern the execution path from the first design session, not after go-live.
The future is not AI replacing workflows. It is AI, workflows, tools, APIs and humans working together under governance. When every capability has an owner, every pattern has a reason and every risk has a named control, you stop lying awake wondering what the agent did overnight. Principles and patterns don’t remove the work; they remove the worry.
Which of these anti-patterns have you run into? I’d like to hear the ones I missed.
Further reading
- Microsoft Learn: Agent workflows in Azure Logic Apps
- Microsoft Learn: AI gateway capabilities in Azure API Management
- Microsoft Learn: Azure API Center overview
- Anthropic: Building effective agents
