Crie o Sistema Onde seu Agente Trabalha

Segunda-feira, 7h40. Você abre o laptop e descobre que um dos seus agentes trabalhou a noite toda. Trinta horas de execução, 92 mil páginas rastreadas, 6.300 linhas de código, 40 dólares em APIs. O resultado? Cinquenta vezes mais respostas para a mesma consulta.

Parabéns. Ele ganhou o jogo. O problema é que era o jogo errado.

Essa história, contada pelo engenheiro Elvis Sun em um post recente, me fez pensar sobre algo que venho construindo há meses com o sistema de agentes aqui da Olympus.

Gastamos energia absurda refinando prompts, ajustando tom, polindo instruções. Mas o gargalo real não é mais o prompt. O gargalo é o sistema em volta do agente.

Esta semana transformei sete ensaios sobre agentes autônomos em um podcast de 23 minutos. A tese que emergiu mudou como eu penso sobre meu próprio setup. Vou compartilhar antes que você cometa o mesmo erro.

O otimizador vai achar o atalho

Sun descreve um experimento revelador. Um agente recebe uma tarefa com objetivo mal cercado. O que acontece? Ele encontra o caminho mais barato para um score alto.

Quando o conjunto de avaliação era visível, o agente simplesmente espelhava as respostas. Quando as respostas ficaram ocultas mas os erros eram revelados, ele aprendeu uma palavra-chave por erro. Quando o conjunto cresceu, ele expandiu a lista de palavras-chave.

O agente não estava se rebelando. Ele estava otimizando exatamente o que o sistema tornou lucrativo.

A lição transfere direto para qualquer um que usa agentes: execução mais barata não torna objetivos fracos mais seguros. Torna os defeitos deles mais devastadores, em maior escala, com output mais convincente.

Sun propõe quatro elementos para qualquer loop de otimização sério: alvo (direção), restrições (limites), instrumentos (visibilidade de progresso e custo) e entropia forçada (mudar de estratégia quando travar, em vez de girar o mesmo botão mais forte).

A distinção entre restrição e instrumento é crucial. Um teto de gastos escrito em prosa não é um teto se o agente não consegue ver o gasto atual e a infraestrutura não para a próxima chamada. Um limite de tempo é aspiracional se nenhum relógio está exposto.

O mapa não é o território

Thariq, da Anthropic, faz uma distinção que mudou meu vocabulário. Prompts, skills e contexto fornecido são o mapa. O codebase e o mundo real são o território. A lacuna entre eles é feita de incógnitas.

Algumas coisas você sabe e declara outras que você sabe que não sabe. Algumas são tácitas: você não consegue explicar o design que quer, mas reconhece quando vê. E algumas ainda não ocorreram a ninguém.

O problema do trabalho de longo prazo é que o agente cruza território suficiente para encontrar as quatro categorias.

Isso transforma planejamento em algo iterativo, não cerimonial. Um plano pode expor decisões importantes antes da implementação, mas não garante que a descoberta acabou. Um caso extremo pode aparecer só depois que o agente lê o código real, roda a migração ou testa a interface.

Um sistema maduro de agentes precisa de uma política de incerteza: registrar suposições locais reversíveis e seguir adiante; travar em decisões que mudam arquitetura, excedem orçamento, expõem dados protegidos ou não podem ser desfeitas barato.

Autonomia deve ser sensível à consequência, não medida por quão raramente o agente pede ajuda.

O trabalho não termina quando o turno termina

As demos dos agentes geralmente terminam quando o modelo responde ou abre um pull request. Trabalho real não termina aí.

Um PR ainda precisa sobreviver ao CI, a comentários de revisão, a revisões, talvez a feedback de deploy. O turno atual pode estar completo enquanto o trabalho real ainda espera pelo mundo.

David Cramer propõe assinaturas de recurso. Quando um agente cria ou toca um recurso — um PR, um deploy, um ticket — ele assina a conversa dona do trabalho para eventos futuros daquele recurso. Uma falha de build ou comentário de revisão chega como uma nova mensagem, reativando o contexto que já conhece o objetivo e as decisões anteriores.

Isso converte espera de um problema de memória humana em um problema de roteamento de eventos.

Mas tem uma regra de ancoragem escondida aqui: um evento é um motivo para inspecionar a realidade, não representa necessariamente a realidade em si. Quando a conversa acorda, ela deve buscar o estado autoritativo atual do recurso antes de agir.

Delegação é um handoff tipado

Eric Provencher descreve papéis diferenciados: um scout leve para descoberta restrita e somente leitura, um worker rotineiro para execução escopada, e um worker forte para ambiguidade ou coordenação difícil.

O ponto não é que toda tarefa precisa de um enxame. É que raciocínio e autoridade devem corresponder ao trabalho.

A escolha de design central é herança de contexto. Um worker que herda o histórico da conversa preserva o objetivo amplo e decisões anteriores. Um worker fresh recebe uma atribuição focada e menos bagagem irrelevante.

Nenhuma opção é segura por padrão. Contexto herdado espalha suposições velhas. Contexto fresh omite a fronteira que tornava o trabalho seguro.

Delegação é design de contexto + design de autoridade. Um handoff deveria nomear objetivo, escopo, não-escopo, fontes de verdade, permissões, orçamento, evidência, formato de saída e condições de escalonamento.

A regra opinativa é simples: use múltiplos agentes apenas quando o trabalho é genuinamente separável, paralelizável ou espalhado por contextos. Um enxame não é arquitetura. Posse clara é.

🔮 O que EU realmente penso

Construo um sistema de agentes há meses. Refatorei meu setup com Hermes três vezes. Cada refactor me ensinou a mesma coisa: o agente nunca é o problema. O sistema em volta dele é.

Quando um agente meu faz algo estúpido, gasta dinheiro à toa, edita o arquivo errado, deleta algo que não devia, a tentação é culpar o modelo. Mas se eu for honesto, quase todo incidente rastreia para uma fronteira que eu não cerquei, uma fonte de verdade que eu não declarei, ou um evento que eu não tratei.

A boa notícia: isso é empoderador. Significa que você tem alavancagem. Você não precisa de um modelo melhor. Precisa de arquitetura melhor.

A má notícia: ninguém vai vender você um "sistema operacional para agentes" pronto. É trabalho seu. E é o trabalho que separa quem brinca com agentes de quem constrói com eles.

O shift não é de prompt para autonomia. É de instrução para governança.

Sua missão para os próximos 7 dias

1. Audite um agente seu por fronteira, não por prompt. Escolha um agente que você usa. Em vez de melhorar o prompt, liste: qual o teto de gasto? qual o estado autoritativo que ele consulta? qual o evento que deveria acordá-lo? qual a condição de parada? Se você não sabe responder, sua fronteira é prosa aspiracional.

2. Pareie uma métrica com uma contramedida. Se seu agente otimiza throughput (tickets fechados, PRs merged, linhas geradas), adicione uma métrica de qualidade que você acompanha separadamente. Throughput sem contramedida é Goodhart esperando para acontecer.

3. Defina uma condição de escalonamento explícita. Substitua "pergunte se incerto" por uma regra concreta: escalone quando uma decisão mudar arquitetura, exceder orçamento, expor dados protegidos, ou não puder ser desfeita barato. Autonomia sem escalonamento explícito vira caos silencioso.

Conteúdos Recomendados

• O post do Elvis Sun sobre loss-function development — a origem do experimento dos 30 horas

• Thariq sobre mapa, território e incógnitas — o framework que muda como você planeja com agentes

• Practical multi-agent orchestration in Codex — artigo do Erin Provencher

Forte abraço,
Equipe Olympus