Montei um exército de agentes no Codex. A parte difícil foi gerenciá-lo.
- Codex
- agentes de IA
- automação
- gestão de engenharia
- multiagente
Em agosto de 2026, eu não estava tentando inventar uma organização de IA. Estava tentando concluir uma história que havia começado com um sonho que anotei catorze anos antes. Depois que uma partida de Dungeons & Dragons trouxe essa lembrança de volta, abri o Codex e comecei a trabalhar nas anotações e nos fragmentos antigos.
Esse projeto pessoal virou uma novela ilustrada, um protocolo de revisão congelado e um pipeline de publicação. Na semana seguinte, apliquei o método a software e comecei a migrar para o Codex meu fluxo de trabalho profissional com SDK.
Não posso mostrar os detalhes internos do SDK, mas posso mostrar os projetos pessoais que me ensinaram o método. A questão não é ter um único modelo brilhante. É fazer com que modelos imperfeitos produzam um trabalho que você consiga inspecionar, rejeitar e retomar sem precisar manter o sistema inteiro na cabeça. Eu chamo isso de meu exército de agentes; na prática, o que importa é um modelo operacional composto por papéis com escopo delimitado, validação independente, evidências duráveis, orçamentos e responsabilidade humana.
Antes do app Codex: eu conectava terminais manualmente
Eu já usava bastante o Claude Code no terminal junto com o Codex CLI. Eles conseguiam enxergar o repositório, executar ferramentas e fazer alterações de verdade. O problema era a coordenação: o Claude tinha um contexto, o Codex tinha outro, e o planejamento ficava em algum outro lugar. Se eu quisesse que um modelo questionasse o outro, eu mesmo precisava transferir as informações.
Cheguei a criar uma ferramenta que restaurava contextos de terminal e encaminhava respostas entre sessões. Funcionava, mas eu ainda era o barramento de mensagens, o agendador, o sistema de permissões e o monitor de falhas.
Em agosto de 2026, descobri que o app Codex conseguia manter tarefas de longa duração, arquivos, ferramentas, subagentes e passagens de contexto visíveis em um único workspace. Eu forneci os papéis, as skills, a memória do repositório e as regras. Modelos diferentes podiam continuar no fluxo de trabalho; a fileira de janelas de terminal já não precisava fingir que era uma organização.
Contextos separados do Claude Code e do Codex CLI, conectados por scripts próprios e repasses manuais.
O Codex manteve conversa, arquivos, ferramentas, papéis e colaboração entre agentes no mesmo lugar.
Contextos novos por tarefa, papéis especialistas, memória no repositório, revisão separada e critérios explícitos de publicação.
As ferramentas mudaram. A mudança mais importante foi tirar a coordenação da minha cabeça e colocá-la em limites explícitos e verificáveis.
A mudança importante não foi a interface. Foi a possibilidade de tornar a coordenação parte do próprio projeto.
O livro foi meu primeiro laboratório
Não comecei dizendo a um agente para “escrever um livro”. Levei ao Codex as anotações antigas e uma grande dose de incerteza. Trabalhamos o mundo, as motivações dos personagens, as cenas que faltavam e o que a história deveria fazer o leitor sentir. O repositório virou memória compartilhada: manuscrito, mitologia, decisões, cânone visual, estado de produção e o histórico do Git que ligava as evidências a cada versão.
Assim que o primeiro manuscrito completo ficou pronto, parei de fazer a pergunta menos útil do trabalho criativo: Você gostou?
Em vez disso, criei leitores isolados, cada um com uma função diferente: leitor do público-alvo, editor comercial, crítico de continuidade, defensor da ambiguidade, cético hostil porém justo e especialistas mais específicos. Cada um recebia um manuscrito limpo e um único papel — sem acesso aos demais pareceres nem à mudança que eu esperava que elogiassem.
Executei o protocolo congelado com GPT e Claude. Auditorias anteriores feitas com DeepSeek e Mistral permaneceram em uma trilha de evidências separada, em vez de virar votos adicionais no mesmo benchmark. Eu queria saber se famílias de modelos isoladas identificariam o mesmo mecanismo de falha.
Uma crítica eloquente é uma opinião; várias execuções dentro da mesma família de modelos são evidências correlacionadas. Quando famílias diferentes encontram a mesma lacuna causal e eu consigo inspecioná-la, o argumento fica mais forte — mas não é provado por maioria de votos.
Congelamos os prompts e a estrutura de pontuação para impedir que uma nova versão “melhorasse” só porque eu havia tornado o teste mais favorável. Antes de alterar o manuscrito, registrávamos o mecanismo suspeito, a intervenção, o efeito esperado, as qualidades a preservar e a condição de reversão.
O processo gerou uma versão de revisão de 290 páginas com a novela, as ilustrações e o material de produção. As verificações automatizadas passaram, mas a etapa de validação antes do lançamento falhou porque várias imagens não tinham travas explícitas de cânone. O PDF parecia pronto; o estado registrado dizia o contrário, e eu não o ignorei. Essas imagens agora estão travadas, mas ainda é necessário executar novamente a verificação do livro completo.
Essa falha me ensinou mais do que uma aprovação animadora teria ensinado.
Depois, testei o mesmo método em software
O segundo projeto pessoal por acaso é um jogo, mas o jogo não é o ponto central. Eu precisava de uma bancada de testes em que os agentes tivessem de alterar uma base de código real, executar uma engine pesada, inspecionar o comportamento e o visual e sobreviver a uma infraestrutura imperfeita.
Arte conceitual do projeto usado como campo de testes de software e de seu futuro protagonista. Ela define um alvo visual; não prova que a versão atual já tenha chegado lá.
Na primeira tentativa, deixei um único agente competente interpretar, projetar, implementar, testar e julgar a funcionalidade. Foi rápido e mal projetado: “compila” virou “funciona”, depois “está melhor” e, por fim, “está pronto”. São quatro afirmações diferentes.
Separei os papéis: um gerente congelava o resultado esperado, uma pessoa implementadora alterava o código, um executor produzia evidências, QA procurava falhas de comportamento e revisores de arte e de lançamento julgavam o resultado. Quem criava já não podia aprovar o próprio trabalho.
Essa estrutura detectou falhas que as verificações centradas em código daquela iteração não haviam encontrado. O código-fonte compilava, o comportamento automatizado passava, os arquivos de captura existiam e QA aprovava o pacote técnico. O revisor de arte abriu as imagens e as rejeitou: uma estava quase toda preta, a funcionalidade crítica ficava fora de todos os enquadramentos e o personagem principal estava ilegível na escala capturada.
A implementação havia atingido seu objetivo técnico específico. O resultado como produto não era aceitável. As duas afirmações eram verdadeiras.
O experimento também destruiu minha primeira fantasia sobre paralelismo. Em um Mac com 16 GB, várias sessões de agentes e suas execuções de ferramentas se chocaram com o Unity, o gerenciador de pacotes e o processo de licenciamento. A pressão sobre a memória aumentou, e a máquina travou.
A solução não foi um prompt mais poderoso. Foi um agendador: apenas um processo pesado de escrita por vez, nenhum agente novo enquanto o Unity estivesse ativo, worktrees separados para processos de escrita realmente independentes, verificações baratas antes de executar a engine e um limite rígido para tentativas de implementação.
Mais agentes não geram mais autonomia automaticamente. Progresso confiável dentro de restrições reais, sim.
O padrão se transferiu para meu trabalho de verdade
Meu SDK de produção já tinha contexto específico por papel, skills, convenções e responsabilidades separadas. Na segunda semana, comecei a migrar esse fluxo de trabalho para o Codex. Os resultados privados ainda são preliminares demais para eu alegar sucesso, mas a estrutura de papéis e evidências se mostrou portátil entre o trabalho criativo, o trabalho baseado em engine e o trabalho profissional — e muitas vezes revelou falhas em vez de fabricar uma aprovação.
A unidade reutilizável não era um “agente escritor” nem um “agente de Unity”. Era o padrão organizacional ao redor deles.
Significado, escopo, critério e decisões irreversíveis
Direciona um resultado delimitado e protege o orçamento
Pesquisa · Criação · Engenharia
Recebe outra tarefa e tenta refutar que esteja pronto
Decisões, entregáveis, manifestos, testes e repasses
Criar e validar são trabalhos diferentes. O repositório guarda as evidências; o proprietário recebe decisões, não ruído operacional bruto.
O responsável define o significado e os limites. Um orquestrador cria uma tarefa com escopo delimitado. Especialistas produzem artefatos; um revisor separado tenta refutar a conclusão de que o trabalho está pronto; o repositório guarda as evidências. O responsável volta a participar diante de trade-offs, lançamentos, mudanças de direção ou trabalhos travados e conflitantes.
É essa a camada que agora ocupa a maior parte do meu tempo de design.
Como a autonomia realmente funciona
Eu não passo o dia inteiro observando agentes trabalharem. Nas manhãs dos dias úteis, antes de começar meu expediente, congelo tarefas com escopo delimitado para o livro e a bancada de testes de software; depois deixo essas filas pessoais rodando sem supervisão por cinco a sete horas. Quando o trabalho profissional começa, troco de contexto e uso agentes ativamente nas minhas responsabilidades normais de engenharia. Os repositórios, as filas de tarefas e os ciclos de revisão permanecem separados.
Depois do expediente, examino o que o turno dos projetos pessoais produziu: artefatos, testes, afirmações rejeitadas e pacotes de decisão, não um fluxo de conversa. À noite, uso tarefas menores para obter feedback rápido, ajusto os papéis ou o processo e, antes de dormir, atribuo trabalhos mais longos que podem rodar até de manhã.
Os produtos importam, mas agora também funcionam como instrumentos. Meu experimento principal é o método para desenvolver quase qualquer coisa dessa forma: por quanto tempo uma tarefa pode rodar com segurança, onde a autonomia falha, quais evidências sobrevivem à noite e que intervenção melhora o turno seguinte. Ao longo do mesmo dia, filas pessoais podem continuar consumindo capacidade computacional enquanto eu uso ativamente agentes separados em tarefas profissionais. Isso é computação paralela, não atenção paralela — e explica por que o consumo de tokens não se parece em nada com o de um agente respondendo a uma pergunta.
A descrição menos formal é que tenho vivido à base de dopamina. O progresso constante e visível torna surpreendentemente difícil dormir, mesmo quando a finalidade do sistema é justamente continuar trabalhando sem mim.
O que eu criaria primeiro
Se hoje você alterna entre várias conversas com IA e transfere as conclusões manualmente, não comece criando doze agentes.
Comece com um fluxo de trabalho que dói e três papéis:
- Gerente — congela um resultado, o que não faz parte do escopo, os critérios de aceitação e o orçamento.
- Criador — produz a menor alteração ou artefato que ainda seja coerente.
- Revisor — verifica o resultado em um contexto separado e não pode consertá-lo discretamente.
Coloque o objetivo, as decisões e as evidências no repositório. Exija um artefato, não uma atualização de status persuasiva; faça o revisor citar o que inspecionou; e encerre o processo depois de um único resultado.
Só acrescente outro papel quando conseguir nomear o conflito, o gargalo ou a lacuna de especialização que ele resolve.
Papéis precisam de contratos, não de figurinos
Muitas demonstrações multiagente apresentam um elenco de desenvolvedores brilhantes e testadores meticulosos. Personalidades podem tornar um prompt agradável. Elas não criam responsabilidade.
Um papel operacional precisa de cinco elementos:
- Uma entrada definida. O que precisa existir antes que esse papel comece?
- Uma saída delimitada. Que artefato ou veredito ele deve retornar?
- Autoridade explícita. Quais ferramentas, arquivos e decisões ele pode acessar ou alterar?
- Ações proibidas. O que ele deve encaminhar para outro papel, mesmo que saiba fazer?
- Uma condição de parada. Quando a tarefa está concluída, rejeitada, bloqueada ou pronta para uma decisão humana?
“Você é um engenheiro de QA cuidadoso” é mais fraco do que “você tem acesso somente leitura, não pode corrigir o que encontrar, deve relacionar cada falha aos critérios congelados e só pode retornar ACCEPT, REJECT ou NEEDS_OWNER_DECISION”.
Nem todo limite tem a mesma força. Quando possível, uso permissões de sistema de arquivos, worktrees, ferramentas em lista de permissão e travas de recursos — a trava do Unity pertence ao agendador, não a um prompt educado. Instruções escritas são mais fracas e não podem autorizar um lançamento sem uma etapa de validação por evidências ou uma decisão humana.
O modelo só importa depois que o trabalho está bem definido. Posso encaminhar arquitetura e revisão final para um modelo de fronteira, exploração para um modelo mais rápido, trabalho determinístico para um modelo mais barato e revisão adversarial para outra família de modelos. Os papéis devem sobreviver a essas substituições. Muitas vezes, quero que o Claude questione um plano produzido no Codex; não quero que quem o questiona edite a implementação que está julgando.
O contexto deve ser montado, não acumulado
Uma conversa interminável acaba lembrando coisas demais: requisitos obsoletos, logs brutos, hipóteses abandonadas e resumos confiantes de versões que já não existem.
Hoje prefiro contextos de execução novos, montados a partir de camadas duráveis.
Um bom prompt de papel não é uma biografia. É a última camada sobre o contexto durável do projeto e um contrato de tarefa bem delimitado.
O repositório é a memória institucional; a conversa é uma interface para ela.
Em cada projeto, mantenho um objetivo, um registro de decisões, a iteração atual, critérios de aceitação, o que não faz parte do escopo, um diretório de evidências e uma passagem de contexto final concisa.
Uma tarefa nova lê o necessário para produzir um único resultado, registra as evidências e termina. As conversas estratégicas continuam úteis porque o resíduo operacional fica de fora. É menos conveniente do que um único contexto gigantesco e muito mais fácil de auditar.
A conta me ensinou o que paralelismo realmente significa
Na época, eu pagava cerca de US$100 por mês pelo Claude e comecei a usar o Codex por meio de uma assinatura do ChatGPT de aproximadamente US$20. Migrei para a opção de cerca de US$100 e, depois de adicionar o trabalho de software e SDK, atingi o limite semanal em aproximadamente dois dias. O próximo upgrade exibido custava cerca de €200; estou preservando as moedas que registrei, em vez de fingir que elas podem ser comparadas diretamente.
Este é um diário de uso de agosto de 2026, não um benchmark de preços. Planos e franquias mudam, e eu estava executando fluxos de trabalho longos, com alto nível de raciocínio, em vários projetos. Ao final da segunda semana, os dois serviços ficaram brevemente sem orçamento.
A lição útil é mais simples:
“Executar agentes em paralelo é uma política de gastos.”
Iniciar cinco revisores de alto esforço é uma decisão orçamentária. Modelo, esforço de raciocínio, quantidade de agentes, novas tentativas e duração da tarefa devem fazer parte do contrato do fluxo de trabalho.
Minhas regras práticas agora são estas:
- Uma tarefa, um resultado. Uma tarefa que conclui uma iteração não começa silenciosamente a seguinte.
- Separe criação de validação. Ninguém corrige a própria prova.
- Primeiro, a evidência barata. Use verificações estáticas ou um único revisor focado antes de builds caros, painéis amplos ou revisões visuais.
- Evidências têm proveniência. Uma aprovação pertence a uma versão específica do código-fonte, a um comando, ao ambiente e à configuração relevantes e a uma saída imutável.
- Autoridade e orçamento são restritos. Revisores permanecem em modo somente leitura; modelo, runtime, novas tentativas e número de tentativas são limitados; decisões irreversíveis voltam para o responsável.
- Uma falha interrompe o ciclo. “Não comprovado” e vereditos conflitantes voltam para o responsável, em vez de iniciar silenciosamente outra tentativa.
- Mude uma variável do processo por vez. Se a rota e o modelo mudarem juntos, não finja que o resultado prova qual dos dois ajudou.
O objetivo não é minimizar cada token. É gastar raciocínio caro onde ele muda uma decisão.
Então fiz este artigo revisar a si próprio
Publicar um artigo sobre fluxos de trabalho confiáveis com agentes sem aplicar o método ao próprio artigo parecia absurdo. Por isso, um snapshot congelado foi enviado para quatro papéis — um leitor sem contexto prévio, um editor responsável pela pauta, um auditor factual e um profissional da área — primeiro com GPT e depois com Claude. Todos os oito relatórios internos retornaram revise.
Consenso, riscos e preferências ficam separados
Editar, manter, verificar ou rejeitar
Oito leituras não são oito fontes independentes. A convergência entre famílias de modelos aumenta a prioridade de um achado, mas não substitui a verificação nem o julgamento do autor.
As duas famílias questionaram os mesmos exageros e discordaram sobre o título e sobre quanto desta seção deveria permanecer. Os relatórios privados não provam que o artigo é bom; eles expuseram afirmações que eu poderia inspecionar. O pipeline não podia editar nem publicar, portanto as decisões — e a responsabilidade — continuaram sendo minhas.
O que continua sendo humano
Não terceirizei o significado do livro, quais críticas importavam, que ambiguidades preservar, a direção do produto nem a responsabilidade pelo SDK. Agentes podem inspecionar, implementar, testar e questionar; não podem assumir a responsabilidade. O papel humano sobe de nível, mas não desaparece.
Meu trabalho consiste cada vez mais em projetar a organização: decidir onde o contexto fica, separar autoridades conflitantes, definir evidências e orçamentos e intervir quando o sistema chega a uma decisão real.
Engenharia de prompt pode melhorar uma resposta. Design organizacional pode tornar úteis meses de respostas imperfeitas.
Comecei com um sonho de catorze anos e uma ponte improvisada entre janelas de terminal. Duas semanas depois, o mesmo padrão organizacional movimentava um livro, um experimento de software e parte do meu fluxo de trabalho profissional — sem exigir que eu acompanhasse cada etapa.
Modelos, interfaces, planos e limites vão mudar. A habilidade duradoura é transformar inteligência em uma organização capaz de avisar quando está errada.
A seguir, pretendo publicar os templates concretos por trás desta configuração: contratos de papéis, cartas de tarefa, pacotes de evidências e as regras que uso para decidir qual modelo recebe cada trabalho.