{"id":11535,"date":"2026-10-07T00:10:05","date_gmt":"2026-10-07T00:10:05","guid":{"rendered":"https:\/\/www.prepaway.com\/certification\/microsoft-ai-103-building-multi-agent-workflows-on-azure\/"},"modified":"2026-10-07T00:10:05","modified_gmt":"2026-10-07T00:10:05","slug":"microsoft-ai-103-building-multi-agent-workflows-on-azure","status":"publish","type":"post","link":"https:\/\/www.prepaway.com\/certification\/microsoft-ai-103-building-multi-agent-workflows-on-azure\/","title":{"rendered":"Microsoft AI-103: Building Multi-Agent Workflows on Azure"},"content":{"rendered":"

Multi-agent systems are useful when a problem genuinely benefits from specialized responsibilities, separate tool access, or explicit handoffs. They are not automatically better than a single agent. Every additional agent creates another source of latency, another state boundary, another identity to govern, and another place where the system can misunderstand what should happen next.<\/p>\n

That tradeoff is especially important in Azure right now because Microsoft’s orchestration stack is changing. The older visual Workflows experience in Microsoft Foundry is scheduled for retirement on December 1, 2026. Microsoft’s current direction for new development is Microsoft Agent Framework, which provides agents plus functional and graph-based workflows. New systems should therefore avoid building a long-lived dependency on a workflow surface that is approaching retirement.<\/p>\n

The current AI-103<\/a> scope reflects this production emphasis: it includes orchestrated multi-agent solutions, workflows, tool integration, safeguards, evaluation, and monitoring. Those topics belong together inside Azure AI engineering<\/a> because orchestration is where model behavior becomes an operational process.<\/p>\n

Start by proving that more than one agent is necessary<\/h3>\n

A task should not be split into multiple agents just because the user request contains several steps. If the steps are deterministic, ordinary application functions or a workflow may be simpler. If one agent can call the required tools and maintain the necessary context, adding more agents can create coordination overhead without improving the result.<\/p>\n

Multi-agent design is strongest when roles have genuinely different context, permissions, models, or evaluation criteria. A research agent may search and summarize evidence. A policy agent may validate whether a proposed action complies with rules. An execution agent may have tightly restricted write permissions. The separation is meaningful because each role has a different trust boundary.<\/p>\n

This matches the principle in multi-agent coordination<\/a>. Decomposition is valuable only when the coordination model is clearer than the monolith it replaces.<\/p>\n

Use workflows when execution order matters<\/h3>\n

Microsoft Agent Framework distinguishes an agent from a workflow. An agent is appropriate for open-ended reasoning, tool selection, or conversation. A workflow is appropriate when the process has known steps and the application needs explicit control over execution order. Most production multi-agent systems need both.<\/p>\n

For example, a proposal-review process may allow a research agent to gather evidence, then require a deterministic validation function, then call a risk agent, then pause for approval before an execution tool can run. Letting one free-form agent decide whether those checks are optional would weaken the business process.<\/p>\n

The lesson from agent workflows<\/a> is to identify which decisions genuinely require model judgment and which should remain code. Workflow structure should preserve business invariants even when model outputs vary.<\/p>\n

Design handoffs as contracts, not conversations<\/h3>\n

An agent handoff should define what information is passed, what format is expected, what the receiving agent is allowed to do, and how errors are returned. Free-form prose can be appropriate for some collaborative tasks, but it is a poor substitute for a contract when the next step depends on precise fields.<\/p>\n

Use structured messages for identifiers, status, confidence, citations, requested action, and tool results where possible. Validate schemas at boundaries. A receiving agent should not have to infer whether a missing field means \u201cnot applicable,\u201d \u201cnot found,\u201d or \u201cthe previous agent forgot.\u201d<\/p>\n

Contracts also make evaluation easier. The team can measure whether the research agent supplied complete evidence, whether the reviewer made the correct decision from that evidence, and whether the execution agent received a valid approved action.<\/p>\n

State ownership has to be explicit<\/h3>\n

Multi-agent systems can accumulate several kinds of state: conversation history, workflow progress, user context, retrieved evidence, tool results, agent memory, and external business state. If every agent writes to the same unstructured memory, stale or irrelevant context can leak between steps.<\/p>\n

Define the owner and lifetime of each state category. Workflow state may persist only for one run. User preferences may persist across sessions. Retrieved documents may need freshness checks. Tool results may be immutable evidence. Long-term memory may require explicit consent and data-governance rules.<\/p>\n

Keep authoritative business state outside the language model. A model can reason about an order status, but the system of record should remain the source of truth. The workflow should re-read critical state before irreversible actions instead of trusting an old conversational summary.<\/p>\n

Identity should follow the agent’s responsibility<\/h3>\n

If every agent shares the same broad project credential, role separation exists only in prompts. Stronger systems align identity with responsibility. A read-only research agent can receive read access. An execution agent can receive narrow write access. A supervisory agent may have no direct business-system access at all and only control the workflow.<\/p>\n

The article on agent identity<\/a> explains the difference between project managed identity, agent-specific identity, and user-delegated access. Multi-agent systems make that distinction more important because agents can become independent callers of services and of one another.<\/p>\n

Authentication does not replace authorization. Agent-to-agent communication should still restrict which operations a caller can request. A trusted identity should not imply unlimited capability.<\/p>\n

Failure handling must include the whole graph<\/h3>\n

A single-agent failure is usually visible at one boundary. Multi-agent workflows can fail partially. The researcher may succeed, the reviewer may time out, and the execution agent may never run. Retrying the whole workflow could duplicate earlier actions or produce a different result.<\/p>\n

Design idempotent steps where possible. Persist checkpoints before side effects. Distinguish retriable service failures from business rejections. Set maximum retry counts. Use compensation logic for actions that can be reversed and manual escalation for those that cannot.<\/p>\n

The workflow should also detect loops. Agents that repeatedly hand work back to one another can consume tokens and time without making progress. Track hop count, repeated state, and repeated tool calls so the orchestrator can stop or escalate.<\/p>\n

Human approval should be a workflow state<\/h3>\n

Human-in-the-loop control is strongest when approval is an explicit state transition, not a suggestion buried in a prompt. The workflow should know that it is waiting, which action is pending, what evidence the reviewer needs, who can approve it, and what happens if the approval expires.<\/p>\n

This is particularly important for high-impact actions such as changing access, sending external communications, modifying production infrastructure, or committing financial transactions. The model can prepare a proposed action, but the application should enforce the approval gate before the execution tool receives authority.<\/p>\n

That design also improves auditability because the system can distinguish model recommendation, human decision, and final machine action.<\/p>\n

Observe each agent and the workflow as separate layers<\/h3>\n

End-to-end success is the top metric, but it is not enough for diagnosis. Capture latency, token usage, tool calls, errors, evaluation scores, and state transitions by agent. A workflow that takes thirty seconds may contain one slow agent or several small delays; the remedy depends on knowing which.<\/p>\n

Quality metrics should also be role-specific. A research agent can be measured on evidence coverage and citation accuracy. A reviewer can be measured on policy decisions. An execution agent can be measured on valid tool invocation and side-effect correctness.<\/p>\n

This makes multi-agent evaluation less mysterious. The team can identify whether a regression belongs to the model, prompt, retrieval layer, tool, orchestration graph, or permission boundary.<\/p>\n

Use Agent Framework as the durable orchestration direction<\/h3>\n

Because Foundry’s older visual Workflows are scheduled to retire, new Azure multi-agent solutions should be designed around Microsoft Agent Framework or another supported orchestration layer rather than treating the retiring experience as the long-term control plane. Existing visual workflows need a migration plan before the retirement date.<\/p>\n

Agent Framework supports specialized agents, functions, middleware, telemetry, and explicit workflows. That makes it a better place to express deterministic routing, parallel branches, approvals, and agent handoffs while still allowing agents to reason inside controlled nodes.<\/p>\n

The architecture should remain portable at the conceptual level. Roles, handoff contracts, state, identities, evaluation, and approval rules are more durable than any one SDK. Teams following Azure AI developer certification<\/a> should learn those boundaries first. A multi-agent system is production-ready when its collaboration is understandable, permissioned, observable, and recoverable\u2014not merely when several agents can talk to each other.<\/p>\n

Cost control is another reason to keep the orchestration graph explicit. A single user request can fan out into several agents, each with its own model call, retrieval step, and tool invocation. Parallel branches can reduce wall-clock time while multiplying token consumption. Record per-node cost and set execution budgets so an ambiguous request cannot trigger an unbounded chain of agent work. A workflow that knows its own budget can stop, summarize partial progress, or request clarification instead of silently spending more resources.<\/p>","protected":false},"excerpt":{"rendered":"

Multi-agent systems are useful when a problem genuinely benefits from specialized responsibilities, separate tool access, or explicit handoffs. They are not automatically better than a single agent. Every additional agent creates another source of latency, another state boundary, another identity to govern, and another place where the system can misunderstand what should happen next. That tradeoff is especially important in Azure right now because Microsoft’s orchestration stack is changing. The older visual Workflows experience in Microsoft Foundry is scheduled for retirement on December 1, 2026. Microsoft’s current direction for new…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-11535","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t