Design agents for internal or external audiences

A returns agent answering customers on a public storefront, and the same agent repointed at warehouse staff, are not one agent with a different sign-in page. Copilot Studio has no switch labelled internal or external, so the word only earns its place once it resolves into settings you can point at. Four of them change with the audience, and this page keeps these four names throughout:

• Identity is the agent authentication option under Settings > Security > Authentication, and the service provider underneath it when that option is Authenticate manually.
• Reach is which channel carries the agent, meaning the surface Copilot Studio connects a published agent to, and which population can find it once it is published.
• Content is the primary language, the terminology, the inputs the agent expects, and the knowledge it is allowed to read.
• Recovery is what happens on the turn the agent cannot complete.

An internal audience means people who sign in with your organization's Microsoft Entra ID and can therefore be identified inside your tenant. An external audience means everyone else: customers, partners and anonymous visitors holding no account you control. Nothing else in the definition matters, and everything in the four decisions follows from it. None of the four is exotic. Each one is a setting you have already used or an artifact you have already authored: an authentication option, a channel connection, a topic, a system topic. The work of this objective is reading the right value for each off a sentence like this agent is for warehouse staff or this agent is for anyone on the storefront. The figure below traces that derivation from the audience question down to the surface each decision lands on.

The neighbouring pages own the mechanisms, and this page deliberately does not repeat them. Identity strategy owns how manual authentication is configured, from the Microsoft Entra ID app registration and redirect URI through to scopes and the authentication variables it exposes. Channels and deployment owns how a channel carries a conversation, including Direct Line secret and Direct Line token handling, per-channel rendering, and the Teams release sequence. What is left here, and what the exam asks, is the choice itself: given who the agent is for, which option, which reach, which content and which recovery path. Microsoft's own project planning guidance^[1] frames this as work you do before the build rather than a setting you correct afterwards, and one of the four cannot be corrected at all: the agent's primary language is fixed the moment the agent is created.

Pick the agent authentication option from who the caller is and where they will be sitting, never from how much sign-in friction you would like to avoid. Copilot Studio offers three options on the authentication settings page^[2]: No authentication, Authenticate with Microsoft, and Authenticate manually. Configuring any of them is identity-strategy work; the audience decision is which one the population in front of you requires.

An employee audience is an Entra identity requirement

If the people using the agent are employees in your tenant, the agent should establish that Microsoft Entra ID identity, because everything downstream that respects a person's permissions needs to know who they are. On the native Microsoft channels, Authenticate with Microsoft sets up Microsoft Entra ID authentication for Teams with no manual configuration, and because Teams authentication already identifies the user, people are not prompted to sign in there unless the agent needs an expanded scope.

When the internal audience is somewhere else, that option stops being the answer. An intranet site or employee portal is served through the Custom website channel, outside the native Microsoft set, and Microsoft's instruction is explicit: if you need to publish to channels other than Teams and Microsoft 365 but still want authentication, choose Authenticate manually. Pair it with Microsoft Entra ID as the service provider, which is the one to choose when access has to stay inside your organization's Entra tenant, and turn on Require users to sign in when identity has to be established before the conversation begins rather than at the first topic that happens to need it. That setting exists only for Authenticate manually, and turning it on creates a read-only Require users to sign in system topic that fires for any unauthenticated user and, when sign-in fails, redirects to the Escalate system topic, the one that tells a person they need to reach a human. The recovery section below owns Escalate in full.

One caution about how far Authenticate with Microsoft reaches. The authentication article states in one place that selecting it gives you the Teams and Microsoft 365 Copilot channels plus native and custom app channels, and in another place that the agent then works only on the Teams channel. The channels page works through that inconsistency; for an audience decision, use the sentence both readings agree on, which is that anything beyond the native Microsoft channels goes to Authenticate manually.

Anonymous is a ceiling, not a shortcut

For an external audience the first question is not how do customers sign in but does anything here need to know who they are. No authentication means the agent asks nobody to sign in, and Microsoft states the consequence directly: an unauthenticated configuration means the agent can only access public information and resources, and anyone who has the link can chat with it. Two further effects decide most exam items on this nugget. Tools that run under the signed-in person's own connection, the End user credentials credential mode, stop working, which is why Microsoft warns against turning agent authentication off when tools require user credentials. And agent sharing stops being an access control, because there is no identity for it to act on.

So No authentication is correct only when public access is intentional and no capability on the agent depends on caller-specific authorization. One topic returning the caller's own order status, or one knowledge source whose results are trimmed to what the signed-in person may open (permission trimming), invalidates the anonymous design for the whole agent rather than for that one topic. When external users must establish identity, the choice is Authenticate manually with Microsoft Entra ID where the people you must identify have accounts in your Entra tenant, or Generic OAuth 2 for any other provider that complies with the OAuth 2 standard.

Whichever option you land on, remember two operational facts that turn up as distractors. Authentication changes take effect only after the agent is published. And No authentication may not even be offered: it is unavailable when a data policy in the Power Platform admin center is configured to require authentication.

What each option leaves you able to control

Option	Who can chat	Sharing as an access control
No authentication	Anyone with the link, or anyone who finds the agent on your site	Not available; you cannot control which users in your organization chat with the agent
Authenticate with Microsoft	Signed-in Microsoft users on the native Microsoft channels	Available; the user is always signed in on Teams, so sharing decides who can chat
Authenticate manually, Microsoft Entra ID	Accounts in your Entra tenant	Available once Require users to sign in is on
Authenticate manually, Generic OAuth 2	Anyone who signs in at that provider	Not available for specific users; you cannot control which individuals chat with the agent

The agent sharing article^[3] lists Authenticate manually with Microsoft Entra ID plus Require users to sign in as its prerequisites, so read the table above as the set of options that permit sharing-based control and the sharing article as the configuration it documents in full.

Publication and distribution are separate acts, and only the second one is an audience decision. Publishing makes the agent's latest content live on its connected channels; distribution is the work of getting it in front of the population it was built for. The channels page sequences the Teams release itself. What belongs here is narrower and easier to get wrong: at each stage, which set of people can actually reach the agent.

For an internal audience Microsoft provides a governed ladder, and even the link on that ladder is a controlled rung rather than one you paste anywhere. In the Teams and Microsoft 365 Copilot channels you install the agent for yourself first^[4], then copy an installation link from Availability options, then show it to teammates and shared users in the Built with Power Platform section of the Teams app store, and only then submit it for admin approval so it appears in the Built for your org section, or in Built by your org in the Microsoft 365 Agent Store. Two boundaries in that ladder are audience facts rather than release mechanics. An installation link works only for users who already have access to the agent, and it cannot be used at all in the Teams mobile app, so reaching Teams mobile users means showing the agent in the Teams app store instead. And only shared users can find the agent in Built with Power Platform: Microsoft states that it does not show for everyone in the organization even when the agent is configured to allow everyone to use it, and that the section is capped by your tenant's Teams app store discovery policy. Reaching everyone genuinely requires the approval route.

The envelope, not the network

What bounds the audience is the authentication option plus sharing, and nothing else. The figure below draws those envelopes nested inside one another: with No authentication the outer envelope is anyone holding the link, and each inner ring exists only because the agent identifies its caller. Sharing an agent for chat grants permission to converse without granting authoring permission, and it can target individual users, security groups, or everyone in the organization.

This is why the most common internal-audience mistake is a network argument. Choosing No authentication for a Custom website because the site is only reachable from the corporate network confuses where a request comes from with who is making it. Network position is not an identity, so the agent still cannot tell one employee from another, sharing still cannot bound who chats, and, as the identity section established, the agent still reads only public information and resources. Microsoft's own note on the Teams channel says the same thing from the other direction: to prevent people outside your organization from using these agents, turn on the security settings for agents built for Teams, Microsoft 365 Copilot, or internal employee use. If the requirement is to restrict which client applications may connect, that is channel security through Require secured access, a different control on the same settings page and one the channels page covers.

For an external audience the reach decision is smaller but has one hard edge. The prebuilt Demo website exists so teammates and stakeholders can try the agent while you build it; Microsoft states it is not intended for production use^[5] and tells you not to share its URL with customers. Customers get a Custom website your organization owns and embeds. Notably, that same live-website path is also how an internal agent reaches an intranet or SharePoint site, which is precisely the case that took you to Authenticate manually in the previous section.

Internal access does not make a customer-oriented conversation design suitable for employees. Fixing the authentication option on a reused agent changes who gets in; it changes nothing about whether the agent speaks the language the audience uses. These content decisions sit alongside identity, and one of them cannot be undone at all.

Language is the irreversible one. You specify an agent's primary language when you create it^[6], and Microsoft states plainly that you cannot change the primary language after creation. The only later adjustment is the region for that primary language, and the Edit control for it appears only when more than one region is available. A multi-country internal rollout is therefore planned early, but it does not force a separate agent per language: add the site's language as a secondary language, then download, translate and upload the localization file so authored topic messages are served in that language. Only the primary language is fixed at agent creation.

That constraint is narrower than it first sounds, so state its bounds. Generative answers, generative orchestration and user language support a long published list of languages, so a person can type in a language other than the agent's primary language and be understood. What stays pinned to the primary language is the authoring surface: you edit topics and content in the primary language, and secondary-language users are served the translations you upload. One concrete consequence to remember, because it is exactly the shape of an exam distractor: suggested prompts are authored and displayed in the agent's primary language, but when that language is not English they do not appear in the Microsoft 365 Copilot channel after publishing, even though they do work in Microsoft Teams and Web Chat.

Terminology and expected inputs

Employees and customers do not type the same things. Internal users reach for internal system names, ticket and incident identifiers, cost-centre codes and team names, and they expect the agent to know the internal process behind a request. Customers type order numbers, product names and postal codes, and they know none of your internal vocabulary. That difference drives concrete authoring: which entity a Question node identifies, which multiple-choice options that node presents as buttons the user can also just type, and how the agent's instructions describe its own job. Planning for an internal audience therefore means naming the employee roles, the channels those roles work in, any multilingual requirement, the inputs you expect to receive, and the fallback behaviour, before the build rather than after the first complaint.

Knowledge scope follows the same split. An internal agent grounded in a permission-trimmed source has to carry the signed-in user's identity so answers stay inside what that employee could open themselves, which is the enterprise-integration mechanism rather than anything you set here. An external agent may read only sources the organization is willing to publish, and no authentication setting rescues the alternative: a public agent grounded in an internal SharePoint site is being asked to turn private content into a public answer. Note one platform bound in the same area: in Teams group chats and channels, agents cannot use knowledge sources that require end-user authentication such as SharePoint, and those agents are supported only in 1:1 chats.

Finally, tell the audience what they are talking to and what it cannot do. Disclosing that responses are generated by AI is a responsible-AI requirement for both audiences, but stating the agent's limits pays off differently for each. An employee who hits a wall knows which internal team to ask next. A customer does not, so an unstated limit becomes two more attempts and then an abandoned conversation.

Fallback, On Error and Escalate are three different system topics^[7] with three different triggers, and only Escalate is the escalation path. Designing an external agent means designing all three, because a customer who gets the wrong one has nowhere else to go.

Fallback informs users that their query could not be matched to a topic and asks them to try again; it triggers when the agent cannot match the user's message to a topic. Read one caveat with it: the same article also lists Conversational boosting, which creates generated answers from external data sources and likewise triggers when the agent cannot find a match. Two system topics are documented against a no-match condition, so check which topics are turned on in the agent you are actually designing rather than assuming one name owns unmatched input.

On Error informs the user that a user error occurred, and Microsoft notes in the same breath that this topic does not handle system errors. Its message includes an error code, the conversation ID and the error timestamp, and in the test panel a detailed error message appears to help you diagnose the issue. Those three values are debugging material. Wiring your customer-service handoff into On Error therefore fails twice over: the customer still receives an error code and a conversation ID, and a customer who was merely not understood, which is a Fallback rather than an error, never reaches a human at all.

Escalate informs users that they need to speak with a human, and triggers when talk to agent is matched or the Escalate system event is called. By default it provides a simple message, and Microsoft's handoff guidance^[8] explicitly allows editing it to carry a URL to a support website or ticketing system, or instructions for emailing support. That is a legitimate design when no engagement hub exists, and it is often the right answer for an internal agent.

Handoff to a person

When a real person has to pick the conversation up, Escalate needs a Transfer conversation node. Agents created in Copilot Studio do not have one by default, though agents created from Dynamics 365 Customer Service already include it; you add it from Topics > System > Escalate, then Add node > Topic Management > Transfer conversation. With a connected engagement hub in place, meaning the product your human agents actually work in, the agent sends the full conversation history and the relevant variables across, together with a default set of context variables the hub can route on: va_Scope, va_LastTopic, va_Topics, va_LastPhrases, va_Phrases, va_ConversationId, va_AgentMessage, va_BotId, va_Language, and any user-defined topic variables.

One testing trap follows directly. Once a Transfer conversation node is in a conversation, users see a No renderer for this activity message on the demo website every time handoff triggers, because bringing a person in from your engagement hub needs custom client-side code on the chat canvas. A handoff that looks broken on the Demo website may be configured correctly, and a handoff that has only ever been exercised there has not been validated for customers.

Bounding the retry loop

The other half of external recovery lives on the Question node, and it is where repeatedly retrying actually comes from. Question behavior properties^[9] expose Reprompt, whose How many reprompts setting defaults to Repeat up to 2 times and can also be Repeat once or Don't repeat. When the agent stops trying, No valid entity found decides what happens next through Action if no entity found, whose values are Escalate (the default, redirecting to the Escalate system topic), Set variable to value, Set variable to empty (no value), and Redirect to a topic. A customer typing a reference from a retired numbering scheme will never satisfy the entity, so the design question is not how many more attempts to allow but which of those four exits the conversation should take. The figure below shows all four recovery routes side by side, with the two that converge on Escalate.

Audience items on this exam rarely announce themselves. They present a working agent, change one fact about who is using it, and ask what to configure. The signal is almost always in the stem's description of the population and the surface, so read those two clauses first and map them onto identity, reach, content or recovery.

What the stem says	Which decision it is	The move
Employees, but the agent lives on an intranet portal rather than Teams	Identity	Authenticate manually with a Microsoft Entra ID service provider; Authenticate with Microsoft does not cover a Custom website
Anonymous public agent, but one topic returns the caller's own data	Identity	The anonymous ceiling applies to the whole agent, so the agent moves to Authenticate manually
The site is only reachable from the corporate network	Identity	Network position is not an identity; No authentication still leaves the agent reading only public resources
Anonymous agent must answer from an unpublished internal SharePoint site	Content	No authentication setting makes private content a public answer; the source or the audience has to change
A shared installation link is being used as the company-wide rollout	Reach	Remove it from Built with Power Platform, then Show to everyone in my org for approval into Built for your org
Employees get a generic didn't understand message and give up	Content and recovery	Design the Fallback message and the escalation path; this is not an authentication problem
A support handoff was wired into the generic error message	Recovery	On Error reports user errors with a code and conversation ID; escalation belongs to Escalate with a Transfer conversation node
Handoff was validated on the demo website	Recovery	No renderer for this activity is expected there; the demo website cannot validate a handoff
A customer's legacy reference number never satisfies a Question node	Recovery	Set How many reprompts deliberately and choose an Action if no entity found exit
A site in another country must receive authored content in its own language	Content	Add a secondary language and upload the translated localization file; only the primary language is fixed at creation

Two habits close out most of these. First, when a stem changes the audience of an existing agent, check all four decisions rather than the one the stem is pointing at: the reused customer agent in an internal deployment can have a correct authentication option and the wrong content. Second, when a stem offers an answer that removes friction for the user, ask what the friction was protecting. Turning off sign-in, sharing a link more widely, or raising a retry count are each the tempting option in a question whose correct answer narrows the audience instead of widening it.