Contexto, Não Controle
Toda regra no prompt do seu agente começou como um bug.
Alguém viu um comportamento ruim, escreveu uma regra e seguiu em frente. Outra pessoa fez o mesmo. Uma terceira adicionou um "nunca faça X" porque o modelo fez algo estranho uma vez numa terça-feira. Ninguém apagou nada.
Seis meses depois, o agente está gastando mais da sua janela de contexto navegando pelo próprio manual de regras do que pensando na tarefa em si.
Isso é pensamento no estilo controle. E acho que é um dos maiores erros de design que as equipes cometem ao construir agentes de IA.
Um Pequeno Exemplo Que Revela um Padrão Maior
Esbarramos em um problema em que um agente disparado por uma tarefa agendada ficava criando novas tarefas agendadas de dentro da própria execução. Recursão infinita, só que com efeitos colaterais no mundo real.
Duas formas de reagir.
Estilo controle: Proibir. Escrever código que impeça agendamentos de criarem agendamentos. Adicionar uma regra no prompt: "nunca crie um agendamento dentro de um agendamento." Subir para produção.
Estilo contexto: Contar ao agente o que está de fato acontecendo.
Você foi disparado por uma tarefa agendada às 3:00 da manhã, horário do Pacífico. ID do agendamento: sched_29x8f. Uma execução agendada é uma execução isolada com um escopo definido que o usuário originalmente autorizou. Criar uma nova tarefa agendada estenderia esse escopo para além da autorização original.
A primeira abordagem remenda um comportamento. A segunda dá ao agente um modelo da situação.
Agora ele consegue raciocinar também sobre questões próximas: Devo enviar uma notificação às 3 da manhã? Devo criar um processo de acompanhamento que o usuário não pediu explicitamente? Devo modificar algo que estende para além do escopo da execução original?
Nenhuma regra necessária. O agente resolveu sozinho.
Muitas equipes recorrem ao controle quando o que realmente precisam é de contexto.
A Mesma Distinção Aparece Dentro dos Prompts
Isso não diz respeito apenas à imposição em nível de sistema. A divisão entre contexto e controle existe também dentro dos prompts.
Prompt no estilo contexto: majoritariamente fatos, opinião mínima:
Você está em execução por causa de uma tarefa agendada. Disparado às 3:00 da manhã, horário de Pequim. ID da tarefa: sched_29x8f. O usuário autorizou esta execução para um escopo específico.
Prompt no estilo controle: opinativo, prescritivo:
Evite criar agendamentos. Você deve notificar o usuário com a ferramenta X. Nunca faça Y a menos que Z.
Às vezes instruções prescritivas são úteis. Mas muitas vezes elas estão compensando fatos ausentes. E, uma vez que você começa a compensar dessa forma, vira vício.
Como Prompts Viram Burocracia
Esse é o modo de falha mais profundo.
Uma equipe vê um problema e adiciona uma regra. Depois outra. Depois mais outra. Cada uma remenda um problema local, mas juntas criam um sistema cheio de proxies.
Bezos descreveu esse padrão em sua carta aos acionistas de 2016: um bom processo serve a você para que você possa servir aos clientes. Mas, se você não tomar cuidado, o processo se torna a própria coisa.
É exatamente isso que acontece em sistemas de agentes.
A regra não é a coisa. A regra é um proxy para o resultado que você quer. E proxies se acumulam. Um deles cria casos extremos que exigem mais. Logo o agente está raciocinando através de camadas de instruções acumuladas, cada uma adicionada por algum motivo histórico que ninguém lembra direito.
Em organizações humanas, isso vira burocracia. Em sistemas de agentes, vira um prompt gigante cheio de tecido cicatricial.
Fatos Envelhecem. Opiniões Apodrecem.
Um fato como "esta execução foi disparada por uma tarefa agendada às 3 da manhã" é estável. Continua verdadeiro independentemente de qual modelo o lê: Claude, GPT, Gemini, ou seja lá o que for lançado no próximo trimestre.
Uma afirmação como "você deve evitar criar subagendamentos" é frágil. Depende de interpretação. Pode ajudar em uma situação e falhar silenciosamente em outra.
Quando você troca de modelo, cada opinião no seu prompt é uma mina terrestre em potencial. O novo modelo tem tendências de raciocínio diferentes, e seu "evite" cuidadosamente calibrado pode significar algo completamente diferente para ele.
Mas fatos fundamentados sobre o ambiente, as permissões, o escopo e as restrições tendem a generalizar entre modelos e casos extremos. É por isso que fatos são o melhor material de construção.
A Armadilha das Esquisitices do Modelo
Esta talvez seja a versão mais insidiosa do problema do controle: as equipes constantemente transformam defeitos temporários do modelo em estrutura permanente do sistema.
Um modelo se comporta mal em algum caso específico. A equipe adiciona uma proteção: um remendo no prompt, uma verificação no código, um ramo esquisito que só existe para impedir um modo de falha específico.
Esse remendo é uma aposta de que a esquisitice vai persistir. Quase nunca persiste.
Três meses depois, o modelo muda. O comportamento original desaparece. Mas o remendo permanece. Ninguém quer removê-lo, porque talvez ele estivesse ali por algum motivo.
É assim que prompts de sistema viram código legado.
Conseguimos reconhecer facilmente o perigo quando ele é descrito de forma abstrata. Mas, na prática, remendar as tendências atuais de raciocínio do Sonnet prompt após prompt é o mesmo padrão disfarçado.
Documentar comportamento estável do sistema é valioso. Remendar as tendências de raciocínio de um modelo é uma esteira sem fim. O modelo vai mudar debaixo de você mais rápido do que você consegue manter seus remendos.
Um Bom Caso de Teste: Permissão Negada
Você consegue ver a distinção com clareza nos diagnósticos de ferramentas. Quando um agente esbarra em um erro de permissão:
Estilo controle:
TOKEN está ausente. Execute "zero permissions request gmail.send" para corrigir.
Direto, mas o agente não aprende nada. Da próxima vez que esbarrar em um erro de permissão diferente, ele fica travado.
Estilo contexto:
process.env.GMAIL_TOKEN → existe zero connectors inspect gmail → conectado zero permissions inspect gmail.send → negado
Opções:
- Solicitar aprovação do usuário para gmail.send
- Usar um caminho já autorizado, se existir
Agora o agente sabe que o token existe, que o connector funciona e que a permissão específica está negada. Ele entende o estado do sistema e consegue raciocinar sobre situações novas que quem escreveu a regra nunca antecipou.
A Heurística
É a isto que eu sempre volto:
Sempre que você estiver prestes a escrever "não faça", "evite" ou "nunca" em um prompt. Pare. Pergunte: que fato esta regra está compensando?
Normalmente há um fato ausente. O agente não entende em que ambiente está, o que o usuário autorizou, quais ações são irreversíveis ou por que esta execução difere de uma interação de chat normal.
Anote esse fato. Apague a regra.
Às vezes você ainda vai querer a restrição, especialmente em torno de ações destrutivas, movimentação de dinheiro ou limites de segurança. Controles rígidos ainda importam.
Mas muitas regras de prompt não são limites de verdade. São compensações para um entendimento ausente. E essas são exatamente as que se acumulam e apodrecem.
O Objetivo
O objetivo não é um agente que decora uma lista de verificação.
O objetivo é um agente que entende a própria situação bem o suficiente para tomar boas decisões dentro de limites claros.
Uma filosofia controla o comportamento empilhando regras. A outra melhora o comportamento tornando o mundo legível.
A primeira tende à burocracia. A segunda tende ao entendimento.
Construa contexto. Apague o tecido cicatricial. Suba agentes que conseguem pensar.
