Status: Public Preview — behaviour may change.

What it does

Lets more than one person work with a single Sales Development agent instance. The manager who created the agent grants other people a Supervisor role, and the group then talks to the agent in a Microsoft Teams group chat rather than each person having their own private thread.

Key facts

• Two roles only. Manager can do everything, including granting, revoking and listing Supervisor access. Supervisor can chat with the agent and use most of its capabilities but can't manage anyone else's access.
• The Manager role is assigned when the agent is created and can't be transferred through a chat command. Supervisor is the only role a manager can hand out.
• Access management works only in the manager's private one-to-one chat with the agent. Attempt it in the group chat and nothing happens.
• Granting is natural language with a Teams @mention — Give @Jane Doe Supervisor access. Reviewing is List users with Supervisor access; revoking is the equivalent remove phrasing.
• Group chat ceiling is 10 people plus the agent — one manager and up to nine supervisors. Everyone in the chat needs a role on that agent instance.
• If anyone in the chat has no role, the agent stops responding to the entire chat, not just that person, until they're granted access or leave.
• The agent only acts when @mentioned or replied to. It reads the surrounding conversation for context but ignores general chatter between participants.
• One agent per group chat. Add a second and the Sales Development agent posts that the configuration isn't supported.
• Requests are handled one at a time per chat, in arrival order. Several people messaging at once means queuing, not parallelism.
• A Grant Supervisor Access card can arrive in the manager's one-to-one chat when someone without access tries to interact. It's held until any active manager session ends, arrives one card per person, and may be disabled at tenant level entirely.

When to use / skip

Use it where the agent is a shared team asset — an inside sales pod or an SDR desk where two or three people need to see and steer the same outreach. It's a real improvement on the single-owner model, where the agent's work was invisible to anyone but its creator.

Skip it where each seller has their own agent instance, which is the more common shape. Ten people is a small ceiling and the one-request-at-a-time behaviour makes a busy group chat feel sluggish, so this isn't a route to shared service-desk usage. It's also preview, so don't build a support model around it yet.

Configuration decisions

• Who creates the agent instance, because that person is the Manager permanently and the role can't be moved by chat command.
• Whether supervisors get access at all, or whether each seller gets their own agent — a licensing and capacity question as much as an access one.
• Which Teams group chat is the working surface, and who's allowed to add people to it, given that an unauthorised joiner silences the agent for everyone.
• Whether the tenant has the access-card capability enabled, and if not, that managers grant access proactively rather than waiting for a prompt that never comes.
• Whether nine supervisors is enough for the team shape, or whether you need multiple agent instances.

Gotchas

• One person joining the Teams chat without a role takes the agent offline for the whole group. It looks like an outage and it's a permissions problem. The agent doesn't repeat the warning either, so anyone arriving later just sees an agent that says nothing.
• The Manager role being non-transferable is a genuine one-way door. If the agent is set up by a consultant or a departing team lead, the client is stuck with that account as manager, and agent instances can't be deleted without Microsoft support.
• Access management silently does nothing in group chats. There's no error telling the manager they're in the wrong thread.
• The access card is triple-conditional — the manager's session must have ended, cards arrive one at a time, and the tenant may not have the capability at all. Don't teach managers to rely on it.
• Sequential request handling means one long research request blocks the rest of the chat. Users read that as the agent having crashed.

Consultant notes

• Decide the agent ownership account in the design session, not during a demo. A Manager role that can't be transferred is the kind of constraint that turns into a support case six months in.
• The ten-person ceiling and single-manager rule map badly onto how most sales teams are structured. Walk the client's org chart against it before promising shared access — you'll usually find they need instance-per-pod rather than one agent for the department.
• In UAT, deliberately add someone without a role to the group chat and let the client watch the agent go quiet. It's the behaviour most likely to generate a P1 in week one, and it's cheaper to demonstrate than to explain.
• Preview status matters more than usual here because the feature is about permissions. Agree that access changes are a manual job for a named manager for now, rather than assuming it will slot into whatever joiner-mover-leaver process the client runs.

---

Revisit when the feature reaches GA, if the 10-person group limit moves, or if Manager role transfer becomes supported.