Multi-agent orchestration in Microsoft Foundry is becoming less about drawing a visually impressive workflow and more about choosing an execution model that can survive production constraints. Microsoft Foundry Agent Service can host and scale agents, while Microsoft Agent Framework provides orchestration patterns such as sequential, concurrent, handoff, group chat, and manager-driven coordination. In Microsoft AI Agents, those choices should map to real task dependencies, approval needs, identity boundaries, and failure behavior rather than a generic preference for “multi-agent” architecture.
One current-status detail matters immediately in October 2026: Microsoft documentation states that Foundry’s visual Workflows feature is scheduled for retirement on December 1, 2026 and recommends Microsoft Agent Framework for new workflows. Existing visual workflows may still matter during migration, but new orchestration design should account for that direction now. A durable architecture separates business coordination logic from a short-lived authoring surface.
Choose an orchestration pattern that matches the dependency structure
Mixed patterns are often appropriate, but the transition between them should be explicit. A manager might dispatch two concurrent research agents, then hand the combined evidence to a sequential approval stage. Treat each transition as a contract with known inputs and completion criteria. Otherwise a visual or code-based workflow can become a maze of implicit control flow that is difficult to test and nearly impossible to explain during an incident.
Sequential orchestration is appropriate when each step depends on the previous result. Concurrent orchestration works when specialists can act independently. Handoff is useful when responsibility should move from one agent to another based on context. Group chat supports collaborative discussion, while a manager-driven pattern can dynamically assign work across specialized agents. The correct pattern follows the work, not the number of agents available.
Agentic AI orchestration is easier to reason about when each stage has a clear entry condition, exit condition, and owner. Mixing patterns without explicit boundaries can create loops where agents repeatedly delegate to each other or duplicate the same work.
Use Foundry Agent Service for runtime capabilities, not as a substitute for workflow design
Hosted agents are useful when the team needs custom orchestration libraries, proprietary logic, or framework-specific behavior while still using Foundry-managed hosting and identity. Prompt agents reduce operational code but give up some execution control. Choosing between them should follow requirements for runtime customization, portability, and operations rather than an assumption that one is inherently more “enterprise.”
Foundry Agent Service provides managed deployment, scaling, identity, model access, and tools across different agent types. Prompt agents reduce runtime code, while hosted agents allow custom frameworks and orchestration logic. These platform capabilities remove infrastructure work, but they do not decide how state should move or which agent has authority over a business action.
Agent tool reasoning should remain explicit in the design. A hosted multi-agent system still needs typed tool contracts, clear result schemas, and well-defined state transitions so platform autoscaling does not simply make an ambiguous process run faster.
Keep agent roles narrow enough that handoffs have meaning
A handoff only helps when the receiving agent has a distinct responsibility or capability. Creating several general-purpose agents with nearly identical prompts gives the system more places to disagree without adding useful specialization. Roles should reflect expertise, data access, tools, or decision authority that genuinely differs across the workflow.
Agent lifecycle management should version role definitions and handoff contracts together. Changing one specialist’s scope can affect every upstream agent that delegates to it, so multi-agent changes need integration testing rather than isolated prompt review.
Design shared state separately from conversation history
Conversation transcripts are convenient but make poor system-of-record state. Long histories grow expensive, contain unstructured assumptions, and are difficult to validate. Persist workflow state as explicit fields, artifacts, or records that agents can read and update according to defined rules. Use conversation context for reasoning, not as the only place where business state exists.
API security reinforces this separation. State updates should pass through services that enforce authorization and validation. An agent should not be able to alter business state merely by writing a sentence into shared context and hoping downstream agents interpret it correctly.
Give each agent an identity and permission scope that matches its job
Foundry supports enterprise identity capabilities, and hosted or prompt agents should not all inherit the same broad access simply because they participate in one workflow. A research agent may need read access to approved knowledge, while a remediation agent may need a narrowly scoped write operation. Identity should reflect the effect of the role.
Authentication and identity architecture should define whether an action runs under an agent identity, user-delegated authority, or another service identity. That distinction affects auditability, least privilege, and whether the resulting action represents the user’s intent or an autonomous system decision.
Use human-in-the-loop controls at irreversible or policy-sensitive boundaries
Microsoft Agent Framework supports human-in-the-loop interaction through approval-required tools and information requests. Approvals are most effective when tied to specific consequential actions rather than inserted randomly throughout the workflow. A human reviewer should see what action is proposed, which resource is affected, what evidence supports it, and what happens if the request is denied.
Agent access and approval boundaries should be designed before deployment. If every routine step requires approval, users will approve reflexively. If no step requires approval, the system may cross authority boundaries that were never intended to be autonomous.
Handle agent failure as a workflow state, not as an exception string
Compensation should be designed for workflows that perform multiple writes. If one agent creates a resource and a later agent fails, the system needs a documented decision: keep the partial result, roll it back, or pause for human review. Retrying the whole workflow can duplicate side effects unless each action is idempotent. Multi-agent reliability therefore depends on transaction-like thinking even when no single database transaction spans the work.
A multi-agent process needs rules for timeout, retry, fallback, cancellation, partial completion, and compensation. If a concurrent specialist fails, the coordinator may still be able to finish with reduced confidence. If a sequential dependency fails, later steps should normally stop. Handoff workflows need protection against endless back-and-forth when neither agent can resolve the task.
Agent analytics and monitoring should record which agent failed, which orchestration pattern was active, and what recovery action followed. A single “workflow failed” metric hides the information needed to improve the design.
Evaluate the whole orchestration, not only each individual agent
Use adversarial orchestration cases as well as happy paths. Test ambiguous handoffs, a specialist returning incomplete evidence, conflicting recommendations, an approval denial, tool unavailability, and a branch that exceeds its time budget. These scenarios reveal whether the coordinator understands workflow state or merely produces plausible text when every component behaves perfectly.
An agent can score well in isolation and still participate in a poor workflow. The manager may delegate the wrong tasks, concurrent branches may produce inconsistent assumptions, or the final synthesizer may discard important evidence. Evaluation sets should include end-to-end scenarios that measure routing, handoffs, tool use, state transitions, approval behavior, and final business outcomes.
Generative AI evaluation pipelines can compare orchestration patterns as well as models. That allows teams to answer whether a multi-agent design materially improves quality or whether a simpler single-agent workflow would be cheaper and easier to operate.
Production traces should correlate the initiating request with every agent invocation, tool call, handoff, approval, state write, and final result. Metrics should include branch latency, agent retries, handoff count, token usage, tool failures, and time spent waiting for human input. This makes the orchestration graph visible as an operational system instead of a collection of chat transcripts.
GenAI observability should also distinguish user-facing latency from background work. Concurrent agents can reduce elapsed time but increase total compute, while approvals can dominate latency even when model calls are fast.
Design for the post-Workflow migration path now
Do not wait until the retirement window to decide how ownership transfers. The team that originally built a visual workflow may not be the team maintaining Agent Framework code after migration. Define the receiving service owner, support model, deployment repository, and incident path before cutover. A technically correct migration can still fail operationally if nobody is accountable for the new runtime, its package dependencies, and the monitoring that replaces the old surface.
Migration work should begin with an inventory of active Foundry visual workflows, their owners, invocation volume, dependencies, and business criticality. Prioritize workflows that are difficult to reproduce or have many external integrations. A low-value experimental graph can often be retired, while a regulated production workflow needs a planned rebuild, parallel validation period, and clear cutover criteria before the December retirement date.
Because the current Foundry visual Workflows feature has a published retirement date, teams should inventory existing workflow assets, identify orchestration semantics that must survive migration, and avoid coupling business rules to visual nodes that have no equivalent representation elsewhere. Microsoft Agent Framework is the documented direction for new orchestration and should be evaluated against the needs of each existing workflow.
Governance standards can make that migration auditable by defining owners, approved frameworks, testing gates, and retirement milestones. Microsoft provides capable agent runtime and orchestration primitives, but the enduring architecture is the set of boundaries around roles, state, identity, approvals, failure, and evaluation—not the visual surface used to connect the boxes.
