标签：#copilotstudio

A team lead asks the question in a planning meeting and the room splits three ways: do we build this agent in Copilot Studio, write the orchestration ourselves and host it, or hand our container to Foundry and let it run our code? All three are official Microsoft build paths in 2026, all three end up in the same tenant-wide agent inventory, and the wrong pick costs you a rebuild once the project outgrows it. The answer is not "the most powerful one." It is the one whose service model matches who is building the agent, who owns the runtime, and how much pro-code control over orchestration and protocols you actually need. This article is the decision framework for that choice, grounded in Microsoft Learn and current as of mid-2026. Two of these three paths are public preview, so this is a guide to architectural fit and direction, not a production-reliability scorecard. TL;DR Three build paths, picked by service model, not power. Copilot Studio: low-code managed SaaS for makers. GA. Foundry Hosted agents: managed PaaS runtime for your own container. Public preview. Microsoft 365 Agents SDK: pro-code, self-hosted, widest channel reach. Agent Framework orchestrator in public preview. Monday move: before picking a platform, write down four things for this agent - who builds it (maker or pro-dev), who must own the compute, what channels it has to reach, and whether you need custom protocols or background/async behavior. Those four answers pick the path more reliably than a feature checklist. The three paths in one paragraph each Microsoft's own Cloud Adoption Framework frames the build options as three service tiers, which is the cleanest mental model to start from. The CAF positions them as Copilot Studio (SaaS, no/low-code), Microsoft Foundry (PaaS, pro-code or low-code), and GPUs and Containers (IaaS, code-first frameworks for maximum flexibility). The first two are managed by Microsoft. The third is where the self-hosted SDK path lives when you own the compute end to e

I wanted a chat agent that could pull security alerts from Sophos Central on demand. Type "get Sophos alerts" into a Copilot Studio chat, get back a readable answer. No dashboard, no manual API calls. It works now, end to end. Agent calls a Power Automate flow, the flow talks to the Sophos API, and the response comes back formatted in chat. This post is how I got there, including the bugs that ate most of my time. The shape of the thing Three pieces: A Copilot Studio agent that the user talks to A Power Automate flow that does the actual API work The Sophos Central API on the other end The agent does not call Sophos directly. It calls the flow, the flow handles auth and the request, and the result gets passed back to the agent to format. Keeping the API logic in the flow means the agent stays simple. The flow The flow is named Sophos - Get Alerts , living in a solution called Sophos Integration . Here is the structure: [Trigger: When Copilot Studio calls a flow] | [Init ClientId] - String (Sophos Client ID) [Init ClientSecret] - String (Sophos Client Secret) [Init TenantId] - String (your Sophos tenant ID) [Init ApiHost] - https://api-<region>.central.sophos.com | [HTTP Get Token] POST https://id.sophos.com/api/v2/oauth2/token Header: Content-Type: application/x-www-form-urlencoded Body: grant_type=client_credentials&client_id={ClientId}&client_secret={ClientSecret}&scope=token | [Parse Token] - extract access_token | [HTTP Get Alerts] GET {ApiHost}/common/v1/alerts Headers: Authorization: Bearer {access_token} X-Tenant-ID: {TenantId} Accept: application/json | [Return value(s) to PVA: AlertsResponse = body('HTTP_Get_Alerts')] Auth is OAuth client credentials. You request a token, then use it as a bearer token on the alerts call. The tenant ID goes in an X-Tenant-ID header, not the URL. Where the credentials live This is the part people will have opinions about, so let me be upfront. The Sophos client ID, secret, and tenant ID are stored as flow-scoped variables wit