Part 22 · One Agent, Five Platforms

Part 21 put the nine tools on Azure: Logic Apps, Functions and API Management, with one gateway in front. This part builds the agent on top. Microsoft shops already have identity in Entra and approvers in Teams and Outlook, so the question is: what does the agent build look like when identity and Office come for free?

It's documentation-only, like the other builds. Everything below comes from Microsoft Learn as I read it on 10 November 2026, linked in the text. It covers Foundry Agent Service, agent identity, the AI gateway, the Teams approval, observability, and Azure's provisional scores.

The invoice agent on Azure, drawn on the reference architecture

How the pieces map

Using the five layers from Part 3:

  • Channel: the AP exception queue, and approvers in Teams.
  • Agent: a prompt agent in Foundry Agent Service, with its own Entra agent identity.
  • Tools: the three MCP servers from Part 21, behind API Management.
  • Process layer: process APIs with the rules and the approval_id check.
  • System of record: the ERP, reached only through process APIs.

1. The agent in Foundry Agent Service

The Agent Service overview describes two main kinds of agent:

  • Prompt agents: instructions, a model and tools, with "no code or infrastructure to manage".
  • Hosted agents: code-based agents, for example built with Agent Framework or LangGraph, run as containers with a managed endpoint and their own Entra identity.

The invoice agent is a prompt agent. Its job is narrow: investigate one exception, explain it and propose a fix. Following Part 2, the process layer runs the three-way match and duplicate check first, and only real exceptions reach the agent.

Two settings on the MCP tool matter for this design:

  • allowed_tools limits which tools an agent can use. That's how the stages from Part 9 work here: stage 1 lists only the read tools. The page warns that an empty list allows all tools, not none.
  • require_approval defaults to always. When the model wants to call a tool, the response returns an mcp_approval_request, and your application answers with an mcp_approval_response. That's an approval of the tool call, made by your app in the conversation. It isn't the business approval from Part 6, which has to be checkable by the process API that posts. I'd use both: require_approval on the two write tools, and the approval_id check behind them.

The overview also says versions are snapshotted automatically, with rollback to any earlier version, and a published agent gets a stable endpoint.

2. Agent identity with Entra

This is Azure's strongest area. The agent identity page says:

  • Each new agent gets its own agent identity in Microsoft Entra, created from an agent identity blueprint. Older agents share a project identity and don't get that separation.
  • No secret or certificate is stored. Foundry uses a federated credential, and the page says the project and the agent code "never hold the credential".
  • For tool calls, Agent Service exchanges tokens for one target audience at a time. A new identity starts with no permissions. You grant the least privilege it needs.
  • Agent identities show up in the Entra admin center, with sign-in and audit logs you can filter by agent.

Conditional Access for agents adds policies on top, for example blocking agents flagged as high risk. Three limits to know:

  • It needs a Microsoft Agent 365 licence (with Entra P1 or Microsoft 365 E3) or Microsoft 365 E7.
  • Agents that use API keys bypass Entra, so Conditional Access doesn't apply to them. Part 21's key-based options for Logic Apps and Functions would skip it.
  • A policy on the agent identity doesn't cover calls the agent makes on behalf of a user. Those need separate policies.

For this agent, that means: Entra tokens, not keys, all the way to the tools, and API Management validating them.

3. API Management as the AI gateway

Part 21 used API Management for tools. The same gateway can sit in front of the model. The AI gateway overview lists:

  • Token limits per caller with llm-token-limit.
  • Content safety checks on prompts.
  • Token metrics to Azure Monitor with llm-emit-token-metric, with custom dimensions.
  • Load balancing and circuit breakers across model backends.

Token metrics with an "invoice type" dimension would give the cost per exception type that Part 5's cost criterion asks for. Foundry's own content filters, which the overview says help mitigate prompt injection, sit on top of that.

4. The approval in Teams

The Microsoft Teams connector works in Logic Apps, and its Post adaptive card and wait for a response action "will pause the flow until any user responds". That's the approval step.

Part 21 found one constraint that shapes this design: Foundry MCP calls time out after 100 seconds. So the flow is in two parts:

  1. The request_approval tool starts a separate Logic Apps approval workflow and returns straight away with a pending status.
  2. That workflow posts the card to the approver in Teams and waits. When they answer, it records the decision and the approver as an approval_id.
  3. Later, post_invoice_adjustment sends the approval_id, and the process API checks it. No valid approval, APPROVAL_MISSING.

The connector page lists limits worth knowing: cards over about 28 KB fail, the Flow bot is throttled to 25 calls per 300 seconds per connection, and the Workflows app must be allowed in the Teams admin center. The Flow bot isn't supported in government cloud tenants.

Outlook is the other option, with the Office 365 Outlook connector's Send approval email action. But its known issues say the responder's user ID can come back empty in some cases. For an audit trail of who approved, I'd use Teams.

5. Observability and evaluation

Tracing. The tracing page says tracing is generally available for prompt and hosted agents, uses OpenTelemetry conventions and stores traces in Application Insights (Azure Monitor). It captures inputs and outputs, tool calls and results, token use and latency. The page warns that traces can capture sensitive data, so treat them like production data: mask supplier bank details.

Evaluation. The evaluation how-to runs an agent against your own JSONL dataset and scores every response. The agent evaluators include Tool Call Accuracy, Tool Selection and Tool Input Accuracy. Some others, such as Task Adherence, are in preview. The page also suggests evaluation as a quality gate in a GitHub Actions pipeline. That's the closest any platform has come to running the 30-invoice golden set from Part 10 as a built-in step.

Provisional scores

Documentation-only scores are capped at 4. Blank means no evidence in what I read, as Part 5 requires.

  1. Tool exposure (MCP): 4. Three hosts plus API Management, with clear schema guidance. How errors reach the agent is still unconfirmed.
  2. Agent build experience: blank.
  3. Multi-agent and A2A: 4. The A2A tool is generally available on protocol 1.0, and Foundry agents can expose an A2A endpoint. Incoming A2A is text-only with no streaming.
  4. Human-in-the-loop: 3. Tool-call approval in Agent Service and a Teams wait action in Logic Apps. The business approval and its audit are still mine to build, and the 100-second limit forces an asynchronous design.
  5. Identity and access: 4. A separate Entra identity per agent, no stored credential, least privilege per audience, and Conditional Access. Conditional Access needs extra licensing.
  6. Governance and gateway: 4. Token limits, content safety, per-agent tool allow-lists and Entra policies.
  7. Observability: 4. Generally available OpenTelemetry tracing in Application Insights, including tool calls and tokens.
  8. Evaluation support: 4. Your own dataset, built-in agent and tool evaluators, and a pipeline gate.
  9. Deployment and CI/CD: 3. Automatic versions, rollback and published endpoints. Promotion across environments wasn't covered in what I read.
  10. Cost transparency: 3. Token metrics with custom dimensions and token use in traces. Cost per outcome is still something you assemble yourself.
  11. Data residency and on-prem: 3. Virtual network isolation and bring-your-own storage are documented for data residency, and API Management has a self-hosted gateway. I didn't check where model processing happens for each deployment type.

That's ten scores, averaging 3.6. MuleSoft averaged 3.3 across ten, Boomi 2.8 across ten and SAP 3.0 across eight. Part of Azure's lead is that Microsoft documents more, so there's more evidence to score. That's a fair thing to reward, but it isn't the same as a hands-on result.

What this sets up

Azure's advantage is identity: of the four platforms so far, it has the most fully documented agent identity, with a directory identity per agent, no stored secret and the same kind of access policies as people. The cost is assembly. The approval, the audit trail and the cost per outcome are built from parts, not provided.

Part 23 compares agent identity on Azure and AWS in one picture.

Azure users: Logic Apps or Functions for agent tools?

This series describes a reference build on a fictional company. This part is based only on Microsoft Learn as of 10 November 2026; no hands-on build has been run yet. Preview features may change. Views are my own. Check current docs before you build.