Skip to content

Add support for Targeted messages in a group setting #177

Open
1 of 1 issue completed
Open
Feature
1 of 1 issue completed
@MattB-msft

Description

@MattB-msft

Note: The terms bots and agents can be used interchangeably for the purpose of this thread.

Introduction

When users engage with bots or agents there are many scenarios where there may be a need to ask for additional information from users before the bot may be able to respond. In a setting where the bot is being messaged from a group setting (like a Group Chat or a Channel on MS Teams), this request to the original sender becomes noise for the other members of the group. Additionally, having the request visible to other members in the group opens up opportunities for the other users to act on these bot requests which may not be an acceptable outcome.

This proposal is to support the ability for bots and agents to be able to send a message which is visible only to a subset of users in a group setting. We call these messages "Targeted" messages.

Sample scenarios

Here are a few scenarios where Targeted Messages can be used:

Bot needs the sender to log in before responding to user query

  1. Let's take the example of a GitHub bot.
  2. The user messages the GitHub bot and requests details about a PR. The user does this in a group chat so that other members can see the details as well.
  3. The GitHub bot receives the request and sees that it doesn't have a valid access token to fetch the requested information from GitHub API on behalf of the user.
  4. The GitHub bot then sends a message back to the user asking them to sign-in with their GitHub account so that a valid access token can be generated.
  5. Once the token is ready, the GitHub bot can then query the GitHub API and return the originally requested information about the PR to the group chat for viewing by all members of the chat.

In this scenario, steps 3 and 4 are meant only for the user who is requesting the PR information. The bot message which is asking the user to sign-in is irrelevant to other members of the chat, and them clicking on sign-in may not be helpful.

When Targeted Messages are supported, the message sent in step 3 would be marked by the bot as "targeted" only to the original sender. The chat client (Teams client in this case) would ensure that the message is not visible or accessible by any other member of the chat.

AI based chat assistant agent (co-pilot or any other agent) proactively shares chat summary to users who join a group chat or channel at a later stage

  1. Let's say a group chat or channel exists where a team has been discussing some problem that needs to be solved.
  2. A new member gets added to the chat when the conversation history is already a few months long.
  3. The chat assistant listens to the member added event and proactively sends a summary of the conversation so far to the newly added member, helping them catch up quickly without having to browse through the complete chat history.

This is a proactive scenario where the agent listens to an event of choice (member added, in this case) and sends a summary to the user. Without Targeted Message support, this summary will simply be irrelevant and noisy to other members of the chat. However, of the agent can mark the message as Targeted only to the new member, clients can ensure that it's visible only to the relevant person.

Implementation details

To support this requirement, we would introduce a new entity to describe how the activity should be treated by clients. In case of targeted messages, the activityTreatment would be targeted to indicate that only the recipient should be able to see the message even if the activity is being sent to a group of people (like chats or channels in Teams).

Entity

{
    "type": "activityTreatment",
    "treatment": "targeted"
}

The type activityTreatment indicates that this object will contain metadata to indicate to clients how the activity should be handled. While the current scope of Targeted Messages feature is limited to "messages", but keeping the generic "activity" prefix in the name keeps the model more flexible in case the capability needs to be extended to events or other types of activities in the future.

Same for the treatment field. Setting this up as a string/enum allows for more flexibility in the future. An alternative approach could be to set this up as a boolean, but that would make the field very feature specific. Eg: isTargetedActivity: true.

Original issue: microsoft/Agents#94

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions