Hoje eu prestei mais atenção em dois números do que em mais um benchmark bonito. O repositório single-file-agents apareceu forte no X e estava com 435 estrelas quando eu li. Já o minion abriu a conversa com uma promessa bem menos sexy e bem mais útil: começar perto de 625 tokens em vez de desperdiçar 20 mil a 50 mil tokens só para dizer "oi".
Hoje eu prestei mais atenção em dois números do que em mais um benchmark bonito.
O repositório single-file-agents apareceu forte no X e estava com 435 estrelas quando eu li. Já o minion abriu a conversa com uma promessa bem menos sexy e bem mais útil: começar perto de 625 tokens em vez de desperdiçar 20 mil a 50 mil tokens só para dizer "oi".
Para mim, esse é o sinal do dia.
A conversa sobre agentes está ficando adulta. Menos teatro de arquitetura. Mais pressão por tarefa simples, contexto curto e resultado visível.
TL;DR
Eu não começo piloto de agente pelo framework. Eu começo por uma tarefa pequena, com dono claro, arquivo claro e métrica clara.
Eu uso o método C.O.R.T.E.: Caso único, Objetivo visível, Rastro curto, Teto de contexto e Escopo fechado.
Se o agente precisa de muita ferramenta, muito contexto e muita fé no primeiro teste, eu não tenho um agente. Eu tenho um PowerPoint com autoestima.
O problema
Eu vejo muita empresa comprando complexidade antes de comprar clareza.
Primeiro alguém vê uma demo. Depois aparece a vontade de ligar tudo: CRM, Drive, Slack, banco, calendário, editor, navegador, MCP, workflow, automação, oração e talvez um cafezinho.
Só que piloto bom não nasce gordo.
Ele nasce magro.
Foi isso que me chamou atenção nesses dois sinais que eu li hoje. O single-file-agents organiza agentes para uma função de cada vez: mexer em CSV, gerar SQL, editar arquivo, raspar página, usar jq. O minion faz a provocação pelo outro lado: se um agente já entra na conversa carregando 20 mil ou 50 mil tokens, o custo, a latência e a confusão chegam antes do valor.
Na prática, os dois sinais dizem a mesma coisa.
Antes de orquestrar vinte peças, prove uma.
Eu gosto dessa abordagem porque ela força o time a responder a pergunta que quase todo piloto tenta evitar: qual trabalho exato esse agente vai entregar até sexta-feira?
Sem essa resposta, framework vira fantasia de controle. Bonito na reunião. Caro na operação.
Se você quiser montar repertório antes de escalar, eu ligaria esse tema com agente de código, contexto da IA e skills de IA. Tudo isso ajuda. Mas nada disso salva piloto sem recorte.
O framework / método
Quando eu preciso decidir se vale começar simples ou já cair em arquitetura grande, eu uso o método C.O.R.T.E.
Nome feio de propósito.
Se o agente não aguenta um corte, ele não aguenta produção.
1. C de caso único
Eu começo por um trabalho só.
Não é "atender cliente".
É "ler uma planilha, separar leads parados há 14 dias e devolver uma lista pronta para follow-up".
Não é "ajudar o time comercial".
É "transformar anotações de reunião em três próximos passos com dono e prazo".
Caso único tira a ilusão de amplitude e devolve foco.
2. O de objetivo visível
Eu quero uma entrega que eu consiga enxergar sem filosofia.
Tabela pronta. Resumo pronto. SQL pronto. Arquivo editado. Rascunho salvo. Nada de promessa abstrata como "ganho de produtividade" no dia um.
Produtividade é consequência. Entrega é teste.
3. R de rastro curto
Se eu não consigo explicar em dois minutos o que o agente fez, ele já está complicado demais para o primeiro piloto.
Eu quero rastro curto:
prompt ou instrução principal em um lugar só;
ferramentas liberadas de forma explícita;
entrada conhecida;
saída revisável;
log simples do que aconteceu.
Foi por isso que eu gostei do espírito do single-file-agents. Mesmo quando eu não quero literalmente um arquivo só, eu quero a mesma disciplina: pouca coisa para entender, pouca coisa para quebrar, pouca coisa para esconder.
4. T de teto de contexto
Contexto virou buffet livre em muito projeto de IA.
Todo mundo pega prato grande. Ninguém olha a conta.
O número do minion é útil justamente por isso. Quando um projeto diz que tenta começar perto de 625 tokens e cutuca agentes que entram com 20 mil ou 50 mil, ele está lembrando o básico: contexto é custo, demora e chance maior de distração.
Eu não preciso do menor contexto possível.
Eu preciso do menor contexto que resolva a tarefa.
Essa diferença separa engenharia de ego.
5. E de escopo fechado
No primeiro piloto, eu fecho a cerca.
Um dono humano. Uma fonte de dados. Um tipo de saída. Uma janela curta de teste. Uma regra clara de desligamento.
Se o agente só funciona quando já nasce conectado a tudo, eu desconfio.
Ferramenta boa não pede a chave da casa na primeira visita.
Como aplicar hoje
Se eu fosse testar isso ainda hoje, eu faria assim.
Passo 1: escolher uma tarefa chata e repetitiva
Eu pegaria algo que acontece toda semana e ninguém faz com prazer.
Exemplos bons:
consolidar anotações de reunião em próximos passos;
limpar uma base CSV e destacar linhas fora do padrão;
revisar um bloco de texto e devolver versão final com checklist;
buscar páginas de um site e extrair pontos específicos para análise.
Exemplos ruins:
"melhorar marketing";
"automatizar operação";
"usar IA no comercial".
Isso não é briefing.
Isso é preguiça fantasiada de estratégia.
Passo 2: colocar instrução, entrada e saída no mesmo lugar
Eu faria um documento, script ou workflow curto com três coisas visíveis:
1. o que entra; 2. quais ferramentas entram; 3. o que ele precisa devolver.
Não precisa ser literalmente um arquivo Python. A lição do single-file-agents não é idolatrar extensão de arquivo. É reduzir atrito.
Se o time precisa de sete pastas, três integrações e duas reuniões para começar, eu já compliquei cedo demais.
Passo 3: limitar contexto e ferramenta desde o começo
Eu definiria um teto simples:
uma base de dados por teste;
no máximo duas ferramentas no piloto;
janela curta de contexto;
sem acesso a sistema crítico no primeiro dia.
É menos glamouroso. Também é menos burro.
Passo 4: medir quatro números por 7 dias
Eu mediria só isto:
tempo humano antes;
tempo humano depois;
número de erros por execução;
retrabalho gerado pelo agente.
Se esses quatro números não melhoram depois de uma semana, eu não compro arquitetura. Eu corto o piloto ou redesenho a tarefa.
Passo 5: escalar só depois da prova
Se o teste funcionar, aí sim eu penso em memória, mais ferramentas, servidor MCP, workflow maior ou integração com outras áreas.
A ordem importa.
Muita empresa quer escalar antes de provar. Depois descobre que industrializou uma tarefa ruim. É quase uma homenagem ao desperdício.
Resultados esperados
Quando eu aplico esse recorte, eu espero três ganhos rápidos.
Primeiro, eu descubro em 7 dias se existe valor real ou só demo simpática.
Segundo, eu reduzo a chance de começar o piloto com contexto inchado. Em vez de aceitar projetos que já nascem na casa de dezenas de milhares de tokens por conversa, eu forço o time a justificar cada pedaço de contexto.
Terceiro, eu saio com prova operacional: uma tarefa, uma saída, um dono e quatro métricas. Isso vale mais do que mais uma discussão abstrata sobre "transformação". Essa palavra já apanhou pouco.
No fim do dia, agente simples não é brinquedo.
É filtro.
Se ele não entrega valor em pequeno, dificilmente vai entregar valor em grande. Só vai errar com mais camadas.
Perguntas rápidas
Agente simples é agente fraco?
Não. Eu vejo agente simples como agente com recorte. Fraqueza é querer resolver cinco problemas ao mesmo tempo e não fechar um direito.
Eu preciso literalmente usar um arquivo só?
Não. O ponto não é fetiche por arquivo único. O ponto é clareza operacional. Se o fluxo cabe em um lugar fácil de revisar, eu já ganhei metade da briga.
Quando eu devo comprar framework?
Quando o piloto simples já provou valor e o gargalo deixou de ser a tarefa. Aí faz sentido discutir observabilidade, memória, orquestração e integração maior.
Contexto curto sempre vence?
Não. Contexto curto sem contexto suficiente também atrapalha. Eu só não aceito contexto gordo por preguiça. Cada bloco precisa pagar aluguel.
Qual tarefa eu testaria primeiro em uma empresa B2B?
Eu começaria por algo repetitivo e visível: resumo de reunião, triagem de leads parados, limpeza de base, revisão de proposta ou consolidação de dados em relatório.
Conclusão
Eu acho que muita empresa vai economizar tempo e dinheiro no segundo semestre se parar de começar por arquitetura e voltar a começar por tarefa.
Foi isso que eu tirei do que li hoje no X e no GitHub.
Menos camadas. Mais recorte. Mais prova.
Se eu estivesse montando um piloto agora, eu abriria um teste simples ainda hoje e só deixaria o framework entrar depois da primeira semana de evidência.
Se você quiser, a sequência natural daqui é revisar agente de código, ler contexto da IA e então decidir onde skills de IA realmente entram no seu processo.