Copilot Studio Guide

What Is Copilot Studio?

Microsoft Copilot Studio is Microsoft’s low-code platform for building custom copilots and AI agents on top of the Power Platform. It is where you design conversational and autonomous agents, from simple FAQ bots to agents that schedule appointments, process tickets, or edit documents on their own.

Technically, Studio sits in the Power Platform stack next to Power Apps and Power Automate. It draws on 1,400+ connectors, Dataverse, Microsoft 365 Graph and, since 2025, MCP servers. Studio is Microsoft’s direct counterpart to LangDock Workflows or Zapier with LLMs, only deeply integrated into the Microsoft tenant.

Delivery happens in Teams, Microsoft 365 Copilot Chat, on the web, in Power Apps, in your own channels via the Direct Line API, or as a voice agent in Dynamics 365 Contact Center.

Licensing Paths (As of August 2026)

In September 2025, Microsoft replaced the old “per-message” model with a credit model:

Credits are pooled tenant-wide, not per user. A simple scripted FAQ bot costs ~1 credit per conversation ($0.01); an agent with Generative Orchestration, tenant grounding, and deep reasoning can cost $0.25 to $2.00+ per conversation.

For Power Automate flows as tools: classic cloud flows still need Power Automate licenses; Agent Flows (flows built in Studio) are billed entirely through Copilot credits, so no separate PA user plan is needed.

Since April 2026, Microsoft has offered an Agent Usage Estimator (microsoft.github.io/copilot-studio-estimator) for credit forecasts by agent type, traffic, orchestration, knowledge, and tools. Use it before every pilot.

Platforms / Channels

• Web Studio (copilotstudio.microsoft.com) for authoring
• Microsoft Teams (personal chat; with the Toolkit also channels & group chats)
• Microsoft 365 Copilot Chat (M365 Copilot app)
• Web Chat / Custom Web (React Web Chat or WebChat JS)
• Direct Line API for your own apps & channels
• SharePoint (embedded on pages)
• Power Apps (as an agent component)
• Power Pages (public sites)
• Voice Channel in Dynamics 365 Contact Center (IVR, Real-time Voice Agents)
• Facebook, Slack, and more via the Azure Bot Service adapter

Feature Timeline 2025/2026

When Is Copilot Studio Worth It?

Worth it when:

• You sit deep in M365 / Teams / SharePoint / Dataverse and want to “inherit” Azure AD login + permissions.
• You need autonomous agents on SharePoint/Outlook/Forms events (e.g., “auto-triage new tickets”).
• You want a conversational UI in Teams (instead of a CLI / custom web app).
• You need compliance/audit via Microsoft Purview (e.g., in an AZAV, GoBD, or GDPR context).
• You need voice IVR in a Dynamics 365 Contact Center.
• You want to reuse existing Power Automate flows as tools.

NOT worth it as a replacement for:

• Pure API orchestration without conversation → Power Automate (cloud flow) or Logic Apps is enough there.
• Maximum LLM control over prompts, models, and providers → you are better off in Azure AI Foundry, LangDock, or directly with OpenAI/Anthropic.
• Self-hosted / on-prem LLMs → Studio is cloud-only.
• A full-fledged customer service platform → Studio is only the bot frontend; human handoff, ticketing & routing are handled by Dynamics 365 Customer Service (or a third-party system via Generic Handoff).
• Pixel-perfect web UIs → Adaptive Cards are the limit; anything beyond that is Power Apps / Custom Web.

The Concept Model

A Studio agent is the top-level unit. It consists of persona + instructions + topics + tools + knowledge + channels, and it lives in a Power Platform environment with its own DLP and audit configuration.

                ┌──────────────────────────────────────┐
                │           AGENT (= "Copilot")        │
                │                                      │
                │  ┌─────────────┐   ┌──────────────┐  │
                │  │ INSTRUCTIONS│   │ ORCHESTRATION│  │
                │  │  (System    │   │  (Classic vs │  │
                │  │   Prompt)   │   │  Generative) │  │
                │  └─────────────┘   └──────────────┘  │
                │                                      │
                │  ┌──────────┐ ┌──────────┐ ┌──────┐  │
                │  │  TOPICS  │ │  TOOLS / │ │KNOW- │  │
                │  │ (Dialog) │ │ ACTIONS  │ │LEDGE │  │
                │  └──────────┘ └──────────┘ └──────┘  │
                │       │           │           │      │
                │       ▼           ▼           ▼      │
                │   Nodes:      Connector    Web/SP/   │
                │   - Message   Action       Dataverse/│
                │   - Question  PA-Flow      Files/    │
                │   - Condition Agent-Flow   Graph/    │
                │   - Variable  Prompt       MCP/      │
                │   - Action    REST/HTTP    Azure AI  │
                │   - Adaptive  MCP-Tool      Search   │
                │     Card                             │
                │                                      │
                │  ┌──────────────┐  ┌──────────────┐  │
                │  │   TRIGGERS   │  │  CHANNELS    │  │
                │  │ user / event │  │ Teams / Web /│  │
                │  │ /schedule    │  │ Voice / ...  │  │
                │  └──────────────┘  └──────────────┘  │
                └──────────────────────────────────────┘
                              │
                              ▼
                    ┌────────────────────┐
                    │ POWER PLATFORM ENV │
                    │ (DLP, Solutions,   │
                    │  Audit via Purview)│
                    └────────────────────┘

What You Build in Copilot Studio

Microsoft restructured the product overview in September 2026 and has since explicitly named several building blocks that you use individually or combine into an end-to-end solution: a workflow may, for example, call an agent for one step. For project practice this is more than cosmetics: anyone who still translates “Copilot Studio” as “chatbot builder” in a customer workshop has been underselling the platform since this restructuring.

Apps as a New Building Block (Public Preview Since September 2026)

On September 10, 2026, Microsoft announced that Copilot Studio can now build not only agents and workflows but also apps. You describe the business outcome, the user group, the data, and the desired actions in natural language, iterate in conversation, see a preview, and only then publish. If you want to dig deeper, you can inspect the generated code.

Technically, according to Microsoft, these are full-stack apps on open standards, not canvas apps in the classic Power Apps sense. They support Git-based version control, deployment stages, and version isolation, so teams can keep building the next version without disturbing the one that is running. Identity via Microsoft Entra as well as organizational and connector policies apply by default. Enterprise data is connected through connectors and Work IQ.

For the IT side: published apps appear as inventory with operational controls in the Microsoft 365 Admin Center; users find approved, enterprise-ready apps at managedapps.cloud.microsoft.com.

Copilot Managed Runtime: where the apps run (public preview since September 25, 2026)

Since September 25, 2026, the infrastructure underneath the apps has a name: Copilot Managed Runtime (formerly "Microsoft-managed host" in the Licensing Guide). It launched in public preview and hosts apps from Copilot Studio, Copilot Cowork and the CLI; with the Copilot Managed Runtime SDK, apps from third-party tools such as GitHub Copilot or Claude Code can run inside your own tenant as well. Every app gets Entra authentication, access to more than 1,500 connectors and a Git repository, and automatically inherits Conditional Access, DLP, advanced connector policies and sharing limits. Data access always uses the identity of the signed-in user.

For admins: app creation in Copilot Studio is on by default. It is controlled in the Microsoft 365 admin center under Apps > Overview > Set up app creation spaces (or via PowerShell through the tenant setting enableManagedAppsMcsPreview), and it can be scoped to selected makers with a security group. The CLI path is off by default, and Cowork depends on Frontier onboarding. Global admins and Power Platform admins can manage these settings.

Key Terms at a Glance

A Studio agent can get going in two fundamentally different ways:

• (a) A user asks a question or sends a message, and the agent matches a topic.
• (b) An event happens somewhere, and the agent starts autonomously (no user in the loop).

User-Initiated Triggers

Autonomous / Event Triggers (GA Since 2025)

Prerequisite: Generative Orchestration must be enabled on the agent. Otherwise the UI does not show the event triggers at all.

What event triggers cost, require, and quietly bring along

Microsoft expanded the trigger documentation considerably in September 2026. Four points from it decide more projects than the question of which connector to pick:

• Every payload is a message. Microsoft counts every trigger payload as a message sent to the agent – even when nobody is talking to it. The documented example leaves no room for doubt: a recurrence trigger set to every 10 minutes sends a payload every 10 minutes and consumes accordingly. An autonomous agent that idly “just checks whether anything is there” quickly becomes the most expensive agent in the tenant.
• Fewer than 15 actions or topics in a row. Microsoft explicitly recommends calling fewer than 15 actions or topics consecutively: complex agents that run many steps as a single sequence struggle to run reliably. If your blueprint exceeds that, break it into agent flows or child agents rather than tuning the instructions.
• Triggers always run on maker credentials. Event triggers can only use the agent author’s credentials, and for an autonomous run every authenticated action has to go through them too. Users of a published agent can therefore reach data and systems opened with the maker’s permissions. Copilot Studio shows a warning about this before publishing – it is not a formality, it is the core question of the sign-off.
• Without solution-aware cloud flow sharing there are no triggers at all. Makers can only add event triggers in environments where this setting is turned on. If no trigger can be added and the data policies do allow triggers, that is almost always the reason. Independently of that, admins can block event triggers entirely for an environment via data policy.

Topics

A topic is the smallest meaningful “conversation loop.” It has (1) a trigger, (2) a sequence of nodes, and (3) optional input/output variables.

Topic types:

• Custom Topics: built by you.
• System Topics: Microsoft defaults (Greeting, Goodbye, Escalate, Confused, Reset Conversation, On Error, Multiple Topics Matched, ...).
• Generative Answer Topic: the fallback that searches the knowledge sources when nothing else matches.

Nodes Inside a Topic

Actions / Tools

An action is a “tool” the agent calls. Since 2025, Microsoft primarily calls these Tools.

Knowledge Sources

Knowledge is “what the agent knows,” not “what the agent does.”

Important to know: Files carrying the Sensitivity Labels confidential or highly confidential are shown as “ready” but do not return answers. Sensitivity labels (MIP) have been visible in connectors, Test Chat, Teams, and M365 Copilot since July 2025.

Page-Level Citations for PDFs

When the agent answers from a PDF, the citation normally points to the whole document, which helps nobody with a 200-page works agreement. For one path it gets more precise: PDFs added via Upload files → SharePoint (that is, stored and indexed in Dataverse) deliver page-level citations. A click on the reference opens the PDF in a new tab directly on the cited page, and the user can verify the answer without searching the document.

The limits, because they regularly cause confusion in projects: it applies only to PDFs, all other file types fall back to document-level citations. It applies only to this one integration path: the fully integrated SharePoint knowledge source and individually uploaded files still cite at document level. And the file must reach the indexing threshold of roughly 4 KB; smaller PDFs fall back as well. If page-level traceability is a compliance argument in your project, the choice of integration path decides whether you get it.

Attachments and Generated Files (Preview Since July 2026)

Since July 2026, users can attach files to a message, and the agent can generate files itself during the conversation. Both apply to agents on the GitHub Copilot harness and run on Copilot Credits, including when testing in the Preview tab.

The most important point first, because it is regularly confused in projects: an attachment is not a knowledge source.

What can be attached: images (.png, .jpg, .gif, .webp; the agent uses vision-capable models), PDFs (text is extracted), text documents (.txt, .csv, .html, .md), and URLs. For a URL, the agent downloads the file for that turn; the download must finish within 30 seconds, and the URL must be publicly reachable. Links behind a login or firewall do not work. If an attachment fails, the agent skips it and continues processing the rest of the message; the message still goes through.

Generated files are not something you configure; they appear when the task calls for a file: a report, a spreadsheet, a chart, a code snippet, or the revised version of an attached file. The agent attaches a Created File card with file name, preview, and download action below the answer. Users can refer to it in a follow-up turn (“make the chart taller”), the agent reads the file back and generates a new version.

So attachments do not live for one turn only: within the retention period, the agent can go back to a file sent earlier (“compare this with the file from before”). Both functions are available wherever the agent runs (Preview tab, Microsoft Teams, Microsoft 365 Copilot, web chat), as long as the channel supports attachments.

Variables / Slots

• Topic Variable: visible only within that topic. The default for User.Name-style variables.
• Global Variable: available everywhere in the agent, persistent across topic switches.
• System Variable: managed by Studio (e.g. System.User.Id, System.Conversation.Id, System.LastMessage, System.Activity.Channel).
• Environment Variable: solution level, ALM-friendly, e.g. API URLs per environment.

Slot Filling: When the user answers the agent’s question “proactively” (e.g. the user says right away “Book Frankfurt → Berlin on Friday” and the agent extracts city, city, and date in one go), Microsoft calls that slot filling. Entities (prebuilt or custom) are the prerequisite.

Authentication Building Blocks

• No Authentication: anonymous; only makes sense for public web chat / Power Pages.
• Authenticate manually with Microsoft Entra ID v2: the standard for enterprise. Prefer federated credentials (no stored client secret).
• Authenticate with Microsoft (SSO): the user token is passed through; tools/knowledge run in the user’s context (permissions are inherited!).
• Microsoft Entra External ID: for B2C scenarios (customer login).
• Generic OAuth 2.0: for your own identity providers.

How Does Data Flow?

Data is passed between nodes & topics via variables. Power Fx is the formula language.

Ask Question ─► Topic.Name (string)
                │
                ▼
Set Variable   ─► Global.Customer = Topic.Name
                │
                ▼
Condition      ─► If Global.Customer in adminList
                │
                ▼
Call Action    ─► Input: Global.Customer, Output: Action.Result
                │
                ▼
Send Message   ─► "Status: {Action.Result.status}"

Variable Scopes

Power Fx in Studio

Power Fx is the Excel-like formula language of the Power Platform. In Studio you use it for Set Variable, condition expressions, string manipulation, and date/number logic.

// Set Variable: calculate the gross amount
Set(Topic.Gross, Topic.Net * 1.19)

// Condition: user is admin AND amount > 1000
Topic.IsAdmin = true And Topic.Amount > 1000

// String manipulation: extract the email domain
Last(Split(System.User.Email, "@"))

// Date: 7 days in the future
DateAdd(Now(), 7, Days)

Gotcha: Power Fx uses US formatting: comma as the parameter separator, period as the decimal point. Anyone coming from German Excel trips over this regularly.

LangDock Modes Mapped

In LangDock you can fill fields as auto, manual, or AI prompt. Studio maps that as follows:

The most important architecture switch in Studio: do you select topics via hard-wired trigger phrases (Classic), or do you let the LLM choose based on topic descriptions (Generative)?

Comparison Table

Choosing the primary model – two separate lists since September 2026: Which models you see at all now depends on the harness, not on the product. Since September 2026 Microsoft maintains two separate availability pages: one for the standard harness and one for the GitHub Copilot harness. The two rosters overlap only partially, and Microsoft designates a default model exclusively for the standard harness. The most important change in September: GPT-5.5 Chat has replaced GPT-4.1 as the default, in all regions at once (documentation as of September 18, 2026).

A deprecated model remains usable for up to one month after retirement. External models can be added as the primary model after admin approval, and here the two documentation pages diverge: the standard harness page names Anthropic, xAI, and Mistral, while the GitHub Copilot harness page lists only Anthropic and Mistral in its body text and mentions xAI solely in the admin controls. If you have planned Grok for the new experience, verify that in your own tenant before committing to it.

How model selection got here: Since October 2025 you choose the Generative Orchestration model in the agent settings; the Auto category (dynamic routing between fast and deep models at each conversation step) was added in spring 2026. GPT-4o was deprecated in October 2025, Claude Sonnet 4.5 once the migration deadline passed on June 30, 2026.

Harnesses: The Runtime Layer Between Agent and Model

Since the end of July 2026 Microsoft documents a layer that used to be implicit: the harness. You build the agent, the model delivers reasoning and text, and in between sits the harness as the runtime. It decides when the model is called, which components are sent along, how the answer is interpreted, and which tools run. In practice this means the harness determines which features you get at all and how you are billed. That is now a more important decision than the old question of “Classic or Generative Orchestration”.

The “new experience” on the Copilot Studio home page is exactly the switch between the GitHub Copilot harness and the Standard harness. Via the New experience toggle on the home page (or Other ways to build) you get back to classic agents and Agent Flows. Both worlds continue to exist side by side.

GitHub Copilot Harness: Generally Available Since September 2026

On September 2, 2026, Microsoft declared the GitHub Copilot harness generally available. The runtime itself is thus out of preview and, according to Microsoft, the recommended basis for agents and workflows that work in multiple steps, generate files, and automate a process from start to finish. For project practice this mainly changes the argument: a GA feature can be defended differently in conversations with the works council, data protection, and procurement than a preview.

Describing Solutions in Natural Language (Preview)

Since September 9, 2026, the product overview has its own section Build with natural language as a preview: you describe the business goal, and Copilot Studio decides on its own which combination of agents and workflows solves it. Refinement happens through follow-up questions and corrections in the same conversation, and several assets can emerge in one session, without you fixing the type up front or switching between designers.

For workshops this is a real gain: the question “Do we need an agent or a flow here?” may stay open at the start instead of blocking the discussion. For cost planning the opposite applies: exactly this prompt-based generation is credit-billed on the GitHub Copilot harness, from the very first attempt (see Chapter 10).

Skills: Reusable Instruction Building Blocks

A skill is a self-contained capability made of a name, a description, and instructions in Markdown. That clearly separates it from the other building blocks: Instructions describe general behavior, Knowledge is knowledge, Tools are actions via external services, and a Skill is a task-specific way of working that the orchestration activates when needed. The description is the trigger; the runtime uses it to decide whether the skill applies, so that is exactly where care pays off.

The format is deliberately portable: a SKILL.md file with YAML front matter (name, description) plus Markdown instructions. As a skill package the whole thing comes as a ZIP with optional companion files such as scripts, templates, and reference documents. You can write skills in Copilot Studio, build them in any editor and upload them, or adopt existing GitHub Copilot and Claude Code skills. A skill is built once and used in several agents.

Memory: Persistent Context per User

Memory is a production-ready preview and runs only on the GitHub Copilot harness. The agent keeps a separate store for every user in Microsoft-managed storage: it captures preferences and relevant context (Capture), stores them as files in the user’s own folder (Store), and reads them back in later interactions (Apply). Memory is switched on and off per agent via the toggle in the Build tab.

For data protection conversations in the DACH region, these points matter most:

• A user’s memories are private. Neither the maker nor other users can see them.
• After 28 days without interaction the system automatically deletes that user’s memories for that agent.
• In group chats and Teams channels Memory is disabled.
• Every user can view and completely delete everything stored in the Memory portal, or ask the agent in chat to change or forget something. On first contact in a new channel the agent shows the portal link itself.

When to Use What?

Classic Orchestration is your default for:

• Highly regulated customer-facing bots where every answer must be predictable
• FAQ and routing scenarios with clearly defined intents
• Bots that need Custom Data Sources or Bing Custom Search
• Compliance cases where the audit story “the user said X → this topic was triggered” is decisive

Generative Orchestration is your default for:

• Internal productivity agents with many tools (10+)
• Autonomous agents on event triggers (prerequisite!)
• Multi-tool chaining where one tool supplies the input for the next
• Scenarios where topics sound similar but need different actions in detail

AI Builder Prompts as Sub-Prompts

Within both modes you can embed targeted LLM sub-prompts as AI Builder actions, for example “Classify email” or “Extract the date from this text”. That gives you targeted LLM usage without forcing the agent into full Generative mode.

DLP Policies (Data Loss Prevention)

DLP policies come from the Power Platform and apply to Copilot Studio as well. You categorize connectors into three classes:

Tenant-wide policies take precedence over environment policies and cannot be overridden. Since early 2025, DLP enforcement has been active for all agents; the earlier exemptions have been abolished.

In addition, you can control via policy:

• Which tools/actions are permitted (for example “no HTTP request”).
• Which knowledge sources are permitted (for example “no public web”).
• Which channels may be published to.
• Whether agents may use No Authentication.

In practice, control works via connector names, and in the Power Platform Admin Center they are named differently from what you would search for. Hence this translation table:

Two mechanisms that projects often overlook: instead of blocking a connector completely, you can use endpoint filtering for SharePoint, public websites and HTTP and allow or forbid individual targets. And in case of a violation the Publish button is disabled; via Details → Download on the Channels page the maker gets a file with one line per violation that can be passed straight to the admin. With Set-PowerAppDlpErrorSettings you store an admin email address and a “Learn more” link tenant-wide in these error messages, one of the most effective small measures against ticket ping-pong.

Environment Strategy

At least three Power Platform environments are recommended:

Optional: personal dev environments per developer. Each environment has its own DLP policies, its own connectors, its own audit trails. Entra security groups restrict access.

Authentication (Recap)

• No Authentication: careful, external channels (Direct Line) break if “No Auth” is set internally.
• Entra ID v2 with Federated Credentials is the recommended default: no client secret rotation stress.
• SSO with Entra in Teams: the user identity is passed through automatically.
• Entra External ID: for customer and partner logins (B2C).
• Teams and Microsoft 365 tolerate only one option. The Teams + Microsoft 365 channels support Authenticate with Microsoft and nothing else. Pick any other option and those channels go into blocked status. Conversely, Authenticate with Microsoft is not available for agents integrated with Dynamics 365 Customer Service. If you need both, you need two agents.
• The variable difference will cost you the publish. Under Authenticate with Microsoft only User.ID and User.DisplayName exist; User.AccessToken and User.IsLoggedIn are missing. If you switch from manual auth to Microsoft, those variables appear as Unknown in every topic and have to be fixed before publishing. For an access token you need Authenticate manually. Its provider list now holds five entries: Entra ID V2 with federated credentials, with certificates, or with client secrets, plus Entra ID (V1) and Generic OAuth 2.
• Newly documented (as of September 17, 2026): Power BI and Entra auth are mutually exclusive. Agents using Microsoft authentication cannot be embedded in Power BI reports through iframe-based visuals. And with Generic OAuth2, anyone who signs in can talk to the agent – individual users can no longer be controlled through agent sharing. Both only surface during rollout if nobody checked beforehand.

Microsoft Entra Agent ID (Mandatory; Rollout May to July 2026)

Copilot Studio integrates with Microsoft Entra Agent ID: each agent automatically gets its own identity in Entra, similar to service principals but with its own audit story and lifecycle. Benefits:

• Audit log in Microsoft Entra (sign-in events per agent).
• Connector permissions appear as API Permissions on the agent identity, so Entra and M365 admins can see what an agent is able to do without a Power Platform login.
• Conditional Access for connector scopes (network location, device compliance, risk conditions).
• Integration with Entra ID Governance.

What this concretely triggers in the tenant: With the first agent after the rollout, Copilot Studio creates a blueprint named Microsoft Copilot Studio agent identity blueprint together with its blueprint principal in the tenant (blueprint ID 25664c89-cea5-4ab6-b924-a54fd8a19ae0). Every single agent identity hangs as a child under this global blueprint. So do not be alarmed if a principal nobody consciously created suddenly appears in Entra: that is the expected path, not an audit finding.

Existing agents: Agents created before the rollout continue to run via app registrations. Microsoft will migrate them to Agent IDs at a later date. During the transition, the governance functions work for both variants, so you do not have to migrate yourself, but your inventory list will contain two identity types side by side for a while. If you would rather not wait, you can convert existing agents yourself: through the Power Platform Admin Center, with PowerShell scripts, or via the Power Platform APIs. When an agent is deleted, Copilot Studio deletes the associated Entra Agent ID with it.

How the connector scopes really work: On publish, Copilot Studio attaches API permissions to the agent identity for every configured Power Platform connector. These scopes are honored exclusively by the Power Platform connector runtime and are re-checked at runtime against Advanced Connector Policies (ACP) and DLP. So they are a visibility and Conditional Access tool, not a way around your governance policies, and conversely their presence does not replace a DLP policy either.

Looking up the GUID: In Copilot Studio under Settings → Advanced → Metadata the GUID of the agent identity is shown as Entra Agent ID. With it you can check in the Entra Admin Center whether the identities are actually populated.

Microsoft Agent 365 (GA May 1, 2026)

Since May 1, 2026, Microsoft Agent 365 has been generally available for the commercial segment (per-user licensing, Microsoft E5 as the recommended prerequisite). It is the central governance and control plane for enterprise agents tenant-wide, not only for Copilot Studio agents but also M365, Foundry and partner agents. You see inventory, permissions, behavior and activity in one place and can apply shared policies, security controls and lifecycle oversight. In Copilot Studio, admin status information now surfaces directly in authoring (security posture per agent, auth gaps, policy impact).

What You Should Concretely Check in the Tenant

• Advanced Hunting: The table AIAgentsInfo is replaced by the new table AgentsInfo (Agent 365 is now the single source of truth for the agent inventory). AIAgentsInfo is deprecated but not yet removed. Saved queries, custom detections and workbooks must be migrated.
• Block rules: Tenants that had the old Agent 365 rules set to Block have no longer been blocking since July 1, 2026. Redefine the rules under Settings → Security for AI → Policies & rules → Real-time protection. This concerns Agent 365 real-time protection only, not the Defender for Cloud Apps path.
• Defender portal: The AI Agents sub-tab under Cloud Assets has been removed for all customers, regardless of license. All Security for AI functions now sit under the shared Security for AI Agents switch.
• Third-party agents can no longer be discovered via Defender for Cloud connectors; use Registry Sync in the Microsoft 365 agent registry instead (Preview).
• Customer Lockbox does not cover the governance, telemetry and audit events that run via Agent 365, nor the security audit logging of Copilot Studio itself (details further below).

MCP Certification (Preview Since July 2026)

From a governance perspective an MCP server is a third-party service to which you entrust tool calls and thus often data. Since July 2026 there is an official seal for this: the Microsoft MCP server certification. Microsoft validates the package and runtime behavior of a submitted server before it becomes broadly available, and the publisher remains responsible for maintaining the certified experience afterwards.

Submission goes through the Partner Center offer type Apps and Agents for M365 and Copilot. The old submission path was usable only until the end of July 2026; MCP servers that were already certified need not do anything because of the change, Microsoft migrates them itself. The prerequisite is a verified publisher with completed business verification in Partner Center, enrollment in the Microsoft 365 and Copilot program, and ownership of or control over the submitted endpoint. Independent publishers without their own service may not submit.

What you get out of it as a customer: The list of certified MCP servers is in the connector reference and serves as a basis for an allow list. For assessing a non-certified server nothing changes: it remains allowed, but you carry the review yourself. A sensible governance rule is therefore not “certified MCP servers only” but “certified or your own documented approval”. As an aside: Microsoft supports only ASCII header names and values in manifest and tool files; umlauts in the manifest make validation fail.

Knowledge Source Permissions

When SSO is active and you connect SharePoint, Graph or Dataverse as knowledge, the agent inherits the user’s permissions. This is one of the most important security features: an employee only sees knowledge they are allowed to see anyway.

Without SSO, everything runs in the context of a maker or service account. That is usually NOT what you want, and it is the source of many data leaks.

Protection Status: The Security Traffic Light per Agent

Governance rarely fails for lack of policies, but because nobody sees which agent is currently violating them. That is exactly what the Protection status column on the Agents page in Copilot Studio is for. For every published agent it shows one of three states: Protected (green shield, no action needed according to detected signals), Needs review (policy violation or insufficient authentication) or Unknown. The point for maker enablement: the traffic light sits where the maker already works, not in the Admin Center.

A click on the status opens a summary that breaks the security profile down into three categories, each again with Protected, Needs review or Unknown:

If Authentication or Policies is at Needs review, that propagates to the overall status in the agent list. Content moderation deliberately does not.

Security Analytics: What Was Actually Blocked

Via See details you reach the Security analytics dialog with statistics and trends over the last 7, 14 or 30 days (periods without data do not even appear in the picker). Two views are relevant in practice: the stacked bar chart Reason for block breaks all blocked messages down by block reason: potential threats, policy violations, content moderation. The Session block rate trend graph shows per category the share of sessions with a blocked request over time, so whether a spike is a one-off or a pattern.

Automatic Security Scan Before Publish

Agents are securely configured out of the box. Because makers soften these defaults for understandable reasons without knowing the risk, an automatic security scan runs before publishing and warns the maker. Three deviations trigger the warning:

• Authentication set to No authentication. Default is Authenticate with Microsoft; with no auth anyone with the link can talk to the agent.
• Connectors and flows switched to Maker-provided credentials. Default is End user credentials, that is, the rights of the respective user. The switch means: everyone sees what the maker is allowed to see.
• Agent shared with everyone in the organization. Default is “shared with nobody”.

The scan is a warning, not a gate: it does not block publishing but forces a conscious decision. For a governance concept this means you should still lock down these three points hard via data policies if they are non-negotiable in your organization. In addition, Copilot Studio continuously assesses knowledge, tools and actions for possible data leakage and security risks during configuration, so findings become visible before publish rather than after.

Audit Logs via Microsoft Purview

Studio agents log to the Purview audit log. Logging happens at SDK level, so a single action often triggers several events. Roughly three classes:

• Admin and maker actions on the agent itself: BotCreate, BotDelete, BotDeleteCleanup and the BotUpdateOperation variants for name, icon, authentication, publish and share.
• Component changes: BotComponentCreate / -Update / -Delete for topics, skills and entities, plus component collections, AIPluginOperation* for AI plugins, EnvironmentVariable* for environment variables and BotAppInsightsUpdate for changes to the Application Insights configuration.
• Usage: CopilotInteraction for every interaction of a user with an agent.

Compliance admins work in the Purview portal under Solutions → Audit. Developers get the same data via the Office 365 Management API.

Switching off only works halfway. Capturing administrative activities is active by default on all tenants and cannot be disabled. What you can do: switch off the audit log tenant-wide in Purview and use a data lifecycle management policy with retention of 0 days for “Copilot Experiences” to prevent user and response text from being retained. Two prerequisites are easy to miss: users need an assigned Microsoft 365 license for events and transcripts to be written at all, and in FedRAMP tenants none of this applies.

Two more details for practice: for agents with an Entra Agent ID the authentication activity additionally lands in Microsoft Entra ID and is visible in the Entra Admin Center, so the governance story spans two portals. And individual channels are excluded from logging. Which channel generated an event is shown in the audit solution in the JSON field CopilotEventData as AppHost, in DSPM for AI as App accessed in. If events are missing, the channel is the first suspect, not the policy.

Further Governance Controls at a Glance

Microsoft lists a number of controls in the governance overview that are rarely all known in projects. The most relevant ones besides DLP, Entra Agent ID and Purview:

MIP Labels & Sensitivity (Preview Since July 2025)

Microsoft Information Protection (MIP) sensitivity labels have been passed through in Copilot Studio since July 2025: connectors, Test Chat, Teams and M365 Copilot show the label of the source document. Files labeled confidential or highly confidential return no content in Generative Answers, which is good for oversharing prevention but can create knowledge gaps. The Purview integration with Dataverse classifies sensitive data automatically.

Responsible AI Guardrails

• Disable topics with a single click, without having to delete them.
• Define Allowed/Disallowed Topics: what the agent may (or may not) answer at all.
• Content Moderation on Generative Answers: standard toxicity and PII filters.
• Restrict to defined topics toggle: generative answers only when a topic was matched.
• Conversation Boosting Off: no free-form LLM chatter outside the topics.
• Citations mandatory for Generative Answers: the user sees the source.

Studio offers four ways to bring a human into the workflow, plus, since November 2025, approval gates per tool step for autonomous agents.

1. Adaptive Card with Approval Button

With “Ask with Adaptive Card” you send a card (“Approve / Reject”). The agent waits for the submit, parses the response into a variable, and continues.

• Good for: Quick inline confirmations in the chat.
• Limit: Only within the active chat context.

2. Power Automate “Approvals” Action

The classic Power Automate approval action (Teams or Outlook approval card): the agent calls a flow that blocks on the approval and waits for the response.

• Good for: Asynchronous approvals (over hours or days).
• Limit: The Power Automate license costs extra.

3. Agent Flow “Request for Information”

Since 2025, agent flows have a dedicated HITL action: the flow pauses, sends a structured email (via Outlook) with input fields, collects the response directly from the email, and continues.

• Good for: Structured off-system reviews.
• Limit: Currently Outlook is the only channel.

4. Hand-off to a Live Agent

On hand-off, the entire conversation context (variables + transcript) travels along, so the human agent does not have to start “from scratch.”

Approval Gates per Tool Step (November 2025)

Since November 2025 you can set an approval gate per tool/action in autonomous agents: the agent only performs the step once a defined approver agrees.

Important for: Cost thresholds, policy validation, sensitive data operations.

Human Supervision for Computer Use

Computer Use tools have their own human supervision field: when “potentially harmful instructions” are detected (for example a prompt injection on a website), a defined reviewer is notified via Outlook. Good to know: the reviewer only sees the run context if they initiated the run themselves; otherwise they have no view of what is happening. A response time limit setting decides whether the run waits or aborts.

Smart Approval with Conditions

Combine conditions with HITL to request approval only when it is needed:

Agent flow: extract invoice amount

Condition: amount > €1,000?
├─ Yes → Request for Information (manager approval via email)
│        → SAP connector: post payment
└─ No → SAP connector: post payment directly

That gives you automation for routine cases and control for exceptions.

Draft vs. Published

• Draft: the version you edit in Studio. Tests in the test pane run against the draft.
• Published: the live version that users see on the channels.
• Every click on “Publish” creates a new published version. Studio keeps the history (restore is possible).

Solutions (ALM Containers)

Best practice: always work in a solution with your own publisher and prefix. A solution can contain:

• Agents
• Topics
• Agent Flows / Cloud Flows
• Connection References (instead of fixed connections)
• Environment Variables (instead of fixed values)
• Dataverse tables, AI prompts, custom connectors

Dev → Test → Prod

Four deployment mechanisms:

Component Collections (November 2025): quick export and import of topic, tool and knowledge bundles via the sidebar, including child agents and MCP connector types. Helpful for reuse across several agents.

Agent Evaluations as a CI/CD gate (GA March 2026, REST API in preview April 2026): mandatory test sets before a prod deployment, Custom Graders for domain-specific pass/fail criteria, multi-turn conversation tests. Test results stay visible in Studio for 89 days and can be exported as CSV.

Expansion of evaluations in September 2026: via the Message Center (RM569607), Microsoft is rolling out an extended evaluations experience as generally available. New are more detailed explanations for every result, the agent’s reasoning traces, the cited Knowledge Sources per test case, the comparison of two evaluation runs, support for larger datasets, configurable test case generation and the generation of test data directly from Knowledge Sources. Added to that is a pre-validation that reports configuration errors before a run starts.

Two details from the evaluations documentation that are regularly looked up in projects: Copilot Studio measures the response time per interaction in seconds, end to end including reasoning, tool, connector and workflow steps, a pure metric without pass/fail effect, well suited for before-and-after comparisons. And there is a dedicated sharing role Agent Viewer: whoever receives it may view, start, rename, cancel and delete other makers’ test sets, but may not change the agent itself, not publish it and not manage sharing. Status and metrics of a run are visible to all makers, the agent answers and result explanations only to the person who started the run.

Best practices:

• Managed solution in Test & Prod, unmanaged only in Dev.
• Environment Variables for API URLs, connector endpoints, etc.
• Connection References for connector connections (the solution can travel without hard-wired credentials).
• After deployment: post-deploy configuration for the Application Insights connection and manual auth settings (they are environment-specific).

Model Lifecycle: The Deployment Case Almost Everyone Forgets

In August 2026 Microsoft published a dedicated guidance series on the model lifecycle, and it closes a gap that exists in almost every project: a model change is treated like a dropdown change but behaves like a migration. A newer model interprets instructions more literally, chooses tools differently, answers in a different length and format and brings different latency. The documentation’s guiding principle: build flexibly, operate conservatively, secure every upgrade with an evaluation.

The documented cycle for production agents has seven steps: Discover (find new, changed, new-default and retiring models), Inventory (which agents, environments, owners and business processes depend on them), Evaluate (measure the candidate against an established baseline), Approve (according to documented quality and operating criteria), Deploy (via the normal ALM path), Monitor (observe production, add newly discovered cases to the regression suite) and Repeat. You also trigger a review when a model becomes available in your region, when the default changes, when a deprecation or automatic upgrade is announced, or when monitoring shows quality, latency or consumption problems.

What you should record per agent so that an announced deprecation does not turn into firefighting: name, agent ID, environment and environment type, business criticality, business and technical owner plus tester and approver, the configured model including release tag, whether the agent follows the default or uses a fixed model, cross-geo needs and regional requirements, the harness used (it decides which evaluation methods are available at all), the location of the regression test set with the date of the last baseline run, and whether the retired-model window is used, when it expires and who approved it.

You do not have to do the inventory by hand. In the Power Platform Admin Center, Manage → Copilot Studio shows a Model column across all agents in the tenant, filterable and exportable; under Licensing → Copilot Studio → Environment → Message consumption details there is additionally the LLM Model column including consumption. Programmatically, the Inventory API returns name, display name, environment and model in a single tenant-wide query; prerequisites are the Power Platform or Dynamics 365 administrator role, an access token for https://api.powerplatform.com/ and an Agent Inventory enabled for the tenant.

POST https://api.powerplatform.com/resourcequery/resources/query?api-version=2024-10-01
Authorization: Bearer <access-token>
Content-Type: application/json

{
  "TableName": "PowerPlatformResources",
  "Clauses": [
    { "$type": "where", "FieldName": "type", "Operator": "in~",
      "Values": ["'microsoft.copilotstudio/agents'"] },
    { "$type": "project", "FieldList": [
        "name",
        "properties.displayName",
        "properties.model",
        "environmentId = tostring(properties.environmentId)"
      ] }
  ],
  "Options": { "Top": 200 }
}

// Response: properties.model comes back as properties_model.
// If there are more hits than Top: send the skipToken from the
// response back as Options.SkipToken and repeat.

If you group the result by properties_model, you see at a glance where which model is used in the tenant; in case of a deprecation you filter the same list for the retiring model and have the affected agents with environment ID for contacting the owners. For a single environment, pac copilot list --environment <id> from the Power Platform CLI is enough, but the command returns no model; for that you need the Inventory API.

Channel Publishing

Each channel has its own publish pipeline:

• Teams / M365 Copilot: Studio generates the app manifest; it has to be approved by a Teams admin before users can install it. Personal scope first, then team/channel scope optionally via a manifest tweak.
• Web: embed code for your own sites.
• Custom (Direct Line): secret Direct Line token; use it in your own app.
• Voice: D365 Contact Center provisioning.
• Teams Phone Agent (Preview since June 2026): the Copilot Studio voice agent attaches to a Teams Phone Agent and takes over specialized requests such as billing, order status or prescription refills. Handover and return run seamlessly, transfer targets come as tags from a tag template in the Teams Admin Center instead of being hard-coded in the agent. The channel is gated: the tenant has to be enabled via Microsoft Support, otherwise the option does not appear at all.
• SharePoint / Power Pages: embed web part.

Environment-Level Telemetry with Application Insights (Preview Since July 2026, Reworked in September)

Until July 2026 you had to wire up Application Insights per agent. Since July 2026 the export can be enabled in the Power Platform Admin Center for an entire Managed Environment: an export package of type Copilot Studio, and all agents in the environment deliver traces. For operations this is the real leap: you see agent runs, node and tool executions, can build alerts and write your own dashboards and queries without every maker having to think of it. As of the documentation dated September 17, 2026 this explicitly covers agents on both harnesses, the standard one as well as the GitHub Copilot harness.

Two details that break existing dashboards: after the end of the private preview, Microsoft emits an agent’s root invocations (invoke_agent) as dependencies instead of, as before, requests. Older root traces may therefore still show up in the requests table – anyone analyzing across both periods has to handle that in the query. And delivery takes up to 24 hours on a newly created configuration: if nothing arrives after you switch it on, that is first a question of patience and only then a fault. If you want to analyze at environment level exclusively, the documentation describes how to switch agent-level telemetry off.

Rollback / Restore

Studio keeps the published versions, so you can return to an earlier one. But solution deployments are “forward-only”: a rollback between environments runs via re-deploying an earlier solution version.

Pricing Models in Detail

Since September 2025 the unit is the Copilot Credit, no longer the “message.”

Credits are pooled tenant-wide. Since March 2026 Microsoft has published official billing rates:

Reasoning models are billed twice: feature rate + AI Tools premium rate (e.g. Generative Answer with a deep model = 2 credits + 100 credits / 10 responses).

Voice billing per minute: Classic voice (Classic Orchestration) 10 credits/min, GenAI voice 35 credits/min, premium GenAI voice 75 credits/min. The core agent activity (classic or generative answer, agent action) is already included in the per-minute rate.

Rule of thumb: A conversational sales lead qualifier costs $0.15 to $0.80 per conversation; an autonomous mail triage agent $0.30 to $2.00 per email; a Computer Use run with 10 steps roughly $0.50 (standard) to $1.50 (premium).

Usage-Based Billing of the GitHub Copilot Harness

Everything mentioned so far applies to the Standard harness: fixed billing rates per feature, billing from publish onward. Agents, workflows and apps on the GitHub Copilot harness are billed differently, and that is currently the most expensive misconception in projects.

The billing documentation (as of August 27, 2026) literally names agents, workflows, and apps as the scope. With the launch of app building in September 2026, every generated app therefore also falls under this model; include them in pilots from the start instead of treating them as a free by-product.

What September adds: on September 15, 2026 Microsoft published three roadmap entries on cost transparency, all targeting GA in September 2026 with status In development: RM571194 will surface costs directly in the preview chat and the agent history, RM571195 breaks them down in agent evaluations by evaluation generation, test runs, and model grading, and RM571196 brings them into the Monitor tab per agent, including an estimated breakdown across the lifecycle from authoring through testing and evaluations to production. That is exactly what is missing today: the build budget is spent, but nobody can say on what. Until this ships, the only reliable view is the consumption view in the Power Platform Admin Center.

Enforcement here is harder than the 125 percent rule: If an environment has no assigned credits left or all are consumed, every function that needs credits stops. End users no longer get answers, makers can no longer author via natural language, no longer test in the preview and no longer generate evaluations. Both groups see the same message that credits are missing. Microsoft allows a certain overage as a goodwill buffer so that business processes do not break off abruptly, but guarantees no amount. The three ways out: reallocate capacity from the tenant or another environment, buy additional capacity, or set up a PAYG meter for the overage.

Credit Governance: The Environment Is the Unit

Since September 17, 2026, there is a dedicated guidance article on this. The core message: because the GitHub Copilot harness consumes credits while you build, test and evaluate, governing only published agents isn't enough. Governance starts at the environment level from day one. Important: developer and trial environments have been on usage-based billing since September 1, 2026. Consumption data from before that date is only directional, not a cost forecast.

Microsoft recommends classifying every environment into one of three classes: exploration and prototyping (fixed boundary, development limit per agent, documented path to more capacity), test and validation (time-bound capacity for representative evaluations) and funded production (clear cost owner, limits based on criticality). For a hard prepaid boundary, allocate a fixed amount, turn off Draw from the available capacity in my tenant and don't connect PAYG. You find the affected agents through Power Platform Inventory: the properties.harness field with the value GitHub Copilot filters them out.

Overage Enforcement of the Standard Harness (125% Rule)

When the tenant reaches 125% of its prepaid capacity, Microsoft deactivates all custom agents (it waits for the conversation to end). The admin is notified by email and in the Power Platform Admin Center. Workaround: activate a PAYG meter or reallocate capacity. Agent Flow enforcement is separate: at full capacity, new flow runs are blocked while other agent features keep running. Tip: set a monthly spend limit per agent in the Admin Center before it escalates.

Known Limits (As of August 2026)

Rate Provisioning: Throughput Is Not Licensing

Since June 2026 Microsoft’s architecture guidance cleanly separates two things that are often confused in projects. License provisioning is the commercial question: licenses, credits, prepaid capacity, PAYG. Rate provisioning is the technical question: how fast requests may arrive before throttling kicks in. You can have enough credits and still be throttled.

The limits in the table above apply, depending on the service, at agent, environment, tool, connector or channel level, and the lowest limit in the runtime path determines the user experience. The agent can stay within its limits while a flow, a connector, a Dataverse call or a downstream API is already throttling. Messages to an agent, for example, are counted per Dataverse environment, that is, including all other agents and autonomous workloads in it.

So do not calculate in monthly volumes but in peak windows: requests per minute and per hour. A one-hour campaign peak topples a setup that looks harmless on a weekly average. The first response should be design optimizations, not a limit request: place external calls deliberately, spread high-volume agents across separate environments, smooth autonomous runs via queues, batches and trigger filters, pull reporting and telemetry out of the interactive path. Only once that is in place is the support request in the Power Platform Admin Center worthwhile. It is needed before UAT and load testing, not after the first production failure, and an increase is never guaranteed.

New since September 2026: the guidance now describes how to back up an increase request: run a representative pilot phase, measure peak usage, extrapolate to the full user base and attach exactly those numbers to the request. Without pilot data, the request remains an estimate.

Cost Drivers

1. Generative Orchestration: every user turn = at least 1 LLM call for topic/tool picking.
2. Knowledge querying: every Generative Answer = embedding + retrieve + synthesis = several credits.
3. Autonomous agents with high event volume: e.g. mail triage on 10,000 emails/day = four-figure credits per day.
4. Deep Reasoning: multi-step planning is significantly more expensive than single-shot.
5. Tool chaining: every tool call can trigger another round of LLM reasoning.

Rule of thumb: Estimate credits = (conversations/month × average user turns × ~5 credits/turn) plus knowledge hits.

1. Start with Classic Orchestration for regulated use cases. Generative is powerful but less predictable, and compliance loves deterministic paths.
2. Every agent in its own solution. Otherwise ALM deployments turn into a jumble with unintended co-deployments.
3. Environment variables for everything environment-specific. API endpoints, group IDs, SharePoint URLs: the solution then moves cleanly between environments.
4. Enable SSO as soon as you connect knowledge to SharePoint/Graph/Dataverse. Otherwise everything runs in the maker context and users see things they are not allowed to see.
5. In Generative Orchestration, topic descriptions matter as much as their content. Describe precisely when a topic should be selected, not what it does.
6. At most one clear task per tool. “Helper tool that can also do X” → Generative Orchestration mixes them up. Split it.
7. Build in HITL from the very first step if the agent is autonomous. Better too many approval gates at the start; removing them is easier than cleaning up incidents after the fact.
8. Conversation boosting off + Generative Answers only from configured knowledge sources. Otherwise the agent hallucinates “creatively” about topics you do not control.
9. Power Fx is your friend for logic, but do not overuse it. Move more complex logic into an agent flow (easier to test).
10. Test in multi-channel mode, not just in the Studio pane. Adaptive Cards, SSO, and auth tokens behave differently in Teams/web/Direct Line than in the test bot.

Top 5 Failure Patterns

Common Pitfalls

Pitfall 1: “Topic Found, but Nothing Happens”

Usually connector auth: Connection References with a broken credential mean silent failures. Check the connection first, then the topic.

Pitfall 2: Adaptive Card Looks Fine in Studio, Broken in Teams

Teams uses an older card schema version plus a 28 KB limit. Always test in Teams, not just in Studio.

Pitfall 3: Generative Orchestration “Loses” Topics

Once you have 50+ topics, the descriptions become too similar and the LLM picks the wrong one. Fix: sharper descriptions, or go back to Classic.

Pitfall 4: SharePoint Knowledge Shows Only Snippets, Not the Whole File

If you only have an M365 E3 license (no M365 Copilot), the 7 MB limit applies. Larger files? Split them or upgrade the license.

Pitfall 5: “Why Is My Agent Answering Things It Shouldn’t?”

Conversation Boosting is set to On (default). Toggle it off and turn on “Restrict to defined topics”.

Pitfall 6: Publishing to Teams Hangs for Weeks

The Teams admin has to approve the app catalog entry. Often there is no approval process in place. Clarify the process first, then deploy.

Pitfall 7: Power Automate Flow Does Nothing in the Run Log

If you use an old Power Automate cloud flow as a tool, it runs under a different service account: permissions may be missing where they worked in your own test.

Pitfall 8: MCP over SSE Breaks After August 2025

SSE was deprecated in August 2025. Streamable HTTP is now mandatory for connecting MCP servers.

Pitfall 9: “My Autonomous Agent Doesn’t Fire.”

Generative Orchestration has to be on; otherwise event triggers are not visible in the UI.

Pitfall 10: “Agent Disabled, Billing Issue”

You have exceeded 125% of your prepaid capacity → overage enforcement kicks in. Confirm in the Power Platform Admin Center whether you want to reallocate capacity or activate PAYG. For Agent Flows: separate enforcement, blocks only new runs.

Pitfall 11: Real-time Voice Does Not Work in an EU Tenant

Real-time Agents are hosted only in North America (GPT-Realtime) and, since June 2026, in Australia (GPT-Realtime-Mini). EU Data Boundary tenants cannot use the feature, because the cross-geo processing this requires is prohibited in the EU. Outside NA/Australia, cross-geo processing must be explicitly allowed.

Pitfall 12: “Generative Answers Returns Nothing Even Though the SharePoint File Exists”

Likely cause: the document carries an MIP sensitivity label confidential or highly confidential. These files show as “ready” but do not return any content.

Pitfall 13: Generative Orchestration Ignores the Conversational Boosting System Topic

Known limitation: in Generative Orchestration, modifications to the Conversational Boosting system topic are not taken into account. Custom data sources and Bing Custom Search are likewise only available via the Classic data option in the Generative Answers node.

Pitfall 14: Multiple Topics Matched System Topic Does Not Disambiguate

Generative Orchestration currently does not invoke the Multiple Topics Matched system topic. Turn the topic off while testing; turn it back on once Microsoft ships the disambiguation fix.

Pitfall 15: The Agent Answers Twice, or Not at All

At the end of August 2026 Microsoft documented why this happens, and the cause is structural, not a bug. The Standard harness distributes context across the components involved. Each component works from its own context, and the orchestration layer does not reconcile the context at the top level. As long as a component is running, the orchestration layer does not see its messages to the user. Result: a request looks unanswered, so someone answers it a second time.

Context flows in on two paths (explicit inputs plus implicitly passed conversation context) and back out on two paths (explicit outputs plus implicit context). Whatever a component only shows to the user or only keeps in its own variables never reaches the orchestration layer. According to Microsoft, around half of the cases with duplicate or missing answers are due to this implicit passing.

Adaptive Cards are the most common trigger. Only plain text comes back implicitly from topics (message nodes, question nodes, card content, typed user answers), and without the information whether the user has seen it. Action buttons of an Adaptive Card and the clicks on them never reach the context of the Standard harness at all. So never rely on card content as context: return everything a later step needs as a topic output and additionally set an output that records the answered status.

Sub-agents are the second trigger. A child agent runs inside the parent and always receives its conversation context, with no way to switch that off. For a connected agent you control this via a setting. If the passed context contains a request that looks unanswered, the sub-agent tries to compensate and answers a second time.

Pitfall 16: Activity.Text is empty although the user wrote something

Anyone using Activity.Text for logging will find gaps in production, and the cause is not a bug. When the agent calls a knowledge source for lack of context, Activity.Text stays empty for that turn: the agent constructs no natural-language response of its own because it delegates the decision to the knowledge source. The same happens with tools that are activities by design. The variable picks up any activity handed to the agent, not the previous user message. The documented fix is simple: use LastMessage.Text when you need the last user message, and Activity.Text only where you really mean the activity.

Two aggravations on top. The OnPlanComplete trigger executes only after the tool has finished. If a knowledge source was used, its output is written straight into the activity – and because Activity.Text was empty beforehand, what ends up there is the tool usage details rather than a conversational message. With intent-based or natural-language triggers this does not happen, because they fire earlier and the activity already contains a constructed message. And in Teams it is far more visible than in Copilot Studio, because Teams surfaces activity objects directly while Copilot Studio normalizes them. The same agent therefore behaves visibly differently depending on the channel, without anything in its logic having changed.