Por que os frameworks de agentes de IA são tão complexos? Precisamos de um framework revolucionário como o Rails

Principais problemas atuais dos frameworks de agentes de IA

• Esgotamento da janela de contexto
  • Em tarefas complexas, o modelo esquece o objetivo original
  • Ocorrem alucinações e loops infinitos
• O framework atua como um wrapper superficial
  • Joga para o desenvolvedor a escolha do modelo, do provedor de embeddings e a estruturação das ferramentas
  • Viola o princípio de "não me faça pensar"
• Confusão causada pelo excesso de ferramentas
  • Avaliar opções desnecessárias desperdiça contexto

Solução proposta: arquitetura centrada em subagentes

• Usar subagentes como cidadãos de primeira classe
  • Delegação natural, como em uma chamada de função
  • Mantêm contexto independente → preservam o foco do agente pai
  • Ex.: subagente de busca no codebase → retorna apenas os caminhos de arquivos relevantes
• Efeitos
  • Agente único: consome 90% do contexto
  • Com subagentes: o contexto do pai usa apenas 25%

Aplicando a lição do Rails: Convention over Configuration

• Prioridade para convenções padrão
  • Seleção automática do modelo (com base na complexidade da tarefa)
  • Herança do orçamento de contexto entre pai e filho
  • Criação automática de checkpoints para tarefas arriscadas
• Introdução de arquétipos (Archetype)
  • Searcher: apenas ferramentas de busca
  • Writer: apenas ferramentas de escrita
  • Researcher: apenas acesso à web → evita excesso de ferramentas

Princípios práticos de design

• Design centrado na tarefa
  • Em vez de "qual modelo usar?", priorizar a tarefa real (ex.: validação de formulário de cadastro)
• Temporalidade do contexto dos subagentes
  • Apenas o resumo do trabalho intermediário é retornado ao agente pai
• Diferença entre ferramenta e subagente
  • Ferramenta: sem estado (formatação de data, parsing de JSON)
  • Subagente: exige repetição e julgamento (busca, análise)

Escolha tecnológica: TypeScript

• Mais segurança de tipos (Branded types, discriminated unions)
• Compatibilidade com o ecossistema de ferramentas de desenvolvimento (VS Code etc.)
• Possibilidade de compilar um executável independente com Bun

Desafios ainda em aberto

• Compartilhamento de contexto entre subagentes (base de conhecimento do projeto)
• Colaboração entre agentes pares (troca de mensagens)
• Avaliação de agentes (captura e reprodução de cenários, critérios de sucesso, consistência e preferência)

Conclusão

• O framework não deve adicionar complexidade, mas sim fornecer a "complexidade certa"
• Um framework revolucionário como o Rails pode transformar o desenvolvimento de agentes
• Menos trabalho de infraestrutura → mais foco no problema central

[ahwjdekf]

Frameworks de agentes... o nome é grandioso, mas no fim das contas são só ferramentas que passam tudo para o llm. São uma casca vazia.

[click]

O Rails é conveniente porque impõe convenções e faz muita mágica por baixo da camada de abstração, mas existe o trade-off de perder desempenho; por outro lado, isso não é algo que gera custo imediato.
Mas, se o framework escolher o modelo por conta própria e você acabar tomando uma explosão no uso de tokens... quem vai se responsabilizar por isso?

[nomak]

Será que em 2026 não surge alguma ferramenta nova? Não seria como o Rails, mas algo com um nível de abstração maior... fico na expectativa.