Channels and chats
Microsoft Teams keeps conversations in two separate places, and Daslab can reach exactly one of them. Getting this straight up front saves a lot of confusion, because in ordinary English both of them are "a group chat".
The two surfaces
A channel lives inside a team. You reach it by expanding a team name in the left rail. Channels are topic-based, persistent, and threaded — a root message with replies hanging off it.
A chat lives in the Chat section of the left rail. That covers 1:1 conversations, ad-hoc group chats, and meeting chats. A chat belongs to no team, and its messages are flat rather than threaded.
Microsoft treats these as different objects with different APIs and different permissions. So does Daslab.
What Daslab can see
Channels, and everything in them. The teams you belong to, their channels, root messages, threaded replies, and search across channel messages. Standard channels and private channels alike.
Private channels are not a special case: if you're a member of one, Daslab reads it exactly like any other channel — messages included. If you're not a member, it isn't listed and its messages aren't reachable. Membership is the whole rule.
Nothing in the Chat pane. No 1:1 conversations, no group chats, no meeting chats. Daslab holds channel permissions only and requests no chat permission at all.
This includes search. teams_search_messages is bounded by the same permissions as everything else, so it returns channel messages and never chat messages. An empty search result means nothing matched in channels — it does not mean the conversation doesn't exist.
Working with this
If you want an agent involved in an ongoing conversation, give it a channel. Create one, put the people who care in it, and point the scene at it. This is the normal pattern and it works better than the alternative would anyway: a channel is a durable place with a name and a membership list, rather than an ad-hoc thread that only some people can see.
A channel is also the right destination for anything the agent produces on a schedule — run summaries, alerts, approval requests. teams_post_message accepts HTML with html=true, so a status summary can carry structure instead of arriving as a wall of text.
Tools
| Tool | What it does |
|---|---|
teams_list_teams | Teams the connected user belongs to |
teams_list_channels | Channels in a team, with membershipType (standard, private, shared) |
teams_read_channel_messages | Root messages in a channel, newest first |
teams_read_replies | Replies to a root message — the rest of a thread |
teams_search_messages | Full-text search across channel messages |
teams_post_message | Post to a channel — pauses for approval |
teams_reply_to_message | Reply in a thread — pauses for approval |
Reads run freely. Both write tools stop for human approval and show the exact content first.
Threads
teams_read_channel_messages returns root messages only. A channel conversation with fifty replies under one root shows up as a single message until you call teams_read_replies on it. When a channel looks surprisingly quiet, that's usually why — the discussion is in the replies, not the roots.
Permissions
The Teams integration uses Team.ReadBasic.All, Channel.ReadBasic.All, ChannelMessage.Read.All and ChannelMessage.Send. All four are delegated — they resolve to what the connected user can already open, not to everything in the tenant.
They're .All permissions, so a Microsoft 365 tenant administrator has to consent for the organization once. That grant covers Outlook, OneDrive, SharePoint and Power BI too, since all five share one application. See Microsoft 365 permissions for the full list and how to revoke it.