In-app Copilot sidecar or a Copilot Studio MCP agent…

In-app Copilot sidecar or a Copilot Studio MCP agent — which one, for what?

Two surfaces, two jobs, and one combination that people reach for first and cannot have yet. Knowing which is which saves a design cycle, and knowing the unsupported combination saves a sprint.

7 minute read.

Start with the combination that does not work

The obvious idea — "we already have the Copilot panel in the ERP, let us add the ERP MCP server to it as a tool" — is explicitly unsupported today. MCP (Model Context Protocol) is the open standard that connects AI agents to data systems; the ERP MCP server is how an agent reaches Dynamics 365 finance and operations data and business logic.

Microsoft's own limitation list says so — known limitation 10 on the ERP MCP server page. Adding the Dynamics 365 ERP MCP server as a tool in the Copilot for finance and operations apps agent, enabling it for use with the sidecar chat panel in the client, "isn't yet supported".

You are not blocked from adding it, you might experience errors in the execution, and Microsoft support "doesn't guarantee assistance" for resolving them.

That is a narrow sentence with wide consequences, because it removes the architecture most teams sketch on the whiteboard in the first meeting. If your agent needs the MCP server, it does not live inside the in-app sidecar. Design accordingly and revisit when the limitation lifts.

What each surface is actually for

Where the user is — In-app sidecar — Copilot for finance and operations apps [GA]: Inside the ERP client, in context on a form · Copilot Studio agent on the ERP MCP server [GA]: In Teams, Microsoft 365, a channel, or running autonomously
Default knowledge — In-app sidecar — Copilot for finance and operations apps [GA]: Microsoft Learn documentation and in-app context · Copilot Studio agent on the ERP MCP server [GA]: Whatever the security role reaches across entities, forms and actions
Reads your records — In-app sidecar — Copilot for finance and operations apps [GA]: Not by default. Someone adds finance and operations data as a knowledge source — release plan [GA] 26 January 2026, though Microsoft's how-to page still carries a prerelease banner · Copilot Studio agent on the ERP MCP server [GA]: Yes, live, scoped by role
Acts — In-app sidecar — Copilot for finance and operations apps [GA]: Only through client actions a maker adds — finance and operations client code, [GA] 24 April 2026 · Copilot Studio agent on the ERP MCP server [GA]: Yes — that is its purpose
Extends via — In-app sidecar — Copilot for finance and operations apps [GA]: The underlying Copilot Studio agent, client actions, knowledge sources · Copilot Studio agent on the ERP MCP server [GA]: Tools, including the MCP server and your own X++ actions
Can use the ERP MCP server — In-app sidecar — Copilot for finance and operations apps [GA]: Not yet supported — Microsoft known limitation 10 · Copilot Studio agent on the ERP MCP server [GA]: Yes

The clean way to hold it: the sidecar is in-context help and narrow actions for a person already looking at a form. The Studio agent is work that spans records, forms or systems, and it does not need a human in the client at all.

Those are different products serving different moments, and the confusion comes from both being called Copilot.

Where an ERP agent can run

If you have chosen the agent path, these are the hosts that matter and the choice is not obvious.

**Copilot Studio** — What it buys: The default. Low-code, first-party MCP connector, Teams and Microsoft 365 channels, tool execution bundled into the agent-action rate · What it costs: Less control over orchestration and model behaviour
**Microsoft Foundry** — What it buys: Pro-code, your choice of model, custom orchestration · What it costs: You pay token costs separately, MCP tool calls meter individually, and its Entra application ID has to be allow-listed in the ERP first
**VS Code with GitHub Copilot** — What it buys: Development and testing against the server — it is one of the clients Microsoft pre-registers · What it costs: Our position: a development surface, not where you ship
**Any other MCP-capable client** — What it buys: Full control of the runtime · What it costs: Its Entra application ID has to be allow-listed in the ERP first

Copilot Studio and Visual Studio Code are the clients Microsoft pre-registers. Anything else — Foundry included — has to be registered in Entra ID and its client ID added to the Allowed MCP clients form (Dynamics 365 ERP MCP server).

Most teams should start in Copilot Studio and move only for a specific reason. The most common good reason is orchestration control; the most common bad reason is that a developer prefers code.

The project dependency nobody schedules

Here is a small, concrete thing that delays projects, and it is easy to fix if you know about it in week one.

For agents using the ERP MCP server, Microsoft's published guidance is specific: Claude Sonnet 4.5 is recommended, on the stated basis that it "provides a better success rate in Copilot Studio over other default models like GPT-4.1". GPT-5 (Chat) is the fallback where Sonnet is unavailable. And GPT-4.1 should not be used as the Copilot Studio orchestration model — Microsoft says you can use it "in other clients like Microsoft Visual Studio Code with GitHub Copilot and achieve good results", but "don't use it as the orchestration model for agents in Copilot Studio".

The dependency: Claude models are external models not hosted in Azure, so a tenant administrator must approve them before makers can select them.

That approval sits with a security or compliance function, not with the ERP team, and it has a queue. Raise it at kickoff. Discovering it late turns a configuration change into a schedule risk, which is an expensive way to learn a one-line prerequisite.

Orchestration mode, and why descriptions are production code

Copilot Studio offers two orchestration modes, and the choice is close to made for you here. Newly created agents use generative orchestration by default.

**Classic** — Behaviour: Matches trigger phrases to authored topics; tools "can only be called explicitly from within a topic" · Implication: Predictable and auditable, and far too brittle for a dynamic tool surface
**Generative** — Behaviour: The agent can choose to call tools based on their name and description · Implication: The practical choice for a dynamic tool surface — and the default for new agents

Which produces a consequence worth saying out loud to a team used to low-code: in generative mode, Microsoft calls the description of a tool or topic "the most important factor" in whether the agent selects it. Descriptions are not documentation in that mode. They are the interface, and they belong under the same review as anything else that changes behaviour.

One regional blocker to name before a European rollout

The Copilot Cowork route to the ERP [PP] — the Microsoft 365 agentic workspace reaching finance and operations through the MCP server — carries a requirement that catches EU manufacturers.

Label it honestly first. Microsoft's 2026 release wave 1 plan lists public preview for July 2026 and no general-availability date, the tenant must be enrolled in the Frontier preview program, and the preview is open to selected preview customers only. Plan around it; do not commit a go-live to it.

The Dataverse data available in Microsoft 365 Copilot setting, in the Microsoft 365 Admin Center under Copilot > Settings, must be on. Microsoft says the condition is common in EU countries or regions with Works Council requirements — naming Germany, France and Sweden as examples — where Dataverse might be disabled by default.

If it is off, users see the plugin in the Copilot Cowork catalog but get the message "Disabled by your organization's administrator." (enable the Dynamics 365 ERP apps plugin for Copilot Cowork)

That is not a technical fault and it is not something you fix in an afternoon; it is a consultation process. If your rollout includes those countries, put it on the plan at the start rather than discovering it during user acceptance testing.

The counter-argument

"Users do not care about our architecture diagram. They want one box in the ERP that answers everything. Give them the sidecar and add capability over time."

The user-experience instinct is right and it is why this question is hard. One entry point is better than three, and the sidecar is where people already are.

It fails on availability rather than on design. The sidecar cannot use the MCP server today, so "add capability over time" means client actions, AI actions and knowledge sources — each authored one capability at a time, against a dynamic tool surface the MCP server already exposes in full. You would be committing to the surface you have to hand-extend, because it is the more comfortable doorway.

The pragmatic resolution most teams land on: keep the sidecar for what it is genuinely good at — in-context help and narrow actions — and put the cross-record work in a Studio agent surfaced in Teams, where users also already are. Two doorways, each honest about what is behind it, beats one doorway that cannot deliver.

What to do this week

Take your top agent scenario and ask whether a person is looking at a form when it runs. If yes, the sidecar is a candidate. If no, it is a Studio agent and the question is settled.
Check today whether external models are approved in your tenant. If they are not, start that conversation now — it is the cheapest schedule risk you will remove all quarter.
If your rollout includes EU countries with Works Council requirements — Microsoft names Germany, France and Sweden as examples — confirm the Dataverse setting and find out who owns the consultation. That is a people process with a lead time.

Where we would draw the line

We would not build an ERP agent inside the in-app sidecar while the MCP server is unsupported there, because it means designing around a documented limitation to reach a doorway. We would not choose Foundry over Copilot Studio for a first agent unless there is a named orchestration requirement that Studio cannot meet. And we would not let a tool description ship without review, because in generative mode that text is the thing deciding what the agent does.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

If you are choosing a surface for your first ERP agent, we will walk both options against your scenario on a call. https://cognilium.ai

In-app Copilot sidecar or a Copilot Studio MCP agent — which one, for what?