Agentic AI and Multi-Agent Orchestration on Microsoft Azure
Agents on Microsoft Foundry, with Entra identity behind them
Azure's advantage here is not the agent runtime, it is what sits underneath it. If your organisation already runs Microsoft Entra ID, the hardest part of agentic governance (giving an agent its own identity, applying conditional access to it, and answering who authorised what) has somewhere to live rather than needing to be invented. Foundry Agent Service runs the agents, Microsoft Agent Framework is the orchestration engine underneath, and Copilot Studio is the right answer whenever the people operating the agent are not developers.
Why Azure
When this is the right platform.
- Agent identity has a real home. Microsoft Entra Agent ID gives each agent its own identity construct, which lets existing conditional access and governance thinking extend to non-human actors.
- Microsoft Agent Framework is the current, supported orchestration engine and consolidates what were previously two competing paths in Semantic Kernel and AutoGen, with a documented migration route from both.
- Copilot Studio covers the low-code case properly. Where a business team rather than a developer will own the agent, that is a genuine capability rather than a compromise.
- Hosted agents run your own container or source with a managed endpoint, autoscaling and a dedicated identity, so you are not choosing between platform convenience and owning the code.
- Bring-your-own resources for retrieval and conversation state matter where data residency is contractual rather than preferential.
Where it is less suited
We would rather say this now than after a migration.
- Multi-agent workflows in Foundry Agent Service was announced as public preview, so we would not put an irreversible business process behind that specific surface yet. Keeping deterministic control flow in your own Agent Framework code avoids the dependency.
- The enterprise agent governance and security features are licensed, and the product surface in this area is actively converging. Which capability sits behind which licence needs confirming against your tenant at design time rather than assuming from documentation.
- Semantic Kernel and AutoGen are supported but are no longer where new orchestration work should start, so an existing codebase in either carries a migration ahead of it even though nothing breaks today.
- Copilot Studio is genuinely easier and genuinely more constrained. Teams that start there because it is quick sometimes hit a boundary that means rebuilding in Foundry, so the build-versus-configure decision deserves real thought per agent.
- Bring-your-own retrieval and state solves residency and gives you more to operate. It is the right call when data location is contractual and unnecessary overhead when it is only a preference.
- Naming in this area has changed repeatedly and vendor documentation does not always agree with itself. We verify against your deployed tenant and record the date, rather than trusting an article.
Business outcomes
What Azure delivers here.
- Agents with Entra identities
- Each agent holds its own identity rather than sharing an application secret, so authorisation decisions and audit entries resolve to a specific actor.Agreed measure: Whether every agent action in the trace resolves to a distinct agent identity and, where applicable, an initiating user.
- Orchestration you own
- Workflow logic written against Microsoft Agent Framework and held in your source control, with the Foundry runtime as the hosting layer rather than the place your design lives.Agreed measure: Proportion of orchestration logic held in version control rather than configured only in a portal.
- Tools exposed once, governed centrally
- Existing REST APIs fronted and governed for agent consumption, and custom tools hosted as services, rather than credentials copied into agent configuration.Agreed measure: Number of tools reachable per agent, and how many bypass the governed gateway.
- Full traces, not just answers
- Every model call, tool invocation and handoff captured through Application Insights integration, which is what makes a wrong outcome debuggable rather than mysterious.Agreed measure: Share of production runs with a complete retrievable trace.
- The low-code path used where it fits
- Copilot Studio for agents a business team will own and operate, with custom Foundry work reserved for what genuinely needs it.Agreed measure: Build-versus-configure decision recorded per agent, with the reasoning kept.
- Network isolation where it is required
- Private networking for prompt agents and a bring-your-own virtual network option for hosted agents, so agent traffic need not traverse the public internet.Agreed measure: Whether agent and tool traffic stays inside your network boundary, verified at handover.
Common client problems
What we usually hear first.
Should we use Copilot Studio or build in Foundry?
Decide it on who will own the agent in a year, not on capability. If a business team will maintain it and it works with packaged connectors and Microsoft 365 surfaces, Copilot Studio is the right answer and building custom is a false economy. If it needs bespoke tools, non-Microsoft systems, tight cost control or its own release pipeline, Foundry is warranted. We record the decision per agent because the wrong one is expensive in both directions.
We already built on Semantic Kernel. Do we have to move?
Not urgently. Version 1.x remains supported, so there is no fire. But Microsoft positions Agent Framework as its successor and consolidated the AutoGen multi-agent abstractions into it, so new orchestration work should start there rather than extending a Semantic Kernel codebase. There is a documented migration path. We would sequence a move around a release you were making anyway rather than as a project of its own.
How do we give an agent access to our line-of-business APIs safely?
Through one governed layer rather than by handing credentials to the agent. Existing REST APIs are fronted and exposed as agent-consumable tools with authentication, throttling and per-consumer quota applied there, and custom tools are hosted as services with their own scoped identity. That gives you one place to see what agents are calling and one place to revoke it. Note that some of the tooling in this space is preview, and we will tell you which parts.
Can we run multi-agent workflows in Foundry today?
Multi-agent workflows are authorable in Foundry Agent Service, visually or in YAML, and it was announced as public preview rather than generally available, so we would not put an irreversible business process behind it yet. What we do instead for production is keep the deterministic control flow in code you own with Agent Framework, which gives you the same topology without depending on a preview surface for the parts that must not fail.
Our security team wants to apply conditional access to agents.
That is the right instinct and Azure is the platform where it is most achievable, because agent identity is a first-class construct rather than a shared application registration. Be aware the enterprise agent governance features are licensed and the product surface in this area is actively converging, so exactly which capability sits behind which licence is worth confirming at design time rather than assuming. We check it against your tenant rather than a marketing page.
Where does conversation state actually live?
Either platform-managed or in resources you provide, and the answer matters more than it sounds. Foundry supports bringing your own store for conversation state and retrieval, which is what you need when data residency is a contractual obligation rather than a preference. The trade is more to operate. We make the call explicitly during design and record it, because discovering it after go-live means a migration.
How we deliver
Our Azure delivery approach.
- 01
Assessment and advisory
The Azure assessment leans on what is already in your tenant, because identity and permissions decide far more about agent feasibility than model choice does.
- Entra readiness for non-human actors. Whether your identity model, conditional access and governance processes can extend to agents, and what licensing that actually requires.
- Copilot Studio or Foundry per agent. Decided on who will own and operate each agent in a year, not on which platform is more capable in a demo.
- Tool surface inventory. The APIs and systems each workflow must reach, and whether they can be fronted centrally or need custom hosting.
- Residency and state decision. Whether conversation state and retrieval must sit in your own resources, settled before build rather than migrated afterwards.
- Preview surface identified. Which capabilities in the proposed design are preview rather than generally available, recorded with the date verified.
- Australian region availability. Model and agent capability availability confirmed in Australia East and Australia Southeast, since parity is not guaranteed.
- 02
Architecture and implementation
Deterministic orchestration in code you own, agents hosted by the platform, tools behind one governed layer, and traces flowing somewhere you already look.
- Agent Framework for orchestration. Graph, sequential, group-chat and human-in-the-loop patterns written in .NET or Python and held in source control rather than portal configuration.
- Hosted or prompt agents chosen deliberately. Prompt agents where configuration is genuinely enough, hosted agents where you need your own container, dependencies and release pipeline.
- Tools fronted by an API gateway. Existing REST operations governed for agent consumption with authentication, throttling and quota applied in one place rather than per agent.
- Custom tools as scoped services. Bespoke tool implementations hosted as functions or containers with their own managed identity and least-privilege permissions.
- Retrieval and state as your resources. Search and conversation state in resources you control where residency requires it, with the operational cost of that accepted knowingly.
- Traces into Application Insights. Model calls, tool invocations and handoffs emitted as traces so a failed run can be reconstructed step by step.
- 03
Security and governance
Most of the differentiated value on Azure sits here. The controls exist; the work is applying them to a non-human actor deliberately and proving the boundary holds.
- Entra agent identity per agent. Each agent given its own identity construct rather than sharing an application registration, so authorisation and audit resolve to one actor.
- Conditional access extended to agents. Existing policy thinking applied to non-human actors, with the licensing prerequisites confirmed against your tenant rather than assumed.
- On-behalf-of rather than broad rights. An agent acting for a user carries that user's entitlements, so it cannot reach content the person asking could not already open.
- Guardrails plus application defence. Platform content filtering combined with tool allowlists and validated arguments, because a filter does not stop a manipulated tool call.
- Purview labels respected by tools. Sensitivity labelling honoured wherever an agent reads content, with the excluded set published rather than left implied.
- Network isolation where required. Private networking for prompt agents and a bring-your-own virtual network for hosted agents, verified rather than assumed at handover.
- 04
Adoption and enablement
Agents arriving inside Teams and Microsoft 365 adopt quickly, which is an advantage and a risk: a poor agent spreads just as fast as a good one.
- Published where the work happens. Agents surfaced into the Teams channel or application a team already uses, rather than as another destination for them to remember.
- Approval surfaces people can judge. A reviewer sees the proposed action, the reasoning and the evidence, because an approval nobody can assess is a rubber stamp with an audit trail.
- Autonomy widened by gate. Propose-only first, then approve-then-act, with a recorded decision before any step is allowed to run unattended.
- Business owners trained on failure. How the agent fails, how to report it and what never to paste into it, taught before rollout rather than after an incident.
- Agent inventory published. Which agents exist, who owns each and what it can reach, kept current because ungoverned sprawl is the predictable next problem.
- Trajectory reviews with the process owner. Real runs walked through weekly during the pilot, which finds more design faults than prompt tuning ever does.
- 05
Managed continuation
This is the fastest-changing surface Microsoft ships. Continuation is largely about noticing a change before it changes your outcomes.
- Evaluations on every model change. Foundry model updates and prompt edits re-scored against the held-back set, with a regression blocking promotion.
- Preview capability watch. Anything preview in your design tracked for status change, deprecation or rename, which in this area happens on a scale of months.
- Trace sampling by a person. Real trajectories reviewed on a cadence, because an aggregate success rate hides the individual failure that causes a complaint.
- Cost per run against the case. Foundry consumption reported per workflow and per run, separated from hosting and licence cost so each can be judged alone.
- Identity and permission drift. Agent identities and their reachable tools reviewed as people, projects and APIs change, with unused agents retired.
- Monthly report with one recommendation. Usage, task success, incidents and spend, ending in the single improvement we would make next.
Reference architecture
An agentic workflow on Azure, layer by layer.
How the pieces fit together on Microsoft Azure. Every engagement adapts this, and we will tell you which layers you already have.
- 01
Orchestration
Deterministic control flow in code you own, calling models for judgement.
- Microsoft Agent Framework
- Foundry Agent Service
- Human approval step
- 02
Identity
One identity per agent, acting for itself or on behalf of a user.
- Microsoft Entra Agent ID
- Conditional access
- Managed identities
- 03
Tools
Every tool declared, validated and reached through one governed layer.
- Azure API Management
- Azure Functions MCP tools
- Tool allowlist
- 04
Grounding
Retrieval and state in resources you control where residency requires it.
- Azure AI Search
- Azure Cosmos DB
- Purview sensitivity labels
- 05
Evaluation
Traces and scores on every run, with regressions blocking promotion.
- Application Insights
- Azure Monitor
- Held-back evaluation set
Across every layer
- Retrieved content treated as untrusted input
- Idempotent writes to every business system
- Cost per run instrumented from the first build
- A named owner recorded per agent
Technology reference
The Microsoft Azure services we build with.
A reference architecture view of the platform services used in this domain, and what each one does in the design.
Agent platform and orchestration
Microsoft FoundryThe control plane where agents, models, tools, guardrails and evaluations are defined for a project.
Foundry Agent ServiceRuns the agents, as configuration-only prompt agents or as hosted agents built from your own container or source.
Foundry ModelsThe model catalogue the reasoning steps are selected from, compared on your own evaluation set rather than a benchmark.
Microsoft Copilot StudioLow-code agent authoring for the cases where a business team rather than a developer will own the agent.
Azure Container AppsHosting for orchestration services and custom agent workloads that need their own runtime and release pipeline.
Identity and governance
Microsoft Entra IDThe identity plane agents authenticate against, including acting on behalf of a named user rather than with broad rights.
Privileged Identity ManagementTime-bound elevation for the human roles that administer agents and their permissions.
Microsoft PurviewSensitivity labelling and data loss prevention applied to the content agents can reach.
Azure Key VaultSecrets and keys for tool integrations that cannot yet use a managed identity, kept out of agent configuration.
Tools and integration
Azure API ManagementFronts existing REST APIs for agent consumption with authentication, throttling and per-consumer quota in one place.
Azure FunctionsHosts custom tool implementations and the deterministic glue code between agent steps.
Power AutomateApproval routing and business-system connectors where a low-code flow is the appropriate integration.
Azure Virtual NetworkNetwork isolation for agents and tools where traffic must not traverse the public internet.
Grounding, state and evaluation
Azure AI SearchRetrieval in your own resources, with permission filtering applied at query time.
Azure Cosmos DBConversation state held in a resource you control, which matters where residency is contractual.
Application InsightsReceives agent traces so every model call, tool invocation and handoff is inspectable after the fact.
Azure MonitorMetrics, alerting and cost signals per workflow against thresholds agreed at design time.
Product names and icons are trademarks of Microsoft and Amazon Web Services, reproduced unmodified from their official architecture icon libraries to identify the technologies used in these architectures. Their presence does not indicate partnership, certification or endorsement by either vendor.
Azure questions
What people ask about doing this on Azure.
Cost, lock-in and the parts that go wrong, answered before you have to ask twice.
Is Microsoft Foundry the same thing as Azure AI Foundry?
Microsoft Foundry is the current name. Azure AI Foundry was the previous one and now survives only as Microsoft Foundry (classic) for older surfaces. It matters practically rather than cosmetically: documentation, tutorials and Stack Overflow answers written under the old name may describe a portal experience that has moved, which is a common source of wasted time when a team is learning the platform.
Do we need Copilot Studio licences as well as Azure consumption?
Only if you use Copilot Studio, and that is a decision worth making per agent rather than platform-wide. Copilot Studio is licensed separately and suits agents a business team will own. Foundry work is consumption-based. For most clients the answer is a mix, and the mistake we see is licensing everyone for the low-code tool and then building the important agents in Foundry anyway.
Can a Foundry agent reach our on-premises systems?
Yes, through the same patterns you would use for any Azure workload: private networking, a gateway in front of the on-premises API, or a hosted tool inside your virtual network. What we would not do is grant an agent broad network reach to make integration easier. Each system it touches gets an explicit, scoped tool, because the whole security model depends on the tool list being enumerable.
What does agent identity actually give us that a service principal does not?
Attribution and revocability. A shared application registration across several agents means an audit log tells you an application acted, not which agent did, and revoking one agent's access breaks the others. A per-agent identity lets existing conditional access and governance thinking apply to a specific non-human actor. Confirm the licensing for the enterprise features against your own tenant, because that part is moving.
How do we stop an agent reading documents the user cannot see?
By having it act on behalf of the user rather than with its own broad permissions, so retrieval is filtered by that person's existing entitlements. We test it by running the same requests as accounts at several permission levels, including one that should see nothing. If your underlying SharePoint or file permissions are wrong, an agent will surface that quickly, which is why permission review comes before the build.
Related industries
Where this work has the most leverage.
Professional Services
Governed enterprise search, document intelligence and secure copilots that respect matter confidentiality and conflict boundaries.
Construction and Property
Tender intelligence, addenda tracking and project reporting that keep estimators and contract administrators ahead of the documents instead of buried in them.
Healthcare and Community Services
Administrative automation, policy search, workforce analytics and privacy uplift for healthcare and community providers, with clinical decisions left entirely to clinicians.
Free discovery workshop
Start with a agentic ai discovery workshop.
Bring one challenge. We will assess whether Microsoft Azure is the right platform for it before recommending anything.