An AI agent on Teams or on Slack: what changes

You do not choose, and that is the first thing to say. The messaging platform is already installed, nobody changes it for an agent, and the real question is whether the agent you are evaluating exists on yours. Many exist only on Slack.

That gap is worth facing, because it is not about to close. Teams holds roughly 37% of the enterprise messaging market against 13% for Slack, with something like 320 million monthly users against 79 million daily ones, and it dominates in large organisations and regulated sectors. Slack dominates elsewhere, notably among technology companies under five hundred people, where it approaches 52%.

Why the tooling ships where the market is not

Because the companies building these products use Slack, and you build first for the room you are standing in.

The clearest example of 2026 is the arrival of Claude Tag, an agent installed as a member of a channel, available on Slack only at launch. Anthropic has said it intends to expand, and there is no reason to doubt it, but between the announcement and availability a European company running Microsoft 365 waits. The same pattern repeats across most agent vendors: Slack first, Teams once the market asks loudly enough.

There is an honest technical reason for this, and it is not incidental. Slack’s API is simpler, better documented, and above all it reflects fairly faithfully what you can do in the interface. On the Microsoft side you deal with several development kits, a permission model in three classes, and a distinction between what a bot sees and what a directory sees. The build cost is not the same, and it is paid in weeks.

The consequence for a buyer is easy to state. Availability on your surface is an evaluation question in its own right, to be asked before features, because an excellent product on a messaging platform you do not have is worth exactly nothing.

What a bot cannot do on Teams

Three limits, observed in August 2026 while building, and they are design limits rather than gaps somebody will shortly fill.

It cannot react to a message. Adding a reaction as a bot does not exist among the available operations, and the equivalent directory call does not accept application permissions, which are precisely the ones a bot holds. Reactions exist only inbound, meaning the agent sees that people reacted to its messages without being able to answer in kind. This is not cosmetic: the quiet acknowledgement is the cheapest gesture a colleague can make, and having to replace it with a message means replacing it with noise.

It cannot read an email address from a conversation roster. The paged member list does not return one to a bot. The directory does. So you hold two sources of information about the same people, only one of which knows how to write to them, and you have to decide which governs. We settled it by making person lookup take a name rather than an address.

It cannot join a channel by itself. It has to be installed, which requires rights at the tenant’s application catalogue level. That is also true on Slack today, and it is a good thing in both cases: somebody invites the agent, always, and nobody discovers on a Monday that it had been listening for three weeks.

What a bot cannot do on Slack

It would be dishonest to present Teams as the constrained surface and Slack as the free one, because the most awkward limit we have run into is on the Slack side.

A bot has no search there. Message search requires a user token, which a bot does not hold. So a question as ordinary as “what was said about this client last month” is not handled by a search but by a loop over channels, one at a time.

And that loop meets a ceiling. For an app distributed outside the marketplace, the throughput available on those reads drops to one request per minute and fifteen objects per page. Do the arithmetic on a workspace with forty channels and some history: the question is not slow, it is impossible, and no optimisation recovers it.

It is the kind of constraint that shows up in no demo, since a demo runs on a fresh workspace with three channels. It nonetheless decides what the agent can be, and it cost us a design assumption we had to abandon.

What parity actually costs

We took the position that both surfaces offer the same verbs, and I can say what that represents, because we have just done it.

It is not a renderer to write. It is a file consent flow to implement where the other surface simply sends, a member pagination that does not return the same fields, a document share that takes a different path, and a permission matrix to document line by line so that nobody subsequently builds against an assumption. The part users can see, which is receiving the same deliverable on both sides, is a fraction of the work.

The general lesson holds beyond our case, and it contradicts a widespread intuition. People readily imagine these platforms are the same room repainted, and that an adapter will do. They are two different models of what a program may do inside a conversation between humans, and each forbids something the other allows. Parity is therefore a product decision you have to want, not a checkbox on a roadmap.

What if you have both?

It is more common than people admit, and almost nobody announces it in a meeting. Engineering is on Slack, the rest of the company on Teams, or an acquisition left two platforms coexisting for three years while the merger never quite happened.

The temptation is to install two agents, one per surface, and that is the mistake. You get two memories diverging about the same client, two sets of preferences, and one person who has to re-explain things depending which room they are in. The rule we apply settles this without hesitation: an agent holding context about you must be unique, an agent holding an expertise can be called as often as you like. This is the first case, and the surface is only a door.

So what to check with the vendor is precise, and it is not availability on both. It is whether both doors lead to the same agent. A conversation started in Teams on Tuesday must be known to the one resuming in Slack on Thursday, failing which you have bought two agents that do not talk to each other while believing you bought one.

The related question, about rights, is settled in the same place. Someone without access to a file must not gain it by switching messaging platform, which sounds obvious and is not, once both surfaces have their own notion of belonging to a channel.

Where Teams is right against Slack

One thing deserves crediting to Microsoft, and it concerns exactly the subject that occupies us most.

The permission model distinguishes three classes. Those a conversation owner consents to at install, valid only for that conversation. Those an administrator consents to once for the whole organisation. And a third, rarer one, where consenting to the scope grants nothing at all: access appears only after an explicit grant, object by object, and disappears when it is withdrawn.

That third class is least privilege done properly by the platform rather than improvised by the application. It is precisely what we ask for when we write that an agent should act with the requester’s rights and that a limit only holds when it is written into the product. Seeing a platform offer it natively is more useful than any internal policy.

What to ask before signing

Four questions, in this order, and the first eliminates many candidates.

Which surface does the product exist on today, in production, at customers who are not launch references. A roadmap is not availability, and “Teams is coming next quarter” is a sentence whose value is measured by the track record of whoever says it.

Do both surfaces offer the same verbs, and if not, which are missing. Ask for the list rather than a reassuring answer, because the answer is almost always yes and the list almost never empty.

What happens when the agent cannot do something on your surface. The right behaviour is to say so; the wrong one is to pretend, which is also the mark of an agent that cannot refuse.

And finally, does anything about your messaging have to change in order to install it. The answer must be no, as it must be no for your ATS, and for the same reason: an agent that demands a migration is not an agent, it is a project.