Blue-green ou canário para agentes de IA?

Trocar a versão do sistema não encerra o trabalho em andamento

Uma empresa mantém duas versões de um agente comercial. A nova versão passou pelos testes e está pronta para receber tráfego. A equipe move todas as novas entradas para ela e conserva a anterior disponível para rollback.

A troca parece segura até alguém perceber que dezenas de oportunidades continuam em filas abertas pela versão antiga. Algumas aguardam aprovação. Outras já criaram tarefas no CRM e esperam confirmação. Voltar o roteamento não desfaz esses efeitos nem informa qual versão deve concluir cada caso.

Estratégias conhecidas de publicação de software precisam de adaptação quando o componente executa trabalho, conserva estado e produz consequências externas. Blue-green facilita uma troca coordenada entre dois ambientes. Canário expõe a candidata a uma parcela delimitada da produção e amplia conforme a evidência.

A escolha depende do tipo de unidade processada, da possibilidade de separar coortes, do custo de manter ambientes equivalentes e da capacidade de reconciliar estado e efeitos durante a reversão.

O que é implantação blue-green

Blue-green mantém dois ambientes de produção equivalentes:

• o ambiente ativo recebe a operação atual;
• o ambiente candidato contém a nova composição;
• a equipe valida a candidata antes da troca;
• o roteador direciona novas entradas para o novo ambiente;
• o ambiente anterior permanece disponível durante a janela de reversão.

A estratégia reduz o tempo de indisponibilidade e permite voltar rapidamente o ponto de entrada. Também oferece um ambiente completo para testes finais de configuração, integração e capacidade.

Para agentes de IA, cada ambiente precisa representar a composição inteira: modelo ou rota, instruções, skills, ferramentas, fontes, políticas, permissões, filas, memória, observabilidade e controles. Trocar apenas o código enquanto ambos compartilham configuração mutável elimina parte da separação que o desenho deveria oferecer.

O que é implantação canário

Na implantação canário, a versão candidata recebe uma parte controlada das unidades reais. A versão vigente continua atendendo o restante durante a comparação.

A exposição pode seguir:

• uma equipe interna;
• uma carteira de clientes;
• uma classe de tarefa;
• um grupo de usuários;
• uma região;
• uma janela acompanhada;
• uma fração estável do volume;
• ações de baixo impacto.

O guia de implantação canário para agentes de IA detalha coortes, afinidade por entidade, critérios de avanço e rollback. Neste artigo, o canário funciona como uma das opções de publicação a comparar com blue-green.

A diferença central está na exposição

| Critério | Blue-green | Canário | |---|---|---| | troca inicial | novas entradas migram em conjunto | candidata recebe uma parcela | | comparação em produção | curta ou indireta | concorrente por coorte ou classe | | contenção | retorno do roteamento para o ambiente anterior | interrupção da coorte candidata | | infraestrutura | dois ambientes completos e equivalentes | duas versões operando com roteamento segmentado | | velocidade de migração | alta depois do gate | gradual por anéis | | aprendizado | valida troca e reversão | mede comportamento em segmentos reais | | risco principal | estado e efeitos atravessarem a troca | evidência fraca por coorte enviesada ou pequena |

Blue-green costuma ser mais simples quando a versão pode receber novas unidades sem disputar objetos em andamento e quando a equipe consegue validar bem a candidata antes do corte. Canário ganha força quando a incerteza depende do comportamento real e a empresa consegue segmentar a exposição sem misturar o estado.

Quando blue-green tende a funcionar melhor

Tarefas curtas e delimitadas

Se cada execução começa e termina em poucos minutos, a equipe pode interromper novas entradas, deixar o ambiente atual drenar e mover o roteamento depois. O número de unidades atravessando a troca permanece pequeno.

Estado externo e compatível

Quando o estado oficial vive em sistemas com contratos estáveis, as duas versões conseguem consultar a mesma unidade sem criar memória incompatível. O agente não depende de uma sessão interna difícil de transferir.

Efeitos idempotentes

A repetição de uma tentativa não pode duplicar tarefa, envio, atualização ou pagamento. Chaves estáveis e confirmação no destino reduzem o risco de uma unidade reaparecer depois da troca.

Testes offline representativos

Blue-green transfere muitas entradas de uma vez. A equipe precisa chegar ao corte com regressão, falhas de integração, permissões e desempenho já bem testados. Se a principal incerteza só aparece em produção, o canário oferece contenção melhor.

Reversão rápida de novas entradas

O roteador precisa conseguir devolver o fluxo ao ambiente anterior sem deploy adicional. DNS com propagação longa ou configuração manual em vários pontos enfraquece a promessa de rollback rápido.

Ambientes realmente equivalentes

Segredos, políticas, rede, ferramentas, fontes, modelos e observabilidade precisam corresponder. Uma candidata testada com permissões menores ou base diferente não representa o corte que ocorrerá.

Quando canário tende a ser melhor

A qualidade depende de entradas reais

Novos canais, documentos, idiomas, perfis de cliente e exceções alteram o comportamento do agente. Uma coorte limitada permite observar a candidata antes de ampliar.

O processo admite segmentação estável

A empresa consegue manter todos os eventos de um cliente, chamado, pedido ou oportunidade na mesma versão. Isso evita que duas composições escrevam sobre o mesmo objeto.

A mudança amplia autonomia

Liberar envio, escrita, desconto, atualização cadastral ou outra consequência pede evidência específica. A candidata pode começar em preparação ou em ações reversíveis para uma classe simples.

Existe capacidade de comparar

A equipe possui linha de base, métricas por versão e volume suficiente nas classes relevantes. Sem comparação, o canário vira apenas uma publicação menor.

O erro pode ser contido por faixa

A arquitetura consegue suspender uma carteira, ferramenta, ação ou classe sem derrubar a versão vigente. Feature flags para agentes de IA ajudam a separar capacidade disponível de versão instalada.

Estado é o critério que costuma ser ignorado

Software sem estado pode trocar instâncias e continuar atendendo. Agentes frequentemente mantêm trabalho entre eventos.

Uma unidade pode estar:

• recebida;
• em preparação;
• aguardando ferramenta;
• esperando aprovação humana;
• parcialmente executada;
• aguardando confirmação externa;
• interrompida;
• em retentativa;
• concluída com pendência;
• sob investigação.

Antes de escolher a estratégia, defina quem possui cada estado durante a transição. Uma versão nova consegue continuar uma tarefa iniciada pela anterior? O schema de memória permanece compatível? Uma aprovação concedida para uma composição ainda vale depois da troca? A fila preserva a versão de origem?

Sem resposta, a equipe pode mover o tráfego e deixar a parte mais perigosa operando fora da visão.

Modele a unidade de roteamento

O roteador deve trabalhar com uma unidade que represente o processo.

Por execução

Cada chamada pode seguir para uma versão. Funciona apenas quando as execuções são independentes e não disputam estado.

Por entidade

Todos os eventos de um cliente, contrato, pedido, chamado ou oportunidade permanecem na mesma composição. É a opção mais segura para jornadas longas.

Por classe de tarefa

A versão candidata recebe somente tipos aprovados. Uma nova rotina de classificação pode entrar sem alterar mensagens externas.

Por capacidade

A mesma versão pode usar leitura nova e manter escrita antiga, desde que flags e permissões imponham essa fronteira na camada executável.

Por ambiente completo

Blue-green direciona novas unidades para um conjunto inteiro de serviços. O roteamento ainda precisa reconhecer tarefas que pertencem ao ambiente anterior.

A chave de afinidade deve ser estável, registrada e disponível em reentregas. Sortear novamente a cada evento faz a unidade alternar entre versões e destrói a atribuição do resultado.

O rollback precisa tratar quatro camadas

1. Entrada

Bloqueie novas unidades na candidata e confirme que agendadores, webhooks, filas e chamadas diretas respeitam a mudança.

2. Trabalho em andamento

Decida quais unidades podem terminar na candidata, quais devem congelar e quais podem migrar. Transferência exige contrato explícito de estado entre versões.

3. Efeitos externos

Identifique tarefas criadas, mensagens enviadas, registros alterados, reservas, arquivos e outras consequências. O rollback de código não apaga o que já aconteceu.

4. Reconciliação

Compare fila, memória e sistemas oficiais. Resolva confirmação perdida, duplicidade, versão divergente e objetos parcialmente atualizados antes de retomar o volume normal.

A reconciliação de agentes de IA ajuda a tratar diferenças entre intenção registrada e estado confirmado. A idempotência em agentes reduz repetição de efeitos quando uma unidade volta à fila.

Como executar blue-green com agentes

1. Congele a composição candidata

Registre código, modelo, instruções, fontes, ferramentas, políticas, permissões e schema de estado. Mudanças durante a validação criam outro candidato.

2. Prepare o ambiente verde

Use integrações e configurações equivalentes sem permitir consequências prematuras. Segredos devem vir do cofre e respeitar escopos próprios.

3. Rode testes de integridade

Verifique saúde, conectividade, catálogo de ferramentas, políticas, filas, logs, custo, latência e capacidade de interrupção.

4. Execute regressão e casos de transição

Inclua tarefas sem estado, em andamento, aguardando aprovação, com confirmação perdida e com retentativa. Teste compatibilidade de memória e payloads.

5. Defina a política de drenagem

Pare novas entradas no ambiente azul quando necessário e permita que unidades seguras terminem. Defina prazo e destino para tarefas que não concluem.

6. Faça o corte

Mova novas unidades para o verde por um mecanismo observável. Registre horário, responsável, configuração e primeira unidade recebida.

7. Acompanhe a janela

Monitore qualidade, falhas, filas, correções, custo e desfechos. Preserve o azul sem mudanças enquanto a possibilidade de retorno estiver aberta.

8. Encerre a transição

Depois da decisão, desative recursos antigos de forma controlada, revogue credenciais exclusivas, retenha evidências e atualize o inventário de versões.

Como executar canário com agentes

1. Escolha uma coorte legível

Use classe, carteira, equipe ou entidade que represente a próxima faixa de expansão. Evite selecionar apenas usuários especialistas e casos fáceis.

2. Preserve afinidade

Todos os eventos da unidade permanecem na candidata durante a janela. Registre a chave e a versão atribuída.

3. Limite a consequência

Comece por leitura, preparação ou escrita reversível. A coorte pequena não justifica liberar uma ação crítica sem evidência própria.

4. Defina referência e recortes

Compare a candidata com a versão vigente ou com a linha de base do processo. Abra resultados por classe e risco.

5. Escreva os gates antes da exposição

Defina entrada, avanço, pausa e reversão. Erros impeditivos encerram a janela independentemente da média.

6. Amplie por anéis

Aumente volume, usuários, classes e autonomia separadamente. Cada passagem deve produzir evidência suficiente para a próxima.

7. Reconcile ao sair

Mesmo uma coorte limitada pode deixar unidades abertas. A decisão final precisa resolver estado, fila e efeitos antes de remover a rota.

Uma estratégia híbrida costuma ser necessária

Blue-green e canário podem trabalhar juntos.

A equipe prepara um ambiente verde completo, executa regressão e valida integrações. Em vez de mover toda a operação, o roteador envia uma coorte estável para esse ambiente. A candidata enfrenta produção com alcance limitado. Depois dos gates, novas unidades migram em conjunto e o ambiente azul permanece disponível durante uma janela curta.

Esse desenho combina isolamento de ambiente com exposição gradual. Também custa mais. A empresa precisa manter duas composições, roteamento por coorte, métricas comparáveis e tratamento de estado.

Use a combinação quando o impacto justifica a complexidade. Em um agente interno de resumo sem escrita, um deploy simples com flag pode ser suficiente. Em um agente que altera CRM, atende clientes ou participa de processos financeiros, o custo de contenção e reversão merece peso maior.

Blue-green, canário, modo sombra e feature flag

Essas práticas controlam objetos diferentes.

Blue-green

Controla a troca entre ambientes completos e preserva uma rota de retorno.

Canário

Controla quem recebe a versão candidata e quanto da produção fica exposto.

Modo sombra

Compara comportamento sobre entradas reais sem liberar a consequência externa. É útil antes do canário quando a incerteza está na decisão do agente.

Feature flag

Controla se uma capacidade específica está disponível para um público e condição. Pode interromper escrita sem retirar leitura e preparação.

O controle de mudanças em agentes de IA governa a decisão completa: hipótese, versão, teste, aprovação, publicação, observação e reversão.

Matriz de decisão

| Pergunta | Sinal para blue-green | Sinal para canário | |---|---|---| | a tarefa é curta e independente? | forte | neutro | | existe estado longo por entidade? | exige drenagem e compatibilidade | favorece coorte com afinidade | | a qualidade offline é representativa? | forte | ainda pode complementar | | a principal incerteza depende de produção? | fraco | forte | | é possível separar usuários ou classes? | dispensável | necessário | | a troca precisa ocorrer rapidamente? | forte | fraco | | a consequência aumentou? | pede gates adicionais | favorece exposição gradual | | dois ambientes completos cabem no custo? | necessário | depende da arquitetura | | há volume para comparar coortes? | dispensável | necessário | | rollback de estado foi testado? | obrigatório | obrigatório para a faixa |

A matriz orienta a conversa. A decisão final precisa considerar impacto, reversibilidade, volume, ciclo da tarefa e capacidade real de operação.

Exemplo: agente de triagem de atendimento

Uma empresa possui um agente que identifica o cliente, classifica o assunto, define prioridade e encaminha o chamado. A nova versão passa a consultar contrato e histórico recente.

Opção blue-green

A equipe cria um ambiente verde, testa integrações e deixa o azul drenar chamados abertos. Depois, move todos os novos chamados. Funciona se o volume de unidades em andamento for pequeno, o schema permanecer compatível e o rollback puder devolver novas entradas sem perder atribuição.

Opção canário

Uma fila interna de baixo risco recebe a candidata. Todos os eventos desses chamados ficam nela. A equipe compara encaminhamento, reclassificação, prazo e casos sem fonte. Depois, amplia para outra fila.

Opção híbrida

O ambiente verde recebe primeiro a fila interna. Ao cumprir os gates, passa a receber todos os novos chamados, enquanto o azul conclui ou transfere unidades conforme a política de drenagem.

A escolha híbrida oferece evidência melhor, mas pede roteamento, métricas e governança suficientes para não criar dois processos invisíveis.

Erros comuns

Tratar retorno do tráfego como rollback completo

Novas entradas voltam. Filas, aprovações, efeitos e memórias permanecem. O plano precisa reconciliar cada camada.

Compartilhar estado mutável sem contrato

Ambientes separados que leem e escrevem a mesma estrutura podem corromper compatibilidade. Versões precisam declarar quais campos e estados entendem.

Usar percentual sem afinidade

A mesma oportunidade alterna entre versões a cada evento. A comparação perde validade e as duas composições podem produzir ações conflitantes.

Manter o ambiente anterior sem testar retorno

Uma versão parada pode perder credencial, configuração, capacidade ou compatibilidade. O rollback só existe quando foi exercitado.

Escolher canário sem volume suficiente

Poucos casos comuns não sustentam conclusão sobre exceções raras. Testes dirigidos continuam necessários para riscos críticos.

Escolher blue-green para evitar observação

Troca rápida reduz indisponibilidade. Não prova qualidade operacional. A equipe ainda precisa monitorar resultado e possuir critérios de interrupção.

Checklist antes de publicar uma nova versão

• [ ] A composição candidata está congelada e identificável?
• [ ] A unidade de trabalho e a chave de afinidade foram definidas?
• [ ] Estado, memória e filas são compatíveis entre versões?
• [ ] Novas entradas podem ser interrompidas por um ponto conhecido?
• [ ] Unidades em andamento possuem política de drenagem ou migração?
• [ ] Efeitos externos usam idempotência e confirmação?
• [ ] Ambientes possuem políticas e permissões equivalentes?
• [ ] Regressão cobre falhas e transições de estado?
• [ ] A estratégia escolhida corresponde à incerteza principal?
• [ ] Coortes são comparáveis quando houver canário?
• [ ] Critérios de avanço, pausa e reversão foram definidos?
• [ ] Métricas separam versão, classe, risco e resultado?
• [ ] O rollback foi testado com tarefas em vários estados?
• [ ] A reconciliação possui dono e procedimento?
• [ ] O ambiente anterior tem prazo e condição de desativação?

A estratégia precisa proteger o processo inteiro

Blue-green reduz atrito na troca entre ambientes. Canário reduz a exposição inicial e produz evidência sobre comportamento real. Nenhuma das duas resolve sozinha estado incompatível, efeito duplicado, aprovação pendente ou ausência de critério.

A escolha melhora quando a empresa parte da unidade de trabalho e da consequência possível. Depois, define ambiente, coorte, afinidade, gates e reconciliação. Publicar um agente com segurança significa preservar a capacidade operacional durante a mudança, inclusive quando a versão candidata precisa voltar.