ARTICLE START

Este artigo é sobre uma pequena experiência: ligar a nossa base de dados de recrutamento no Notion ao Claude Code e executar um workflow dinâmico que despacha mais de 100 agentes de IA em paralelo para ler currículos, pontuá-los de acordo com uma grelha de avaliação consistente e verificar cruzadamente os julgamentos uns dos outros — produzindo uma lista curta e ordenada sobre a qual pudéssemos agir de imediato.

O processo todo custou $65 e demorou cerca de 13 minutos a analisar 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 só, como evitar a inflação de pontuações pela IA, e o que significa codificar "excelência" em algo que uma máquina consegue efetivamente executar.

1. O que é um Workflow Dinâmico

Comecemos pelo conceito, porque é a base sobre a qual assenta tudo o resto.

A maior parte do uso de IA hoje segue um padrão de prompt-e-resposta: envia-se uma mensagem, obtém-se uma resposta, itera-se. Isto funciona bem para tarefas pontuais, mas torna-se incómodo quando é preciso fazer o mesmo a 115 objetos — ou se copia e cola 115 vezes, ou pede-se a uma única conversa que os processe sequencialmente, o que se torna mais lento e mais confuso à medida que avança.

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

• Fluxo de controlo determinístico + julgamento de IA, mantidos separados. Ciclos, despacho, agregação e aplicação de quotas são geridos por código (reprodutível, auditável); o julgamento subjetivo (este currículo é suficientemente forte?) é delegado a agentes de IA.
• Paralelismo em leque (fan-out). Uma única chamada parallel(...) pode lançar dezenas ou centenas de agentes independentes em simultâneo, cada um a trabalhar na sua própria fatia sem contaminar os outros.
• Pipelines em múltiplas etapas. O resultado de uma etapa alimenta a seguinte. O código trata da filtragem, ordenação e desduplicação entre etapas.
• Resultado estruturado. Cada agente devolve JSON conforme a um schema — não texto de conversa em formato livre — para que o código a jusante o possa consumir diretamente.

Uma analogia: uma única conversa é como consultar um especialista durante uma tarde. Um workflow dinâmico é como montar um painel de avaliação com 125 pessoas, entregar a cada membro uma grelha de avaliação e um ficheiro de candidato, executar todas as avaliações em paralelo, verificar cruzadamente os melhores resultados e agregá-los numa lista ordenada — com a montagem, o despacho e a lógica de agregação incorporados no script.

A triagem de currículos encaixa naturalmente neste padrão: volume elevado, critérios uniformes, julgamento subjetivo, exigência de equidade.

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

2. O Workflow de Recrutamento: Objetivos e Design

O problema

Tínhamos um ponto de dor concreto: mais de cem candidatos parados no estado de "análise inicial" na nossa base de dados de recrutamento no Notion, sem forma realista de os processar manualmente sem deriva de critério — o nível que se aplica ao currículo 80 quase nunca é o mesmo que se aplica ao currículo 5.

Queria testar uma ideia específica: conseguimos abstrair "o que é excelente na era dos agentes de IA" numa grelha executável por máquina e legível por humanos, e depois processar os 115 candidatos por essa mesma calibração?

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

1. Comprimir 115 candidatos numa lista curta, ordenada e justificada, para que a atenção humana vá para quem realmente a merece.
2. Tornar os critérios transparentes e iteráveis — se o resultado estiver errado, muda-se um ficheiro Markdown, não código nem intuição.

Três decisões de design fundamentais

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

Os critérios de avaliação vivem em ficheiros Markdown autónomos (criteria/), não incorporados no código do workflow. Qualquer pessoa — incluindo colegas não técnicos — pode alterar o comportamento da triagem editando estes ficheiros:

criteria/
├── 00-philosophy.md          Filosofia geral: para que estamos a contratar + a regra "subir a fasquia"
├── 01-pedigree.md            Formação académica sólida / boa base inicial    (peso 20%)
├── 02-ai-agent-fluency.md    Capacidade nativa em 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 topo                         (peso 15%)
└── scoring.md                Fórmula de pontuação + faixas de nota + regra da quota de 5%

Estas quatro dimensões são 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 em IA tem o peso mais elevado (35%). Em 2026, se alguém usa genuinamente ferramentas agênticas como o Claude Code como parte central do seu trabalho é um fator de produtividade determinante. Penalizamos especificamente o "enchimento" de palavras-chave — listar "Claude Code" sem evidência verificável de projetos é tratado como um sinal fraco.
• Evidência concreta de resolução de problemas (30%). Procuramos "cicatrizes": coisas construídas de forma independente a partir do zero, narrativas de superação de obstáculos reais — não reproduções ao nível de tutorial.
• Base sólida (20%). A formação académica serve de indicador do potencial em bruto — é um sinal, não um requisito. Um diploma de uma universidade seletiva associado a um trabalho medíocre é penalizado; um autodidata sem credenciais prestigiadas mas com trabalho real e lançado obtém um bónus.
• Sinal de talento de topo (15%). Esta dimensão é deliberadamente subjetiva. A instrução pergunta: uma equipa como a da Anthropic, ou um fundador como o Musk, iriam querer contactar esta pessoa de imediato? Capta a iniciativa, o bom-gosto e a velocidade que as outras três dimensões não captam.

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

O scoring.md inclui uma regra firme: os candidatos que atingem o nível de topo (S) devem representar ≤ 5% do conjunto total. Depois de concluída toda a pontuação, o código aplica um limite global: mesmo que muitos candidatos pontuem tecnicamente na faixa S, só os melhores 5% podem passar. Isto combate diretamente um modo de falha conhecido — a pontuação por IA é naturalmente permissiva. Sem uma restrição rígida, classificará metade do conjunto como "excelente".

Decisão 3: Adicionar revisão adversarial para detetar pontuações inflacionadas

A pontuação por si só não é suficiente. Um único agente de pontuação pode deixar-se influenciar por palavras-chave impressionantes — "publicado numa revista de topo", "construiu a sua própria framework". Por isso, os candidatos mais bem classificados passam por uma segunda etapa: um painel de agentes "advogado do diabo", cuja função explícita é argumentar contra "esta pessoa merece uma classificação de topo" e reduzir as pontuações sempre que a evidência não as sustente totalmente.

O workflow

Configuração 📋 Base de dados de recrutamento no Notion — extração via Notion CLI → um ficheiro de dados estruturado por candidato

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

• Lê os 6 ficheiros MD de critérios + o ficheiro de dados desse candidato
• Visita ativamente ligações do GitHub / portefólio para verificar evidências
• Devolve JSON estruturado: pontuações em 4 dimensões + raciocínio + destaques + sinais de risco

Código Síntese Determinística

• Calcula os totais ponderados
• Ordenação global por classificação, calcula as vagas da quota 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" analisa cada candidato de topo
• Argumenta contra a designação de nível de topo
• 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

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

As etapas azuis (pontuação / revisão) são de IA. As etapas cinzentas (síntese / veredito) são de código. Esta separação é intencional: tudo o que é matemático — ponderação, ordenação, aplicação de quotas — vai para o código, por razões de reprodutibilidade; tudo o que exige julgamento — esta pessoa é suficientemente forte? — vai para a IA.

3. O Que Observámos: Resultados e Conclusões

Todos os candidatos abaixo foram anonimizados. Descrevemos o tipo de trabalho, não nomes nem detalhes identificativos.

O que executámos

Distribuição

A quota de 5% (5 vagas) não foi usada de todo — não foi a quota que bloqueou ninguém; foi o limiar absoluto de pontuação. Ninguém ultrapassou sozinho o patamar mínimo da faixa A. Mais adiante explicamos por que isso é, na verdade, um sinal útil.

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

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

• #1: Um estudante de pós-graduação que construiu do zero uma bancada de trabalho multi-agente ao estilo Claude Code — incluindo o ciclo principal do agente, análise de chamadas a ferramentas, compressão de contexto, criação de sub-agentes e mecanismos de segurança. Tudo código verificável, não descrições.
• #2: Outro estudante de pós-graduação que tinha implementado um sistema multi-agente real e publicamente acessível (aplicação de domínio vertical), com produção académica sobreposta.
• Mais abaixo: alguém que escreveu um motor de orquestração de agentes em Go a partir 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 tinham em comum: os seus sinais fortes quase nunca apareciam no corpo do currículo — estavam nos repositórios do GitHub e nos portefólios. É exatamente por isso que cada agente de pontuação foi instruído a visitar ativamente as ligações e verificar as evidências, em vez de se limitar a ler o texto do currículo.

Três conclusões

Conclusão 1: A revisão adversarial detetou genuinamente pontuações inflacionadas

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

"Construiu uma bancada de trabalho multi-agente verificável — a capacidade nativa em IA é um sinal forte. Mas o projeto tem cerca de 3 semanas, um único contribuidor, 0 estrelas, sem testes. Conceptualmente é uma reimplementação, não resolução de problemas original. Quase nenhuma evidência de suporte além da linha do diploma: um candidato sólido e de alto potencial, mas não excecional."

"Um construtor genuinamente nativo em IA e verificável. Mas a alegada publicação numa revista de topo só aparece em notas de recrutador, sem fonte independentemente verificável. O backend do sistema principal é privado; não é possível confirmar a contribuição individual. Usar credenciais académicas não verificadas para aspirar ao nível de topo é inflação de pontuação orientada por palavras-chave."

Isto é exatamente o que o design pretendia fazer: não descartou estes candidatos — recuou as pontuações para o que a evidência consegue efetivamente sustentar. Um único agente de pontuação pode deixar-se entusiasmar; um painel de agentes separado, cuja função é contrapor, reduz isso de forma fiável.

Conclusão 2: S:0 / A:0 não é um erro — é um espelho

O primeiro instinto é perguntar se a fasquia foi mal colocada. Mas olhando honestamente para o conjunto:

• Uma grande parte dos candidatos tinha currículos muito escassos — dimensões-chave (experiência em 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 nenhuma ligação ao GitHub.
• O conjunto também continha e-mails comerciais de recrutadores e notificações de sistema do LinkedIn — foram corretamente identificados como irrelevantes e pontuados a 0, o que revelou incidentalmente que a nossa base de dados de recrutamento precisava de limpeza.

Por outras palavras, uma grelha rigorosa separou claramente o sinal do ruído. Os construtores genuínos (top 6) e os "generalistas competentes" (nível intermédio) acabaram em lugares claramente distintos. É esse o objetivo — falhar alguns em vez de inflacionar todos.

Isto também levanta uma questão em aberto que vale a pena discutir: será que o atual limiar da faixa A (78 pontos) é demasiado rigoroso para candidatos que são estudantes com registos fortes 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 manteve-os na faixa B. Se se deve relaxar esse limiar para candidatos de alto potencial em início de carreira é uma decisão de julgamento melhor tomada depois de vermos a qualidade real das entrevistas do grupo B. A boa notícia: essa alteração é um único número num único ficheiro Markdown. Sem necessidade de código.

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

As conversas sobre padrões de contratação costumam manter-se vagas — "queremos pessoas com iniciativa", "alguém capaz de resolver as coisas". Como esta grelha está escrita com pesos e exemplos de referência, a conversa torna-se imediatamente concreta: "A capacidade em IA deve valer 35% ou 40%?" "Quanto ganha realmente um construtor fora da curva sem diploma prestigiado?" "A quota deve ser 5% ou 8%?" — cada desacordo corresponde a uma linha específica num ficheiro Markdown que pode ser alterada, versionada e debatida. O padrão passa a ser um ativo que se mantém, não um consenso que se repete em todas as reuniões.

4. Custo e ROI

Gasto exato

Usámos o Claude Opus 4.8 (nível superior). Detalhe preciso por categoria de tokens:

Isso equivale a cerca de $0,57 por candidato.

Uma descoberta contraintuitiva: a escrita em cache é a maior parcela

O pressuposto natural é que, como os 115 agentes estão todos a ler os mesmos 6 ficheiros de critérios, o cache de prompts devia ajudar bastante. Não ajuda, da forma que se esperaria.

O cache de prompts 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) — pelo que um cache escrito pelo agente A não pode ser aproveitado pelo agente B. O cache ajuda, sim, dentro da própria execução multi-turno de cada agente (ler critérios → visitar GitHub → visitar portefólio → produzir resultado, relendo conteúdo anterior em cada ronda).

Isto revela um compromisso arquitetural: o paralelismo em leque multiplica os custos de escrita em cache (cada agente constrói o seu próprio cache), mas compra julgamento isolado e não contaminado, e elimina a acumulação quadrática de contexto do processamento sequencial. Para tarefas sensíveis à qualidade do julgamento, esse compromisso vale a pena.

Como pensar sobre o ROI

Comparação direta com a revisão manual: um responsável de recrutamento a ler um currículo com atenção, a verificar o GitHub e a escrever notas — conservadoramente, 5 a 10 minutos por candidato. Para 115 candidatos, isso são 10 a 19 horas de trabalho focado, com os padrões a irem sofrendo deriva ao longo do processo.

Este workflow entregou:

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

Poderia ser mais barato?

Sim, mas provavelmente não precisa de o ser. Se isto 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 de topo.

Mas a contratação é de baixa frequência, alto risco e difícil de desfazer. Com $65 para processar todo um pipeline com auditabilidade completa e critérios iteráveis, a conclusão é clara: usar o melhor modelo. Não trocar qualidade de julgamento por poupanças marginais de custo.

O panorama geral

O que é genuinamente entusiasmante nesta experiência não é "a IA consegue fazer triagem de currículos" — isso não é uma ideia nova. É que o modelo de workflow dinâmico — código a orquestrar uma frota de agentes de IA — torna certas categorias de trabalho estruturáveis, reprodutíveis e iteráveis pela primeira vez.

A contratação é apenas o ponto de entrada. O mesmo padrão — critérios como ficheiros legíveis + avaliação paralela em leque + revisão adversarial + agregação determinística — transfere-se para qualquer domínio onde seja preciso fazer julgamentos subjetivos consistentes e de alto volume: moderação de conteúdo, revisão de código, triagem de feedback de utilizadores, análise da concorrência, due diligence.

A grelha é a v0.1. Não é perfeita. Mas é agora um ativo versionado, debatível e melhorá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 esta experiência realmente tratou.