Era líder de backend na Manus: Por que abandonei function calling em agentes após 2 anos e o que uso em seu lugar

O artigo atual não é só uma crítica à function calling, é um manifesto técnico sobre como a filosofia Unix, com seus fluxos de texto, pipes e ferramentas pequenas e especializadas, oferece um modelo mais escalável para agentes de IA do que o paradigma de APIs tipadas. Enquanto a function calling exige definições rígidas de parâmetros, schemas JSON e tratamento explícito de erros (e foi alvo de ataques de jailbreaking com >90% de sucesso em modelos de ponta, segundo estudo de julho de 2024), o comando run(command="...") delega a interpretação ao sistema operacional, que já resolveu há décadas problemas como timeout, permissão, redirecionamento e composição. Isso reduz a superfície de ataque e elimina a necessidade de manter um catálogo sincronizado entre LLM e backend, um gargalo real em equipes que evoluem rapidamente suas ferramentas internas.

A abordagem ganhou tração prática: a CLI llm, lançada por Simon Willison em junho de 2024, já é usada por times de infraestrutura para automatizar auditorias de configuração via llm 'list all nginx configs with insecure TLS settings' | grep -E '(ssl|tls)'. Não é mágica, é reaproveitamento de camadas maduras. O que muda agora, em 2026, é que essa ideia deixou de ser um experimento de devops para virar arquitetura de produto em agentes que operam em ambientes reais, como servidores Linux gerenciados por IA ou pipelines de CI/CD auto-reparáveis.

Isso importa porque a maior barreira para adoção de agentes em produção não é o raciocínio do modelo, mas a confiabilidade da interação com o mundo externo. Function calling força os engenheiros a construírem duas interfaces: uma para humanos (APIs REST) e outra para IA (funções tipadas). A abordagem Unix unifica as duas, o mesmo script que um SRE executa manualmente pode ser invocado diretamente por um agente, sem tradução intermediária. Em ambientes regulatórios, isso também simplifica auditoria: cada comando executado gera um log estruturado nativo do SO, sem dependência de wrappers proprietários ou SDKs de terceiros.