← Voltar aos artigos
Série Harness e agentes de IA · Parte 1 de 4

Harness multiagente: o que eu de fato construí (não só o nome)

"Harness" virou bandeira antes de virar prática, inclusive na minha própria mão. Esta é a história do que eu montei, do que deu errado e do que aprendi, e o ponto de partida de uma série que aprofunda cada parte.

Multiagente Harness Engenharia com IA Experiência

No artigo anterior eu citei "harness" como exemplo de termo que vira bandeira antes de virar prática: gente discutindo vocabulário como se dominar o nome certo já resolvesse alguma coisa. Prometi contar o que eu mesmo estava fazendo a respeito. Este texto é essa outra metade, a história. E é também a porta de entrada de uma série que aprofunda cada parte do assunto.

Ilustração de agentes especializados conectados a um orquestrador central
Ilustração de agentes especializados conectados a um orquestrador central
📖
Harness, em uma frase

Tudo o que existe em volta do modelo de IA para transformá-lo em um agente que trabalha de verdade: as ferramentas que ele pode usar, as regras que ele segue e as verificações que barram o erro. O modelo sozinho só gera texto; o harness o transforma em trabalho.

O problema que me fez construir isso

IA generativa escrevendo código sem contexto do projeto, sem arquitetura combinada, sem ninguém checando se o que saiu bate com o que foi pedido. O código sai rápido, mas sem direção, porque ninguém definiu antes o que "certo" significava ali.

A resposta que fui construindo não foi "usar mais IA" nem "usar uma IA melhor". Foi estruturar o processo em volta dela: dar papel, dar gate, dar critério de aprovação antes de deixar a próxima fase começar.

O que eu construí

Não é um agente genérico tentando fazer tudo. São papéis especializados, cada um com escopo fechado (analista, arquiteto, dev backend e frontend, QA, revisor de código) e um crítico que não produz nada: só existe para questionar o que os outros produziram antes de a próxima fase começar.

Diagrama
flowchart LR
    A([Specify]) --> B{{Critique}}
    B --> C([Design])
    C --> D{{Critique}}
    D --> E([Tasks])
    E --> F([Implement])
    F --> G{{Critique}}
    G --> R([Code Review])
    R --> H([Validate])
    H --> I([Quality Report])
    

Cada losango é um ponto onde o trabalho pode ser barrado e devolvido. Nenhuma fase avança por omissão. E nem toda mudança passa por tudo isso: uma correção pequena e isolada segue direto para a implementação.

A regra que mais importa em todo o desenho: quem produz nunca é quem valida. O revisor encontra, não corrige; a correção volta para quem implementou, passa por um validador, e só então o mesmo revisor confirma item a item.

O que aprendi (e onde cada tema é aprofundado)

Nada disso nasceu junto. Foi entrando um item por vez, geralmente depois de ver o anterior falhar sozinho. As lições que mais pesaram:

As armadilhas de virar bandeira

Já vi, e já cometi, usar o nome sem o cuidado por trás: copiar a estrutura sem entender por que cada gate existe, empilhar revisões sem build ou teste real checando nada, tratar o fluxo completo como obrigatório para qualquer mudança, achar que o processo substitui entender o problema de negócio.

Um cenário comum: o time adota "harness" como palavra de ordem, monta agentes com nomes bonitos, e nas primeiras semanas a entrega até parece mais organizada. Meses depois, ninguém lembra por que o gate de crítica existe, ele vira etapa que todo mundo aprova sem ler, e o processo que devia pegar erro cedo só atrasa a entrega. Pior que não ter processo, porque agora há falsa sensação de segurança.

Onde isso ainda é experimento

Não existe fórmula que substitua julgamento. Os scores ajudam a sinalizar padrão, mas não decidem sozinhos se algo está pronto. E a base de conhecimento que alimenta esse processo depende de alguém escrever e curar: não se atualiza sozinha.

É ferramenta que estou construindo e ajustando, não fórmula pronta. O que é o mesmo alerta do artigo anterior: nomenclatura nova não é competência nova. E é ferramenta que precisa continuar sendo ajustada para continuar valendo o que custa.

💡
Em breve, mais artigos

Vamos publicar novos artigos, cada um aprofundando um ponto estratégico deste tema. Se houver algum que você gostaria de ver primeiro, me diga.

Série: Harness e agentes de IA · 4 partes
  1. 1
    O que eu construíA história por trás: o problema, o fluxo que montei e as armadilhas de usar harness como bandeira.Você está aqui
  2. 2
    Harness de IAA base conceitual: anatomia, harness da ferramenta contra o seu, níveis de maturidade e custo de manter.
  3. 3
    Multiagente na práticaQuando usar vários agentes, padrões de organização, um exemplo completo e os modos de falha.
  4. 4
    Como medir o harnessAs três camadas de medição e uma versão mínima para começar em uma tarde.
💬
Quer trocar ideia sobre isso? Se você tem uma experiência parecida — ou uma forma diferente de estruturar isso — me manda uma mensagem no LinkedIn ou fale comigo por aqui.