Summary

Add support for mutliple Teams bots for single Openclaw gateway.

Problem to solve

Currently channels.msteams is a single object (additionalProperties: false). One Azure App Registration, one Teams bot identity for the entire OpenClaw instance.

For organizations running multiple agents (e.g. one agent per team member), this means all agents share a single bot identity — users DM "Bot"
regardless of which agent they're actually talking to. The routing works, but the identity layer is invisible and the UX feels like a generic chatbot rather than a named agent.

Proposed solution

Allow channels.msteams to accept either the current single-object form (fully backward compatible) or an array of bot configurations, each bound
to a specific agent:

"channels": {
"msteams": [
{
"appId": "aaa-111",
"appPassword": "...",
"tenantId": "...",
"agentBinding": "main",
"dmPolicy": "allowlist",
"allowFrom": ["anon@example.com"]
},
{
"appId": "bbb-222",
"appPassword": "...",
"tenantId": "...",
"agentBinding": "john",
"dmPolicy": "allowlist",
"allowFrom": ["john@example.com", "anon@example.com"]
}
]
}

Alternatives considered

No response

Impact

Affected: users / systems / channels

• Any OpenClaw deployment running multiple named agents sharing one Teams bot
• Specifically: multi-agent org setups where agents are paired 1:1 with human team members
• All inbound/outbound Teams communication for every agent in the org

Severity: Workflow limitation — not a blocker, but a meaningful UX ceiling
The current single-bot setup works functionally. Routing is correct. But it creates a permanent identity gap: every agent speaks as the same
bot, regardless of who the user thinks they're talking to. For orgs where agents are meant to be named colleagues (Axis, Forge, Grid, Pulse),
this undermines the entire model. The more agents you add, the worse it gets — the single bot identity becomes a lie that grows more obvious
over time.

Frequency: Always — by design
This is not an intermittent bug. Every single Teams message, every DM, every reply is affected. There is no workaround within the current config
schema that provides per-agent identity — the constraint is structural.

Practical consequences:
No agent identity in
Teams

Can't leverage Teams
directory

Onboarding friction

Multi-instance workaround
is costly

Scales poorly

Evidence/examples

No response

Additional information

No response