No dia 20 de agosto a Red Hat liberou em GA o automation orchestrator do Ansible Automation Platform 2.7 . Confesso que quando vi o título achei que era só mais um drag and drop canvas. Fui ler com calma e a conversa é outra. É uma mudança no jeito de orquestrar operação em escala para quem vive de SRE e plataforma.

Quero deixar aqui o que entendi, sem hype. O que esse componente faz na prática, onde ele ajuda de verdade e onde ele só atrapalha se você forçar a barra. E como ele se comporta perto de coisas que a gente já usa no dia a dia como Terraform, ArgoCD, Jenkins e StackStorm.

O que é o automation orchestrator, concretamente

O automation orchestrator é um composable workflow canvas 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, e 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 acima, e qualquer workflow nele herda automaticamente o RBAC, os approval gates e o audit trail que você já tem . Não é um novo produto substituto, é um acréscimo.

Isso importa porque a alternativa real no mercado geralmente ou você aceita uma 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”

O termo multimode automation descreve a capacidade de casar o “tipo de execução certo” a cada passo do workflow, sob um modelo de governança compartilhado .:

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 usar para workloads dinâmicas.

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

vs. GitOps / ArgoCD

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, 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 e te garante menos dor de cabeça

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 na ferramenta. É aqui que a comparação fica interessante, e é onde mora o principal concorrente de facto que times de SRE/devops estão adotando para esse caso: o n8n.

Se voce não conhece, o n8n é um workflow automation tool open-source com drag and drop visual, 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”?

Qual a força do n8n

  • 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, não é necessario inicialmente a 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 verdadeiro ponto 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 . 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 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

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

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