O Loop de Criação Iterativa: Como Construir Melhor com Plan Mode, Diálogos Multi‑Agente e Verificação

Um guia de campo prático para 2026 sobre programação, pesquisa, conteúdo, produtos, sistemas de conhecimento e fluxos de trabalho nativos de IA

Há um ponto em que adicionar mais inteligência a um fluxo de trabalho de IA deixa de ajudar.

Não porque o modelo seja fraco.

Mas porque o fluxo de trabalho é fraco.

Você pode dar a um agente uma janela de contexto enorme, uma dúzia de ferramentas, uma instrução longa e um prompt cuidadosamente projetado. Ele ainda pode entender mal o objetivo, confiar excessivamente em uma premissa, duplicar pesquisas, alterar algo que deveria permanecer intocado ou declarar sucesso antes que alguém realmente tenha verificado o resultado.

A resposta instintiva costuma ser:

Adicione outro agente.

Depois mais outro.

Depois um revisor.

Depois um "arquiteto sênior".

Depois um editor final.

Eventualmente, você construiu uma pequena empresa artificial que gasta mais tempo se coordenando do que fazendo o trabalho.

Esse não é o objetivo.

A ideia mais útil é mais simples:

Não otimize para o número de agentes. Otimize para a qualidade das transições de estado entre intenção, evidência, ação e conclusão verificada.

Este guia chama esse sistema de Loop de Criação Iterativo.

OBSERVE → CONTRACT → PLAN → CHALLENGE → SPECIALIZE
        → REFINE → APPROVE → EXECUTE → VERIFY → LEARN ↺

Os agentes são opcionais.

O loop, não.

Para algumas tarefas, um agente forte deve executar a maior parte do loop. Para outras, pesquisadores independentes, críticos, especialistas e verificadores merecem seus próprios contextos. A arquitetura deve seguir a forma do trabalho.

O resultado não é um "enxame". É algo mais útil: um processo repetível para transformar trabalho incerto em trabalho verificado.

---

TL;DR

A mudança útil é de geração de respostas para progressão de artefatos.

Em vez de:

Human → Prompt → Model → Answer

use:

Goal Contract
     ↓
Observe real evidence
     ↓
Create a falsifiable plan
     ↓
Attack the plan
     ↓
Delegate only real uncertainties
     ↓
Execute in checkpoints
     ↓
Verify independently
     ↓
Record what was learned

Algumas descobertas atuais explicam por que vale a pena levar isso a sério, sem transformar o artigo em hype.

Fontes primárias: Anthropic, PACT, MAST, Rethinking Multi-Agent Collaboration.

Regra prática: comece com um agente, encontre o gargalo, adicione a menor quantidade de coordenação que o remova e meça se a complexidade extra se paga.

---

Sumário

1. 01.A ideia central: construir um loop, não um conselho
2. 02.Quando multiagente realmente ajuda — e quando piora as coisas
3. 03.Modo Plano: o limite entre pensar e mudar o mundo
4. 04.A arquitetura artifact-first
5. 05.Papéis e topologias: escolha a estrutura a partir da tarefa
6. 06.O protocolo de diálogo: Ação, Estado, Resultado
7. 07.O Loop de Criação Iterativa completo
8. 08.Como executar o loop hoje: Cursor, Claude Code, SDKs e harnesses personalizados
9. 09.O que as evidências de 2025–2026 realmente nos dizem
10. 10.Quatro playbooks práticos: software, pesquisa, conteúdo e produtos
11. 11.Verificação e mensuração: tornar o “feito” observável
12. 12.Modos de falha: como sistemas de agentes bem-apresentados quebram
13. 13.SEO, GEO e publicação legível por IA sem o folclore
14. 14.O kit operacional reutilizável

---

1. A ideia central: construir um loop, não um conselho

A frase “sistema multiagente” faz os agentes parecerem o objeto principal.

Eles não são.

O objeto principal é o estado do fluxo de trabalho.

Um agente especialista é simplesmente uma fronteira de contexto temporária. Um crítico é um papel com um objetivo adversarial. Um verificador é um portão que requer evidência. Um gerente é um mecanismo de roteamento.

O que sobrevive de uma etapa para a próxima deve ser o estado do trabalho.

INTENTION
   ↓
OBSERVED STATE
   ↓
HYPOTHESIS / PLAN
   ↓
CHALLENGE
   ↓
ACTION
   ↓
NEW OBSERVATION
   ↓
VERIFICATION
   ↓
LEARNING

Esse padrão não é novo. Engenharia de software tem testes e revisão de código. Ciência tem hipóteses e experimentos. Operações tem resposta a incidentes e postmortems. Times de produto prototipam, observam e iteram.

Sistemas agenticos tornam uma parte do loop dramaticamente mais barata: você pode executar mais investigação, crítica, síntese e verificação sem que um humano realize cada passo intermediário.

O problema difícil, portanto, passa de “Um modelo pode gerar algo impressionante?” para:

O sistema pode preservar o estado correto ao passar de uma intenção incerta para um resultado verificado?

1.1 Geração de resposta vs progressão de artefato

Uma resposta de chat é um objeto terminal. Um artefato pode ser inspecionado, alterado, versionado, testado e reutilizado.

Compare:

Question → Answer

com:

Goal Contract
→ Plan
→ Evidence Ledger
→ Decision Log
→ Implementation / Draft
→ Verification Report

O segundo pipeline cria objetos com os quais agentes futuros e humanos podem trabalhar.

Essa é a mudança de design fundamental.

1.2 As três perguntas que cada etapa deve responder

Em qualquer ponto do loop, o próximo participante deve ser capaz de responder:

1. 15.O que estamos tentando alcançar?
2. 16.O que sabemos atualmente?
3. 17.Qual é a próxima ação justificada?

A maioria dos fluxos de trabalho de agentes ruins falha porque uma dessas perguntas se torna implícita.

O objetivo se perde em um contexto longo.

A evidência se mistura com especulação.

A próxima ação é escolhida porque o modelo anterior soou confiante.

O loop existe para manter essas três perguntas explícitas.

1.3 Por que “mais agentes” é o objetivo errado

Suponha que um agente possa resolver uma tarefa em oito chamadas de ferramenta.

Você cria quatro agentes:

Planner
Researcher
Critic
Verifier

Agora você tem:

- cinco contextos em vez de um,

- mais roteamento,

- mais transferência de estado,

- mais tokens,

- mais latência,

- mais oportunidades de contradição.

A menos que esses contextos extras comprem algo real — evidência independente, trabalho paralelo, ferramentas especializadas, verificação melhor, ou isolamento útil — você aumentou a complexidade sem aumentar a capacidade.

É por isso que a arquitetura deve ser orientada à demanda.

---

2. Quando multiagente realmente ajuda — e quando piora as coisas

A questão não é se sistemas multiagente são poderosos.

Eles são.

A questão é de onde vem esse poder.

Um modelo útil é:

Multi-agent benefit
≈
parallelism
+ context isolation
+ specialization
+ independent criticism
+ additional tool capacity
− coordination cost
− token cost
− latency
− new failure modes

Não existe uma fórmula numérica universal. O ponto é arquitetural: cada agente adicional introduz um custo que deve ter um motivo para existir.

2.1 O teste de topologia de tarefas

Antes de criar uma equipe, classifique a tarefa.

O artigo de setembro de 2026 Rethinking Multi-Agent Collaboration: When More Is Less faz essa mesma distinção de forma mais formal: os benefícios são mais fortes em tarefas de longo prazo com dependências esparsas, enquanto fluxos de trabalho sequenciais fortemente acoplados podem favorecer sistemas de agente único porque a sobrecarga de coordenação se torna dominante.

Fonte: Rethinking Multi-Agent Collaboration: When More Is Less.

2.2 Dependência esparsa vs. dependência densa

Esta distinção é uma das maneiras mais rápidas de decidir.

Dependência esparsa

A ───┐
B ───┼──→ synthesis
C ───┤
D ───┘

A, B, C e D podem trabalhar independentemente.

O uso de múltiplos agentes é atraente.

Dependência densa

A → B → C → D
    ↑   ↓
    └───┘

Cada estágio depende de detalhes do anterior.

Um único agente ou fluxo de trabalho determinístico pode ser mais fácil de gerenciar.

2.3 O teste de independência

Antes de gerar um especialista, pergunte:

Esta pessoa conseguiria trabalhar de forma independente por dez minutos e retornar algo que outra pessoa realmente consiga consumir?

Se a resposta for não, provavelmente não é uma subtarefa paralela adequada.

2.4 O teste de contexto

Pergunte:

O especialista precisa de toda a conversa?

Caso contrário, isole-o.

Um pesquisador de desempenho provavelmente não precisa de todo o resumo do produto.

Um verificador de fatos provavelmente não precisa de toda a transcrição do brainstorming.

Um especialista em segurança pode precisar da arquitetura e dos arquivos alterados, mas não da discussão de marketing.

O isolamento de contexto não é apenas uma otimização de custos. Frequentemente, é uma otimização de qualidade.

2.5 A regra do "não gere"

Não crie nenhum agente extra quando:

- the task is simple,
- there is no meaningful parallelism,
- all stages need the same context,
- deterministic tools already solve the verification problem,
- or the expected benefit is purely stylistic.

Um bom orquestrador pode dizer:

No specialist required.
Proceed with single-agent execution.

Isso é orquestração madura.

---

3. Modo Planejamento (Plan Mode): a fronteira entre pensar e mudar o mundo

O modo Planejamento é útil por um motivo enganosamente simples: ele torna o plano visível antes que a implementação se torne custosa de desfazer.

O Cursor descreve o modo Planejamento como um fluxo no qual o agente pesquisa a base de código, faz perguntas, cria um plano detalhado, permite que você o revise ou edite e, então, constrói a partir desse plano. Os planos podem ser salvos no espaço de trabalho. A CLI do Cursor também expõe o modo de planejamento por meio de comandos como /plan e --mode=plan.

O Claude Code também oferece suporte a um modo de permissão de plano, além de subagentes e equipes de agentes para fluxos de trabalho mais complexos.

Fontes:

- Cursor Plan Mode

- Cursor CLI

- Claude Code Permissions

- Claude Code Subagents

- Claude Code Agent Teams

3.1 Raciocínio reversível vs. ação irreversível

Sem uma fronteira de planejamento:

request
  ↓
agent edits
  ↓
discovers constraint
  ↓
edits again
  ↓
discovers dependency
  ↓
repairs previous edit
  ↓
human untangles diff

Com uma:

request
  ↓
inspect
  ↓
identify constraints
  ↓
compare approaches
  ↓
plan
  ↓
review
  ↓
execute

O modelo não se tornou mais inteligente.

O fluxo de trabalho tornou-se mais seguro.

3.2 O Contrato de Objetivo

Antes do plano, congele o problema.

goal: "Refactor the authorization layer without changing behavior"
constraints:
  - "preserve public API"
  - "preserve current authorization semantics"
  - "keep existing tests passing"
forbidden:
  - "framework migration"
  - "database schema change"
acceptance:
  - "all existing tests pass"
  - "new regression tests pass"
  - "duplicate authorization branches removed"
unknowns:
  - "legacy route behavior"

O contrato deve ser fácil de citar e difícil de interpretar mal.

3.3 Um plano deve prever o futuro

Fraco:

Melhorar a arquitetura e a confiabilidade.

Refutável:

Substituir a resolução de permissões duplicada nos módulos A e B pelo resolvedor canônico existente, preservar as assinaturas públicas, adicionar cobertura de regressão para os limites de convidado/admin e, em seguida, comparar o escopo de arquivos aprovado com o diff final.

A segunda versão pode falhar.

É precisamente por isso que ela é útil.

3.4 Antipadrões de planejamento

O problema da ficção científica de arquitetura

O agente assume que abstrações existem porque fizessem sentido.

Correção:

Inspect first.
If a component is not found, mark it UNKNOWN.
Do not invent it.

O problema de “tudo está no escopo”

O usuário pede uma refatoração. O agente redesenha silenciosamente três sistemas.

Correção:

approved files
approved services
forbidden changes

O plano que não pode ser testado

Se você não consegue explicar como uma etapa será verificada, a etapa não está pronta.

---

4. A arquitetura centrada em artefatos

A decisão de projeto mais importante é tornar o estado compartilhado visível.

Não projete em torno de “quem fala com quem”.

Projete em torno de quais artefatos circulam pelo sistema.

Recomendo cinco artefatos canônicos:

1. Goal Contract
2. Plan
3. Evidence Ledger
4. Decision Log
5. Verification Report

4.1 Contrato de Objetivo

É a definição estável de sucesso.

# Goal Contract

Goal:
Refactor the reporting module without changing public behavior.

Constraints:
- preserve API
- preserve error semantics
- preserve current output format

Forbidden:
- schema migration
- framework replacement
- unrelated cleanup

Definition of done:
- existing tests pass
- regression suite passes
- public API diff is zero
- performance remains within target

4.2 Plano

O plano é uma hipótese, não uma promessa de que a realidade obedecerá a ele.

Ele deve conter:

- locais observados,

- dependências,

- premissas,

- sequência,

- riscos,

- testes de aceitação,

- caminho de reversão/recuperação.

Quando novas evidências invalidarem o plano, revise o plano em vez de fingir que o antigo ainda descreve a realidade.

4.3 Livro Razão de Evidências

Este é o artefato que impede que a repetição se transforme em verdade.

Exemplo:

claim: "OAI-SearchBot is relevant to OpenAI web search discovery"
source: "OpenAI Publishers and Developers FAQ"
source_type: "official-documentation"
state: "VERIFIED"
used_for: "AI crawler preflight"

A fonte pode apoiar a afirmação sem apoiar uma afirmação muito mais forte, como “isso garante a citação”.

Essa distinção é o objetivo principal de um livro razão de evidências.

4.4 Estados de evidência

Use um vocabulário reduzido.

Um agente a jusante nunca deve ser capaz de transformar DESCONHECIDO em VERIFICADO apenas repetindo-o.

4.5 Registro de Decisões

Registre as escolhas e as alternativas rejeitadas.

Decision: Use manager + specialist-as-tool orchestration.

Rejected: unrestricted peer handoffs.

Reason: final synthesis needs one owner and specialists have bounded tasks.

Evidence: OpenAI Agents SDK manager-style orchestration guidance.

Os registros de decisão se tornam mais valiosos ao longo do tempo porque explicam não apenas a arquitetura atual, mas por que ela existe.

4.6 Relatório de Verificação

O relatório final deve ler como uma prova, não como uma celebração.

Criterion 1 — PASS
Evidence: 128/128 tests passed.

Criterion 2 — PASS
Evidence: public API snapshot unchanged.

Criterion 3 — FAIL
Evidence: duplicate branch remains in module C.

Decision: NO-GO
Repair: remove duplication and rerun targeted suite.

Esse documento pode ser reutilizado pelo próximo agente, revisor ou ser humano.

---

5. Papéis e topologias: escolha a estrutura a partir da tarefa

Papéis são úteis enquanto representam diferentes responsabilidades, contexto ou autoridade.

O modelo clássico de quatro papéis é um bom ponto de partida, não uma lei:

5.1 Orquestração sequencial

Planner → Specialist → Executor → Verifier

Use quando cada etapa depende da saída anterior.

5.2 Orquestração concorrente

┌→ Research A ─┐
Planner ┼→ Research B ─┼→ Synthesizer
        └→ Research C ─┘

Use quando os ramos são independentes.

5.3 Transferência

Triage → specialist

Use quando um especialista deve assumir o contexto ativo ou a interação com o usuário.

5.4 Gerente + agentes-como-ferramentas

┌→ Specialist A
Manager ─────────┼→ Specialist B
                 └→ Specialist C
                     ↓
                 final synthesis

Use quando um agente deve ser o responsável pela resposta final e decidir quando os especialistas são necessários.

O SDK de Agentes da OpenAI documenta explicitamente tanto o estilo de “agentes como ferramentas” de gerente quanto os padrões de transferência, além da orquestração orientada a código onde a aplicação controla o fluxo de trabalho.

Source: OpenAI Agents SDK — Orquestração de Agentes.

5.5 Chat em grupo

A ↔ B ↔ C ↔ Manager

Chat em grupo pode funcionar para deliberação genuína, mas tem um modo de falha desagradável: todos continuam falando porque ninguém tem a responsabilidade de parar.

Use limites explícitos de rodadas e um responsável pela decisão.

5.6 Orquestração dinâmica / magnética

O Agent Framework da Microsoft descreve a orquestração magnética como um gerente que coordena agentes especializados dinamicamente com base no estado evolutivo da tarefa.

Isso é útil quando o caminho não é conhecido antecipadamente.

Não é automaticamente melhor que um pipeline mais simples.

Source: Microsoft — Orquestração magnética.

5.7 A matriz de decisão de topologia

---

6. O protocolo de diálogo: Ação, Estado, Resultado

Um sistema multiagente pode falhar mesmo quando cada resposta individual do modelo parece boa.

Por quê?

Porque a própria comunicação é um recurso do sistema.

Considere:

Agent A → 2,000-word explanation
Agent B reads it and writes 1,800 words
Agent C receives A+B and writes 1,500 words
Agent D receives everything and decides what matters

Grande parte desse texto é uma explicação do histórico de raciocínio, não o estado necessário para continuar.

Um artigo de junho de 2026, What Should Agents Say? Action-state Communication for Efficient Multi-Agent Systems, introduz o PACT — Protocolized Action-state Communication and Transmission (Comunicação e Transmissão Protocolizadas de Ação e Estado). O artigo analisa diversas estratégias de comunicação e argumenta que mensagens úteis entre agentes devem preservar o estado centrado na ação, em vez de simplesmente repassar saídas em formato livre. Seus experimentos relatam uma relação de custo-desempenho substancialmente melhor e menor consumo de tokens nos cenários testados. O artigo também enfatiza que nenhuma estratégia de comunicação fixa isolada é ideal para todas as situações.

Fonte: PACT.

A parte que vale a pena copiar é direta:

Passe o estado necessário para continuar, não a transcrição que o produziu.

6.1 A mensagem de Ação-Estado-Resultado

Um registro de transferência (handoff) prático:

### Action-State Message

From: Critic
To: Planner

Action:
Reject plan step 3.2.

State:
The plan assumes generated routes are all crawlable. Repository inspection shows that one route family can produce orphaned URLs without canonical links.

Result:
Add a route-crawlability acceptance test and an explicit canonical URL requirement.

Evidence:
route manifest + crawler output + relevant source file.

Confidence:
High.

Next needed:
Revise step 3.2 before execution.

6.2 Por que "Resultado" ("Result") é útil

"Ação" ("Action") diz o que aconteceu.

"Estado" ("State") diz o porquê.

"Resultado" ("Result") diz qual artefato ou decisão o receptor deve levar adiante.

Sem o Resultado, o próximo agente precisa reconstruir a transferência pretendida.

6.3 Mantenha as mensagens orientadas ao receptor

Um remetente pode se importar com cinquenta detalhes.

O receptor pode precisar de cinco.

Uma boa mensagem responde a:

What changed?
Why does it matter?
What should I use?
What remains unresolved?

6.4 Não repasse a cadeia de pensamento privada

A coordenação estruturada não exige o envio de rastros de raciocínio ocultos.

Passe:

- observações,

- saídas de ferramentas,

- conclusões,

- evidências,

- decisões,

- perguntas em aberto,

- próximas ações.

Isso é suficiente para coordenar.

6.5 Um formato JSON compacto

Quando você precisar de transferências legíveis por máquina:

{
  "action": "reject_plan_step",
  "state": "route family can produce orphaned URLs",
  "result": "add crawlability + canonical acceptance test",
  "evidence": [
    "route-manifest.json",
    "crawler-output.json"
  ],
  "confidence": "high",
  "next_needed": "revise_plan"
}

Isso é especialmente útil quando o orquestrador é orientado por código.

---

7. O Loop de Criação Iterativa completo

O loop é uma sequência de portões de validação (gates), e não um ritual por si só.

7.1 Passo 0 — Congele o contrato

Escreva:

Goal
Constraints
Forbidden changes
Definition of done
Unknowns

Faça isso antes que a equipe comece a criar.

7.2 Passo 1 — Observe

Regra:

Sem invenção onde a inspeção for possível.

Para software, inspecione:

- árvore de código-fonte,

- arquivos relevantes,

- dependências,

- testes,

- configuração,

- abstrações atuais,

- alterações recentes.

Para pesquisas, inspecione:

- fontes primárias,

- documentação oficial,

- comportamento atual do produto,

- artigos de pesquisa,

- evidências contraditórias.

Para conteúdo, inspecione:

- intenção de busca,

- referências autoritárias,

- terminologia,

- interpretações concorrentes,

- dúvidas do público.

A saída deve começar com Fatos Observados (Observed Facts).

7.3 Passo 2 — Planeje

O planejador (Planner) produz:

observed facts
assumptions
proposed sequence
dependencies
risks
acceptance tests
rollback path

Tudo o que não for verificado permanece rotulado.

7.4 Passo 3 — Desafie

O crítico (Critic) recebe uma instrução:

Suponha que o plano esteja errado. Encontre o menor número de motivos de alto impacto pelos quais ele pode falhar.

Priorize:

goal violations
wrong assumptions
hidden dependencies
missing tests
security/reliability risks
scope creep
unnecessary complexity

Não peça ao crítico para reescrever o plano.

Peça a ele para destruir o plano.

7.5 Passo 4 — Especializar

Gere especialistas apenas para incertezas não resolvidas.

Exemplos:

Performance question
Security question
Framework compatibility question
Research evidence question
Accessibility question
Crawler behavior question

A atribuição de um especialista deve ser específica o suficiente para caber em uma única frase.

7.6 Passo 5 — Resolva divergências

Não use:

latest response wins

Use uma hierarquia de prioridade de evidências:

1. direct mechanical evidence
2. reproducible experiment
3. official / primary documentation
4. source-code inspection
5. peer-reviewed or clearly identified research
6. strong secondary analysis
7. expert judgment
8. model intuition

Esta é uma heurística prática, não um ranking científico universal. Sua função é impedir que a confiança retórica supere as evidências.

7.7 Passo 6 — Refine o plano canônico

Não acrescente mais debates a uma transcrição gigantesca.

Atualize o Plano.

O plano deve continuar sendo o estado atual canônico.

7.8 Passo 7 — Aprove um ponto de verificação

Não aprove uma implementação arriscada inteira como uma única promessa atômica.

Aprove uma unidade pequena:

Checkpoint 1
→ execute
→ verify
→ update state

Checkpoint 2
→ execute
→ verify
→ update state

7.9 Passo 8 — Execute

A execução agora deve ter um contrato, escopo e condições de teste.

7.10 Passo 9 — Verifique

O verificador deve ver:

- Contrato de Meta,

- critérios de aceitação,

- artefato resultante,

- evidência bruta relevante,

- saída de teste determinística.

Não se deve dizer a conclusão antecipadamente a ele.

7.11 Passo 10 — Aprenda

Registre:

what failed
which assumption was wrong
which test caught it
which communication was wasteful
whether the specialist was necessary
whether the overall topology paid off

Isso se torna a futura memória organizacional.

7.12 O diagrama de estado completo

┌──────────┐
│  OBSERVE │
└────┬─────┘
     ↓
┌──────────┐
│ CONTRACT │
└────┬─────┘
     ↓
┌──────────┐
│   PLAN   │
└────┬─────┘
     ↓
┌──────────┐
│ CHALLENGE│
└────┬─────┘
     ↓
┌──────────┐
│SPECIALIZE│  only where needed
└────┬─────┘
     ↓
┌──────────┐
│  REFINE  │
└────┬─────┘
     ↓
┌──────────┐
│ APPROVE  │
└────┬─────┘
     ↓
┌──────────┐
│ EXECUTE  │
└────┬─────┘
     ↓
┌──────────┐
│ VERIFY   │
└────┬─────┘
     ↓
┌──────────┐
│  LEARN   │
└────┬─────┘
     │
     └────────────→ OBSERVE

---

8. Como executar o loop hoje: Cursor, Claude Code, SDKs e harnesses personalizados

O framework deve vir depois do fluxo de trabalho.

8.1 Cursor

O Plan Mode do Cursor é um lar natural para a primeira metade do loop:

Plan Mode
→ inspect repository
→ ask questions
→ create/edit Markdown plan
→ review
→ build
→ review diff
→ run checks

A documentação do Cursor recomenda especificamente o Plan Mode para recursos complexos, alterações em vários arquivos, requisitos incertos e decisões de arquitetura. Para edições pequenas e familiares, o modo Agent pode ser mais adequado.

Referências úteis:

- Cursor Plan Mode

- Cursor Plan Mode help

- Cursor CLI

- Cursor quickstart

Configuração prática

1. Write Goal Contract.
2. Enter Plan Mode.
3. Ask for observed facts first.
4. Ask for plan + acceptance tests.
5. Run a fresh-context Critic pass.
6. Revise the plan.
7. Build one checkpoint.
8. Run deterministic checks.
9. Run verifier.

8.2 Claude Code

O Claude Code oferece suporte a controle de permissão orientado a planos, subagentes com contextos de trabalho separados e equipes de agentes para uma coordenação mais independente.

A distinção útil é:

Subagent
= isolated worker for a bounded task

Agent team
= multiple independent sessions coordinating on a broader problem

Use subagentes quando o trabalho intermediário for grande, mas apenas o resultado precisar retornar ao contexto principal.

Use equipes quando trabalhadores independentes precisarem se coordenar em torno de uma tarefa compartilhada.

Referências úteis:

- Claude Code Subagents

- Claude Code Agent Teams

- Claude Code Permissions

8.3 OpenAI Agents SDK

A documentação atual do SDK da OpenAI descreve duas grandes estratégias de orquestração:

Orientada por LLM: o modelo decide quais agentes/ferramentas invocar.

Orientada por código: a lógica da aplicação determina o fluxo.

Ela também distingue:

Agentes como ferramentas: o gerenciador mantém o controle.

Transferências (Handoffs): o especialista assume.

A mesma documentação descreve o encadeamento, loops de avaliadores e execução paralela de agentes como padrões comuns orientados por código.

Isso fornece uma implementação direta do Loop de Criação Iterativa:

planner
→ critic
→ refiner
→ executor
→ evaluator
→ repair/replan

Referências:

- OpenAI Agents SDK

- Agent orchestration

- JavaScript multi-agent guide

8.4 LangChain e LangGraph

A documentação atual do LangChain trata explicitamente o design multi‑agente como um problema de engenharia de contexto e documenta padrões como:

- subagentes,

- entregas,

- roteadores,

- habilidades.

O LangGraph oferece controle de grafo/estado mais explícito para aplicações que precisam de transições de fluxo de trabalho persistentes e inspecionáveis.

Referências:

- LangChain multi-agent

- LangGraph

8.5 CrewAI

CrewAI é uma abordagem orientada a papéis e tarefas para prototipar fluxos de trabalho de equipes.

A questão importante não é se a estrutura chama seu processo de “crew”. A questão importante é se você pode representar:

Goal
→ task decomposition
→ ownership
→ dependencies
→ outputs
→ verification

Referência: CrewAI documentation.

8.6 Microsoft Agent Framework

A documentação atual do Microsoft Agent Framework expõe vários padrões de orquestração:

Sequential
Concurrent
Handoff
Group Chat
Magentic

Ela também suporta interações de fluxo de trabalho com humano no loop.

Esse vocabulário é útil mesmo que você nunca use a estrutura, porque fornece nomes para diferentes formas de coordenação.

Referências:

- Workflow orchestrations

- Magentic orchestration

- AI agent orchestration patterns

8.7 Tabela de seleção de frameworks

Isso não é uma classificação. É um mapa de adequação.

---

9. O que as evidências de 2025–2026 realmente nos dizem

O campo multi‑agente acumulou evidências suficientes para que “mais agentes = mais inteligente” não seja mais um princípio de design sério.

A questão interessante é de onde vêm os ganhos e onde eles desaparecem.

9.1 Anthropic: mais computação pode comprar mais capacidade de pesquisa

O relatório de engenharia da Anthropic sobre seu sistema de Pesquisa multi‑agente é um dos exemplos públicos mais claros.

A arquitetura usa um agente líder para planejar a pesquisa e delega direções a subagentes que investigam em paralelo.

A Anthropic relata:

- 90,2 % de melhoria em relação ao seu baseline de agente único na avaliação interna BrowseComp,

- aproximadamente 15× o uso de tokens de um chat comum,

- ganhos significativos provenientes da paralelização e da capacidade adicional de contexto,

- ajuste pobre para algumas tarefas fortemente acopladas onde os agentes precisam de contexto compartilhado intenso.

A lição correta não é “usar muitos agentes”.

É:

Quando uma tarefa tem alto valor, muita coleta de informação paralelizável e um gargalo em um único contexto, a execução multi‑agente pode comprar capacidade de raciocínio adicional útil.

Fonte: Anthropic — How we built our multi-agent Research system.

9.2 PACT: comunicação é uma superfície de otimização

O PACT faz uma pergunta mais restrita:

O que os agentes realmente devem dizer uns aos outros?

A resposta não é “enviar tudo”.

O artigo avalia múltiplas estratégias e propõe comunicação Ação‑Estado como forma de preservar informações relevantes à decisão enquanto reduz a transferência de contexto desnecessária. Ele relata economias substanciais de tokens em seus experimentos, incluindo melhorias em harnesses de codificação avaliados.

A ideia mais transferível é:

public state update
> conversation transcript

Fonte: PACT.

9.3 MAST: a coordenação cria modos de falha

O artigo Why Do Multi-Agent LLM Systems Fail? analisou mais de 150 rastreamentos em detalhes para construir uma taxonomia de 14 modos de falha agrupados em:

1. 18.especificação e design de sistemas,
2. 19.alinhamento incorreto entre agentes,
3. 20.verificação de tarefas e término.

Posteriormente, o projeto disponibilizou um conjunto de dados de rastreamento anotado maior para uma avaliação mais ampla.

O ponto importante é arquitetural:

Um sistema multiagente é um sistema novo. Ele precisa de sua própria engenharia de confiabilidade.

Fonte: MAST.

9.4 MultiAgentBench: a própria coordenação pode ser medida

O trabalho do ACL 2025 MultiAgentBench avalia não apenas a conclusão da tarefa, mas também o comportamento de coordenação. Ele estuda protocolos de coordenação em estrela, corrente, árvore e grafo, e utiliza métricas orientadas a marcos.

Isso é útil porque a precisão final por si só oculta o comportamento do sistema.

Um fluxo de trabalho pode produzir a resposta certa pelos motivos errados.

Ele também pode gastar recursos enormes para produzir um resultado modesto.

Fonte: MultiAgentBench.

9.5 Setembro de 2026: “quando mais é menos” torna-se a questão central

O estudo de setembro de 2026 Rethinking Multi-Agent Collaboration: When More Is Less examina diretamente o dimensionamento de conjuntos de agentes e a profundidade de recursão.

Sua principal mensagem é que a estrutura da tarefa define o limite de capacidade. Mais agentes não geram consistentemente melhores resultados.

Essa é quase exatamente a razão pela qual este guia recusa-se a transformar “quatro agentes” ou “dez agentes” em uma receita universal.

Fonte: Rethinking Multi-Agent Collaboration.

9.6 O padrão de evidência

Em todas essas fontes, surge um panorama de engenharia coerente:

Multi-agent helps when:
+ work can be decomposed
+ branches are reasonably independent
+ contexts benefit from isolation
+ additional tool capacity matters
+ independent checking has real value

Multi-agent hurts when:
− dependencies are dense
− everyone needs the same context
− communication dominates work
− verification is weak
− agents duplicate each other
− the task is too small to justify the overhead

Essa é uma conclusão muito mais útil do que “o sistema multiagente é o futuro”.

---

10. Quatro manuais práticos: software, pesquisa, conteúdo e produtos

O loop é abstrato. Estes manuais tornam-no concreto.

10.1 Software: refatore sem desvio comportamental

Objetivo

Dividir um grande módulo de relatórios sem alterar seu comportamento público.

Planejador

Inspecionar:

- exportações públicas,

- chamadores,

- estado compartilhado,

- testes,

- caminhos sensíveis a desempenho,

- configuração.

Saída:

current boundaries
candidate extraction points
dependency order
regression tests
rollback path

Crítico

Atacar:

hidden coupling
changed error behavior
circular dependencies
performance regressions
snapshot drift
unapproved files

Especialista

O especialista em desempenho recebe uma pergunta:

A extração do formatador transfere trabalho para um caminho crítico (hot path) ou duplica a serialização?

Executor

Altera apenas os arquivos aprovados.

Verificador

Prefira portas determinísticas:

unit tests
integration tests
type checking
lint
build
API snapshot
benchmark
diff scope

Exemplo de registro de verificação

PASS — 128/128 unit tests
PASS — 24/24 integration tests
PASS — 0 type errors
PASS — public API unchanged
PASS — benchmark within target
PASS — changed files within approved scope

O LLM não é o verificador completo.

Ele é a camada que interpreta os resultados que as ferramentas determinísticas não conseguem interpretar totalmente.

10.2 Pesquisa: construa um mapa de evidências em vez de uma pilha de resumos

Pergunta:

Como os sistemas atuais de busca por IA descobrem e utilizam fontes da web?

Não lance seis “pesquisadores” genéricos.

Divida a incerteza:

Cada trabalhador retorna registros estruturados:

claim: "X"
source: "https://example.com/source"
source_type: "official-docs"
published: "2026-08-12"
evidence: "exact observation"
state: "SUPPORTED"
limitations:
  - "platform-specific"

O papel de pesquisa mais valioso muitas vezes não é outro pesquisador.

É o pesquisador de desconfirmação.

Atribua esta tarefa a um trabalhador:

🇫🇷

Encontre evidências que tornem a conclusão emergente errada ou materialmente mais fraca.

Isso reduz as cascatas de confirmação.

10.3 Conteúdo: separar o trabalho epistêmico do trabalho de estilo

Um artigo técnico sólido pode usar este pipeline:

Question map
    ↓
Evidence map
    ↓
Argument map
    ↓
Outline
    ↓
Draft
    ↓
Fact check
    ↓
Human-voice edit
    ↓
SEO/GEO preflight

O pipeline ruim é:

SEO agent
→ writer
→ humanizer
→ GEO agent
→ headline agent
→ final polish agent

Por quê?

Porque cada agente está otimizando a forma superficial. Ninguém é claramente responsável pela verdade epistêmica.

Rótulos de afirmações de conteúdo

Um conjunto de rótulos interno útil:

FACT
REPORTED RESULT
OBSERVATION
INTERPRETATION
OPINION
PROPOSAL
UNKNOWN

O artigo publicado não precisa exibir todos os rótulos. O fluxo de trabalho interno deve conhecê-los.

10.4 Criação de produto: dar a cada função um alvo de falha diferente

Use quatro perspectivas:

O Defensor do Usuário deve ter uma tarefa concreta:

Encontre todos os lugares onde o produto pede ao usuário que compreenda nossa arquitetura interna em vez de entender seu próprio trabalho.

Isso produz um feedback muito mais acionável do que “revisar UX.”

---

11. Verificação e medição: tornar “concluído” observável

Um fluxo de trabalho se torna um sistema de engenharia quando pode explicar por que acredita estar completo.

11.1 Hierarquia de verificação

Use o portão confiável mais barato primeiro.

LEVEL 1 — Mechanical
schema validation
unit tests
type checks
lint
HTTP checks
file existence

LEVEL 2 — Deterministic comparison
snapshots
diffs
benchmarks
invariants
regression datasets

LEVEL 3 — Model evaluation
semantic quality
classification
summarization fidelity
comparative judgment
style compliance

LEVEL 4 — Human review
high-stakes decisions
ambiguous interpretation
final publication
material production changes

Não use um modelo para responder a uma pergunta que um compilador pode responder.

11.2 Verificação critério por critério

Ruim:

Tudo parece bom.

Bom:

Criterion: Preserve public API
Status: PASS
Evidence: API snapshot diff = 0

Criterion: Remove duplication
Status: FAIL
Evidence: legacy branch remains in src/auth/legacy.ts

Criterion: Existing tests pass
Status: PASS
Evidence: 128/128

11.3 PASS / FAIL / UNKNOWN

UNKNOWN é importante.

Um verificador deve poder dizer:

Não consegui estabelecer este critério.

Isso é melhor que um PASS fabricado.

11.4 Contexto fresco não significa automaticamente independência

Um verificador fresco ainda pode ser tendencioso se você lhe fornecer a conclusão do criador.

Evite:

The implementation succeeded. Please verify it.

Prefira:

Original goal:
...

Acceptance criteria:
...

Result:
...

Raw test evidence:
...

Determine PASS / FAIL / UNKNOWN.

O verificador recebe evidências, não o veredicto.

11.5 Métricas principais

11.6 Execute um teste A/B no seu fluxo de trabalho

Em vez de debater se multi-agente é “melhor”, compare:

A — one agent
B — planner + critic
C — planner + critic + specialist

Para a mesma classe de tarefa, meça:

cost
latency
pass/fail
rework
defects
verification catches
human interventions

Mantenha a coordenação adicional apenas se melhorar o resultado verificado o suficiente para justificar seu custo.

---

12. Modos de falha: como sistemas de agentes visualmente bons quebram

Adicionar agentes cria um novo sistema. Novos sistemas criam novos modos de falha.

O MAST formalizou esse problema com 14 modos de falha divididos em especificação/design de sistema, desALINHAMENTO entre agentes e verificação/encerramento de tarefas.

Fonte: Why Do Multi-Agent LLM Systems Fail?.

A tabela operacional a seguir transforma essa pesquisa em verificações de engenharia.

12.1 Diálogo infinito

Defina:

max_rounds = 3

Então:

if no acceptance-blocking issue remains:
    approve
else:
    escalate

Não permita que o sistema invente motivos para continuar o debate.

12.2 Teatro de consenso

Um crítico deve ter permissão para rejeitar um plano.

Mas o Planner também deve ter permissão para rejeitar o Critic quando a objeção não tiver suporte.

Uma boa colaboração contraditória não é “todo mundo discorda”.

É:

claim
→ evidence
→ challenge
→ resolution

12.3 Cascatas de alucinação

Uma única afirmação sem suporte torna-se perigosa quando passa por vários agentes:

UNKNOWN
 ↓
plausible
 ↓
supported-sounding
 ↓
“fact”
 ↓
implementation decision

Seu modelo de estado deve tornar essa conversão explícita.

12.4 Corrupção de estado compartilhado

Para artefatos importantes, use um único escritor canônico.

Critic      → proposes change
Specialist  → proposes evidence
Planner     → updates canonical plan
Verifier    → updates verification report
Human       → approves/rejects high-impact decisions

Os outros propõem. Um único proprietário confirma (commit).

12.5 Alucinação de ferramenta

Mantenha um registro de mundo fechado:

tool: run_tests
description: "Runs the repository's configured test suite"
permissions: [read, execute]
side_effects: "may create temporary files"

Não permita que um agente assuma que “deve haver uma ferramenta para isso”.

12.6 Economia de tokens

Um fluxo de trabalho pode ser tecnicamente bem-sucedido e economicamente absurdo.

O dado publicado pela Anthropic de 15× mais tokens para pesquisas com múltiplos agentes é um aviso útil, embora seja específico para a arquitetura e avaliação da Anthropic.

Meça:

cost per verified success

e não apenas:

cost per run

---

13. SEO, GEO e publicação legível por IA sem o folclore

O trabalho criado por agentes torna-se cada vez mais conteúdo público.

Isso cria um segundo problema: uma vez que o fluxo de trabalho produz um ótimo artigo, como você faz para que pessoas, mecanismos de busca e sistemas de IA o descubram e compreendam facilmente sem transformar o artigo em uma “sopa de SEO”?

A resposta começa com uma distinção:

A arquitetura de informação legível por máquina é útil. Truques mágicos de GEO não são um substituto para ela.

13.1 O que o Google realmente diz em 2026

As diretrizes atuais do Google sobre recursos de IA são incomumemente diretas:

- as melhores práticas de SEO existentes continuam relevantes,

- as páginas precisam estar indexadas e elegíveis para a Pesquisa para apoiarem links em AI Overviews ou AI Mode,

- não há requisitos técnicos extras exigidos especificamente para esses recursos de IA,

- o conteúdo importante deve estar disponível em formato textual,

- links internos, rastreabilidade, experiência da página e conteúdo original útil continuam importantes,

- não há marcação Schema.org especial necessária para AI Overviews ou AI Mode.

O Google também afirma que atender às melhores práticas não garante rastreamento, indexação ou exibição.

Fontes:

- Google — AI Features and Your Website

- Google — Optimizing for generative AI features

Esse último ponto importa porque acaba com uma das piores formas de marketing de busca por IA:

“Faça essas três coisas e a IA do Google vai citar você.”

Não existe essa garantia universal.

13.2 O Search Console agora oferece uma camada de medição melhor

O Google introduziu relatórios de desempenho de IA generativa na Pesquisa em junho de 2026 e afirmou que havia disponibilizado esses insights globalmente até 31 de agosto de 2026.

Os relatórios expõem a visibilidade dentro de recursos de IA generativa na Pesquisa, incluindo AI Overviews e AI Mode, dentro do sistema de relatórios de desempenho do Search Console.

Essa é uma melhoria prática importante porque fornece aos editores uma superfície de medição própria (first-party), em vez de forçar todas as análises de busca por IA a dependerem de palpites de terceiros.

Fonte: Google Search Central — Search Generative AI performance reports.

Use esses dados onde estiverem disponíveis.

13.3 O que “legível por IA” deve significar

Uma página útil deve permitir que uma máquina responda:

What is this page about?
Who wrote it?
When was it published/updated?
What are the major claims?
What evidence supports them?
Which sections answer which questions?
Which parts are facts versus interpretations?
Where are the primary sources?
What is the canonical version?

Isso não é formatação especial para IA.

É uma boa arquitetura de informação.

13.4 Estrutura para conteúdo de referência de formato longo

Uma estrutura de artigo durável:

Title
↓
TL;DR
↓
Table of Contents
↓
Definition / thesis
↓
Evidence
↓
Counterexamples
↓
Architecture
↓
Implementation
↓
Examples
↓
Failure modes
↓
Measurement
↓
Limitations
↓
Templates
↓
Sources

Essa estrutura ajuda humanos e sistemas de recuperação pelo mesmo motivo subjacente: reduz a ambiguidade.

13.5 Dados estruturados: úteis, não mágicos

Para um artigo, as propriedades relevantes do Schema.org podem incluir:

Article
author
datePublished
dateModified
headline
image
mainEntityOfPage

Mas a marcação deve descrever o conteúdo visível com precisão.

Não afirme que o schema de Article garante citações ou posicionamentos em IAs.

A documentação de dados estruturados do Google diz explicitamente que os dados estruturados o ajudam a entender o conteúdo, enquanto a elegibilidade e a exibição dependem de sistemas e requisitos adicionais.

Fontes:

- Google — Structured data policies

- Schema.org — Article

13.6 robots.txt é uma camada, não toda a pilha

O Google diz que o robots.txt controla o acesso de rastreadores; ele não é um mecanismo geral de noindex.

Para manter as páginas fora da Pesquisa Google, o Google aponta para noindex ou autenticação, em vez de depender apenas do robots.txt.

Fontes:

- Google — robots.txt

- Google — meta tags and attributes

Para rastreadores de IA, a mesma verdade prática se aplica: a página pode ser permitida pelo robots.txt e ainda assim falhar por meio de outra infraestrutura.

Pense em camadas:

robots.txt
   ↓
WAF / CDN
   ↓
bot mitigation
   ↓
authentication
   ↓
rate limiting
   ↓
JavaScript challenges
   ↓
HTTP response
   ↓
rendering / retrieval

A OpenAI documenta o OAI-SearchBot para descoberta relacionada à busca na web e fornece orientações para editores sobre como permitir o acesso. A Anthropic documenta identidades de rastreadores separadas, como ClaudeBot, Claude-User e Claude-SearchBot.

Fontes:

- OpenAI — Publishers and Developers FAQ

- Anthropic — Web crawlers and robots.txt

13.7 llms.txt: experimento razoável, não SEO mágico

O projeto llms.txt é uma proposta da comunidade para apresentar informações organizadas e voltadas para máquinas sobre um site.

Pode ser útil como documentação.

Não é um requisito universal do Google.

A orientação atual do Google sobre IA generativa diz explicitamente que você não precisa criar arquivos de texto de IA especiais, como o llms.txt, para aparecer em seus recursos de busca baseados em IA generativa.

Fontes:

- llms.txt

- Google — generative AI guidance

Use-o porque ele atende a um propósito claro de arquitetura da informação, e não porque alguém o vendeu como um interruptor de ranqueamento.

13.8 A mensuração de GEO vai além da contagem de citações

Pesquisas recentes de 2026 estão caminhando em direção a um modelo mais preciso de visibilidade em buscas por IA.

Um estudo de abril de 2026 separa:

citation selection
≠
citation absorption

Uma página pode ser recuperada e citada sem contribuir de forma relevante para a resposta gerada.

Uma pesquisa de julho de 2026 descreve de forma semelhante o GEO como um processo em várias etapas que envolve descobertibilidade, recuperação, reclassificação (reranking), citação, proeminência, absorção factual e comportamento do usuário a jusante.

Fontes:

- From Citation Selection to Citation Absorption

- Optimizing Visibility in Generative Engines: A Critical Survey

Isso sugere uma pilha de medição melhor:

Discoverability
↓
Retrieval
↓
Citation
↓
Citation position / prominence
↓
Answer contribution
↓
Factual fidelity
↓
Traffic / conversions

Isso é muito mais informativo do que “pontuação de visibilidade de IA = 83”.

13.9 O que as pesquisas recentes de GEO sugerem — com cautela

Estudos de 2026 estão encontrando associações e efeitos controlados envolvendo fatores como relevância tópica, posição do contexto, informações factuais explícitas, estrutura e riqueza de evidências. Um estudo competitivo de GEO avaliou 252.000 testes controlados em seis LLMs; outro grande estudo do ACL 2026 explora o alinhamento de demanda latente do usuário; uma estrutura separada estuda como a influência da citação difere da seleção de citações.

Estas são direções de pesquisa valiosas.

Mas elas não devem ser reduzidas a conselhos universais como:

“Escreva exatamente X palavras, adicione Y títulos e qualquer IA citará você.”

A afirmação prática mais forte é mais segura:

Torne as informações importantes explícitas, relevantes, bem fundamentadas, fáceis de recuperar e fiéis ao material de origem.

Fontes:

- What Gets Cited: Competitive GEO in AI Answer Engines

- Mind Reader — ACL 2026

- From Experience to Skill — Findings of ACL 2026

13.10 Pré-voo prático de GEO/SEO

TECHNICAL
[ ] Crawlable when intended
[ ] Indexable when intended
[ ] Canonical URL is correct
[ ] Important text is accessible
[ ] No accidental noindex
[ ] Internal links are present
[ ] HTTP responses are healthy

CONTENT
[ ] Clear title
[ ] One clear H1
[ ] Coherent heading hierarchy
[ ] Direct answers to major questions
[ ] Definitions before jargon
[ ] Material claims supported by sources
[ ] Facts separated from interpretation
[ ] Publication/update date
[ ] Author / provenance

AI ACCESS
[ ] Intended AI crawler policy is deliberate
[ ] WAF/CDN does not silently block intended access
[ ] Authentication is understood
[ ] Rate limits are sane
[ ] JavaScript challenges are not accidental blockers

STRUCTURE
[ ] Accurate Article/Organization/etc. structured data where appropriate
[ ] Structured data matches visible content
[ ] Stable URLs
[ ] Duplicate versions controlled
[ ] Sources are easy to follow

Para uma verificação prática de pré-voo em páginas públicas, o Website SEO Checker do AuditMe pode inspecionar uma URL e apontar problemas em SEO técnico, estrutura de conteúdo, schema, desempenho e dimensões de prontidão relacionadas.

Isso o torna útil como uma passada de diagnóstico.

Não é uma prova de que um sistema de IA citará a página.

Links do AuditMe para o fluxo de trabalho

- AuditMe — Auditoria de SEO e Inteligência de Sites

- AuditMe — Verificador de SEO de Site

- AuditMe — Verificador de Pontuação de SEO

A maneira correta de usar uma ferramenta de auditoria neste processo é como evidência pré-voo: encontrar problemas técnicos e estruturais antes de solicitar que um motor de busca ou sistema de IA descubra a página.

---

14. O kit operacional reutilizável

Esta seção foi projetada para ser copiada.

Você pode colocar os modelos em um repositório, uma base de conhecimento, uma biblioteca de prompts ou um motor de fluxo de trabalho.

14.1 Modelo de Contrato de Meta

# Goal Contract

## Goal
[One precise sentence]

## Why
[Why the work matters]

## Constraints
- [constraint]
- [constraint]

## Forbidden Changes
- [forbidden change]
- [forbidden change]

## Definition of Done
- [measurable criterion]
- [measurable criterion]

## Unknowns
- [unknown]
- [unknown]

14.2 Prompt do Planejador

You are the Planner.

Goal:
[goal]

Constraints:
[list]

Forbidden changes:
[list]

Definition of done:
[criteria]

First inspect the real evidence available to you.
Do not execute implementation.
Do not invent architecture.
Mark assumptions and unknowns explicitly.

Return:
1. Observed facts
2. Assumptions
3. Proposed plan
4. Dependencies
5. Risks
6. Acceptance tests
7. Rollback/recovery path

14.3 Prompt do Crítico

You are the Critic.

Assume the current plan is wrong.
Find the smallest number of high-impact reasons it could fail.

Prioritize:
- goal violations
- incorrect assumptions
- hidden dependencies
- missing tests
- security/reliability risks
- unnecessary complexity
- scope creep

Do not rewrite the plan.
Return each issue as:

Action:
State:
Result:
Evidence:
Confidence:
Next needed:

14.4 Prompt do Especialista

You are a domain specialist.

Question to resolve:
[one specific question]

Do not review the entire project.
Do not redesign unrelated systems.
Prefer primary documentation, code inspection, tests, or reproducible measurements.

Return:
Action:
State:
Result:
Evidence:
Confidence:
Open questions:

14.5 Prompt do Verificador

You are the Verifier.

Original Goal:
[goal]

Definition of Done:
[criteria]

Inspect the result independently.
Do not rely on the creator's explanation.
Prefer deterministic evidence whenever available.

For every criterion return:
PASS / FAIL / UNKNOWN

For each result include:
- evidence
- blockers
- defects found
- repair needed

Final decision:
GO / CONDITIONAL GO / NO-GO

14.6 Prompt do Editor de Voz Humana

You are the final human-voice editor.

Do not make the article more enthusiastic.
Make it more credible and authored.

Remove:
- generic AI transitions
- inflated adjectives
- repeated conclusions
- fake certainty
- unnecessary headings
- repetitive sentence rhythms

Preserve:
- technical specificity
- source attribution
- disagreement
- uncertainty
- concrete examples
- author judgment

Do not invent personal experience, clients, benchmarks, or case studies.

14.7 Esquema de Transferência de Agente

from: "critic"
to: "planner"
action: "reject_plan_step"
state: "orphaned routes are possible"
result: "add crawlability and canonical acceptance test"
evidence:
  - "route-manifest.json"
  - "crawler-output.json"
confidence: "high"
next_needed: "revise_plan"

14.8 Layout de Repositório Sugerido

.agent/
├── goal-contract.md
├── plan.md
├── evidence-ledger.md
├── decisions.md
├── verification.md
├── prompts/
│   ├── planner.md
│   ├── critic.md
│   ├── specialist.md
│   ├── verifier.md
│   └── human-voice-editor.md
└── runs/
    ├── 2026-09-22-run-001.md
    └── 2026-09-23-run-002.md

O diretório exato não importa.

A separação importa.

14.9 Loop Mínimo Viável — 15 a 30 minutos

0–5 minutes

Escreva:

Goal
Constraints
Forbidden changes
Definition of done
Unknowns

5–10 minutes

Modo Planejamento / passagem do planejador.

10–15 minutes

Crítico de contexto fresco.

15–20 minutes

Resolva correções baseadas em evidências.

20–25 minutes

Execute um ponto de verificação.

25–30 minutes

Verifique em relação ao contrato original.

Isso é suficiente para começar.

Você não precisa de uma plataforma de orquestração distribuída para obter o benefício principal.

14.10 Checklist compacto

Before execution

[ ] Goal Contract exists
[ ] Constraints explicit
[ ] Forbidden changes explicit
[ ] Definition of done measurable
[ ] Real evidence inspected
[ ] Unknowns labeled
[ ] Plan falsifiable
[ ] Critic allowed to reject
[ ] Specialists have narrow assignments
[ ] Canonical plan has one owner

Durante a execução

[ ] Independent work parallelized only where useful
[ ] Handoffs pass state, not speeches
[ ] Evidence provenance preserved
[ ] Tool permissions scoped
[ ] Checkpoints explicit
[ ] Scope remains inside contract
[ ] Raw test outputs retained

Antes de enviar

[ ] Deterministic checks passed
[ ] Material claims verified
[ ] Contradictions resolved or labeled
[ ] Final artifact matches Goal Contract
[ ] Unknowns documented
[ ] Verification is independent enough to matter
[ ] Cost / latency / rework measured
[ ] Final artifact is reusable

14.11 As 12 regras que vale a pena lembrar

1. Comece com um agente.

Não projete um conselho antes de conseguir nomear o gargalo.

2. Divida por incerteza, não por cargo.

Um especialista existe porque algo requer contexto, ferramentas, expertise ou julgamento independente diferentes.

3. Paralelize trabalho independente.

Essa é uma das razões mais claras para usar múltiplos agentes.

4. Mantenha o Contrato de Objetivo estável.

Caso contrário, o sistema pode “ter sucesso” ao mudar o problema.

5. Torne o plano canônico.

Não use o histórico de chat como seu banco de dados.

6. Passe estado, não discursos.

Ação + Estado + Resultado é um padrão prático.

7. Ataque antes de executar.

Uma suposição errada em Markdown é barata. Uma suposição errada dentro de um diff de produção não é.

8. Verifique com o método mais barato e confiável.

Compilador ao invés de conversa. Teste ao invés de opinião. Fonte ao invés de memória.

9. Trate UNKNOWN como um estado válido.

Evidência ausente é informação.

10. Meça resultados verificados.

Chamadas de ferramenta são atividade. Um teste de aceitação aprovado é evidência de progresso.

11. Mantenha a estrutura menor que o problema.

Se a orquestração for mais difícil que a tarefa subjacente, simplifique.

12. Pare quando o objetivo for alcançado.

Mais diálogo não significa automaticamente mais qualidade.

14.12 Pensamento final

A era dos agentes produzirá muitas demonstrações espetaculares.

Algumas delas serão úteis.

Muitas também confundirão atividade com progresso.

Dez agentes podem conversar por vinte minutos e não produzir nada que um humano possa enviar com segurança.

Um agente pode resolver um problema difícil com um bom plano e um teste real.

O problema de engenharia interessante, portanto, não é:

Quantos agentes eu posso fazer colaborar?

É:

Que informação deve sobreviver de uma etapa para a outra para que o sistema possa passar da intenção para a ação respaldada por evidências e, finalmente, para a conclusão verificada?

Esse é o Loop de Criação Iterativa.

A implementação mais simples ainda costuma ser a melhor:

Goal Contract
→ Plan
→ Adversarial Critique
→ Narrow Specialist when needed
→ Checkpoint
→ Deterministic Verification
→ Independent Review
→ Learn

Comece por aí.

Meça isso em comparação com a versão de agente único.

Adicione complexidade somente quando ela trouxer algo que você possa observar.

Essa é a parte que vale a pena escalar.

Não o número de agentes.

A qualidade do loop.

---

Leituras adicionais e fontes primárias

Orquestração de agentes e planejamento

- Cursor — Plan Mode

- Cursor — Ajuda do Plan Mode

- Cursor — CLI

- Claude Code — Subagentes

- Claude Code — Equipes de agentes

- Claude Code — Permissões

- OpenAI Agents SDK

- OpenAI — Orquestração de agentes

- OpenAI — Orquestração multi-agente em JavaScript

- LangChain — Sistemas multi-agente

- LangGraph

- Documentação do CrewAI

- Microsoft — Padrões de orquestração de agentes de IA

- Microsoft Agent Framework — Orquestrações de fluxo de trabalho

- Microsoft Agent Framework — Orquestração magentic

Pesquisa e avaliação multi-agente

- Anthropic — Como construímos nosso sistema de pesquisa multi-agente

- PACT — O que os agentes devem dizer? Comunicação baseada em ação-estado para sistemas multi-agente eficientes

- Por que os sistemas LLM multi-agente falham?

- MultiAgentBench

- Repensando a colaboração multi-agente: quando mais é menos

SEO, busca por IA e acesso à web

- Google — Recursos de IA e seu site

- Google — Otimização para recursos de IA generativa

- Google — Como a Pesquisa funciona

- Google — robots.txt

- Google — Meta tags e atributos

- Google — Políticas de dados estruturados

- Google — Relatórios de desempenho de IA generativa na Pesquisa

- OpenAI — Perguntas frequentes para editores e desenvolvedores

- Anthropic — Web crawlers e robots.txt

- Proposta do llms.txt

Pesquisa e mensuração de GEO

- GEO: Generative Engine Optimization

- Da seleção de citações à absorção de citações

- O que é citado: GEO competitivo em mecanismos de resposta por IA

- Otimizando a visibilidade em mecanismos generativos: Uma análise crítica

- Mind Reader — ACL 2026

- Da experiência à habilidade — Descobertas da ACL 2026

Verificação pré-voo prática

- AuditMe — Auditoria de SEO e Inteligência de Sites

- AuditMe — Verificador de SEO de sites

- AuditMe — Verificador de pontuação de SEO

---

Nota editorial

Este guia separa intencionalmente resultados de engenharia divulgados por fornecedores, descobertas acadêmicas, documentação oficial de produtos e heurísticas práticas.

As métricas dos fornecedores não são benchmarks universais. Os resultados acadêmicos dependem do design do benchmark e das condições experimentais. A documentação do produto descreve o comportamento atual declarado pelo editor, e não todos os resultados possíveis no mundo real. As medições de GEO podem variar de acordo com a consulta, o mecanismo, o conjunto de fontes, o processo de recuperação, o modelo e o tempo.

O experimento mais útil continua sendo o menos glamouroso:

Execute a mesma classe de tarefa com e sem coordenação adicional. Meça o resultado verificado. Mantenha apenas a complexidade que realmente o melhora.