Starting an AI project today feels like building on shifting sand — the ground moves before the concrete even sets.
The orchestration layer is the backbone of the AI system, and the agent is the conductor that drives how models, tools, memory, and MCP servers work together. On the Microsoft cloud space today the three main Agent builders would be:
- Copilot Studio – Low‑code conversational agents built and orchestrated inside the Power Platform.
- Azure AI Foundry Hosted Agents – Fully managed, cloud‑hosted agents running on Microsoft’s Agent Service.
- In‑Process Agents (Agent SDK) – Code‑based agents running inside your own compute (Functions, Container Apps, AKS, etc.).
Copilot Studio is on the edge of simplicity with low code-no code. In-process agents are on the edge of flexibility requiring more code than the other options. What is best for your project depend on the “non-negotiable” requirements. Before discussing that, check this table:
| # | Category | Hosted Agent (Azure AI Foundry) | In‑Process Agent (SDK) | Copilot Studio Agent |
|---|---|---|---|---|
| 1 | Runtime location | Runs in Azure’s managed Agent Service | Runs inside your app (Functions, Container Apps, AKS, App Service) | Runs in Copilot Studio’s orchestration layer; calls models/agents behind the scenes |
| 2 | State & memory | Built‑in persistent memory (files, vectors, long‑term state) | Stateless unless you build your own memory + storage | No native long‑term memory; relies on connectors, Dataverse, or external systems |
| 3 | Tool orchestration | Azure orchestrates tools automatically | You implement tool routing, retries, orchestration logic | Orchestrates connectors, plugins, Power Automate flows; not model‑level tool routing |
| 4 | Built‑in tools | Code Interpreter, File Search, Web Search, Multi-Agent, and 1,000+ curated tools via Foundry Tools catalog. Note: some tools (including memory and web search) are still in preview and may not be suitable for production workloads. | None built‑in; you implement tools manually | Power Platform connectors, actions, plugins, and flows |
| 5 | Function Calling | Supported; agent decides when to call tools | Supported; you control when/how tools are invoked | Supported via MCP and connectors with generative orchestration enabled; agents dynamically select tools at runtime. Not native model-level function calling, but functionally equivalent for most connector-based scenarios. |
| 6 | MCP (Model Context Protocol) | Can consume MCP servers as tools/resources | Can host or consume MCP servers; full control | Natively supported (GA since May 2025); connect MCP servers directly via the Add Tools catalog. Requires generative orchestration to be enabled. |
| 7 | Scaling | Auto‑scales; no compute to manage | You own scaling, concurrency, hosting, retries | Auto‑scales within Power Platform limits; governed by environment capacity |
| 8 | Networking | Supports private networking, RBAC, governance | You configure VNet, private endpoints, firewall, identity | Limited; depends on connector capabilities and Power Platform environment configuration |
| 9 | Latency | Medium (managed orchestration overhead) | Lowest (runs in your process) | Highest (UI + orchestration + connector hops + agent/model call) |
| 10 | Cost model | Pay for model usage + storage; no compute cost | Pay for compute, networking, logging, storage | Power Platform licensing + model usage + connector/API costs |
| 11 | Integration model | Exposed as REST endpoint; ideal for Copilot Studio, Power Automate, APIM | Embedded in your code; ideal for microservices, backend systems | Native integration with Power Platform, M365, connectors, and Foundry agents |
| 12 | Customizability | Limited deep customization; Azure controls runtime | Full control over execution, orchestration, domain logic | Low-code customization; limited deep control over orchestration or model behavior |
| 13 | Multi‑agent support | Native multi‑agent orchestration | You must implement multi‑agent logic manually | No native multi-agent; can call Hosted Agents that perform multi-agent orchestration |
| 14 | Security posture | Azure-managed identity, isolation, compliance | You own identity, secrets, network isolation, DevOps | Power Platform governance, DLP policies, environment isolation |
| 15 | Use cases | Enterprise workflows, copilots, automation, multi‑agent systems | High‑performance apps, internal logic, custom orchestration, low‑latency pipelines | Business-facing copilots, workflow automation, M365 integration, rapid delivery |
Based on what you are trying to achieve:
Flexibility and Customisation
Probably the most important aspect is flexibility because you don’t want to paint yourself into a corner. Depend on how far you need to customize In-process Agents are far more flexible
- Full control of orchestration — you decide the reasoning loop, sequencing, and logic.
- Full control of runtime — runs anywhere, with any dependencies or libraries.
- Full control of memory — choose your own storage, vector DB, and memory strategy.
- Full control of tools — integrate with any internal API, service, or protocol.
- Full control of performance — lowest latency, custom batching, caching, and tuning.
- Full control of security — your VNet, your identity, your compliance posture.
- Full control of multi‑agent patterns — design your own agent hierarchies and collaboration models.
Performance
Copilot Studio introduces the most latency because it’s an orchestration layer, not an execution environment. Every message flows through connectors, governance layers, and the Studio runtime before it reaches the underlying agent or model.
Foundry Hosted Agents sit in the middle. They run inside Azure’s managed Agent Service, which provides autoscaling and built‑in tools but adds a predictable amount of overhead compared to running the agent yourself.(Microsoft Foundry and Azure: Hosting AI Agents | All things Azure)
In‑Process Agents deliver the lowest latency because the agent runs directly inside your application or service. There’s no network hop, no managed orchestration layer, and you control every part of the execution path.
Cost and simplicity
Foundry Hosted Agents are generally the most cost‑efficient because they require no infrastructure, and you only pay for model usage and storage, though you may still need a lightweight Azure service in front of them for secure access unless they’re invoked through Copilot Studio’s Deno‑based (soon GA) or HTTP connectors. In‑process SDK agents sit at the opposite end of the spectrum: they offer maximum control and performance but come with the highest infrastructure and operational cost because you pay for the compute, scaling, networking, and hosting required to run them. Copilot Studio agents fall in the middle‑low range, with costs tied to Power Platform licensing and API/model usage, making them inexpensive for business‑facing copilots but not ideal for high‑volume or deeply agentic workloads.
High-end Enterprise grade
Copilot Studio delivers excellent enterprise copilots, but it does not produce high‑end enterprise agents because it isn’t an agent runtime — it’s an orchestration layer. Every action flows through connectors, Power Automate, or external APIs, and the system has no control over the underlying reasoning loop, tool‑calling behavior, memory strategy, or execution environment. This makes it ideal for business workflows and M365‑integrated experiences, but fundamentally limits its ability to support deeply agentic, multi‑step, deterministic, or low‑latency logic.
High‑end enterprise agents require capabilities Copilot Studio doesn’t expose: custom orchestration, private in‑process execution, advanced tool routing, multi‑agent collaboration, domain‑specific reasoning, and full control over memory, security, and performance. Those capabilities live in Azure AI Foundry Hosted Agents and In‑Process Agents (SDK). Copilot Studio is the front door for business‑facing copilots; Foundry and SDK agents are the engine room for complex, mission‑critical agentic systems.
In‑process (SDK) agents are the strongest option for high‑end enterprise scenarios because they give architects complete control over the agent’s runtime, orchestration, security, and integration surface. Unlike managed or low‑code agents, SDK agents run inside your own compute, allowing you to shape the reasoning loop, enforce deterministic multi‑step logic, integrate directly with internal systems, and apply your own memory, identity, and networking strategies. This makes them uniquely suited for mission‑critical workloads that demand low latency, strict compliance, private networking, custom tool routing, and deep domain‑specific behavior — the kind of capabilities that define true enterprise‑grade agentic systems.
Conclusion
When you look across the three agent models, the pattern becomes clear. In‑process (SDK) agents are the top choice when you need maximum flexibility, deep customisation, deterministic behaviour, and the lowest possible latency. They give you full control over the orchestration loop, memory, security, and integration surface — everything required for high‑end, mission‑critical enterprise agents.
Azure AI Foundry Hosted Agents sit comfortably in the middle, offering a strong balance of capability, cost efficiency, and simplicity. They provide built‑in tools, persistent memory, autoscaling, and native multi‑agent orchestration without the operational overhead of running your own compute. For most enterprise workflows, this is the sweet spot.
Copilot Studio is the right fit for business‑facing copilots and lightweight automation, where rapid delivery, connectors, and Power Platform integration matter more than deep agentic control. It’s the front door for enterprise users, not the engine room for complex agent systems.
In short: SDK agents for power and precision, Foundry agents for capability and cost, Copilot Studio for simplicity and speed of delivery.
Leave a Reply