Most comparisons between the Copilot Studio classic experience and the new agent experience focus on what changed in the authoring interface — Topics disappeared, Skills appeared, the canvas gave way to a tab-based surface. That framing misses the actual story.
The interface changed because the engine changed. And not just once — Copilot Studio now ships with three distinct orchestration models, each built on a different runtime architecture, each with different behavior, different debugging tools, and different tradeoffs. Choosing the wrong one for a given scenario produces an agent that either fails silently or behaves unpredictably, no matter how well the rest of the solution is designed.
This article goes under the hood. It describes how each of the three orchestration models processes a request from the moment the user sends a message to the moment the agent responds — and what that means architecturally for the people who build on top of them.
The three orchestration models covered in this article
- Architecture 1 — Classic State Machine: the original Copilot Studio engine. Deterministic, topic-driven, fully explicit. The developer authors every conversation path.
- Architecture 2 — Standard Generative Orchestration: an LLM-based planner that generates a single execution plan per turn. Available in both the classic experience (with generative mode enabled) and the new experience.
- Architecture 3 — Agentic Reasoning Loop (New Orchestrator): the default engine in new-type agents. An iterative loop that plans, acts, observes results, and adapts the plan within a single turn until the user’s goal is reached.
Each model is examined the same way: what the runtime does when a message arrives, what the developer controls versus what the engine decides, and what breaks if the configuration is wrong.
Three Engines, One Platform
Before diving into each architecture individually, the diagram below maps the key dimensions side by side — execution model, authoring unit, mid-execution pivot capability, output variability, and debugging surface.
Copilot Studio · Runtime Architecture
Three Engines. One Platform.
Choosing the wrong engine at design time means re-authoring from scratch — there is no migration path between them.
Architecture 1 — The Classic State Machine
The classic engine is a conversation state machine. The developer authors a set of Topics — discrete conversation units, each with trigger phrases and a node graph. When a user sends a message, the engine finds the best-matching topic and executes its graph node by node. Every path through the conversation is explicit. The engine adds nothing, infers nothing, and varies nothing.
Same input → same output, every time. This is what “deterministic” means in practice.
How a Request Is Processed: Step by Step
The diagram below maps the full request lifecycle — from NLU scoring through topic selection, state machine execution, slot filling, and topic completion.
Architecture 1 · Classic State Machine
The State Machine Request Flow
Every branch, every message, every condition is authored explicitly. The runtime adds nothing.
Step 1 — NLU Scoring
The user message is evaluated against every trigger phrase across every topic using a Natural Language Understanding (NLU — the component that interprets what the user said and maps it to a defined intent) model. Each topic receives a confidence score. Three NLU options are available:
- Built-in NLU (default): out-of-the-box model supporting trigger phrases, predefined entities, and custom entities.
- NLU+: grammar-based enhanced model for large enterprise agents; guarantees exact match with annotated training data; requires a Dynamics 365 Contact Center license.
- Azure CLU (Conversational Language Understanding): bring-your-own Azure AI Language model, integrated via connector, for scenarios where the built-in model is insufficient.
Step 2 — Topic Selection
The topic with the highest confidence score above the disambiguation threshold is selected. Two special cases apply: if multiple topics score similarly, the “Multiple Topics Matched” system topic fires and presents options to the user; if no topic reaches the threshold, the Fallback topic fires.
Step 3 — State Machine Execution
The agent enters the selected topic and traverses its node graph. The available node types are: Message nodes (send fixed text), Question nodes (prompt for input, store answer in a variable), Condition nodes (evaluate variables and branch), Action nodes (call Power Automate flows, HTTP endpoints, or connector actions), and Redirect nodes (transfer execution to another topic).
Step 4 — Slot Filling
When a question node is reached and the required variable is not yet populated, the agent pauses and waits for the user’s answer. The developer designs exactly which question to ask, in what order, and how to handle each possible answer. Nothing is inferred automatically.
Step 5 — Topic Completion
The topic ends and control returns to the idle state, or a redirect node transfers execution to another topic. Every transition is explicit in the graph.
The Generative Fallback Layer
The classic experience optionally supports a generative orchestration mode — a layer that sits above the state machine. When no topic matches a user message, the generative layer can produce an answer from connected knowledge sources instead of falling back to the default Fallback topic.
💡 Important distinction
Generative mode does not change the authoring model. The state machine remains the primary execution engine. Generative mode is a safety net for unhandled intents — it does not give the engine the ability to plan, compose tools, or adapt dynamically. Think of it as: deterministic scaffolding with a generative fallback.
When Architecture 1 Is the Right Choice
- Processes where every conversation path must be auditable and predictable.
- Regulatory or compliance scenarios where output variability is not acceptable.
- High-volume, low-complexity interactions where the full set of possible intents is known and stable.
- Maintaining or extending existing classic agents — there is no migration path to the new engine.
Architecture 2 — Standard Generative Orchestration
Standard Generative Orchestration replaces the state machine with an LLM-based planner. When a user sends a message, the planner generates an execution plan — an ordered list of steps — and the runtime executes it. The developer does not author conversation paths. Instead, the developer describes components (tools, knowledge sources, child agents, skills) and the planner composes them at runtime based on the user’s intent.
This model is available in two contexts: in the classic experience with generative orchestration mode enabled, and in the new experience. The key distinction from Architecture 1: the developer configures what the agent can do. The planner decides how to do it.
The Components the Planner Works With
- Orchestrator (planner): the LLM-driven core. Receives a user message or autonomous trigger event and produces a structured plan. The plan is generated fresh at runtime for each turn — it is never pre-authored.
- Knowledge layer: read-only retrieval sources — SharePoint, Azure AI Search, Dataverse, Microsoft 365 organizational data via Microsoft IQ (the organizational data layer that connects Copilot to enterprise content) — that the planner queries to ground answers in factual content.
- Tools and connectors: external actions the planner can invoke — APIs, Power Automate flows, MCP (Model Context Protocol — an open standard for connecting AI agents to external services) servers, connector actions.
- Skills: named, reusable instruction sets that load on demand. A Skill describes when to use it, what tools it relies on, and the procedure to follow. Covered in depth in a dedicated section below.
- Event triggers: mechanisms that start the orchestrator without a user message — scheduled timers or event-based triggers such as a Dataverse record update or an inbound email.
The Four Decision Levels: The Most Important Thing to Understand
This is the single most important thing to understand about Standard Generative Orchestration. The planner does not make a single routing decision — it reads metadata at four distinct levels, in priority order, before generating a plan.
Architecture 2 · LLM Planner
The Four Planner Decision Levels
The planner never reads your tool’s code — only its name and description. That’s the only surface you control.
Level 1 — Agent Instructions (highest priority, always loaded)
Top-level behavioral guidance: the agent’s purpose, its persona, cross-cutting rules that apply to every turn. These are loaded into the planner’s context on every single turn, regardless of what the user asks. Because they are always present, they consume context tokens on every turn. The rule: put here only what genuinely applies to every conversation. Everything scenario-specific belongs in a Skill.
Level 2 — Child Agent / Connected Agent Name and Description
When the plan requires delegating a step to a child or connected agent, the planner reads the agent’s Name first (higher priority) and Description second (tiebreaker). A child agent named “Account Agent” routes account-related intents correctly on name alone. The Description carries what the name cannot — what this agent does in detail, and critically, what it does not handle.
Level 3 — Tool Name and Description
Same priority pattern as Level 2. A tool’s Name carries the primary routing signal. The Description adds the attributes the Name cannot express: what kinds of inputs the tool accepts, what scenarios it is designed for, and when not to use it. If the planner keeps calling the wrong tool, the problem is almost always in the Name or Description — not in the user’s message.
Level 4 — Input Descriptions (the most underestimated level)
Input descriptions tell the planner not just what value to supply for a given parameter, but exactly how to format it. An input described as “Search query that includes state in the format of two-digit state code in all caps” instructs the planner to translate “Texas” into “TX” — not “texas”, not “Texas”. Without that description, the planner guesses the format. The tool call fires with the wrong value and returns nothing.
🔑 The Golden Rule
Names and Descriptions are not labels for human readers. They are the machine-readable metadata the planner uses to decide what to invoke and how. A vague tool Description is a tool that fires at the wrong time or never fires at all. A vague input Description is a tool that fires with incorrectly formatted arguments.
Descriptions in Practice: What Vague Looks Like vs. What Works
The diagram below shows real examples for each level — what a vague description produces and what a precise one enables.
Architecture 2 · LLM Planner
Writing Descriptions That Route Correctly
A vague description is a broken tool. The planner cannot call what it cannot understand.
A Concrete Execution Example
A user sends: “What are the accounts in Texas, and get me the full details on each of them?”
- Planner reads: agent Instructions (full text), all child agent Names+Descriptions (metadata only), all tool Names+Descriptions (metadata only), all Skill Names+Descriptions (metadata only).
- Planner generates plan: delegate to Account Agent → call FindAccount with search=”TX” → call GetAccountDetails for each result in parallel.
- Runtime invokes Account Agent. Account Agent’s planner invokes FindAccount; the input Description formatted “Texas” as “TX”.
- FindAccount returns a list of four accounts.
- GetAccountDetails invoked once per account — four parallel calls.
- All four results assembled. Planner synthesizes a final response. One user message. One plan. Multiple tool calls. Zero branches authored by the developer.
Note: if the user follows up with “get me the details on them” — using the pronoun “them” — the planner resolves “them” against prior turns in the conversation history before generating the next plan step. Pronoun and context resolution is the planner’s responsibility, not the developer’s.
Automatic Slot Filling
In the classic state machine, missing inputs require manually authored question nodes. In Standard Generative Orchestration, this is automatic. When the planner needs to invoke a tool but a required input value is absent from the conversation, it generates a clarifying question on its own — using the input’s Name and Description as the basis for the question’s wording.
⚠️ Watch out: use human-readable input names, not technical identifiers. An input named startDt produces an awkward or incorrect auto-generated question. An input named start date produces a natural one.
When Architecture 2 Is the Right Choice
- New conversational agents that need to compose multiple tools or knowledge sources per turn.
- Teams that need full visibility into every planner decision for tuning and debugging (via Activity Map and Get Rationale).
- Scenarios where the full set of possible intents is not known in advance, but predictable per-step behavior matters.
- Agents that must handle ambiguous or multi-intent user messages without requiring explicit branching.
Architecture 3 — The Agentic Reasoning Loop
The Agentic Reasoning Loop is the default orchestrator in new-type agents — agents created in the new experience. It shares the same components as Standard Generative Orchestration — planner, knowledge layer, tools, skills — but operates on a fundamentally different execution model.
Standard Generative Orchestration generates a complete plan and executes it linearly. The Agentic Reasoning Loop does not commit to a complete plan upfront. Instead it operates as a continuous loop within a single conversation turn:
Plan → Act → Observe → Iterate
The Agentic Reasoning Loop — default in new-type agents
The loop generates the first action, executes it, observes the result, and uses that observation to decide the next action. It continues until the user’s goal is reached or an unresolvable obstacle is encountered — all within a single turn, with no intermediate messages to the user.
Architecture 3 · Agentic Reasoning Loop
The Agentic Reasoning Loop
The agent does not follow a script. It generates the next step only after observing the result of the last one.
The Loop in Detail
Plan
The planner reads the user’s goal and generates an initial action — not necessarily a complete multi-step plan. It picks the most appropriate first step based on the current context and available component descriptions.
Act
The runtime executes that step: calls a tool, queries a knowledge source, or loads and applies a Skill. The loop waits for the result before proceeding.
Observe
The planner receives the result and evaluates: did the step succeed? Does the result change what needs to happen next? Is the user’s goal now satisfied? This is where tool errors are caught — and where the Agentic Reasoning Loop diverges most sharply from Architecture 2.
Iterate
If the goal is not yet achieved, the planner generates the next action based on what it just observed. The loop repeats until the task is complete or an obstacle is unresolvable.
The Architectural Difference That Matters
Standard Generative Orchestration cannot revise its plan mid-execution. If a tool returns an error, the plan proceeds with that error. The Agentic Reasoning Loop observes the error and adapts — it selects a different tool, reformulates the approach, or escalates gracefully. This is the key practical difference.
A Real Mid-Execution Pivot
The order status example illustrates this concretely. The agent is asked about an order’s status and shipping. It calls get_order successfully, then calls get_shipment — which returns a tool error because the order has not shipped yet.
Standard Generative Orchestration reports the tool error to the user. The Agentic Reasoning Loop observes that the error means the order has not shipped, selects get_fulfillment_status as the appropriate alternative tool, retrieves the warehouse stage, and synthesizes a complete answer: “Your order is being picked in the warehouse. Expected to ship within 24 hours.” The developer did not author this pivot. The loop reasoned to it.
A Multi-System Reasoning Example
From a Microsoft lab demonstration: a user asks for a policy-compliant gift recommendation for a client. Within a single turn, the loop executes four steps autonomously:
- Queries a knowledge base → retrieves the gift policy document.
- Queries Dataverse → finds the client’s account record and primary contact name and city.
- Calls a weather API → retrieves current conditions at the contact’s city.
- Synthesizes → produces a policy-compliant, weather-appropriate gift recommendation with a citation to the policy document.
One user message. One answer. Four systems queried. No intermediate prompts to the user. No “step 1 done, shall I continue?”
When Architecture 3 Is the Right Choice
- Multi-step tasks where the correct sequence of tool calls cannot be determined upfront.
- Scenarios where tool errors or unexpected results should trigger a different approach rather than a failure.
- Users who expect a complete, finished answer in a single turn rather than a stepwise conversation.
- Complex reasoning tasks that span multiple systems and require synthesizing diverse results.
How Skills Fit Into the Orchestration Pipeline
Skills exist in Architectures 2 and 3. They have no equivalent in Architecture 1.
What a Skill Is — and Is Not
A Topic in the classic experience is a procedural script — it controls conversation flow step by step. A Skill is a declarative playbook — it describes a capability and a procedure, and the orchestrator decides when to load it based on whether the current request matches the Skill’s description.
The Microsoft CAT (Customer Advisory Team — the Microsoft team responsible for enterprise Copilot Studio guidance) blog defines the architectural role precisely: a Skill packages “when to use me” + the tools it relies on + the procedure to follow into one component. Instead of cramming every rule into agent-level Instructions, the developer gives the orchestrator a named, self-contained playbook that is pulled into context only when it is relevant.
⚠️ A Skill is not a replacement for a Topic. It is a different abstraction for a different runtime. There is no conversion path between them.
The Lazy Loading Mechanism
This is the context window architecture that makes Skill-based agents scale. The diagram below shows exactly what loads on every turn versus what loads on demand.
Architecture 2 & 3 · Context Window
Skill Lazy Loading — Context Window Architecture
Ten skills registered costs ~150 tokens. Ten skills fully loaded costs 2000+. Lazy loading is not an optimization — it is the design.
- Always in context every turn: the agent’s own Instructions (full text, always) + the Name and Description of every registered Skill, Tool, and Knowledge source (metadata only, approximately 10–20 tokens per item).
- Loaded on demand: the full content of a Skill (its Markdown instructions, bundled scripts, reference files) — only when the orchestrator selects that Skill for the current turn.
The consequence: ten Skills cost ten short descriptions per turn, not ten full instruction sets. The context window stays lean regardless of how many Skills are registered. Only the matched Skill is ever fully present.
Instructions vs. Skill: The Decision Rule
Architecture 2 & 3 · Skill Authoring
Skills — Decisions, Routing, and File Structure
Put guidance in the wrong container and it either loads on every turn — or never loads at all.
- Is this guidance true in every conversation, for every scenario? → Agent Instructions. Always-on rules, persona, universal constraints.
- Does this guidance apply only to specific scenarios? → Skill. If it is not relevant to every turn, it does not belong in Instructions.
- Is this a standalone capability that serves a different audience or crosses a security boundary? → Separate agent. Not a Skill.
Debugging Skill Routing
When a Skill fires, the train of thought in the Preview pane shows “Loaded Skill: [skill-name]” before the subsequent tool calls. This is the observable signal that the Skill’s full instructions are active for that turn.
If a Skill fires too often: its Description is too broad — tighten it. If a Skill never fires: its Description does not use vocabulary that matches how users phrase the relevant requests — rewrite it. The fix is always the Description, not the instructions inside the Skill.
Classic Topic vs. Skill — What Actually Changed
Topics and Skills are not the same concept renamed. They run on different runtimes, serve different authoring models, and behave differently at every level. The diagram below maps the full comparison.
Architecture 2 & 3 · Migration Reality
Classic Topic vs. Skill — What Actually Changed
Topics and Skills are not interchangeable. They run on different runtimes and there is no conversion path between them.
Control Layers: Governing the New Runtime
Architectures 2 and 3 operate on probabilistic planning — the engine decides what to do next. This does not mean the developer loses control. The official Microsoft guidance defines three explicit control tiers that the developer designs into the agent.
| Layer | What it covers | How it works |
|---|---|---|
| Deterministic | Mission-critical or irreversible actions — payment processing, record deletion, regulatory workflows | Implemented as tools or flows. Internal execution logic never exposed to AI reasoning. Developer either hides these from the planner entirely or wraps them in a confirmation step requiring explicit user approval. |
| Hybrid (intercept) | Medium-risk processes where AI handles reasoning up to a defined boundary | Mostly deterministic structures with AI flexibility around them. The orchestrator drafts or initiates an action, but a human approval step or rule-based checkpoint intercepts before the action completes. |
| AI orchestrator | Routine tasks — Q&A, information lookups, multi-turn reasoning | Fully generative within guardrails. The planner composes and executes plans without requiring confirmation. Boundaries defined by which tools are exposed and what Instructions say. |
The layered approach is the answer to the “probabilistic means uncontrollable” concern. The engine reasons probabilistically over what to do. The developer controls what it can do, what it can do autonomously, and where it must pause.
Custom Trigger Hooks: Intercepting the Pipeline
Architectures 2 and 3 expose three programmable hooks that allow developers to intercept the execution pipeline at specific points. These have no equivalent in the classic state machine.
| Trigger | When it fires | What it enables |
|---|---|---|
| On Knowledge Requested | Before the agent queries a knowledge source | Intercept the search phrase; route to a proprietary index; inject additional results; filter before retrieval. Advanced trigger — not visible in the UI by default; activated by naming a topic exactly OnKnowledgeRequested in YAML. |
| AI Response Generated | After the LLM drafts a response, before it is sent to the user | Post-process or rewrite the response; redact content; append tracking links; override entirely using a ContinueResponse flag. |
| On Plan Complete | After the full plan executes and the user has received the answer | Trigger end-of-conversation cleanup, surveys, or handoff flows. Use conditionally — firing this on every single turn will break multi-turn conversations. |
Debugging: Activity Map vs. Train of Thought
The debugging surface is one of the sharpest practical differences between the three architectures.
Architecture 1 — The Canvas
In the classic state machine, the canvas is the debugging surface. Every node, every branch, every condition is visible in the topic graph. If the agent behaved incorrectly, the developer traces the execution path through the graph and identifies the node where behavior diverged from intent. Fully transparent by design.
Architecture 2 — Activity Map and Get Rationale
Standard Generative Orchestration provides the Activity Map: a real-time view during testing that shows every decision the planner made for each turn — which child agent was invoked, which tool was called, in what order, with what input values, and what results were returned.
After each turn, the developer can invoke Get Rationale: a plain-language explanation of the planner’s reasoning — which goals it identified, which steps it chose, and why. Get Rationale is the primary diagnostic tool for description quality. If the rationale reflects the correct intent, descriptions are working. If it reflects something subtly different, the mismatch points directly to which Description needs rewriting.
Architecture 3 — Inline Train of Thought
In new-type agents running the Agentic Reasoning Loop, the Activity Map is replaced by an inline train of thought in the Preview pane. As the loop executes, the interface shows a “Working on it…” state followed by each action the loop takes — including “Loaded Skill: [name]” when a Skill is activated.
Every step in the train of thought is expandable. Expanding a step shows the exact parameters sent to the tool and the raw result returned. Architecture 2 exposes every planner decision in the Activity Map, making systematic tuning straightforward. Architecture 3 surfaces its work inline and is more capable — but the debugging surface is less granular.
Architecture Comparison: The Full Picture
| Dimension | Architecture 1: Classic State Machine | Architecture 2: Standard Generative | Architecture 3: Agentic Reasoning Loop |
|---|---|---|---|
| Where available | Classic experience | Classic (generative mode on) + new experience | New-type agents only |
| Core execution model | Deterministic state machine | LLM generates single plan per turn, executes linearly | LLM loops: Plan → Act → Observe → Iterate |
| Authoring unit | Topics: trigger phrases + node graph | Skills + Instructions (new) or Topics (classic) | Skills + Instructions |
| Plan authorship | Fully pre-authored by developer | Generated at runtime by planner | Generated iteratively at runtime |
| Mid-execution revision | Not possible | Not possible | Yes — adapts on tool errors or new observations |
| Slot filling | Manual question nodes | Automatic (from input descriptions) | Automatic |
| Response variability | Zero — identical for identical input | Low — may vary slightly by context | Variable — depends on tool results and loop reasoning |
| Debugging surface | Canvas + topic graph | Activity Map + Get Rationale | Inline train of thought in Preview pane |
| Transparency | Full — every branch explicit | High — every decision in Activity Map | Moderate — steps visible, not as granular |
| Best for | Scripted, auditable, predictable processes | Multi-step tasks with inspectable per-step planning | Complex tasks requiring mid-execution adaptation |
Why There Is No Migration Path
There is no tool to convert a classic agent to the new experience, or a new-type agent back to classic. This is an architectural constraint, not a product limitation.
A classic agent is a description of a state machine. Its source is topic graphs, trigger phrases, node configurations, variable assignments. A new experience agent is a set of components for a planner to reason over: Instruction text, Skill files, Knowledge source connections, Tool definitions.
These are different programs for different runtimes. A topic graph node that branches on a variable value has no mechanical equivalent in a Skill instruction file for an LLM planner — because the runtime that executes the Skill operates completely differently from the runtime that traverses the graph. There is no isomorphism between the two representations. Conversion would require re-authoring, not translating.
Choosing the Right Architecture: A Decision Framework
Use Architecture 1 — Classic State Machine when:
- Maintaining or extending an existing classic agent.
- The scenario requires guaranteed identical output for identical input.
- Every step of every conversation must be auditable through an explicit graph.
- Regulatory or compliance constraints rule out any form of probabilistic output.
Use Architecture 2 — Standard Generative Orchestration when:
- Building a new agent that needs to compose multiple tools or knowledge sources per turn.
- The team needs full per-step visibility for systematic debugging and description tuning.
- The agent must handle multi-intent queries without pre-authored branching.
- A balance between AI flexibility and step-by-step auditability is required.
Use Architecture 3 — Agentic Reasoning Loop when:
- The agent’s tasks require adapting the tool sequence based on what earlier steps return.
- Users expect a complete, finished answer in a single turn with no intermediate check-ins.
- The scenario involves reasoning across multiple systems where the right tool sequence cannot be determined upfront.
The architectural reality: all three models coexist and will continue to coexist. The question is not which architecture is more advanced — it is which one matches the problem. A compliance workflow that must produce identical output every time belongs in Architecture 1. A conversational research assistant that synthesizes data from five systems belongs in Architecture 3. Most real-world enterprise deployments will use all three, in different agents, for different purposes.
Closing Thought
The Topics-to-Skills transition is the visible surface. The real shift is deeper: from a runtime that executes what the developer wrote, to a runtime that reasons over what the developer described. Understanding that shift — at the level of how the engine processes each turn, reads each description, loads each component — is what separates an agent that works from one that works reliably at scale.
The engine is the design decision. Everything else follows from it.
