Os 5 Níveis de Agentes de IA: Do Prompt à Produção

Existem cinco palavras que todo mundo está usando quando o assunto são agentes de IA hoje em dia: engenharia de contexto, engenharia de loop, engenharia Jev, engenharia de harness e engenharia de evals.

Parecem cinco abordagens concorrentes. Mas não são. São cinco camadas de um único sistema, e cada uma responde a uma pergunta específica.

A maneira mais fácil de entender isso é imaginar que você acabou de contratar um funcionário novo:

• Contexto — o que está na mesa dele quando você faz uma pergunta
• Loop — se ele segue o seu checklist ou descobre sozinho qual é o próximo passo
• Jev — a recepção que tria a correspondência, para que ele só veja o que realmente importa
• Harness — o escritório dele. As ferramentas, as chaves e quem revisa o trabalho
• Evals — a mesma prova aplicada todo mês, para você saber se ele realmente melhorou

Um agente de IA é esse funcionário. O modelo é a pessoa, e essas cinco camadas são tudo o que existe ao redor dela. Acerte nessas cinco camadas e uma equipe pequena consegue dar conta de um volume de trabalho que antes exigiria novas contratações. O trabalho repetitivo vai para um agente que aguenta o tranco em produção, e sua equipe fica com as decisões. É assim que escalar sem aumentar o quadro de funcionários funciona na prática.

Para cada camada, vou explicar o que é, como funciona, onde usar e como construir.

E, para cada uma delas, também preparei um atalho. Um jeito mais simples de chegar ao mesmo resultado sem precisar construir tudo do zero, pensado para iniciantes. Meus amigos da Viktor me ajudaram a montar esses atalhos.

Viktor é um funcionário de IA que vive no seu Slack ou Microsoft Teams. Ele participa dos mesmos canais que todo mundo e trabalha como um colega de equipe — alguém que você adiciona ao time sem precisar abrir uma nova vaga.

Trabalhar com ele é igual a trabalhar com uma pessoa:

• Você menciona ele em um canal ou thread e descreve a tarefa.
• Ele entende os passos, executa o trabalho nas suas ferramentas e posta o resultado de volta na mesma thread.

A configuração é simples. Basta adicionar o Viktor ao seu workspace, e ele aparecerá como participante, exatamente como qualquer outro membro da sua equipe. Se quiser testar enquanto lê, use o código YARCHI100.

pic1. As cinco camadas de um agente

1. Engenharia de contexto

Definição

Antes de cada pergunta, você coloca papéis na mesa do funcionário. Coloque as três páginas certas ali e ele responde em segundos. Coloque trezentas e a resposta ficará soterrada no meio da pilha. E ele vai deixar passar.

O modelo é o funcionário. A mesa é a janela de contexto: tudo o que o modelo vê antes de responder. Suas instruções, o histórico do chat até ali, documentos puxados de um banco de dados, o resultado de cada ferramenta que ele executou.

Engenharia de contexto é decidir o que vai para a mesa e em qual posição.

Como funciona

Mais contexto não significa respostas melhores. Passado certo ponto, significa respostas piores.

Stanford testou isso diretamente. Dê a um modelo de 20 a 30 documentos e a precisão dele nos que estão no meio cai para algo entre 50% e 57%. Sem nenhum documento, o mesmo modelo acertou 56%. A resposta estava na janela, e o modelo teve um desempenho pior do que se não tivesse nada.

Dois fatores explicam isso:

• Os modelos prestam mais atenção ao início e ao fim da janela, e menos ao meio.
• Cada token custa dinheiro e tempo, quer ajude ou não.

O único mecanismo que vale a pena conhecer aqui é o prompt caching. O provedor armazena o início do seu prompt e o reutiliza na próxima chamada, e um token em cache custa cerca de dez vezes menos que um token novo.

O detalhe: o cache só funciona se esse início for idêntico, byte por byte. Mude um caractere lá no começo e tudo o que vem depois será cobrado a preço cheio. Por isso, a regra é sempre: conteúdo estável primeiro, conteúdo variável por último.

Como construir

Cada pedaço de contexto vai para um destes quatro lugares:

1. System prompt. Apenas o que é verdade em todas as chamadas: papel, restrições, formato de saída. Mantenha byte por byte idêntico. Nada de timestamps no topo ou chaves JSON em ordem aleatória.
2. Ferramentas. Não adicione nem remova ferramentas no meio da conversa. Isso quebra o cache e faz o modelo tentar chamar ferramentas que não existem mais. Para restringir uma ferramenta em determinada etapa, bloqueie a chamada, mas mantenha a definição.
3. Disco. Qualquer coisa grande ou de longa duração vai para um arquivo, e apenas o caminho fica na janela. O mesmo vale para uma página web: guarde a URL, descarte o corpo. Descarte o conteúdo, guarde a chave que permite recuperá-lo.
4. Final (tail). A cada poucas etapas, reafirme o objetivo atual perto do final do contexto. Você não consegue consertar o meio, então mantenha o que importa fora dele.

Ferramentas também têm limite. A Anthropic mediu que 58 definições de ferramentas consumiam cerca de 55.000 tokens antes mesmo de o usuário digitar uma palavra. Permitir que o modelo buscasse as ferramentas em vez de carregar todas fez o Opus 4 saltar de 49% para 74% no benchmark deles.

Menos de 20 ferramentas? Mantenha carregadas. Mais que isso? Mude para busca.

Mais um truque para tarefas grandes: envie um subagente. Ele lê os 50 arquivos na própria janela e devolve um resumo de uma página. Seu contexto principal só enxerga o resumo.

pic2. O que entra em uma única chamada de modelo

Atalho

O Viktor tira a maior parte disso das suas costas, porque o contexto dele existe no nível da empresa.

• Memória. Ele mantém uma memória persistente do seu negócio para toda a equipe. O que ele aprendeu com seu cofundador na semana passada não precisa ser colado no seu pedido de hoje.
• Fontes conectadas. Com Notion, Google Drive ou HubSpot conectados, você para de colar arquivos no chat. Você diz o nome do documento ou registro e ele lê direto na fonte. É a regra do disco, já pronta para você.
• Skills. Você grava a tela executando uma tarefa uma única vez. Ele transforma a gravação em um procedimento escrito, você corrige e aprova. Daí em diante, aquela instrução fica fixa e revisada, como um bom system prompt.

O que sobra para você fazer:

• Escrever um breve resumo da empresa uma única vez: o que você vende, quem compra, quais números importam e o que ele nunca deve fazer.
• Uma tarefa por thread, deixando claro na primeira mensagem o que significa "concluído".
• Se ele aprendeu algo errado, limpe a memória dele nas configurações em vez de corrigi-lo em cada thread.

2. Engenharia de loop

Definição

Você pode dar ao funcionário um checklist: abra o arquivo, altere a linha 12, salve. Ou pode dar um objetivo: faça o teste passar.

Com um objetivo, ele tenta algo, observa o que aconteceu e decide o que fazer em seguida. O checklist é um workflow. O objetivo é um loop.

Como funciona

Um loop são quatro movimentos em repetição: pensar, agir, observar, decidir. Corrigir um bug funciona assim:

1. Rodar os testes. Três falham.
2. Ler o primeiro erro. É um import faltando.
3. Adicionar o import, rodar de novo.
4. Um teste ainda falha. Ler esse erro, corrigir, rodar de novo.
5. Tudo passou. Parar.

Ninguém escreveu esses passos com antecedência. O modelo escolheu cada um depois de ver o resultado anterior.

Essa é toda a diferença. Cem passos que você escreveu continuam sendo um workflow. Três passos que o modelo escolheu formam um loop.

Use um loop apenas quando não for possível escrever os passos com antecedência. Se puder escrevê-los, escreva. Um workflow é mais barato, roda em paralelo e, quando a etapa quatro falha, você refaz só a etapa quatro, não tudo.

Loops também são caros. Um agente usa cerca de quatro vezes mais tokens que uma chamada única. Configurações multiagente chegam a quinze vezes mais.

Como construir

Um loop precisa de quatro partes. Tire qualquer uma e ele para de funcionar:

1. Um objetivo com um "pronto" claro. Não "corrija o bug". Em vez disso: "o teste que está falhando em auth_test.py passa e nada mais quebrou."
2. Um verificador. Algo fora do modelo que diga aprovado ou reprovado: uma suíte de testes, um compilador, um linter. As pesquisas sobre autocorreção são consistentes nisso: funciona com feedback externo real e falha quando o modelo apenas revisa a si mesmo. Sem verificador, não há loop, só gasto sem fim.
3. Uma regra de parada. O verificador aprova, ou você atinge o limite de turnos, ou as duas últimas tentativas geraram o mesmo resultado.
4. Um orçamento. De turnos e de dinheiro, ambos.

No código, tudo isso cabe em algumas linhas:

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # concluído
7    if repeated(history, 2):  break   # travou
8    if spent() > BUDGET:      break   # caro demais
9else:
10    fallback_workflow(goal)

A melhor configuração de produção que já vi publicada é híbrida. A Atlan roda um filtro determinístico primeiro, e apenas cerca de 14% dos alertas recebidos chegam de fato ao agente.

O loop então tem no máximo três ciclos. Se a confiança ainda estiver abaixo de 50% após três, um workflow fixo em Python assume o controle.

Filtre primeiro, faça o loop rapidamente, tenha um plano B.

pic3. Como decidir entre um workflow e um loop

Atalho

Toda tarefa que você dá ao Viktor em uma thread é um loop. Você escreve o objetivo, ele escolhe os passos, trabalha nas suas ferramentas e volta à thread com o resultado.

As quatro partes se encaixam assim:

• Objetivo. Ele questiona briefings incompletos e pergunta em vez de chutar. Ainda assim, defina o que é "pronto". "Relatório de receita da semana passada, totais batendo com o Stripe, postado em #finance até as 9h de segunda" é muito melhor que "faça o relatório".
• Verificador. Ele sinaliza números estranhos antes de postar. Torne isso mais forte indicando a fonte de comparação: o total do Stripe, a contagem de linhas, a suíte de testes.
• Regra de parada. Ações sensíveis pausam para aprovação humana, e o resultado sempre volta para você.
• Orçamento. Créditos. O tier de raciocínio define o preço de cada passo e, em tarefas recorrentes, a frequência importa. Um relatório horário custa bem mais que um semanal.

O modelo híbrido da Atlan funciona sem código também. O trabalho que se repete vira uma tarefa agendada: ele propõe, e ela fica pausada até você aprovar. Esse é o seu workflow.

Qualquer coisa aberta vai para uma thread, e esse é o seu loop. Você é o plano B.

3. Engenharia Jev

Definição

O especialista de um escritório não abre todos os envelopes. Alguém na recepção separa a correspondência: contas numa pilha, spam no lixo, contratos para o advogado.

Seu agente faz dois tipos de trabalho: escrever algo e decidir algo. Hoje, um único modelo grande faz as duas coisas, então você está pagando o advogado para separar a correspondência.

Jev é a recepção. Ele nunca escreve. Só escolhe.

Como funciona

Você dá ao Jev uma pergunta e as possíveis respostas com antecedência. Ele retorna uma de três coisas, além de uma pontuação de confiança:

• sim ou não
• uma opção dentro de um conjunto
• um número em uma escala

Como ele apenas escolhe, é rápido e barato. Os números divulgados são de 70 a 500 milissegundos contra 3 a 329 segundos, e US$ 0,042 por milhão de tokens de entrada, com a saída gratuita.

Agora, a parte honesta. O Jev tem duas semanas de vida e os testes independentes estão apenas começando a sair.

• Na classificação de e-mails, uma regressão logística básica marcou 98,9% contra 98,6% do Jev.
• Na detecção de phishing, o Jev ficou com 62,6%, enquanto o Claude Haiku 4.5 alcançou 81,3%.
• O número de "zero alucinações" vem com a própria nota de rodapé dos autores: não é empírico, significa apenas que a saída sempre corresponde ao schema.

A pontuação de confiança também não é uma probabilidade real logo de cara. Trate-a como um ranking e defina seus próprios limites com base nos seus dados rotulados.

Como construir

A configuração mais sensata é um portão na frente do modelo caro:

1. Tudo chega.
2. O Jev responde a uma pergunta bem específica sobre cada item.
3. Confiante e rotineiro: resolvido de forma barata. Rotulado, direcionado ou descartado.
4. Incerto ou incomum: vai para o modelo principal.

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # fail closed: incerteza vai para o caminho caro

Antes de tudo isso, tente a solução mais simples que poderia funcionar. Rotule algumas centenas de exemplos reais, treine um classificador básico e só avance se não for bom o suficiente.

Isso leva trinta minutos de trabalho e é a linha de base que qualquer promessa de fornecedor precisa superar.

pic4. Os três tipos de perguntas que o Jev responde

Atalho

O Jev não faz parte do stack publicado do Viktor, mas a ideia se aplica em dois lugares que você controla:

• O tier de raciocínio. Ele roda em três: Smart no Claude Opus, Balanced no Claude Sonnet por cerca de metade do custo, e Ultra no Claude Fable pelo dobro. Separar solicitações ou extrair um único número não exige o tier mais alto.
• O portão na frente dele. Se quiser que ele lide com um fluxo como e-mails de suporte ou alertas, não entregue o fluxo inteiro. Coloque um classificador ou uma chamada Jev antes, para que apenas os itens que exigem julgamento virem tarefas para ele.

Esta é uma das duas camadas em que a sua própria engenharia ainda faz diferença, mesmo com o Viktor.

4. Engenharia de harness

Definição

Mesmo funcionário, dois escritórios. No primeiro, ele tem as ferramentas certas, um manual na parede, um colega que revisa seu trabalho e nenhuma chave do cofre. No segundo, ele tem um notebook e a sua senha de administrador.

Mesmas habilidades, resultados completamente diferentes. O funcionário é o modelo. O escritório é o harness.

Agente = modelo + harness.

Como funciona

O harness é tudo o que não é o modelo: ferramentas, permissões, sandbox, arquivos que explicam o projeto, verificações na saída.

Virou uma disciplina própria em 2026 porque as pessoas começaram a medir, e o modelo explicava menos do que se esperava:

• A Anthropic mudou apenas os recursos do container e deslocou a pontuação de um benchmark em 6 pontos.
• A LangChain congelou o modelo e moveu o mesmo benchmark em 13,7 pontos mudando apenas o harness.
• Depois, ajustaram o harness ao redor de um modelo aberto dez vezes mais barato até ele marcar 0,86 contra 0,87 do Opus 4.8.

Você não está mais comprando um modelo. Está comprando um modelo e um harness juntos.

Você precisa de um no momento em que o agente toca algo real: um repositório, uma caixa de entrada, um pagamento, um banco de dados de produção.

Como construir

Construa de fora para dentro:

1. Contenção. Aquilo que o agente fisicamente não consegue alcançar. Um container, uma branch separada, um usuário de banco somente leitura, sem rede exceto uma allowlist. Faça isso antes do primeiro prompt.
2. Guias. O que orienta o agente antes de ele agir. Um arquivo no repositório como AGENTS.md, descrições de ferramentas claras o suficiente para o modelo escolher a certa, alguns exemplos de boas saídas.
3. Sensores. O que verifica o agente depois de ele agir. Linter, verificador de tipos, suíte de testes: rápidos e determinísticos, então rode em tudo. Verificações mais lentas, como um segundo modelo revisando um diff, apenas no que realmente importa.
4. Permissões. Quando agentes pedem aprovação, as pessoas aprovam 93% das vezes. O prompt de aprovação protege quase nada. A proteção real são as ações que simplesmente não estão disponíveis. Guarde a aprovação para as poucas coisas que são genuinamente irreversíveis.

Um arquivo de guia não precisa ser longo. Quatro linhas já mudam o comportamento:

1# AGENTS.md
2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Rode os testes com `make test`. Eles precisam passar antes de qualquer commit
4- Nunca edite /migrations manualmente, use `make migration`
5- Acesso ao BD é somente leitura. Pergunte antes de qualquer mudança de schema

Hooks são a versão compulsória dessa mesma ideia. No Claude Code, um hook é um pequeno script que roda antes de uma chamada de ferramenta e pode bloqueá-la. "Nunca faça push para a main" funciona como um hook, não como uma linha no prompt.

Um aviso. Cada peça do seu harness é uma aposta de que o modelo não consegue fazer algo, e essas apostas expiram. A Anthropic deletou um componente inteiro de scaffolding depois que uma atualização do modelo o tornou desnecessário.

Revise seu harness a cada poucos meses e apague aquilo que o modelo já superou.

pic5. Os quatro anéis de um harness

Atalho

Se agente = modelo + harness, a maior parte do que você ganha com o Viktor é harness. O modelo por baixo é o Claude. Tudo ao redor do modelo já vem pronto:

• Ferramentas. Mais de 3.200 integrações: GitHub, Linear, HubSpot, Stripe, Notion, Google Drive e muito mais. Para uma ferramenta sem conexão pronta, ele mesmo pode construir uma.
• Guias. Skills. Em vez de escrever o AGENTS.md você mesmo, você grava a tela, ele rascunha o procedimento e você edita.
• Sensores. Ele sinaliza dados que não batem e questiona briefings com peças faltando. E cada passo vai parar em uma thread do Slack que sua equipe pode ler.
• Permissões. E-mails de clientes e alterações financeiras pausam para aprovação. Novas automações agendadas ficam pausadas até alguém ativá-las.

A parte que nenhum produto pode construir por você é a contenção, porque ela é feita das credenciais que você entrega. Lembre-se dos 93% e conecte-o com o mínimo de acesso necessário para o trabalho:

• um usuário de banco de dados somente leitura
• uma chave restrita do Stripe
• uma caixa de entrada de suporte compartilhada, não a sua pessoal
• um token do GitHub com escopo para repositórios específicos

O que ele não consegue alcançar, ele não consegue quebrar.

pic6. O harness do Viktor

5. Engenharia de evals

Definição

Como você sabe se um funcionário novo melhorou? Aplica nele a mesma prova do mês passado e compara.

Sem a mesma prova, toda mudança que você faz é um chute. Evals são essa prova para o seu agente: um conjunto de tarefas cuja resposta certa você já conhece, executadas toda vez que você muda algo.

Como funciona

Existem dois tipos de verificação:

• End to end. A resposta final saiu correta? Diz que a nota mudou, mas não o porquê.
• Comportamental. Uma ação específica aconteceu? Ele chamou a busca antes de responder? Fez uma pergunta de esclarecimento quando o pedido estava vago? Verificou antes de dizer que terminou?

As verificações comportamentais rodam no trace, o log de tudo o que o agente fez, e não apenas na resposta final. A regra do Google é que essa suíte deve terminar em menos de cinco segundos, para poder rodar a cada alteração.

Se um modelo faz a correção, ele é um juiz, e o juiz também precisa ser verificado. O Airbnb descobriu que cerca de três quartos das respostas de referência geradas por modelo mudavam em execuções repetidas do mesmo input. O eval deles estava medindo o próprio ruído.

Como construir

1. Comece pelas falhas reais. Revise execuções de verdade, encontre o que deu errado, transforme cada caso em um teste. Os golden sets do Airbnb rodam de 50 a 100 exemplos, e as falhas são obrigatórias.
2. Escreva uma verificação comportamental por caso. Um caso, uma coisa para verificar.
3. Teste seu juiz. Corrija uma amostra manualmente e veja com que frequência você e o modelo concordam antes de confiar nele.
4. Amostre a produção. O Airbnb extrai 5% do tráfego ao vivo todos os dias. Seu conjunto de evals perde validade conforme o uso real se afasta dele.

Um único caso pode ser bem pequeno:

1input: "Reembolsar pedido #1042, cliente diz que chegou quebrado"
2expect:
3  - consulta o pedido antes de responder
4  - pede aprovação antes de emitir o reembolso
5check:
6  - trace tem get_order antes de send_reply
7  - trace tem approval_request antes de refund

Não fique olhando apenas a taxa geral de aprovação. Ela pode subir enquanto um comportamento específico quebra silenciosamente. Acompanhe as verificações individuais.

pic7. De onde vêm os bons casos de eval

Atalho

Nenhum produto pode entregar essa camada por você, porque só você sabe qual é a resposta certa para o seu negócio. Mas o método se aplica diretamente:

• Depois de duas semanas, escolha 20 threads dele em que você saiba a resposta correta. Inclua todas aquelas em que precisou corrigi-lo.
• Escreva uma verificação simples por caso. Ele citou a fonte de cada número? Perguntou quando o briefing estava vago? Pausou antes de qualquer coisa sair da empresa?
• Rode o conjunto novamente após cada mudança: uma nova skill, um briefing editado, um tier diferente. Mudar de Smart para Balanced economiza cerca de metade dos créditos, então teste antes de trocar de vez.
• Uma vez por semana, corrija cinco threads aleatórias manualmente.

Juntando tudo

Cinco camadas, cinco perguntas. Contexto é o que ele vê. Loop é quem decide. Jev cuida das decisões baratas. Harness é o que ele consegue alcançar e quem o verifica. Evals são como você descobre se está funcionando.

Com o Viktor, três delas já vêm praticamente prontas: contexto, loop e harness. Jev, evals e as credenciais que você entrega continuam sendo responsabilidade da sua engenharia.

Se você está começando hoje, a ação útil mais barata para cada uma:

• Contexto: mova suas instruções estáveis para o system prompt e pare de alterá-las.
• Loop: coloque um limite de turnos e um limite em dólares antes de deixar rodando.
• Jev: rotule 200 exemplos daquilo que seu agente decide com mais frequência.
• Harness: rode seu agente como um usuário que não pode deletar nada.
• Evals: anote suas últimas cinco falhas como casos de teste.

No Viktor, esse mesmo dia seria assim:

• Contexto: escreva o resumo da empresa e grave sua primeira skill.
• Loop: coloque uma definição de "pronto" em cada tarefa e escolha o tier de propósito.
• Jev: filtre qualquer fluxo antes que ele vire tarefas para ele.
• Harness: conecte-o com credenciais de escopo restrito e somente leitura.
• Evals: salve 20 threads reais como seu primeiro conjunto de testes.

Isso é um dia de trabalho e cobre todas as cinco.

Minha visão: o modelo não é mais a parte difícil. As cinco camadas ao redor dele são. Acerte nelas e você aumenta a capacidade sem aumentar o quadro de funcionários. A maioria das equipes deveria pegar as três primeiras prontas na prateleira e gastar seu próprio tempo nas duas que definem a qualidade: as decisões baratas e os evals.

Obrigado, Viktor, por patrocinar este artigo.

Teste grátis em @viktor_com. US$ 100 em créditos, sem cartão. Link completo na minha primeira resposta.

Use o código YARCHI100 ao se cadastrar.

Parceria Paga