Guia completo de multiagentes de IA: o que são, como funcionam e como criar no Codex

Resposta direta

Multiagentes de IA são fluxos em que dois ou mais agentes executam partes distintas de um objetivo e seus resultados são coordenados em uma entrega comum. No Codex, uma forma prática de aplicar esse padrão é usar subagentes: a sessão principal delega trabalhos delimitados, acompanha threads separadas e reúne os resultados ao final. 1

Isso é útil quando o problema realmente pode ser dividido. Exploração de código, análise de logs, proposta de testes e outras tarefas independentes podem acontecer em paralelo. Já tarefas pequenas, muito sequenciais ou que exigem vários agentes editando os mesmos arquivos tendem a ganhar mais coordenação do que benefício. A própria documentação do Codex recomenda cautela com fluxos paralelos intensivos em escrita. 1

Neste guia, vou explicar o conceito sem transformar “multiagente” em sinônimo de “mais agentes é melhor”. Depois, vou apresentar um laboratório passo a passo no Codex CLI com um coordenador, um planejador, um desenvolvedor e um QA para criar um pequeno gerenciador de tarefas.

Informações técnicas verificadas em 16 de setembro de 2026. Como Codex, modelos e configurações evoluem, confira a documentação oficial antes de reutilizar o exemplo em outro momento.

O que você vai encontrar

• o que diferencia um agente, um subagente e um fluxo multiagente;
• quando vale usar mais de um agente e quando manter uma execução simples;
• como configurar agentes personalizados por projeto no Codex;
• um prompt completo para coordenar planejamento, desenvolvimento e QA;
• como verificar se houve delegação real e quais limitações registrar.

O que são multiagentes de IA?

Para entender um fluxo multiagente, vale separar quatro conceitos: modelo, agente, subagente e coordenação.

No Codex, a documentação chama de subagent workflow o fluxo em que agentes delegados trabalham em tarefas específicas e o agente principal reúne os resultados. Cada subagente trabalha em sua própria thread, que pode ser inspecionada nas interfaces compatíveis. 1

Imagine o pedido: “Adicione um formulário de cadastro a este sistema”.

Em uma execução com um único agente, ele pode analisar o projeto, escrever o código e conferir a alteração. Em um fluxo multiagente, um agente pode mapear as regras existentes, outro pode propor testes e um terceiro pode implementar a mudança. O coordenador mantém os requisitos e consolida as evidências.

O diferencial não é dar cargos à IA. É delegar trabalho real em contextos separados e coordenar seus resultados. Um único agente escrever “agora sou o desenvolvedor” e depois “agora sou o QA” continua sendo uma única execução, ainda que o texto simule papéis diferentes.

Também não é obrigatório usar modelos diferentes. Se nenhum modelo ou esforço de raciocínio específico for configurado, um subagente pode herdar essas escolhas do agente principal. A especialização pode vir das instruções, permissões e do escopo.

Como funciona a coordenação entre agentes?

Há duas decisões importantes: quem mantém o controle da tarefa e quais atividades podem acontecer ao mesmo tempo. Orquestração não é apenas disparar vários agentes; é estabelecer dependências, critérios de conclusão e o formato em que cada resultado volta ao fluxo principal.

Em uma arquitetura com coordenador, o agente principal recebe a demanda, delega atividades e consolida a resposta. Em um fluxo com transferência de controle, um especialista assume a condução de determinada etapa. A OpenAI distingue esses padrões na sua documentação de orquestração. 8

Para o exemplo deste artigo, eu escolheria um coordenador central. Isso deixa explícito quem decide a sequência e verifica se o conjunto atende ao pedido.

Considere a construção de uma funcionalidade. O levantamento de riscos e a proposta inicial de testes podem acontecer em paralelo. Já a validação do código depende de uma implementação disponível. Colocar tudo para executar ao mesmo tempo não elimina essa dependência.

Um fluxo possível é:

Pedido e critérios de aceite
            ↓
Coordenador
            ↓
Planejamento + proposta de testes, em paralelo
            ↓
Consolidação dos contratos entre os módulos
            ↓
Implementação
            ↓
Testes e revisão
            ↓
Correção, quando necessária, e nova validação

Cada delegação deve informar o objetivo, os dados disponíveis, os arquivos que podem ser alterados, as dependências e o formato da entrega. Pedir “faça o QA” deixa decisões demais implícitas. Pedir “verifique os critérios de aceite, execute os testes e apresente falhas reproduzíveis” cria uma tarefa verificável.

Quando usar multiagentes e quando manter um único agente?

Eu começaria com uma execução simples e dividiria o trabalho somente quando houver uma razão concreta. O ganho potencial aparece quando tarefas podem ser delimitadas e executadas com pouca dependência entre si. A documentação atual do Codex recomenda, como ponto de partida, paralelizar trabalhos mais orientados a leitura, como exploração, testes, triagem e sumarização; fluxos em que vários agentes escrevem código ao mesmo tempo exigem mais cuidado por causa de conflitos e sobrecarga de coordenação. 1

Uma investigação que atravessa diferentes módulos é um bom candidato. Um agente pode examinar a interface, outro rastrear a API e outro analisar testes existentes. O coordenador recebe evidências separadas antes de decidir o próximo passo.

Outro caso é uma implementação com critérios claros em que vale separar construção e verificação. O QA pode derivar testes do comportamento esperado sem depender das decisões internas de quem implementou.

Matriz de decisão: um agente ou multiagentes?

Quando eu não usaria multiagentes

Eu não criaria um fluxo multiagente para corrigir um texto curto, alterar uma classe de CSS ou ajustar uma função pequena com requisito fechado. Também evitaria paralelizar a edição dos mesmos arquivos apenas para “usar mais agentes”.

Se o problema ainda estiver confuso, a primeira etapa deve ser esclarecer requisitos, riscos e critérios de aceite. Distribuir uma demanda ambígua entre várias threads pode multiplicar interpretações diferentes sem melhorar a decisão.

A consequência prática é simples: use multiagentes quando a divisão de trabalho for parte da solução, não quando a quantidade de agentes for o objetivo.

Para decidir onde começar com IA sem automatizar por moda, veja IA aplicada à operação digital sem hype. Quando o primeiro gargalo está na entrada de pedidos, a triagem de demandas digitais com IA costuma ser um passo mais simples antes de coordenar várias responsabilidades.

O que o Codex oferece para uma execução multiagente?

As versões atuais do Codex oferecem fluxos com subagentes e permitem configurar agentes personalizados por projeto. Na CLI, o comando /agent permite inspecionar e alternar entre as threads dos agentes durante a execução. 1

Agentes personalizados podem ser definidos em arquivos TOML dentro de .codex/agents/. Cada arquivo declara o nome, a descrição e as instruções do agente, além de poder sobrescrever configurações suportadas, como modelo e sandbox.

Implementando uma operação multiagentes no Codex

Como exemplo didático de aplicação, vou apresentar um passo a passo para montar uma operação multiagentes no Codex.

Escolhi o Codex CLI porque é a ferramenta que estou usando mais neste momento e com a qual estou mais habituado. Ela deixa arquivos, permissões, prompts, threads e comandos visíveis, o que facilita acompanhar o que foi configurado, delegado e validado.

O laboratório é deliberadamente local e limitado, sem integração com API ou biblioteca externa de orquestração. Aqui, os agentes participam do processo de desenvolvimento; o gerenciador de tarefas resultante não terá IA incorporada. Por isso, o exemplo serve para aprender delegação, dependências e validação, não como arquitetura pronta para produção.

Passo a passo: como criar uma execução multiagente no Codex

1. Defina um exercício pequeno e verificável

Vamos pedir a criação de um gerenciador de tarefas local. Ele deverá cadastrar, listar, concluir e filtrar tarefas, preservando os dados no navegador depois de recarregar a página.

Escolhi esse escopo porque permite discutir comportamento esperado, regras, persistência e validação sem adicionar autenticação, banco de dados remoto ou publicação.

O exemplo usará HTML, CSS e JavaScript. Para servir os arquivos localmente e executar os testes, vamos usar Node.js 22 ou superior. O módulo nativo node:test permite criar testes em JavaScript sem instalar um framework adicional. 9

Você precisará de Node.js com npm, Git, um editor de texto e acesso autenticado ao Codex. Trabalhe em uma pasta nova, sem credenciais ou informações reais de clientes.

2. Prepare o ambiente e a pasta do projeto

Para instalar ou atualizar o Codex por npm, use o pacote oficial, documentado no histórico de versões da ferramenta: 10

npm install -g @openai/codex@latest
codex --version

Registre a versão exibida. Esse registro será útil caso o comportamento do seu ambiente seja diferente do tutorial.

Crie o projeto:

mkdir exemplo-multiagentes
cd exemplo-multiagentes
git init
npm init -y
mkdir .codex
mkdir .codex/agents

Os arquivos de instruções e configuração ficarão assim:

exemplo-multiagentes/
├── AGENTS.md
├── package.json
└── .codex/
    ├── config.toml
    └── agents/
        ├── planejador.toml
        ├── desenvolvedor.toml
        └── qa.toml

Crie os arquivos no editor e cole os conteúdos dos próximos passos. O código da aplicação será produzido durante a execução. Neste momento, os comandos de desenvolvimento e testes ainda não foram configurados no projeto.

3. Registre as regras comuns no AGENTS.md

O AGENTS.md fornece instruções ao Codex sobre o projeto. Ele não é uma lista que cria agentes automaticamente. O Codex lê essas instruções ao iniciar o trabalho e pode combinar orientações globais e locais. 4

Na raiz do projeto, crie AGENTS.md:

# Regras do projeto

Este repositório é um exercício local de multiagentes.

## Coordenação
- A sessão principal coordena e consolida as entregas.
- Use subagentes reais quando a tarefa solicitar delegação.
- Não simule respostas de agentes que não foram iniciados.
- Somente o coordenador pode delegar; subagentes não delegam.
- Aguarde cada dependência antes de iniciar a etapa seguinte.

## Trabalho e segurança
- Não edite AGENTS.md nem a configuração em .codex/.
- Não use credenciais, dados pessoais ou serviços externos.
- Não instale dependências sem aprovação do usuário.
- Não faça commit, push, deploy ou operações destrutivas.
- Não edite o mesmo arquivo simultaneamente em dois agentes.
- Declare testes não executados e limitações do ambiente.
- Não remova testes nem reduza critérios para obter aprovação.
- Após duas rodadas de correção, pare e relate os bloqueios.

Repare que as regras não dizem apenas o que fazer. Elas também estabelecem quando parar, o que não alterar e como declarar limitações.

4. Configure a execução no config.toml

Crie .codex/config.toml:

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[agents]
enabled = true
max_concurrent_threads_per_session = 3

Nas versões atuais, as ferramentas multiagente já vêm habilitadas por padrão, mas deixei agents.enabled = true explícito para tornar o exercício fácil de auditar. max_concurrent_threads_per_session = 3 limita a três as threads de subagentes abertas ao mesmo tempo, sem contar a principal; isso não obriga o Codex a iniciar três agentes. 2

O modo workspace-write permite escrita no espaço de trabalho. A política on-request permite que o Codex solicite aprovações quando necessárias. Não é uma promessa de confirmação antes de qualquer alteração. 2

A configuração local só é carregada quando o projeto é considerado confiável pelo Codex. Revise os arquivos antes de confiar em um repositório. Neste exercício, você acabou de criar a pasta e conhece seu conteúdo. 3

5. Crie os três agentes especializados

O coordenador será a própria sessão principal. Os três agentes terão responsabilidades diferentes:

Agentes personalizados podem ser definidos em arquivos TOML dentro de .codex/agents/. Cada arquivo precisa de name, description e developer_instructions. 1

Em .codex/agents/planejador.toml, coloque:

name = "planejador"
description = "Define escopo, arquitetura mínima e critérios de aceite."
sandbox_mode = "read-only"
developer_instructions = """
Analise o briefing e os arquivos existentes sem modificá-los.
Defina módulos, contratos públicos e critérios verificáveis.
Separe requisitos obrigatórios de melhorias opcionais.
Retorne plano, interfaces, riscos e dependências ao coordenador.
Não implemente, não delegue e não invente verificações.
"""

Em .codex/agents/desenvolvedor.toml:

name = "desenvolvedor"
description = "Implementa o escopo definido pelo coordenador."
sandbox_mode = "workspace-write"
developer_instructions = """
Implemente apenas o plano e os contratos recebidos.
Você pode editar src/, scripts/, index.html, styles.css,
package.json e README.md. Não edite tests/ nem .codex/.
Não adicione dependências externas sem aprovação.
Reporte arquivos alterados, comandos e limitações.
Não delegue, não faça deploy e não afirme testes não executados.
"""

Em .codex/agents/qa.toml:

name = "qa"
description = "Cria testes independentes e verifica critérios de aceite."
sandbox_mode = "workspace-write"
developer_instructions = """
Na etapa de planejamento, proponha testes sem editar arquivos.
Na validação, você pode editar somente tests/.
Use os contratos e critérios recebidos, não apenas a implementação.
Execute os testes e reporte comando, resultado e código de saída.
Não altere código de produção para corrigir problemas.
Diferencie falha do produto, falha do teste e bloqueio do ambiente.
Não delegue e não afirme validação visual sem usar um navegador.
"""

O planejador foi configurado para leitura. O QA recebeu escrita porque precisará criar testes. A restrição “editar somente tests/” é uma instrução de trabalho, não uma barreira técnica por diretório. Não trate um prompt como substituto das permissões do ambiente.

Essa separação também evita um anti-padrão importante: vários agentes escrevendo simultaneamente nos mesmos arquivos. Quando a execução precisar de escrita paralela de verdade, isole áreas do repositório ou use worktrees e planeje a integração explicitamente.

Também confira as permissões efetivas: alterações de permissão feitas na sessão principal podem ser reaplicadas aos subagentes e prevalecer sobre padrões dos arquivos. 1

6. Abra o Codex e confira o contexto

Depois de salvar os arquivos, inicie uma sessão nova dentro da pasta:

codex

No primeiro uso, siga o fluxo de autenticação disponibilizado pela CLI. O comando /status mostra informações da sessão. 5

Antes da implementação, envie:

Antes de implementar, confira as instruções e configurações
carregadas neste projeto. Verifique a disponibilidade dos agentes
planejador, desenvolvedor e qa e das ferramentas de delegação.
Informe o modelo e as permissões efetivas que conseguir verificar.
Se algo não estiver disponível, relate o impedimento.
Não simule agentes nem altere arquivos nesta conferência.

Essa conferência ajuda a identificar uma configuração não carregada, mas não comprova uma execução multiagente. A comprovação virá da atividade real das threads e das entregas produzidas.

7. Envie o prompt de execução multiagente

Agora envie o pedido completo à sessão principal:

Atue como coordenador desta execução. Leia AGENTS.md e use
subagentes reais: planejador, desenvolvedor e qa.

OBJETIVO
Criar um gerenciador local de tarefas para estudo, sem backend,
login, serviços externos ou dependências de terceiros.

TECNOLOGIA
HTML, CSS e JavaScript em módulos .mjs.
Node.js 22 ou superior para servidor local e testes com node:test.
Separe regras de tarefas, persistência e interface em src/.
O servidor deve escutar somente em 127.0.0.1:3000 e servir apenas
os arquivos públicos previstos, nunca .codex/, .git/ ou documentos.
Configure npm run dev e npm test.

CRITÉRIOS DE ACEITE
Cadastrar tarefas com título de 1 a 120 caracteres após trim.
Rejeitar título vazio e exibir mensagem compreensível.
Listar, concluir e reabrir tarefas.
Filtrar por todas, pendentes e concluídas.
Persistir no localStorage e recuperar após recarregar a página.
Tratar dados inválidos ou falha de armazenamento sem travar a tela.
Renderizar títulos como texto, sem interpretar HTML.
Usar campos rotulados, foco visível e controles acessíveis por teclado.
Testar regras e persistência; declarar o que exige teste no navegador.

FASE 1: PLANEJAMENTO EM PARALELO
Inicie planejador e qa em paralelo, sem escrita de arquivos.
Envie o briefing completo aos dois.
O planejador define módulos, contratos públicos e dependências.
O qa propõe casos de teste a partir dos critérios de aceite.
Aguarde ambos e concilie divergências antes de seguir.
Registre o plano e os contratos em docs/plano.md.

FASE 2: IMPLEMENTAÇÃO
Delegue a implementação ao desenvolvedor, enviando o plano completo.
Aguarde a entrega. Não mantenha agentes editando os mesmos arquivos.

FASE 3: VALIDAÇÃO
Envie os contratos e critérios ao qa para criar testes em tests/.
Peça que execute npm test e inspecione a implementação.
Use armazenamento simulado nos testes unitários de persistência.
Se houver ferramenta de navegador, valide também o fluxo da interface.
Sem navegador, registre os testes visuais como não executados.
Devolva problemas ao desenvolvedor e repita a validação,
limitando o processo a duas rodadas de correção.

ENCERRAMENTO
Reexecute npm test após a última mudança e confira git diff e git status.
O coordenador pode atualizar somente docs/ e a documentação do README.
Registre em docs/execucao.md os agentes realmente iniciados,
as tarefas delegadas, os arquivos e os resultados observados.
Inclua identificadores das threads quando estiverem disponíveis.
Informe como abrir a aplicação e os riscos ou testes pendentes.
Não publique, não faça commit e não instale dependências sem aprovação.
Se a delegação real não estiver disponível, pare e explique o motivo.

Esse prompt torna a colaboração explícita. Primeiro, planejamento e proposta de testes acontecem em paralelo. Depois, o coordenador consolida o acordo sobre o que será implementado. Só então entram desenvolvimento e validação.

O QA não deve corrigir o produto silenciosamente para aprová-lo. Ele aponta o problema, o desenvolvedor faz a correção e uma nova verificação avalia o resultado. Para este exercício, eu limitaria essa repetição a duas rodadas, preservando as pendências em vez de criar um ciclo sem fim.

Para uma visão geral de agentes, ferramentas e padrões de delegação, consulte também a documentação oficial sobre agentes da OpenAI 7.

8. Verifique se os agentes realmente trabalharam

Durante a execução, use /agent para inspecionar as threads disponíveis.

Confira se existem atividades separadas para as tarefas delegadas. Um relatório que apenas menciona “planejador”, “desenvolvedor” e “QA” não basta.

Ao final, examine docs/plano.md, docs/execucao.md, os arquivos da aplicação e os testes. O relatório deve distinguir o que foi observado do que foi apenas proposto. Identificadores de threads, comandos executados e códigos de saída ajudam nessa conferência, mas precisam corresponder à execução real.

Confira também os arquivos novos. Usar apenas git diff pode deixar itens não rastreados fora da inspeção; por isso, o exercício pede também git status.

9. Teste a entrega e registre as limitações

Quando a implementação terminar, execute os comandos que o prompt exigiu configurar:

npm test
npm run dev

Abra http://127.0.0.1:3000 no navegador e confira o comportamento da aplicação. Cadastre uma tarefa, rejeite um título vazio, conclua e reabra um item, alterne os filtros e recarregue a página.

Digite também um título como <b>teste</b>. Neste exercício, ele deve aparecer literalmente como texto, não como marcação HTML.

A verificação de interface é diferente do teste das funções. Testes unitários aprovados não comprovam, sozinhos, que todo o fluxo funciona no navegador. O projeto deve registrar claramente quando a navegação real não foi validada.

O resultado esperado é uma aplicação local acompanhada de testes e documentação. Isso não equivale a um produto pronto para publicação. Autenticação, uso por várias pessoas, dados sensíveis e operação em produção ficaram deliberadamente fora do escopo.

Como evitar os problemas mais comuns?

Agentes alterando os mesmos arquivos

No exercício, eu separei escrita de código e escrita de testes, além de executar essas etapas em sequência. Essa é uma escolha de organização para manter a primeira experiência controlável.

Em projetos maiores, uma alternativa é trabalhar com Git worktrees, que fornecem cópias de trabalho separadas do repositório. O Codex documenta esse recurso para execuções paralelas. Isolar as cópias não dispensa revisar e integrar o resultado depois. 6

O Codex responde sozinho e não delega

Confira se o pedido realmente solicita subagentes, se os arquivos foram salvos e se a configuração local foi carregada em uma sessão nova. Projetos não confiáveis não carregam as camadas locais de .codex/. 3

Se houver restrição do ambiente ou indisponibilidade da ferramenta, registre o bloqueio. Não aceite uma encenação de múltiplos agentes como equivalente à execução solicitada.

O teste passa, mas o requisito não foi atendido

Minha recomendação é escrever critérios observáveis antes da implementação. “Persistir tarefas” é menos preciso do que “a tarefa cadastrada deve continuar disponível depois de recarregar a página”.

Peça ao QA que justifique os testes com base nesses critérios. Um teste que apenas confirma a estrutura escolhida pelo desenvolvedor pode não verificar o problema que o usuário precisava resolver.

A execução entra em um ciclo de correções

Defina um limite e um formato de encerramento. Quando o limite for atingido, a entrega deve conter o problema restante, o que já foi tentado e a decisão necessária para continuar.

Neste exemplo, o limite de duas rodadas é uma regra do fluxo. Ele não representa um controle técnico de orçamento ou uma garantia imposta pela plataforma.

Multiagentes reduzem custos e aumentam a produtividade?

Não por definição. A documentação do Codex informa que um fluxo com subagentes consome mais tokens do que uma execução comparável com um único agente, porque cada subagente realiza seu próprio trabalho de modelo e ferramentas. 1

O benefício precisa aparecer em outra dimensão: tempo de investigação, qualidade da cobertura, redução de ruído no contexto principal ou capacidade de executar trabalhos realmente independentes em paralelo. Se a tarefa for sequencial, a coordenação adicional pode simplesmente aumentar custo e complexidade.

Para avaliar um piloto, eu compararia tarefas de dificuldade semelhante e registraria pelo menos:

• tempo até uma entrega aceita;
• consumo ou custo disponível no ambiente;
• quantidade de correções necessárias;
• problemas encontrados na revisão;
• esforço humano para revisar e integrar o resultado.

Eu evitaria métricas como “número de agentes” ou “linhas de código geradas”. O que interessa é trabalho útil concluído com qualidade e risco aceitáveis.

Também começaria pequeno. Um coordenador com dois ou três especialistas delimitados é mais fácil de observar do que reproduzir um organograma inteiro em agentes sem necessidade operacional.

Como levar essa abordagem para um projeto da empresa?

Eu começaria com um piloto de baixo risco, escopo delimitado e saída revisável. Exploração de código, análise de testes, triagem de incidentes ou implementação de uma funcionalidade isolada são exemplos que permitem medir resultado sem entregar autonomia irrestrita.

Antes do piloto, eu definiria cinco pontos:

1. Objetivo: qual problema o fluxo precisa resolver melhor do que a execução atual.
2. Divisão de trabalho: quais tarefas são independentes e quais têm dependências obrigatórias.
3. Dados e ferramentas: o que cada agente pode acessar e o que permanece bloqueado.
4. Critérios de aceite: quais evidências precisam existir para considerar a tarefa concluída.
5. Fallback: quem assume quando o fluxo falha, entra em loop ou pede uma ação sensível.

Credenciais, dados de clientes, publicação, alterações irreversíveis e decisões de alto impacto exigem controles proporcionais ao risco. Instruções em linguagem natural ajudam a orientar o comportamento, mas não substituem permissões, ambientes isolados, logs, revisão e mecanismos de reversão.

Para um contexto mais amplo de governança, QA e revisão humana, veja também IA na produção web: como usar sem perder qualidade. Esse é o próximo conteúdo editorial mais próximo deste tutorial porque trata de como incorporar IA à execução sem pular validações.

Se você já tem um processo que parece um bom candidato para multiagentes, o próximo passo não precisa ser construir tudo. Estruture o caso de uso, os dados envolvidos, as ações permitidas e o resultado esperado. Depois, avalie um piloto ou uma prova de valor. A Hit Digital apoia essa avaliação em suas soluções com IA, começando pelo processo, riscos e evidências necessários antes de ampliar autonomia.

Perguntas frequentes

Preciso usar modelos diferentes em cada agente?

Não. No Codex, subagentes podem herdar o modelo e o esforço de raciocínio da sessão principal quando você não define uma configuração específica. Modelos diferentes são uma opção de otimização, não um requisito para existir delegação.

Criar um AGENTS.md já cria uma equipe de agentes?

Não. O AGENTS.md fornece instruções e contexto que o Codex lê antes de trabalhar. Agentes personalizados são configurados separadamente, e a execução multiagente só existe quando há delegação efetiva para outras threads. 4

Como sei se o Codex realmente delegou a tarefa?

Na CLI, use /agent para inspecionar as threads dos subagentes. Além disso, peça que a execução registre quais agentes foram iniciados, quais tarefas receberam e quais evidências retornaram. Um relatório textual citando papéis sem threads ou atividade correspondente não comprova a delegação.

Posso aplicar o exemplo diretamente em produção?

Não. O gerenciador deste guia é um cenário didático, sem autenticação, backend, dados sensíveis ou processo de deploy. Em um ambiente real, permissões, dados, logs, segurança, observabilidade, rollback e revisão precisam ser definidos para o risco da operação.

Comece pela divisão do trabalho, não pela quantidade de agentes

Para uma primeira execução multiagente, eu priorizaria um objetivo pequeno, responsabilidades claras e evidências observáveis de conclusão.

O coordenador precisa preservar requisitos e dependências. O planejador precisa reduzir ambiguidade. O desenvolvedor precisa receber contratos verificáveis. O QA precisa testar o comportamento esperado sem “ajudar” o código a passar. E quem revisa precisa conseguir distinguir uma execução validada de uma afirmação de que o trabalho terminou.

O exemplo deste guia pode ser reutilizado como laboratório. Depois de executá-lo, compare o resultado com uma execução equivalente usando um único agente. Só amplie a arquitetura se a divisão trouxer benefício mensurável para aquele tipo de trabalho.

A pergunta central não é quantos agentes você consegue iniciar. É qual divisão de trabalho ajuda a resolver melhor o problema.

Fontes consultadas

Referências técnicas e institucionais verificadas em 16 de setembro de 2026:

1. OpenAI — Subagents no Codex
2. OpenAI — Configuration Reference do Codex
3. OpenAI — Configuração e confiança em projetos do Codex
4. OpenAI — Custom instructions with AGENTS.md
5. OpenAI — Codex CLI
6. OpenAI — Git worktrees no Codex
7. OpenAI — Agents
8. OpenAI — Orchestration and handoffs
9. Node.js — Test runner
10. OpenAI — repositório oficial do Codex
11. Hit Digital — Soluções com IA
12. Hit Digital — IA na produção web: como usar sem perder qualidade

O passo a passo é um cenário didático proposto para este artigo, não um case de cliente nem um benchmark de produtividade da Hit Digital. Antes de aplicá-lo em uma operação, reproduza o laboratório em ambiente isolado e registre as threads, os arquivos gerados, os testes executados e as limitações observadas.