MICROSOFT / TECHNICAL EXPLAINER

Microsoft AB-100: Copilot Studio Topics, Prompt Actions, and Agent Flows

Architect Copilot Studio conversations with generative orchestration, topic contracts, fallback, prompt actions and deterministic agent flows.

In this article

Start with a conversational business contract

Copilot Studio can combine conversational topics, generative orchestration, knowledge and tools, but an agent needs a specific business task and its limits. For an employee benefits assistant, decide whether it answers approved policy questions, opens a service ticket or changes a protected record. Those are different capabilities with different identities and risk. The agent description should make permitted actions clear to users and the orchestration layer.

List possible utterances, required entities, available source systems, fallback behavior, channel constraints and how the system knows an answer is satisfactory. A generic “help with everything” agent tends to collect overlapping topics and more tools than it can safely manage. Design one bounded useful task first.

Understand generative versus classic orchestration

Generative orchestration can choose among named tools, knowledge sources, topics and agents according to descriptions and user intent. Classic topic-based flows follow more explicit triggers and paths. The Microsoft orchestration guidance explains this composition. Selecting a mode changes which capabilities and behavior are supported; do not treat every platform setting as identical in all harness versions.

A straightforward FAQ might use a deliberately scoped topic and approved knowledge. A request that requires several tools can benefit from generative selection, but each tool still requires deterministic input validation and authorization. More autonomy increases the need for traces and test cases rather than automatically increasing business value.

Design each topic as a reusable subtask

A topic should have a name and description matching user intent, typed inputs where appropriate, specific decision logic and a predictable output. When used by orchestration, it should return useful results without sending duplicate user-facing messages. A topic for finding supplier policy can return a document reference and status; the higher-level conversation can explain it once.

Microsoft’s topic design guidance highlights routing descriptions and output contracts. Test paraphrased prompts and multi-intent requests to ensure the planner chooses the intended topic instead of a similarly named but unrelated action.

Plan fallback as a service outcome

Fallback occurs when the agent cannot confidently classify the request, lacks a valid knowledge source or cannot execute the permitted operation. Different fallback states need different responses: ask for clarification, hand off to a representative, offer a safe limited answer or stop a transaction. A vague fabricated policy is not a successful fallback.

Test a user who asks for a bank detail outside the agent’s knowledge, a malformed form ID and an unavailable connector. Capture the unresolved issue in an approved support workflow with a correlation ID, without disclosing sensitive data in the chat transcript.

Choose prompts for bounded generative transformations

Prompt actions can be appropriate when the system must extract entities, summarize notes or draft text from available context. Define expected input and output rather than relying on broad instructions. Where a prompt returns JSON fields for a workflow, validate schema and allowed values independently before the application consumes the result.

An invoice email extraction might return supplier name, total and payment terms with a confidence or missing-value indicator. The workflow should verify the supplier against a master record and require approval before payments. A model’s extracted number is not authoritative financial verification.

Use agent flows for repeatable business steps

Agent flows implement supported trigger-and-action sequences in Copilot Studio and can be called through an agent. They suit consistent operations and connectors whose behavior must be predictable. An agent flow must have supported triggers and actions, appropriate solution packaging and sufficient execution capacity. A flow can run deterministically yet still require monitoring for external service failures.

Keep the agent’s reasoning for interpreting ambiguous requests separate from the flow’s typed application operation. A help-desk flow could look up a ticket and prepare an update but leave closure authorization to the original service. Add deduplication and retries appropriate to side effects rather than automatically repeating non-idempotent writes.

Connect knowledge without bypassing permissions

A knowledge source supplies context, not unrestricted authorization. SharePoint, Dataverse and external services can have different user permission models. A maker viewing every document in the test tenant must not assume production users inherit that visibility. Grounding responses should preserve source trust, currentness and citations where supported.

Permission-aware retrieval must preserve document freshness and source access rights. Test two users with different source permissions asking the same question; a correct answer that leaks restricted data is not acceptable.

Instrument the agent’s end-to-end path

Record which topic or tool was selected, key inputs, result status, latency, fallback decision and downstream business outcome, with privacy-sensitive fields redacted. An apparently plausible final response can hide a failed tool call or the wrong topic. Trace enough to identify a misrouted action while protecting customer and employee data.

When users report an error, reproduce it with an approved synthetic case. Diagnose unclear descriptions, a broken connector, missing permission or stale knowledge separately. Version a correction and re-run regression tests rather than editing a production prompt without a release record.

Publish only a verified conversational workflow

Build a scenario matrix with known answer, ambiguous request, prohibited action, missing connector and allowed approved task. Verify actual tool choice and external transaction state for each. If a human handoff is required, confirm the receiving channel and context exist. A button appearing in the UI is not proof the downstream action succeeded.