Teams

Kiro Crew can run as a Microsoft Teams bot. DM your agent from Teams and get a typing indicator while it works, then the final reply in one message.

The Microsoft Bot Framework pushes activities to an endpoint you host. Crew:

1. Registers an inbound route: POST /api/messaging/teams
2. Validates every request's Authorization: Bearer <jwt> against Bot Framework signing keys before processing
3. Fast-acks with 200, runs the agent turn in the background, then sends the reply via the Bot Connector REST API

• A public HTTPS URL reaching your gateway (reverse proxy, dev tunnel, or public VM)
• The Teams extra installed: pip install "kirocrew[teams]"
• An Azure Bot registration with a Microsoft App ID and secret

1. Register an Azure Bot in the Azure Portal — create an Azure Bot resource, note the App ID, create a client secret, add the Microsoft Teams channel, and set the messaging endpoint to https://<your-host>/api/messaging/teams
2. Open Settings → Messaging Channels → Teams in the dashboard
3. Paste the App ID, App Password (client secret), and Tenant ID (or leave blank for multi-tenant)
4. Add your Azure AD email or object ID to the Allowed emails list
5. Click Save — the status badge turns green when the credentials validate

Then side-load a Teams app package (Developer Portal → new app → Bot with your App ID, scope Personal) and DM the bot.

In ~/.kiro/crew/.env:

MICROSOFT_APP_ID=<your app id>
MICROSOFT_APP_PASSWORD=<your client secret>
MICROSOFT_APP_TENANT_ID=<tenant id or leave unset>

In ~/.kiro/crew/config.json:

{
  "teams": {
    "enabled": true,
    "allowed_emails": ["you@yourcompany.com"]
  }
}

Install the Teams extra: pip install "kirocrew[teams]"

Then: kirocrew restart

Run /sessions to bind a Teams conversation to one of your dashboard sessions. It works only when teams.allowed_emails holds exactly one identity, so there is one clear owner; with a shared allowlist, the listing is refused to protect your dashboard transcripts. When a text message arrives while that session is already mid-turn, Kiro Crew keeps it rather than dropping it. It either steers the message into the running turn or queues it to run when the turn finishes. The conversation reports which happened: a steering reply says your message was folded into the running turn; a queued reply says it runs when the current turn finishes.

messaging.queue_mode in config.json sets the default: steer (the default) folds the message into the running reply; queue holds it for after the turn. A /steer or /queue prefix overrides the mode for that one message. A message with attachments is neither steered nor queued into the bound session; the reply asks you to send it again once the turn finishes. When no dashboard turn is in progress, the message runs as a fresh turn in the bound session.

• Webhook is exempt from dashboard cookie gate — performs its own Bot Framework JWT validation
• Authorization is deny-by-default on both the email allowlist and conversation scope (personal only)
• All denials recorded in the security event log
• App Password is marked sensitive and never logged

• 1:1 personal chat only — no team channels, group chats, or @mention handling
• No Adaptive Cards / tappable buttons (options delivered as plain text)
• No token-by-token streaming — typing indicator shown, final answer delivered in one message (chunked if long)