No dia 20 de agosto de 2026 a Red Hat anunciou a disponibilidade geral (GA) do automation orchestrator como add-on do Ansible Automation Platform (AAP) 2.7 [1]. É um daqueles lançamentos que, lido por cima, parece “mais uma UI de arrastar e soltar”. Lido por baixo, é uma mudança de arquitetura na forma como times de SRE/plataforma tratam orquestração em escala.

Este post é minha leitura técnica do anúncio. O que o componente realmente faz, onde ele se encaixa (e onde não se encaixa) no seu stack, e como ele se compara de verdade a Terraform/OpenTofu, GitOps/ArgoCD, Jenkins e ferramentas de orquestração de eventos como StackStorm.

O que é o automation orchestrator, concretamente

O automation orchestrator é um canvas de workflow composável que roda dentro do seu ambiente AAP existente. Ele pega o que você já tem: job templates, playbooks, inventories, regiments de governança, e deixa você costurrar tudo isso em workflows mais complexos usando:

  • Nós de lógica (branch, conditional, approval gates)
  • Gatilhos event-driven (via Event-Driven Ansible)
  • Recomendações de agentes de IA embutidas no canvas

O ponto-chave que a Red Hat martela, e que é tecnicamente honesto, é que nada do que você já construiu precisa ser migrado. Seus workflow templates e scheduled jobs continuam rodando no automation controller; o orchestrator é uma camada de orquestração por cima, e qualquer workflow nele herda automaticamente o RBAC, os approval gates e o audit trail que você já tem [1]. Não é um “novo produto que substitui o anterior”, é um acréscimo.

Isso importa porque a alternativa real no mercado costuma ser: ou você aceita um nova plataforma de orquestração (e reconstroi governança do zero), ou você empilha scripts em um CI/CD genérico (e perde RBAC/audit nativo).

O conceito que eles chamam de “multimode automation”

A Red Hat usa o termo multimode automation para descrever a capacidade de casar o “tipo de execução certo” a cada passo do workflow, sob um modelo de governança compartilhado [1]. Traduzindo pro português de quem opera:

Em um mesmo fluxo, o passo 1 pode ser um playbook Ansible contra um bare metal via SSH, o passo 2 um rulebook event-driven escutando um webhook, o passo 3 uma aprovação humana (approval gate), e o passo 4 uma chamada a um agente de IA que sugere o próximo nó.

É exatamente esse tipo de fluxo híbrido que ferramentas puras de uma única categoria não cobrem bem. Vamos ao comparativo.

Comparação com o resto do mercado

vs. Terraform / OpenTofu (provisionamento)

Terraform e OpenTofu são excelentes para provisionar infraestrutura declarativa: clusters, VPCs, recursos de nuvem. O problema começa no Day 2:

  • Terraform gerencia o estado desejado da infra. Ele não foi desenhado para “execute este runbook de remediação CVE agora porque um alerta disparou”.
  • O provider de Kubernetes do Terraform existe, mas a comunidade não recomenda usá-lo para workloads dinâmicas [2].

O automation orchestrator não compete com Terraform no provisionamento. Ele compete no espaço que o Terraform deixa vazio: orquestrar ações (não declarar estado) sobre recursos já vivos, incluindo o que o Terraform acabou de criar. O padrão recomendado de mercado é justamente Terraform primeiro (provisiona), Ansible/AAP depois (configura e opera) [3]. O orchestrator eleva esse “depois” para um workflow visual e governado.

vs. GitOps / ArgoCD (entrega declarativa em K8s)

ArgoCD é o padrão de ouro para delivery GitOps em Kubernetes: drift correction, sync automático, declarative. Mas ele só enxerga o que está no Git como fonte da verdade, e só para o que vira manifesto K8s.

O que o ArgoCD não faz:

  • Rodar um playbook contra um switch de rede (SSH/API)
  • Acionar uma aprovação humana fora do ciclo de PR
  • Orquestrar um fluxo que mistura nuvem, VM e appliance

O automation orchestrator cobre esse gap. Em arquiteturas híbridas (a realidade de quem roda produção de verdade), você ainda tem VMs que nunca containerizaram, gear de rede, e runbooks que o GitOps simplesmente não modela. O orchestrator orquestra esse “resto” sem forçar tudo para dentro do Kubernetes.

vs. Jenkins (CI/CD genérico)

Jenkins faz quase tudo, inclusive orquestrar. O custo é conhecido: você gere o Jenkins. Pipelines em Groovy, plugins frágeis, e o ponto que mais dói para SRE é que o RBAC e audit trail são algo que você tem que construir e manter, não algo herdado do seu control plane de automação.

O automation orchestrator herda RBAC/audit do AAP por construção. Se sua organização já roda AAP com governança madura, colocar a orquestração no Jenkins significa duplicar esse modelo de controle. O orchestrator elimina essa duplicação.

vs. StackStorm / ServiceNow Orchestration (orquestradores de evento puro)

Aqui a comparação é mais justa: StackStorm e ServiceNow são orquestradores de workflows orientados a evento. O diferencial do automation orchestrator:

  • Partida do zero vs. partida do que você já tem: StackStorm exige modelar suas integrações; o orchestrator conecta direto nos job templates AAP que já estão em produção.
  • Custo de entrada em híbrido: ServiceNow Orchestration é caro e pesado para times de infra; o orchestrator é um add-on de uma plataforma que o time de SRE muitas vezes já paga.

Por que, no cenário híbrido, o produto da Red Hat leva vantagem

Resumindo os pontos acima em um argumento direto:

  1. Governança herdada, não reconstruída. RBAC, approval gates e audit trail já existem no AAP. O orchestrator os herda. Concorrentes genéricos (Jenkins) ou de outra categoria (ArgoCD) não.
  2. Sem migração. Você não reescreve nada do que já roda no controller. É camada por cima.
  3. Multimode real. Mistura execução Ansible (SSH/API/agentless), event-driven e IA num único canvas, algo que nenhuma das alternativas cobre ponta a ponta nativamente.
  4. Hybrid-first. Desenhado para o mundo que existe (VM + K8s + network + cloud), não só para o mundo Kubernetes-puro que o GitOps assume.

A parte dos “agentes de IA” e o elefante na sala: n8n

O anúncio da Red Hat menciona AI agent recommendations embutidas no canvas. É aqui que a comparação fica interessante, e é onde mora o principal concorrente de facto que times de SRE/devops estão adotando em 2026 para exatamente esse caso: o n8n.

O n8n é um workflow automation tool open-source com canvas visual de arrastar-e-soltar, nodes para centenas de integrações, e suporte nativo a LLMs/agentes (nodes de OpenAI, LangChain, ferramentas de MCP). É trivial montar nele um “agente que lê um alerta, consulta um LLM, e dispara uma ação”. Muita gente está usando n8n justamente para a automação de agentes que a Red Hat agora posiciona como diferencial do orchestrator.

Então, por que não é só “usa n8n e pronto”?

Onde o n8n brilha

  • Velocidade de prototipagem. Nodes de integração prontos (Slack, HTTP, DBs, LLMs) fazem um PoC de agente subir em minutos.
  • Comunidade e flexibilidade. Qualquer API vira um node. Para automação de negócio e fluxos de dados, é excelente.
  • Custo de entrada baixo. Open-source, self-hosted, sem licença corporativa.

Onde o n8n não entra no território do orchestrator

  • Execução agentless contra infra. O n8n roda ações via API/HTTP. Para tocar um bare metal via SSH, um appliance de rede, ou um playbook Ansible já existente, você tem que reimplementar a ponte, enquanto o orchestrator já é Ansible, herdando todos os execution environments e conexões que seu time já tem.
  • Governança operacional. RBAC, approval gates e audit trail enterprise não são o core do n8n. Você consegue travar acessos, mas não herda um modelo de governança de automação já estabelecido no AAP.
  • Confiança do “proven automation”. O argumento da Red Hat de que “o que você já construiu fica exatamente onde está” vale também na outra ponta: seu controller AAP já tem playbooks testados, approvals e trilha de auditoria. Colocar isso num n8n significa duplicar e revalidar tudo.

O ponto honesto sobre automação de agentes

A automação de agentes de IA em 2026 tem dois mundos que não deveriam ser confundidos:

  1. Agente de produtividade (n8n, Make, Zapier): orquestra SaaS, dados, notificações, e “decide” via LLM. Ótimo para o plano do negócio.
  2. Agente de operação de TI (orchestrator + AAP): sugere o próximo nó de um runbook governado, mas a execução real ainda passa por playbooks com RBAC e audit. É “IA assistindo o operador”, não “IA apertando o botão sozinha”.

O risco de jogar automação de agentes de infra no n8n é exatamente esse: a parte “apertar o botão” vira uma chamada HTTP qualquer, fora do seu modelo de controle. O orchestrator mantém a ação dentro da fronteira de segurança que você já tem.

Minha leitura: n8n e orchestrator não são exclusivos. n8n para a automação de agentes de produtividade/integração; orchestrator para a automação de agentes sobre infra viva e governada. Tentar usar n8n como orquestrador de runbooks de produção é possível, mas você estará reconstruindo, em código e em processos, o que o AAP já te dá de graça.

Um exemplo prático: remediação de CVE

O anúncio usa um caso de CVE remediation como exemplo de canvas [1]. O fluxo típico que dá pra montar:

[Event-Driven trigger: alerta de scanner CVE]
        → [Logic node: severidade > 9?]
              → SIM: [Approval gate: chamado ao on-call SRE]
                        → [Job template: patch via Ansible nos hosts afetados]
                        → [Job template: validação de health check]
                        → [AI agent: sugere rollback se métricas degradarem]
              → NÃO: [Job template: agendado para janela de manutenção]

Tente fazer isso só com Terraform (não provisiona o que já está vivo), só com ArgoCD (não toca fora do K8s), ou só com Jenkins (reconstruir RBAC/audit). Dá, mas cada um desses caminhos carrega um custo de integração que o orchestrator já absorveu por estar dentro do AAP.

Onde ele NÃO é a resposta

Pra ser honesto (e útil), o automation orchestrator não substitui:

  • Terraform/OpenTofu para provisionamento declarativo de infra.
  • ArgoCD para delivery GitOps contínuo em Kubernetes.
  • Um CI real (GitHub Actions, GitLab CI) para build/test de aplicação.

Ele é a cola de orquestração para o que essas ferramentas deixam de fora: ações operacionais híbridas, orientadas a evento, governadas. Se o seu mundo é 100% Kubernetes e 100% GitOps, o ganho é menor. Se o seu mundo é híbrido e cheio de runbooks, é onde ele brilha.

Conclusão

O automation orchestrator do AAP 2.7 não é “mais uma UI”. É a Red Hat reconhecendo que a automação madura não é sobre provisionar infra uma vez. É sobre orquestrar fluxos operacionais complexos, em sistemas heterogêneos, sob governança consistente. Entre as opções de mercado, ele é a que melhor resolve o caso híbrido sem te obrigar a reconstruir governança ou migrar o que já funciona.

Se você já roda AAP, o add-on é um passo na direção certa. Se não roda, o custo de adoção (nova plataforma + licença) ainda precisa ser pesado contra StackStorm open-source ou Jenkins + muito suor.

Referências

[1] Red Hat, Unify IT workflows at scale with the new automation orchestrator for Ansible Automation Platform (2026-08-20). https://www.redhat.com/en/blog/unify-it-workflows-scale-new-automation-orchestrator-ansible-automation-platform

[2] tech-insider.org, Terraform vs Ansible [2026]. (Nota: provider K8s do Terraform não é recomendado para workloads dinâmicas.)

[3] harness.io / usekestrel.ai, Ansible vs Terraform e melhores práticas de composição (Terraform provisiona → Ansible opera).

[4] Red Hat Developers, What’s new in Red Hat Ansible Automation Platform 2.7 (2026-06). https://developers.redhat.com/articles/2026/06/10/whats-new-red-hat-ansible-automation-platform-2-7