7.1 Microsoft Copilot Studio Capabilities

Microsoft Copilot Studio is Microsoft's graphical, low-code studio for building and operating AI-powered agents and workflows. Microsoft Learn describes it as a single place to design a complete business solution: you build agents and automations, connect them to organizational data and systems, and publish them to the channels where people already work. For an AI Transformation Leader, Studio is not a coding lab. It is the product you sponsor when a team needs a purpose-built assistant—onboarding, policy question-and-answer, case intake—that out-of-the-box Microsoft 365 Copilot does not already provide.

Exam AB-731 asks you to understand capabilities of Microsoft Copilot Studio at a business-decision level. You are not expected to author YAML topics or call REST APIs. You are expected to know what Studio is for, what makers configure (topics, knowledge, connectors), where agents go after publish (Copilot, Teams, web, and other channels), and who governs them.

What Studio is for

An agent is an AI assistant that handles conversations and completes tasks. It follows the instructions you give it, draws on the knowledge sources you connect, and uses tools to take action—reasoning through a request and choosing the next step. Microsoft documents that agents can work with employees and customers in multiple languages across Microsoft Teams, Microsoft 365 Copilot, websites, mobile apps, and other channels. Makers can describe an agent in plain language, test it, then publish. Some agents can be given their own account so they work proactively on shared processes such as onboarding a new employee or coordinating a recurring meeting.

Studio also supports workflows (drag-and-drop automations that can call agents and include human-in-the-loop review) and agent flows (the established flow format, similar to Power Automate but native to Studio). A workflow can call an agent; an agent can call a flow as a tool. Leaders should hear this as conversation plus automation in one studio, not as a requirement to become a flow designer.

Studio offers different harnesses—the engine that carries out the work. Microsoft currently documents a GitHub Copilot harness for reasoning-heavy multi-step work, a standard harness for rule-based agents and structured conversations, and a Copilot chat harness for extending Microsoft 365 Copilot Chat with organization knowledge. Harness choice affects reasoning style, out-of-the-box capability, and billing. Do not memorize unpublished credit prices for the exam; know that billing and features depend on the harness, and that finance should read Microsoft's current licensing pages before you scale agents.

You can also use Studio to extend Microsoft 365 Copilot with your own instructions, tools, and knowledge—customizing Copilot for a domain, or creating a standalone custom version of the Copilot chat experience. That is still Studio, not a new Azure application.

Topics and knowledge

On the standard harness, a topic is a portion of the conversation you design on an authoring canvas. Topics contain nodes (message, question, condition, tool, generative answers, and others) that define paths. Agents use either generative orchestration (the agent selects topics, tools, and knowledge from descriptions) or classic orchestration (natural language understanding (NLU) matches the user's message to trigger phrases). The customer does not need to match a phrase exactly; a store-hours topic with the trigger "check store hours" can still fire on "see store opening hours." Every new agent includes system topics (essential behaviors you can turn off but not delete) and starter custom topics (greeting, end conversation) that makers can edit or remove.

Knowledge sources ground answers in enterprise data rather than only the model's general knowledge. You can add knowledge when you create the agent or later. Published agents use those sources to ground responses. Knowledge can sit at agent level or inside a generative answers node on a topic.

Microsoft is explicit on a point that maps directly to Microsoft Graph in the next section: agent user authentication means that when a specific user asks a question, the agent only surfaces content that user can access. SharePoint and connector knowledge are not a backdoor around permissions.

Leaders should also know the Allow ungrounded responses setting. When generative orchestration is on and this setting is off, the agent blocks answers in a turn that did not use a knowledge source or tool—reducing cases where the model simply guessed from general knowledge. Turning it on lets the agent use general model knowledge. Web Search (Grounding with Bing Search) can mix public web results with configured sites; treat that as a governance decision, not a default for confidential processes. Makers can mark a source as an official source (highly trusted, used without extra verification) when generative orchestration is off.

Microsoft publishes different numeric caps for how many sources classic versus generative orchestration will search. In classic conversational boosting, Learn currently lists four public website URLs and four SharePoint URLs among other type-specific caps; generative mode lists higher website and SharePoint URL counts (Microsoft currently documents 25 of each in generative mode), and uploaded files are treated separately from that search-count filter. Quote those numbers from current Learn pages if a vendor asks; do not invent quotas Microsoft has not published, and do not treat classic-mode caps as the only Studio story.

Connectors, publishing, and governance

Connectors are how agents reach systems beyond uploaded PDFs. Two families matter at leader level:

• Copilot connectors (formerly Microsoft Graph connectors) index non-Microsoft content into Microsoft Graph so agents and Microsoft Search can ground answers with citations. Admins set them up in the Microsoft 365 admin center. They fit knowledge bases, tickets, and wikis that should be discoverable across Microsoft 365.
• Power Platform connectors call APIs in real time to read, write, and trigger actions (create a case, check an order). They are governed by Power Platform data policies (the control set often discussed as data loss prevention for makers). They fit live facts and transactions without copying the system of record into Microsoft 365.

Most enterprises mix both: index evergreen policy content; use Power Platform connectors for "what is the status of incident 123?"

Publishing is required before employees or customers can use the agent. Each publish updates all connected channels. Microsoft documents channels including live websites, mobile apps, Microsoft 365 Copilot, Teams, Facebook, SharePoint, WhatsApp, a demo website, and Azure Bot Service channels. Experiences differ by channel (Teams has tighter limits on suggested actions and how citations display). Admins can control which channels are available with Agent access channels in the Power Platform admin center.

Authentication defaults to Authenticate with Microsoft—Microsoft Entra ID for Teams, Power Apps, and Microsoft 365 Copilot without extra setup. No authentication lets anyone who has the link chat; Microsoft cautions that this option also prevents tools that need user credentials. For other channels with sign-in, makers Authenticate manually. Use Studio's test panel while building. Share the demo website only with stakeholders; Microsoft says it is not for production customers.

In most channels, a session ends after about 30 minutes of inactivity, so newly published content appears on the next session. In persistent channels such as Teams, users may need to start over to see an update immediately.

Governance is a leadership job, not a maker hobby:

• Power Platform admin center data policies can require user authentication and block knowledge sources, Power Platform connectors as tools, HTTP requests, skills, publishing to specific channels, and event triggers.
• Admins can disable publishing of agents that use generative AI features for the tenant, and use the Microsoft 365 admin center to govern which agents appear in Microsoft 365 Copilot.
• Environment routing gives makers a safer sandbox; maker welcome messages communicate privacy rules; customer-managed keys and Microsoft Agent 365 identity controls exist for organizations that adopt them.
• Submit widely used Teams and Copilot agents for admin approval so they appear in the organization's store, not as an unreviewed sideload.

Analytics, evaluations (test sets), role-based access, and Copilot credit caps belong in the operating model. Copilot Studio is not a medical device; Microsoft states that any clinical use is the organization's own product and liability.

Studio versus out-of-box Copilot versus Foundry

Use this leader test, not a coding preference:

1. Out-of-the-box Microsoft 365 Copilot — Employees need AI inside Word, Excel, PowerPoint, Outlook, Teams, and Copilot Chat, grounded in mail, files, calendar, chats, and meetings they can already open. No custom agent. Work grounding for the full Graph and Work IQ experience depends on the Microsoft 365 Copilot license Microsoft documents as the add-on / premium work-data path; lighter Copilot Chat experiences may be web-grounded unless the user attaches content or uses a pay-as-you-go work-data agent. Version differences are covered in the Copilot family chapter; here, remember that "the Copilot we already bought" is not the same product as a Studio agent.
2. Microsoft Copilot Studio — A named process, a knowledge base, or a line-of-business action that general Copilot does not run. Low-code makers plus IT governance. Publish into Copilot, Teams, or the web.
3. Microsoft Foundry (and Foundry Tools such as Azure Vision in Foundry Tools and Azure AI Search) — Custom models from a large catalog, prompt or hosted (code) agents, Azure role-based access, networking, tracing, and tools that are not a Teams topic. Foundry is the path when the business need is a custom application or multimodal service. AB-731 candidates do not write that code; they know when to sponsor a Foundry project instead of a Studio FAQ bot.

HR example: A vice president wants new hires in Teams to ask "what is our parental leave policy?" and open a ticket in ServiceNow. That is Studio—knowledge plus a connector or tool—published to Teams with Entra authentication. It is not a Foundry vision model, and it is not a consumer chatbot on the public web.