Prompts gigantes são frágeis, mas às vezes são a melhor escolha

O autor relata um ano de experimentos construindo agentes - revisor de pull requests, agente de implementação, sumarizador de e-mails, harness próprio e boa parte da Baselight AI - e afirma que ainda não há boas práticas consolidadas para esse tipo de sistema. Sua tese: em muitos casos, o que parecia um problema de prompt era um problema de arquitetura.

Prompts grandes: úteis para explorar

As primeiras versões despejavam um prompt grande sobre o agente. Funcionava às vezes; depois surgiam falhas - casos de borda, regressões após atualização de modelo, convenções quebradas, execuções em que o agente fazia o oposto do esperado. Quando o prompting deixou de escalar, ele migrou para um catálogo de habilidades, ideia popularizada por projetos como o Hermes Agent, em que o agente navega por skills e escolhe a receita. Para o autor, era apenas um conjunto de prompts grandes em markdown carregados sob demanda.

Ele defende que prompts grandes continuam valiosos quando ainda não se sabe como resolver o problema, quando a tarefa é aberta, pede criatividade ou não será repetida em escala. Nesses casos, um agente com contexto amplo e muitas ferramentas costuma encontrar um caminho que o desenvolvedor não teria imaginado.

Onde falham

Os problemas surgem quando a tarefa tem sempre as mesmas etapas de alto nível e pode ser decomposta em subtarefas com caminho ótimo claro. Prompts grandes são frágeis, difíceis de depurar e avaliar, e caros: paga-se antecipadamente por muito contexto, mesmo em tarefas simples. Mudar uma linha para corrigir um comportamento pode quebrar algo três passos adiante, descoberto semanas depois.

O agente estreito

Um agente "gordo" é um único assistente com objetivo amplo, contexto grande, todas as ferramentas e ampla discricionariedade, e é rápido de implementar. A versão estreita divide o processo em unidades delimitadas - rotear contexto, checar elegibilidade, implementar, verificar, revisar -, cada uma com contrato explícito de entrada e saída, o menor contexto necessário, permissões mínimas e uma métrica. Um roteador move o trabalho entre elas, e software comum faz verificações, portões e efeitos colaterais. O autor recomenda usar modelos para julgamento sob ambiguidade e código determinístico para permissões, roteamento e validação. Em seu fluxo de revisão de PR, metade das etapas não é chamada de LLM: o portão de elegibilidade, antes um parágrafo de prompt que errava com frequência, virou cerca de quarenta linhas de Python.

Ganhos relatados

Quatro benefícios são citados. É possível saber se uma mudança ajudou, com conjuntos de teste e métricas por etapa; uma métrica ponta a ponta mostra que o sistema regrediu, mas não qual decisão, ferramenta ou documento causou isso. O privilégio mínimo deixa de ser aspiracional: cada agente recebe só as permissões da sua tarefa, reduzindo o dano possível; o roteador não escreve no repositório e o revisor só publica após validação determinística - o que não elimina injeção de prompt, mas move a fiscalização para fora do modelo. O contexto para de crescer: a passagem entre etapas é uma mensagem estruturada (ID da tarefa, entradas, evidências, premissas, incerteza, próxima ação), não uma transcrição, que segundo ele apodrece quando uma execução herda premissa falsa de outra. E a troca de modelo deixa de ser problema: um modelo barato classifica, um forte raciocina, código determinístico valida o esquema, e cada substituição é testada contra o conjunto de avaliação daquele papel.

O loop é a restrição

O autor argumenta que o fator mais importante é o loop de feedback: um agente é tão bom quanto o loop em que opera. O melhor caso é uma medida objetiva direta - limitar o espaço de busca, deixar o agente propor mudanças, medir deterministicamente e manter, reverter ou escalar por um limiar definido de antemão. Para entrega de features, o loop relatado é especificação, implementação, teste, lint e verificação contra a especificação, com um portão de revisão absorvendo o julgamento que a automação não mede honestamente. Nem todo loop valioso tem métrica completa, e fingir que tem leva a otimizar um proxy até o chão. Quanto mais próximas as verificações executáveis estiverem do resultado desejado, mais autonomia é segura. Um loop fraco limita a autonomia possível e não se resolve com um system prompt melhor. Sem sinal confiável e sem reversão segura, o desenho correto é um loop consultivo com humano.

Conclusão

O autor afirma que a única forma segura de colocar IA em produção é uma arquitetura de agentes estreitos, com unidades especializadas testáveis e replicáveis. Em nota final, expressa a opinião de que estamos próximos da AGI, mas que isso não virá de um único modelo, e sim de um enxame de agentes estreitos cooperando; cita incidentes de ataque envolvendo a OpenAI como primeiro aviso e diz que esse trecho não tem relação direta com o resto do texto.