DEV Community

Cover image for Um plano de contingência que avisa sozinho: MCP, agent e WhatsApp no Amazon Quick
Iago Elion Pimentel
Iago Elion Pimentel

Posted on

Um plano de contingência que avisa sozinho: MCP, agent e WhatsApp no Amazon Quick

Blumenau fica nas margens do rio Itajaí-Açu, e "cota de alagamento" é vocabulário cotidiano aqui. A Dati mantém um Plano de Contingência para Enchentes que define, faixa de nível por faixa de nível, o que cada um faz. O plano sempre existiu. O que faltava era saber, a qualquer hora, qual faixa vale agora.

Na noite de 11 de setembro de 2026, com a Defesa Civil projetando 9 metros para as 2h da manhã, essa resposta passou a chegar sozinha no WhatsApp da liderança, de hora em hora. Montar esse envio automático levou 27 minutos.


O El Niño devolveu uma pergunta antiga

A Defesa Civil de Santa Catarina confirmou o El Niño em junho de 2026. A nota daquele mês estimou 90% de probabilidade de formação durante o inverno, com tendência de intensidade forte a muito forte entre a primavera e o verão, e apontou intensificação dos efeitos a partir de setembro. O Vale do Itajaí aparece ali como a região historicamente mais atingida.

Quem trabalha em Blumenau conhece o assunto sem precisar de nota técnica. Uma previsão de chuva prolongada reorganiza a rotina de todo mundo, das escolas às empresas.

O plano da Dati define as ações correspondentes a cada faixa de nível do rio, do comunicado inicial ao acionamento da liderança. E um plano desse tipo depende de uma informação única para funcionar: o nível corrente do rio. Sem esse número, nenhuma faixa pode ser acionada.

O número existe, e a consulta dele era manual

A Proteção e Defesa Civil de Blumenau publica o nível do rio em um painel aberto, alimentado pelo sistema AlertaBLU.

Painel público da Defesa Civil de Blumenau, com a tabela de faixas à esquerda e a situação corrente à direita

O painel público da Defesa Civil de Blumenau. A tabela da esquerda define as faixas, e o bloco da direita traz a medição corrente.

Cada faixa corresponde a um conjunto de ações do plano da Dati. A faixa Alerta, que começa em 6 metros, determina o acionamento do plano de continuidade, o acompanhamento do canal de notícias e do nível do rio, e o acionamento da liderança em situação de risco. A orientação operacional acompanha essas três linhas: retirada do notebook ao final do expediente, celular e powerbanks carregados, e preparação de casa, família e kit de emergência para quem mora em área de risco.

A rotina anterior tinha três tarefas. Alguém abria o painel, localizava a medição mais recente e comparava o valor com a tabela. Depois disso, a mesma pessoa avisava o time.

A fonte atualiza uma vez por hora. Uma cheia dura dias. Multiplicar um pelo outro dá dezenas de consultas manuais, e é por isso que o assunto virou trabalho de engenharia.

Julho: o space, o agent e o MCP server

Diagrama do caminho: feed público da Defesa Civil, MCP server, agent e flow no Amazon Quick, entrega no WhatsApp

O caminho completo. O MCP server roda na conta AWS da Dati, enquanto o agent e o flow vivem dentro do Amazon Quick.

1. O space com o plano

Em 3 de julho de 2026 o Plano de Contingência passou a ocupar um space do Amazon Quick — a biblioteca de documentos que as demais funções do produto consultam —, como documento único de conhecimento, com pouco mais de dois megabytes. Qualquer recurso do Quick que consulte aquele space enxerga o plano inteiro. O conteúdo deixou de depender de quem lembra do arquivo e de onde ele estava salvo.

2. O agent de contingência

Em 6 de julho nasceu o Agente de Contingência Dati, apoiado naquele space. O propósito declarado é responder perguntas de funcionários sobre procedimentos de segurança, faixas de alerta e ações em situação de risco de enchente. A tela oferece três perguntas prontas: o nível atual do rio, os pontos de encontro em caso de evacuação e o procedimento da faixa Observação. Ele nasceu conversacional, para uma pessoa perguntar e ele responder.

As instruções dele determinam quatro comportamentos:

  1. Escopo fechado. As respostas ficam restritas ao conteúdo do plano, com proibição explícita de suposição sobre informação ausente do documento. Fora do escopo, o agent reconhece a ausência e recomenda contato com a liderança.
  2. Faixas fixas. Os limites numéricos de cada faixa, com a cor correspondente, ficam escritos na instrução. A classificação deixa de ser julgamento livre do modelo.
  3. Dado ao vivo. Instrução expressa contra a confiança no conhecimento gravado. O plano guardado no space não traz medição corrente, portanto uma resposta apoiada somente nele entregaria número velho.
  4. Formato obrigatório de saída. Nível, tendência, classificação e horário de atualização, seguidos de um parágrafo descritivo e da conclusão sobre necessidade de ação. Um agent que responde em formato livre entrega texto diferente a cada execução, e uma automação construída sobre saída variável fica frágil.

3. O MCP server sobre o feed público

Em 8 de julho entrou o terceiro componente: um MCP server que expõe o nível do rio como tool. O servidor roda na conta AWS da Dati e consome o feed público da Defesa Civil municipal.

O feed devolve as últimas 24 leituras horárias, com o nível e o horário de cada uma, e a tabela de faixas com o piso de cada faixa em metros.

A escolha por um MCP server, em lugar de deixar o agent buscar a página sozinho, tem três razões:

  • Contrato. Uma tool declara nome, descrição e parâmetros, portanto o modelo sabe que a informação existe e sabe como pedi-la. Uma página HTML depende de o modelo acertar o seletor certo em uma tela que pode mudar.
  • Reuso. O mesmo servidor atende agent, flow e qualquer cliente que fale MCP, sem duplicação de código de coleta.
  • Tipo de autenticação. O Amazon Quick autentica um conector MCP por client credentials, que é autenticação de serviço. Essa propriedade tem consequência adiante.

O servidor não transforma o dado. A tool devolve a resposta da origem como ela chega, portanto o modelo consumidor localiza a leitura mais recente e cruza o valor com a tabela por conta própria. A decisão foi deliberada.

Ao final de julho o conhecimento, a classificação e a coleta estavam resolvidos. A distribuição permanecia manual.

Setembro: o conector do WhatsApp

O Amazon Quick ganhou um conector de WhatsApp em junho de 2026. O Dati Labs abriu um levantamento sobre ele no início de setembro, com uma pergunta de outro projeto: a viabilidade de usar áudio recebido no WhatsApp como entrada de processo agêntico.

O conector foi criado em 3 de setembro de 2026 durante aquele levantamento. A resposta à pergunta original foi negativa. O conector expõe dezessete ações, onze de escrita e seis de leitura, e nenhuma delas lê, recebe ou lista mensagem recebida. A mensagem que chega ao número da empresa vive no webhook da Meta, fora do alcance do produto.

O levantamento produziu duas conclusões que interessam a este relato.

A primeira diz respeito ao Quick Automate, que é a área de automação do produto. O Automate recusa o conector do WhatsApp. A causa é o tipo de autenticação: o conector usa grant de usuário, que é autorização em nome de uma pessoa, enquanto as automations exigem autenticação de serviço. A recusa foi medida em quatro telas distintas do Automate. Duas delas nomeiam a causa em texto, a saber o modal Add actions, com "Only actions configured with service authentication are supported", e o modal Add spaces, com o aviso sobre bases de conhecimento de permissão baseada em usuário. A mesma regra valeu para um segundo conector de teste. A restrição recai sobre o tipo de autenticação em lugar de recair sobre o WhatsApp.

A segunda diz respeito à revisão manual. O conector interrompe cada escrita com um pedido de revisão, e o operador submete um formulário antes do envio.

Lendo essas duas conclusões em sequência, a automação de envio pelo WhatsApp parece impossível dentro do Amazon Quick. A leitura está incompleta, e a parte que falta aparece duas seções adiante.

11 de setembro, a noite do alerta

Na sexta-feira, 11 de setembro de 2026, às 20 horas, a Proteção e Defesa Civil de Blumenau emitiu alerta máximo. A previsão hidrológica daquele horário projetava o rio Itajaí-Açu em 9 metros às 2 horas da manhã seguinte. Nove metros ultrapassam a cota de Alerta Máximo, portanto a projeção descrevia enchente.

Às 20h45 eu criei um flow no Amazon Quick. Às 21h12 publiquei. Às 21h14 a primeira mensagem chegou ao aparelho da líder do time de DHO.

Duas mensagens de alerta no WhatsApp com nível do rio, tendência e ações obrigatórias da faixa Alerta

As duas primeiras mensagens, às 21h14 e às 21h35. O nível marcava 6,32 metros, com subida de 0,54 metro por hora.

A mensagem trouxe o nível em 6,32 metros, a tendência de subida a 0,54 metro por hora, a classificação Alerta na faixa de 6 a 8 metros e o horário da medição. O texto seguiu com o aviso de que o rio havia subido mais de 3 metros em 8 horas, com a projeção de Alerta Máximo nas horas seguintes, e com as ações obrigatórias daquela faixa.

As duas mensagens da imagem têm formatos diferentes, e isso tem explicação. O formato obrigatório governa a saída do agent na etapa 1. A etapa 2 reescreve aquele conteúdo para o WhatsApp, que não renderiza tabela markdown, e essa reescrita varia a cada execução. O formato fixo protege a coleta, e a entrega permanece sem template.

A montagem inteira ocupou 27 minutos. O número cobre apenas o flow de envio: o space, o agent e o MCP server já existiam desde julho, e essa construção prévia é a razão pela qual a noite do alerta coube em meia hora.

O pico ocorreu às 5h20 de sábado, em 7,87 metros. A primeira cota de alagamento prevista pelo plano municipal fica em 7,88 metros. Blumenau escapou da enchente por um centímetro, e a Defesa Civil descartou o risco pela manhã.

A mensagem daquele horário chegou ao aparelho como todas as outras. O pico ocorreu justamente no horário em que ninguém estaria abrindo o painel para conferir.

O flow, por dentro

Editor do flow no Amazon Quick, com as duas etapas do tipo atendente de chat

As duas etapas do flow. A etapa 1 consulta o agent de contingência, e a etapa 2 envia pelo conector do WhatsApp.

O flow tem duas etapas encadeadas, ambas do tipo atendente de chat.

Etapa 1 invoca o Agente de Contingência Dati sobre o space do plano. A instrução pede o nível corrente com situação, tendência e avisos relevantes, e a saída daquela etapa fica disponível como variável referenciável dentro do flow.

Etapa 2 opera sobre o conector do WhatsApp e consome a saída anterior por referência direta no prompt. A instrução pede uma mensagem curta com status, nível e alertas, e nomeia os destinatários.

Uma característica do flow merece atenção de quem vem de ferramentas determinísticas: a etapa 2 não nomeia a ação do conector. O prompt pede o envio de uma mensagem em linguagem natural, e o planner do Quick, que decide o que executar, escolhe a ação correspondente no momento da execução.

A separação entre as duas etapas é a decisão de projeto mais útil do desenho. A coleta pertence ao agent com acesso ao plano, enquanto a distribuição pertence ao agent com acesso ao canal. A substituição do WhatsApp por outro canal dispensaria qualquer alteração na lógica de consulta.

O agendamento fica na trigger do próprio flow.

Modal de trigger do Amazon Quick, do tipo Schedule, com expressão cron personalizada

A trigger do tipo Schedule, com expressão cron disparando no minuto 2 de toda hora.

O modal oferece três tipos de trigger: Schedule, Inbound email e Quick event. A opção Schedule aceita repetições prontas e também cron personalizado. A expressão em uso dispara o flow no minuto 2 de toda hora, acompanhando o intervalo de atualização da fonte:

2 * ? * * *
Enter fullscreen mode Exit fullscreen mode

A página Scheduling your Amazon Quick Flows documenta a execução agendada de flows, com recorrência diária, semanal ou mensal, e com a opção "Run with no confirmation" para a submissão automática dos formulários de ação. O modal de trigger do editor oferece mais que isso: a expressão cron e os tipos Inbound email e Quick event não aparecem naquela página.

O Quick Automate recusa o conector do WhatsApp, todavia a trigger do Flow permanece fora dessa restrição. O flow executa sozinho, de hora em hora, com o conector que a área de automação recusa.

Os dois detalhes que decidem a viabilidade

Duas propriedades da plataforma decidem se esse desenho funciona sem pessoa no circuito. As duas estão documentadas, cada uma em uma página separada do guia do usuário, e eu cheguei às duas por tentativa antes de chegar por leitura.

A autorização do conector acontece uma vez

O pedido de revisão aparece na primeira execução, e o cartão de revisão traz, junto do formulário, a opção de confiar no conector. A autorização concedida naquele momento alcança as execuções seguintes. A página Tool permissions descreve o comportamento em uma linha, a saber "Trust. The action runs and the prompt does not appear for future invocations", e declara que a configuração vale para Chat, Agents, Pages e Flows.

A primeira execução exige uma pessoa diante da tela. As demais acontecem sozinhas. O flow acumula 72 execuções registradas até agora, e a intervenção humana ocorreu somente na primeira.

A janela de 24 horas pertence à Meta

A plataforma da Meta divide o envio em duas modalidades. A mensagem por template aprovado alcança qualquer número, mesmo sem conversa anterior com a linha. A mensagem de texto livre depende da janela de atendimento de 24 horas, que a resposta da pessoa abre e o silêncio dela fecha.

Esse desenho envia texto livre, portanto a janela precisa permanecer aberta. A abertura ocorre quando a pessoa destinatária envia uma mensagem para o número da empresa, e cada nova mensagem dela reinicia o contador.

Essa dependência é a fragilidade estrutural do desenho.

O que precisa estar pronto do lado da Meta

O projeto reaproveitou um app já criado no Meta for Developers, com número já submetido e verificação de negócio já aprovada. Nenhuma submissão foi necessária durante esta construção.

Esse preparo é o pré-requisito invisível do desenho. Quem parte do zero precisa criar o app, registrar o número, submeter templates e concluir a verificação de negócio antes de escrever a primeira linha de configuração. A documentação oficial do conector nomeia os valores exigidos pelo formulário do Amazon Quick, e a coleta deles na plataforma da Meta costuma consumir mais tempo que o preenchimento.

O que o time passou a ter

A líder do time de DHO passou a receber o nível do rio de hora em hora, com a classificação da faixa, a tendência de subida ou de descida e as ações correspondentes do plano. A informação chega ao aparelho sem consulta ao site, sem pergunta no grupo e sem dependência de alguém lembrar do horário.

A diferença aparece na decisão. O plano de contingência da Dati sempre existiu, e a dificuldade nunca esteve no documento. A dificuldade estava em saber, a qualquer momento, qual faixa vale agora. Com essa resposta chegando sozinha, a decisão sobre acionar o plano de continuidade, sobre antecipar a saída do expediente ou sobre avisar quem mora em área de risco passou a ser tomada com o número da hora corrente.

Na noite de 11 de setembro isso significou acompanhar a subida do rio, de 6,32 metros às 21 horas até o pico de 7,87 metros às 5h20, sem ninguém acordado atualizando planilha ou recarregando página. O flow acumula 72 execuções desde então, e o time continua recebendo.

O El Niño permanece ativo segundo a Defesa Civil estadual, portanto a próxima cheia dirá mais que este texto. A parte já provada tem uma frase: a montagem do flow de envio ocupou 27 minutos, sobre um space, um agent e um MCP server construídos dois meses antes, na noite em que a informação passou a importar.

Top comments (0)