Ability to have multiple channels (aka multiple chat agents in a single Teams tenant)

Being limited to a single Teams channel for chat agents deployed within one M365 tenant limits our capability to build efficient and more secure chat agents, requiring all abilities to be “crammed” into a single agent. This leads to:

• Bloated prompt that is longer to execute

• Prompt management challenges

• Reduced interest in building additional capabilities

• An agent that is given too many operating permissions in order to support less-used or user-group specific features.

For example, if we wanted to give an internal Teams chat agent the ability to query and update PSA contract information to our internal help the administration team, the instructions would need to be added to the main internal Teams chat bot all other departments would gain this functionality, even if we don’t want techs to access or modify this information. And, the administration team would have access to a chat agent that can make changes in M365 tenants; again, something that we don’t want them to have access to.

Separate chat agents, each with their own permissions and set of specific instructions would be much more efficient. The only thing preventing this capability is that we are limited to a single internal Teams bot.

We cam create multiple agents and access them through the HTML interface; why not add that capability via Teams apps?

MSPs can decide through their M365 tenant who has access to individual Teams apps through M365 app access controls, providing the ability to determine which users have access to specific Teams apps, but it an ideal world the option to limit channel (or chat agent) to specific Neo users would be great. This could apply to both HTML and Teams chat agents.

This also applies to end-user channels: it could be useful to have multiple chat agents for customers. One could be dedicated to handling IT tickets and troubleshooting, another could be used to allow certain end-user customers check their billing status (if available through the PSA like it is in Autotask), or device status (uptime) for co-managed end-customer technical teams, etc. Another example is a Teams app that is built for a specific language for certain users within an organization, and another Teams app that will have another language. We have a customer that has sites across multiples sites throughout North Amercia and is picky as to which languages information and tools should be according to the site, but they’re all in 1 Microsoft tenant.