Copilot Studio or pro-code

choosing how to build each AI agent

Microsoft offers several ways to build an AI agent, and choosing between them is one of the first architecture decisions in an agent programme. A choice made by habit costs money in either direction: engineers build something a business team could have run in Copilot Studio, or a low-code agent reaches production before anyone has asked whose credentials it acts under.

Microsoft’s guidance gives a sensible order for the decision, and Copilot Studio can now do far more than its early reputation suggests. This article sets out that order, what Copilot Studio now covers, and what still points to code on Microsoft Foundry. It reflects Microsoft Learn as it stood on 30 October 2026, and this area changes quickly.

The order of the decision

Microsoft’s technology plan for AI agents starts with one question: does a ready-made agent meet the requirements? If it does, adopt it. If it does not, the team builds, and Microsoft names two primary platforms, Microsoft Foundry and Copilot Studio, with GPUs and containers as a third option. Its advice on choosing between them is direct: if a low-code solution meets the functional and security requirements, proceed with it; if it does not, move to pro-code or adjust the scope.

  1. 1Does a ready-made Microsoft agent meet the requirements?

    Yes
    Adopt it

    Agents in Microsoft 365 Copilot, GitHub Copilot, Fabric, Dynamics 365 and Security Copilot.

  2. 2Does Copilot Studio meet the functional and security requirements?

    Yes
    Build in Copilot Studio

    Low-code, as a service. Business teams can deploy agents quickly.

  3. 3Does a managed runtime and a model from the Foundry catalogue meet them?

    Yes
    Build on Microsoft Foundry

    Prompt agents, or your own code as hosted agents.

  4. If not, run your own models on GPUs and containers, with full control of the stack.

The order of the decision, as Talastron reads Microsoft’s Cloud Adoption Framework. A “no” at each step moves to the next one. Prototype the candidates before committing.

Microsoft notes that organisations often use more than one approach, because the decision belongs to each use case.

Ready-made agents come first

Microsoft’s ready-made agents include Researcher and the Workflows and App Builder agents in Microsoft 365 Copilot, along with agents inside GitHub Copilot, Microsoft Fabric, Azure, Dynamics 365 and Security Copilot. They offer less customisation than a custom build, and they can be deployed immediately. A use case that one of them covers does not need a build decision at all.

What Copilot Studio now covers

Copilot Studio is a low-code software-as-a-service tool that lets business teams deploy agents quickly. It is sometimes treated as a tool for simple question-and-answer agents only. Microsoft’s current documentation describes much more:

  • Acting without a prompt. Event triggers let an agent respond to an item created in SharePoint, a completed Planner task or a schedule, with no user involved.
  • Reaching people outside Microsoft 365. Agents can publish to websites, mobile apps and messaging platforms as well as Teams and Microsoft Copilot.
  • Choosing the model. A team can choose a primary model or bring one from Foundry.
  • Controlled releases. Agents sit in Power Platform solutions that move between environments, pipelines can hold a release until tests pass, and agent evaluations can run from a CI/CD pipeline.

Microsoft also now offers three runtimes, which it calls harnesses. The standard harness suits short, bounded and rule-based work. The GitHub Copilot harness handles long-running, multi-step processes; despite its name, it is part of Copilot Studio and does not send customer data to the GitHub Copilot service. The Customer Conversation harness serves customers over voice and chat.

Features, channels and billing differ between them, so a capability documented for one should be confirmed for the harness a team intends to use. Microsoft also cautions that a more capable harness can overwork a simple problem, adding cost and latency.

What still points to Microsoft Foundry

Microsoft Foundry is a platform service with a managed runtime. Teams can define prompt agents without code, or package their own code as hosted agents in the framework of their choice.

Copilot StudioMicrosoft Foundry
Who builds itBusiness teams and low-code makersDevelopers, or makers using prompt agents
ModelsChoose a primary model, or bring one from FoundryThe Foundry catalogue, including OpenAI, Anthropic, Meta and Mistral
IdentityStandard harness triggers run on the author’s credentialsA dedicated Microsoft Entra identity for each hosted agent
NetworkOutbound connections over a Power Platform virtual networkAgents can run within your own Azure virtual network
ReleaseEnvironments, solutions and Power Platform pipelinesVersions, your own repository and CI/CD; evaluation is marked preview
SafeguardsBuilt-in responsible AI features reduce the need for custom onesHosted agents: your team owns its responsible AI mitigations
CostCopilot Credits or licensing, depending on the harnessHosted agents: CPU and memory during active sessions
What still separates the two, from Microsoft Learn on 30 October 2026. Harness and agent type change some of these answers, so confirm each one for the option in question.

Custom orchestration. Hosted agents run a team’s own code, accept webhooks and custom payloads, and can preserve long-running work across interruptions. Microsoft’s comparison of declarative and custom engine agents gives a loan approval agent as an example of work needing custom orchestration: specific business rules, precise data gathering and several credit check systems. The same page says custom engine agents range from simple setups in Copilot Studio to advanced pro-code implementations, so complexity alone does not settle the choice.

Identity. Every hosted agent receives its own Microsoft Entra identity. When a user invokes it through Microsoft 365, it can act with that user’s delegated permissions; when no user is present, it acts under its own identity. In Copilot Studio’s standard harness, event triggers use the author’s credentials, and Microsoft warns that this might give users access to data and systems they should not reach. The GitHub Copilot harness has a preview route for triggers that run on each user’s own credentials.

Network. Foundry agents can run within a customer’s Azure virtual network. Copilot Studio supports outbound connections over a virtual network through Power Platform, covering supported connectors, HTTP requests to Azure Key Vault and telemetry.

Responsibility. More control brings more to own. Microsoft says Copilot Studio’s built-in responsible AI features reduce the need for custom safeguards. For hosted agents, Microsoft makes the team responsible for its own responsible AI mitigations and for quality, reliability and security.

In Talastron’s view, the deciding question for any agent that changes records in other systems is whose identity it acts under, and whether every action can be traced to it. That question is best answered before the build starts.

Prototype before committing

Microsoft recommends time-boxed experiments: a short prototype for each candidate, allowing one to two weeks per option, compared on development speed, functional coverage and integration complexity. The findings are documented and reviewed with stakeholders. The same prototypes show whether the task needs one agent or several, and Microsoft advises against adding complexity the task does not need.

Using both

The choice need not be exclusive. Microsoft describes combining Copilot Studio’s low-code interface with Foundry’s models, and a Copilot Studio agent can also call an agent built in Foundry, so a business team can own the conversation while the more complex work runs in code.

Two conditions apply. The Foundry agent needs the Activity protocol enabled, which is off by default, and it must be created in the current Foundry portal. In the standard harness, Microsoft also marks this connection as a preview, which it says is not meant for production use, so the status should be confirmed for the harness in question before a design relies on it.

How Talastron makes the decision

The target architecture in Talastron’s Readiness & Blueprint records a Copilot Studio or code decision for each use case. Where the answer is code, Talastron Kinetic AI builds the agent inside the client’s own Azure tenant. To discuss your use cases, book a demo.

Sources

Microsoft Learn: Technology plan for AI agents; Harnesses in Copilot Studio; Compare Copilot Studio agent harnesses; Event trigger overview; Virtual network support for outbound connections from agents; Agents in Microsoft Foundry; What are hosted agents?; Agent development lifecycle; Compare declarative and custom engine agents; Connect to a Microsoft Foundry agent (preview).

Not sure whereto start?

Tell us where you are today, and we’ll recommend the right starting point.