Desenvolvedores do Microsoft Teams estão sendo alertados de que chamar cada extensão de “bot” agora causa falhas em nível de produção. Em 2026, os próprios limites da plataforma — de 10 a 15 segundos para responder a uma mensagem — transformarão bots mal arquitetados em tempestades de timeout, forçando as equipes a redesenhar seus pipelines.

Por que essa distinção é importante

O Teams oferece três tipos de extensões, cada uma construída para um padrão de interação diferente. Misturá-las força o runtime errado, o SDK errado e o modelo de escalonamento errado.

Teams apps, bots e agents – o que são

  • Teams apps – Abas de interface, páginas estáticas ou componentes simples de UI dentro do cliente Teams. Eles são essencialmente web apps: sem estado (stateless), renderizados sob demanda e hospedados como qualquer outro serviço HTTP. Não se espera um fluxo conversacional.
  • Bots – Construídos com o Bot Framework SDK, os bots seguem diálogos roteirizados. Sua lógica é uma árvore determinística de if/else que decide a próxima resposta baseando-se puramente na atividade recebida. Como o caminho de decisão é conhecido antecipadamente, a resposta se encaixa na curta janela de timeout da plataforma.
  • Agents – Entidades orientadas a objetivos que recebem um objetivo de alto nível, um conjunto de ferramentas e um LLM (large language model). Usando o Agents SDK ou Semantic Kernel, o LLM escolhe qual ferramenta chamar, em que ordem e quando pedir esclarecimentos ao usuário. O fluxo é dinâmico, muitas vezes exigindo múltiplas chamadas externas e raciocínio pesado.

A distinção é clara: um bot é determinístico; um agent é probabilístico e orquestra chamadas de ferramentas em tempo de execução (runtime).

A armadilha do timeout

Quando os desenvolvedores incorporam raciocínio pesado — prompts de LLM, consultas a bancos de dados ou chamadas de API externas — diretamente dentro do manipulador de mensagens de um bot, o Teams percebe que a requisição ultrapassou sua janela de 10 a 15 segundos. A plataforma aborta a resposta e tenta novamente, o que pode causar um efeito cascata de trabalho duplicado e throttling. O sintoma parece um erro intermitente de “bot não está respondendo”, mas a causa raiz é arquitetural.

Construindo um pipeline assíncrono pronto para produção

  1. Ponto de entrada do Webhook – O endpoint HTTP do bot aceita a atividade do Teams e confirma imediatamente o recebimento.
  2. Enfileirar o evento – O manipulador envia o payload para uma fila durável, como o Azure Service Bus.
  3. Worker de segundo plano – Uma Azure Durable Function, um gatilho do Service Bus ou qualquer worker de longa duração extrai a mensagem, executa o raciocínio do LLM ou a orquestração de ferramentas e envia a resposta final de volta ao Teams por meio da API de mensagens proativas do Bot Framework.

Como o webhook inicial retorna instantaneamente, o Teams nunca atinge seu timeout, e o trabalho pesado prossegue em seu próprio ritmo. A fila absorve picos, e os workers escalam automaticamente com base no tamanho do backlog.

Guia de decisão rápida (o teste do quadro branco)

  • Você consegue desenhar toda a árvore de decisão antes de escrever qualquer código? Sim → Construa um bot. O fluxo determinístico se ajusta ao modelo do Bot Framework e permanece dentro da janela de resposta.
  • O problema é definido por um objetivo de alto nível e uma lista de ferramentas possíveis? Sim → Construa um agent. Deixe o LLM planejar e invocar ferramentas; delegue o planejamento para um worker de segundo plano.

O que esperar a seguir

Este guia é a primeira parte de uma série para desenvolvedores .NET 9 que estão construindo soluções inteligentes de Teams no Azure.

Se você já está vendo erros de “Bot timed out” nos logs do Teams, a solução é simples: desacople o webhook do trabalho pesado, adote um worker orientado a filas e escolha o tipo de extensão correto desde o início. A plataforma tem um limite de timeout, mas sua arquitetura pode evitá-lo.

Conclusão: Classificar incorretamente uma extensão do Teams como um bot força um design síncrono que o Teams não consegue sustentar. Separe a requisição do raciocínio, escolha o SDK correto e sua solução de Teams permanecerá responsiva, mesmo quando o cérebro por trás dela for um agent impulsionado por LLM.