Este post trata de um pequeno experimento: conectar nosso banco de dados de contratação do Notion ao Claude Code e executar um fluxo de trabalho dinâmico que despacha mais de 100 agentes de IA em paralelo para ler currículos, pontuá-los com base em uma rubrica consistente e verificar cruzadamente os julgamentos uns dos outros — produzindo uma lista classificada e reduzida sobre a qual pudéssemos agir imediatamente.

A coisa toda custou US$ 65 e levou cerca de 13 minutos para processar 115 candidatos. Mas mais interessante do que o custo foram as questões metodológicas que surgiram — quando usar uma frota de agentes em vez de um único, como evitar a inflação de pontuação da IA e o que significa codificar "excelência" em algo que uma máquina consiga executar de fato.

1. O Que É um Fluxo de Trabalho Dinâmico

Vamos começar pelo conceito, porque é a base sobre a qual tudo o resto se sustenta.

A maior parte do uso de IA hoje segue um padrão de prompt-e-resposta: enviar uma mensagem, receber uma resposta, iterar. Isso funciona bem para tarefas pontuais, mas fica estranho quando você precisa fazer a mesma coisa com 115 objetos — ou você fica copiando e colando 115 vezes, ou pede a uma única conversa para processá-los sequencialmente, o que fica mais lento e ruidoso à medida que avança.

Um fluxo de trabalho dinâmico é um modelo diferente: código que orquestra uma frota de agentes de IA. Suas propriedades definidoras são:

• Fluxo de controle determinístico + julgamento de IA, mantidos separados. Loops, despacho, agregação e aplicação de cotas são tratados pelo código (reproduzível, auditável); o julgamento subjetivo (este currículo é forte o suficiente?) é delegado a agentes de IA.
• Paralelismo por fan-out. Uma única chamada parallel(...) pode ativar dezenas ou centenas de agentes independentes simultaneamente, cada um trabalhando em sua própria fatia sem contaminar os outros.
• Pipelines de múltiplos estágios. A saída de um estágio alimenta o próximo. O código lida com filtragem, classificação e deduplicação entre os estágios.
• Saída estruturada. Cada agente retorna JSON em conformidade com um schema — não texto de chat livre — para que o código posterior possa consumi-lo diretamente.

Uma analogia: uma única conversa é como consultar um especialista por uma tarde. Um fluxo de trabalho dinâmico é como montar um painel de revisão com 125 pessoas, entregar a cada membro uma rubrica e um arquivo de candidato, executar todas as revisões em paralelo, verificar cruzadamente os melhores resultados e agregar tudo em uma lista classificada — com a lógica de montagem, despacho e agregação embutida no script.

A triagem de currículos é uma combinação natural para esse padrão: alto volume, critérios uniformes, julgamento subjetivo, requisito de justiça.

Para uma introdução técnica mais aprofundada: A harness for every task: dynamic workflows in Claude Code

2. O Fluxo de Trabalho de Contratação: Objetivos e Design

O problema

Tínhamos um ponto de dor concreto: mais de cem candidatos parados no status "revisão inicial" em nosso banco de dados de contratação do Notion, sem uma forma realista de processá-los manualmente sem deriva de padrão — a barra que você aplica no currículo 80 quase nunca é a mesma barra do currículo 5.

Eu queria testar uma ideia específica: conseguimos abstrair "como é a excelência na era dos agentes de IA" em uma rubrica executável por máquina e legível por humanos, e então processar todos os 115 candidatos com a mesma calibração?

O objetivo explicitamente não era fazer a IA tomar decisões de contratação. O objetivo era:

1. Comprimir 115 candidatos em uma lista classificada e justificada para que a atenção humana vá para as pessoas que realmente a merecem.
2. Tornar os critérios transparentes e iteráveis — se a saída estiver errada, você altera um arquivo Markdown, não código ou instinto.

Três decisões-chave de design

Decisão 1: Critérios e código são completamente separados

Os critérios de avaliação vivem em arquivos Markdown independentes (criteria/), não embutidos no código do fluxo de trabalho. Qualquer pessoa — inclusive colegas não técnicos — pode alterar o comportamento de triagem editando esses arquivos:

criteria/
├── 00-philosophy.md          Filosofia geral: o que estamos contratando + a regra "elevar a barra"
├── 01-pedigree.md            Base acadêmica / inicial forte    (peso 20%)
├── 02-ai-agent-fluency.md    Capacidade nativa de IA                  (peso 35%)
├── 03-grit-problem-solving.md  Resolução de problemas & superação de dificuldades  (peso 30%)
├── 04-talent-lens.md         Sinal de talento de ponta                     (peso 15%)
└── scoring.md                Fórmula de pontuação + faixas de nota + regra de cota de 5%

Essas quatro dimensões são nosso "padrão de excelência para a era dos agentes de IA, v0.1". O raciocínio por trás de cada uma:

• A capacidade nativa de IA carrega o maior peso (35%). Em 2026, se alguém realmente usa ferramentas agênticas como o Claude Code como parte central de como trabalha é um grande divisor de produtividade. Nós penalizamos especificamente o "empilhamento de palavras-chave" — listar "Claude Code" sem evidência verificável de projeto é tratado como um sinal fraco.
• Evidência concreta de resolução de problemas (30%). Buscamos "cicatrizes": coisas construídas de forma independente do zero, narrativas de superação de obstáculos reais — não reproduções em nível de tutorial.
• Base sólida (20%). A formação acadêmica serve como um proxy para potencial bruto — é um sinal, não um requisito. Um diploma de universidade seletiva combinado com produção medíocre é penalizado; um construtor autodidata sem credencial de prestígio, mas com trabalho real entregue, recebe um impulso.
• Sinal de talento de ponta (15%). Essa dimensão é deliberadamente subjetiva. O prompt pergunta: uma equipe como a da Anthropic ou um fundador como Musk gostariam de entrar em contato imediatamente? Ela captura agência, bom gosto e velocidade que as outras três dimensões não capturam.

Decisão 2: Codificar "elevar a barra" como uma restrição rígida, não um slogan

scoring.md inclui uma regra firme: candidatos que alcançam o nível mais alto (S) devem ser ≤ 5% do conjunto completo. Depois que toda a pontuação é concluída, o código aplica um limite global: mesmo que muitos candidatos tecnicamente pontuem na faixa S, apenas os 5% melhores têm permissão para passar. Isso combate diretamente um modo de falha conhecido — a pontuação por IA é naturalmente permissiva. Sem uma restrição rígida, ela classificará metade do conjunto como "excelente".

Decisão 3: Adicionar revisão adversarial para detectar pontuações infladas

A pontuação por si só não é suficiente. Um único agente de pontuação pode se deixar levar por palavras-chave que soam impressionantes — "publicado em periódico de ponta", "construí meu próprio framework". Então, os candidatos mais bem classificados passam por uma segunda etapa: um painel de agentes "advogado do diabo" cujo trabalho explícito é argumentar contra "esta pessoa merece uma classificação de nível superior" e reduzir as pontuações sempre que a evidência não sustentar totalmente a classificação.

O fluxo de trabalho

Configuração 📋 Banco de dados de contratação do Notion — Notion CLI pull → um arquivo de dados estruturado por candidato

IA Fase 1: Pontuação (115 agentes em paralelo)

• Lê 6 arquivos MD de critérios + o arquivo de dados daquele candidato
• Visita ativamente links do GitHub / portfólio para verificar evidências
• Gera JSON estruturado: pontuações em 4 dimensões + raciocínio + destaques + sinalizações de risco

Código Síntese Determinística

• Calcula totais ponderados
• Ordenação global por classificação, calcula as vagas da cota de 5%
• Seleciona os melhores candidatos para a fila de revisão adversarial

IA Fase 2: Revisão Adversarial (Agentes em paralelo)

• Persona "advogado do diabo" revisa cada candidato do topo
• Argumenta contra a designação de nível superior
• Reduz pontuações onde a evidência é insuficiente

Código Veredito Determinístico

• Reordena usando as pontuações calibradas
• Aplica o limite rígido de 5%
• Atribui as faixas de nota finais: S / A / B / C / D

Saída: Relatório Classificado Markdown estruturado com pontuações por candidato, raciocínio e veredito da revisão adversarial

Estágios azuis (pontuação / revisão) são de IA. Estágios cinza (síntese / veredito) são de código. Essa divisão é intencional: tudo que é matemático — ponderação, classificação, aplicação de cotas — vai para o código para reprodutibilidade; tudo que exige julgamento — esta pessoa é forte o suficiente? — vai para a IA.

3. O Que Vimos: Resultados e Percepções

Todos os candidatos abaixo foram anonimizados. Descrevemos o tipo de trabalho, não nomes ou detalhes identificáveis.

O que executamos

Distribuição

A cota de 5% (5 vagas) ficou completamente sem uso — não foi a cota que bloqueou ninguém; foi o limite absoluto de pontuação. Ninguém ultrapassou o piso da faixa A por conta própria. Mais sobre por que isso é, na verdade, um sinal útil abaixo.

Como era o topo da classificação (anonimizado)

Sem exceção, os candidatos mais bem classificados eram pessoas que realmente construíram agentes — não pessoas que tinham ouvido falar sobre IA:

• #1: Um estudante de pós-graduação que construiu do zero uma bancada de trabalho multiagente no estilo Claude Code — incluindo o loop principal do agente, análise de chamadas de ferramenta, compressão de contexto, criação de subagentes e mecanismos de segurança. Todo código verificável, não apenas descrições.
• #2: Outro estudante de pós-graduação que havia implantado um sistema multiagente real e publicamente acessível (aplicação de domínio vertical), com produção acadêmica agregada.
• Mais abaixo: alguém que escreveu um mecanismo de orquestração de agentes em Go do zero; alguém que lançou um agente de codificação leve estudando a arquitetura do Claude Code; alguém que construiu independentemente um jogo com um LLM local em sete dias, usando ferramentas de IA em todo o processo.

O que eles tinham em comum: seus sinais fortes quase nunca apareciam no corpo do currículo — estavam em repositórios do GitHub e portfólios. É exatamente por isso que cada agente de pontuação foi instruído a visitar ativamente os links e verificar as evidências em vez de apenas ler o texto do currículo.

Três percepções

Percepção 1: A revisão adversarial de fato detectou pontuações infladas

O exemplo mais claro foi o dos dois primeiros candidatos. Após a fase de pontuação, ambos tinham totais ponderados em torno de 82 pontos — o suficiente para entrar na faixa A e roçar o limite de S. Após a revisão adversarial, ambos ficaram em torno de 75 pontos, com um raciocínio bem específico:

"Construiu uma bancada de trabalho multiagente verificável — a capacidade nativa de IA é um sinal concreto. Mas o projeto tem ~3 semanas, um único colaborador, 0 estrelas, sem testes. Conceitualmente é uma reimplementação, não resolução de problemas original. Quase nenhuma evidência de apoio além da linha do diploma: um candidato sólido e de alto potencial, mas não excepcional."

"Um construtor genuíno e verificável nativo de IA. Mas a publicação alegada em periódico de ponta aparece apenas em anotações de recrutador, sem fonte independentemente verificável. O backend do sistema principal é privado; a contribuição individual não pode ser confirmada. Usar credenciais acadêmicas não verificadas para alcançar o nível superior é inflação de pontuação impulsionada por palavras-chave."

Isso é exatamente o que o design pretendia fazer: não descartou esses candidatos — recuou as pontuações para o que a evidência consegue de fato sustentar. Um único agente de pontuação pode se deixar levar; um painel de agentes separado, cujo trabalho é contestar, reduz isso de forma confiável.

Percepção 2: S:0 / A:0 não é um bug — é um espelho

O primeiro instinto é perguntar se a barra foi definida de forma errada. Mas olhando o conjunto com honestidade:

• Uma grande fração dos candidatos tinha currículos muito escassos — dimensões-chave (experiência com IA, trabalho verificável) simplesmente ausentes.
• Muitos candidatos a funções de Agent Engineer tinham zero evidência de uso de ferramentas agênticas e nenhum link do GitHub.
• O conjunto também continha e-mails comerciais de recrutadores e notificações do sistema do LinkedIn — esses foram corretamente identificados como irrelevantes e pontuados com 0, o que, de quebra, revelou que nosso banco de dados de contratação precisava de limpeza.

Em outras palavras, uma rubrica rigorosa separou de forma clara o sinal do ruído. Os construtores reais (os 6 do topo) e os "generalistas realizados" (nível médio) acabaram em lugares claramente distintos. Esse é o objetivo — deixar passar alguns em vez de inflar todos.

Isso também levanta uma questão em aberto que vale a pena discutir: o limite atual da faixa A (78 pontos) é rigoroso demais para candidatos que são estudantes com bons históricos no GitHub, mas ainda sem trajetória profissional? Curiosamente, os próprios agentes de revisão adversarial descreveram os dois primeiros como "candidatos de alto potencial" — mas a pontuação ponderada os manteve na faixa B. Se esse limite deve ser relaxado para candidatos de alto potencial em início de carreira é uma decisão de julgamento melhor tomada depois que virmos a qualidade real das entrevistas do grupo B. A boa notícia: essa mudança é um único número em um único arquivo Markdown. Nenhum código necessário.

Percepção 3: "Critérios como código" torna o desacordo produtivo

Conversas sobre padrões de contratação normalmente permanecem vagas — "queremos pessoas com iniciativa", "alguém que consiga resolver as coisas". Como essa rubrica está escrita com pesos e exemplos de ancoragem, a conversa fica imediatamente concreta: "A capacidade de IA deveria ser 35% ou 40%?" "Quanto um construtor fora da curva sem diploma de prestígio realmente ganha?" "A cota deveria ser 5% ou 8%?" — todo desacordo corresponde a uma linha específica em um arquivo Markdown que pode ser alterada, versionada e debatida. O padrão se torna um ativo que você mantém, não um consenso que você repete em cada reunião.

4. Custo e ROI

Gasto exato

Usamos o Claude Opus 4.8 (nível superior). Detalhamento preciso por categoria de token:

Isso equivale a aproximadamente $0,57 por candidato.

Uma descoberta contraintuitiva: as escritas em cache são o maior item da linha

A suposição natural é que, como 115 agentes estão todos lendo os mesmos 6 arquivos de critérios, o cache de prompt deveria ajudar bastante. Não ajuda, da forma que você esperaria.

O cache de prompt funciona por correspondência exata de prefixo, e cada sessão de agente é independente. 125 agentes significam 125 sessões independentes — cada uma com uma descrição de tarefa diferente (dados de candidato diferentes) — então um cache escrito pelo agente A não pode ser acessado pelo agente B. O cache ajuda dentro da própria execução multi-turno de cada agente (ler critérios → visitar GitHub → visitar portfólio → gerar saída, relendo conteúdo anterior a cada rodada).

Isso revela um trade-off arquitetural: o paralelismo por fan-out multiplica os custos de escrita em cache (cada agente constrói seu próprio cache), mas compra julgamento isolado e não contaminado e elimina o acúmulo quadrático de contexto do processamento sequencial. Para tarefas sensíveis à qualidade do julgamento, esse trade-off vale a pena.

Como pensar sobre o ROI

Comparação direta com revisão manual: um gerente de contratação lendo um currículo com cuidado, verificando o GitHub e escrevendo notas — de forma conservadora, de 5 a 10 minutos por candidato. Ao longo de 115, isso é de 10 a 19 horas de trabalho focado, com os padrões oscilando ao longo do processo.

Esse fluxo de trabalho entregou:

Mas o ROI mais importante é atencional: redirecionou o foco humano dos 83 candidatos claramente inadequados para os 6 construtores genuínos no topo. Isso é a coisa de maior valor que uma triagem inicial pode fazer.

Poderia ser mais barato?

Sim, mas provavelmente não precisa ser. Se isso se tornasse uma operação de alta frequência e alto volume (centenas de candidatos por dia), a otimização prática seria:

• Usar o Sonnet para a fase de pontuação, e o Opus apenas para a revisão adversarial — provavelmente uma redução de custo de 70 a 80% com perda mínima de qualidade.
• Ou usar um modelo mais barato para uma primeira triagem grosseira, e depois o Opus para a avaliação detalhada do nível superior.

Mas a contratação é de baixa frequência, alto risco e difícil de desfazer. A $65 para processar um pipeline inteiro com auditabilidade completa e critérios iteráveis, a conclusão é clara: use o melhor modelo. Não troque qualidade de julgamento por economia marginal de custo.

O panorama geral

O que é genuinamente empolgante nesse experimento não é "a IA consegue triar currículos" — isso não é uma ideia nova. É que o modelo de fluxo de trabalho dinâmico — código orquestrando uma frota de agentes de IA — torna certas categorias de trabalho estruturáveis, reproduzíveis e iteráveis pela primeira vez.

A contratação é apenas o ponto de entrada. O mesmo padrão — critérios como arquivos legíveis + avaliação paralela por fan-out + revisão adversarial + agregação determinística — se transfere para qualquer domínio em que você precise fazer julgamentos subjetivos consistentes e de alto volume: moderação de conteúdo, revisão de código, triagem de feedback de usuários, análise competitiva, due diligence.

A rubrica é v0.1. Não é perfeita. Mas agora é um ativo versionado, debatível e aprimorável — não um acordo implícito que vive na cabeça de alguém. Essa mudança, mais do que qualquer resultado individual, é do que esse experimento realmente tratou.