Calcular o que a infraestrutura obriga a manter ligado

A revisão do protocolo publicada em 28/07/2026 pode cortar duas linhas fixas da fatura de nuvem e, ao mesmo tempo, abrir uma linha de desenvolvimento que ninguém orçou. O CTO da rede de distribuição de material de construção chegou ao comitê com metade dessa conta. Ele pediu verba para refazer os servidores que ligam o agente ao ERP legado, ao CRM e ao e-commerce, com promessa de reduzir custo de nuvem.

A metade apresentada era a economia, e ela existe. A metade ausente era o esforço, que aparece em lugares que o pedido não citava: rede instável, assinatura de notificação e métodos que deixaram de existir. Aprovar com uma ponta estimada e a outra em branco produz o projeto que economiza na fatura de nuvem e estoura na folha de desenvolvimento.

Este capítulo põe as duas pontas na mesma folha e mostra por que três mudanças pequenas dizem muito sobre o futuro do protocolo. No fim, monta o painel que prova, mês a mês, se a migração entregou o prometido.

Protocolo sem estado quer dizer que cada pedido chega completo, como uma carta que traz remetente e assunto sem depender da anterior. O anúncio oficial resume o efeito: qualquer pedido pode cair em qualquer cópia do servidor. Duas peças perdem a razão de existir. Uma é o roteamento com afinidade, que obriga o balanceador a lembrar quem falou com quem. A outra é o armazenamento de sessão compartilhado, que conta à cópia seguinte o que a anterior combinou.

Quem paga essas duas peças hoje tem caso concreto de redução de custo recorrente. A contrapartida vem em horas de desenvolvimento, e precisa aparecer na mesma folha:

• Reescrever a abertura de conexão, porque o initialize deixou de existir.
• Oferecer server/discover no servidor, com versões, capacidades e identidade.
• Construir a repetição segura de pedido interrompido, com controle de duplicidade.
• Refazer as assinaturas de notificação, que viraram um fluxo único com adesão por tipo.
• Trocar pedidos que o servidor fazia ao cliente pelo MRTR, em que o servidor devolve input_required e o cliente reenvia o pedido completo.

Uma correção evita cláusula errada de transporte. A especificação define dois transportes padrão: entrada e saída padrão para o servidor local e Streamable HTTP para o remoto. O transporte antigo HTTP+SSE está depreciado e já pode sair na próxima revisão. Conexão permanente de dois sentidos só existe como transporte customizado, fora do padrão.

Fornecedor que vende transporte fora do padrão como diferencial oferece custo de interoperabilidade disfarçado de vantagem. O roteiro oficial de 22/08/2026 caminha na direção contrária: quer HTTP como modelo único, inclusive para servidor local. Quem constrói sobre transporte próprio assume sozinho o custo de manter a ponte a cada revisão. Pergunte em qual proposta numerada a escolha se apoia e qual o estado dela.

A migração só termina quando o painel prova que ela entregou. Sem monitoramento, a economia fica no papel e a duplicidade aparece na reclamação do cliente. O guia abaixo define o que medir, onde medir, quando disparar alarme e quem responde, com números de partida que a empresa ajusta depois das primeiras semanas.

Peça ao time a folha com as seis linhas preenchidas e o painel mínimo com dono antes da próxima reunião do comitê. Confira no segundo mês depois da virada: a fatura precisa mostrar a economia prevista e o painel precisa registrar zero pedido duplicado em processo que escreve.