A infraestrutura de agência e o novo backend
· 10 min read · Filippo Spinella · AI, Agents, Infrastructure, Developer Tools
Muitas vezes falamos sobre estruturas de agência. LangGraph, CrewAI, AutoGen, vários SDKs, loop, chamada de ferramenta, memória, planejador, crítico, supervisor. Todas palavras úteis, pelo amor de Deus. Mas quanto mais observo os agentes realmente utilizados, mais me parece que a parte interessante deslocou-se para baixo do nível da estrutura.
A questão não é mais apenas: qual biblioteca devo usar para fazer um modelo passo a passo pensar?
A verdadeira questão é: onde mora esse agente quando deixa de ser um demo?
Porque um agente sério não é uma função que chama um modelo e retorna texto. É um pequeno sistema distribuído. Ele deve ler o contexto, usar ferramentas, executar código, mexer em arquivos, lembrar de decisões, pedir permissão, falhar bem, reiniciar, deixar logs, não queimar o orçamento e não virar uma escavadeira dentro do repositório de produção.
A estrutura é o volante. A infraestrutura é a estrada, os freios, a garagem, o seguro e quem sabe onde estão as chaves.
Porque se fala muito sobre isso agora
Em 2023 e 2024 a conversa foi muito centrada no modelo. Qual LLM? Quanto contexto? Quanto custa isso? Quão bom ele é em programação?
Em 2025 e 2026 a conversa mudou. Os modelos são bons o suficiente para realizar trabalho real, mas é por isso que as partes chatas se tornam visíveis: tempo de execução, segurança, conectores, identidade, observabilidade, execução de código, implantação, reversão.
É a transição natural da magia para a engenharia.
Quando um agente precisa apenas gerar uma resposta, basta um chat. Quando você precisa abrir uma solicitação pull, consultar um banco de dados, chamar um CRM, iniciar um trabalho, navegar em um site, ler o Slack, compilar código e atualizar um documento, você precisa de um sistema operacional em torno disso.
Não no sentido literal. No sentido organizacional.
A primeira parte: um tempo de execução onde o agente pode durar
Um agente geralmente trabalha em etapas. Observe o estado, escolha uma ação, use uma ferramenta, observe o resultado, atualize o plano, repita.
Se esse loop residir dentro de uma única solicitação HTTP, você terá um problema imediatamente. Algumas ações são lentas. Alguns aguardam a contribuição humana. Alguns falham e devem ser tentados novamente. Alguns devem sobreviver a uma implantação ou tempo limite.
É aqui que entram em jogo fluxos de trabalho duráveis, filas, históricos de trabalho e máquinas de estado. Eles não são glamorosos, mas são a diferença entre um agente que parece inteligente na demonstração e aquele que você pode deixar trabalhando enquanto vai tomar um café.
Para mim, o tempo de execução da agência deve responder a perguntas muito concretas:
- onde salvo o estado entre uma etapa e outra?
- o que acontece se o processo morrer no meio?
- posso fazer uma pausa e pedir aprovação?
- posso repetir uma corrida para entender por que ele fez essa escolha?
- posso limitar a duração, a memória, as ferramentas e o custo?
A Vercel está se esforçando bastante nessa frente com SDKs de IA, funções, fluxos de trabalho e ferramentas para construir agentes em aplicações web. Mas a questão não é apenas Vercel. A questão é que o agente precisa de um local operacional, não de um único terminal.
A segunda peça: sandbox, pois o agente deve conseguir se sujar sem quebrar
Assim que um agente escreve código ou executa comandos, é necessária uma sandbox.
Parece uma palavra técnica, mas a ideia é doméstica: você dá uma bancada para ele. Ele pode abrir arquivos, instalar dependências, executar testes, fazer experimentos, gerar resultados. Se ele errar, você conteve o dano. Se funcionar, promova o resultado.
Um sandbox agente deve ter algumas propriedades:
- sistema de arquivos isolado;
- CPU, memória e limites de tempo;
- rede controlada;
- segredos montados somente quando necessário;
- registros completos;
- possibilidade de exportar artefatos;
- reinicialização limpa entre execuções, quando necessário.
O Vercel Sandbox vai exatamente nessa direção: ambientes isolados para executar código, instalar dependências, trabalhar com arquivos e produzir artefatos sem executar tudo no tempo de execução da aplicação principal.
Essa coisa é mais importante do que parece. Muitos protótipos agentes saltam diretamente do modelo para o sistema real. O modelo pode chamar tool. As ferramentas podem fazer coisas. Tudo parece elegante até o primeiro comando errado, a primeira dependência instalada no lugar errado, o primeiro token que vai parar em um log.
A caixa de areia é a forma adulta de dizer: vá em frente, mas aqui.
A terceira peça: MCP e o problema do conector
O Model Context Protocol tornou-se uma das partes mais interessantes do ecossistema porque tenta padronizar algo que de outra forma rapidamente se tornaria incontrolável: como um modelo descobre e usa ferramentas externas.
Sem um padrão, cada integração é uma pequena ilha. Um conector para GitHub feito de uma maneira, um para Slack feito de outra, um para bancos de dados com semântica diferente, um para automação de navegador que parece nada.
O MCP propõe uma linguagem comum entre cliente e servidor: ferramentas, recursos, prompts, autorizações, transporte, descoberta. Não resolve magicamente a governança e a segurança, mas fornece uma gramática.
E a gramática é importante. Quando um agente pode se conectar a muitas ferramentas, a questão não é apenas “ele consegue fazer isso?”. O problema é “ele entende o que pode fazer, com quais limites, em nome de quem e deixando quais rastros?”.
Para mim, o MCP não é exagero porque "faz chamadas de ferramentas". Nós já fizemos isso. É um exagero porque muda o centro de gravidade da integração única para o catálogo operacional de ferramentas.
Em uma boa arquitetura agêntica, o MCP se torna uma espécie de patch panel:
- GitHub para código e problemas;
- Slack para contexto conversacional;
- Linear ou Jira para trabalhos planejados;
- banco de dados somente leitura para análises;
- navegador ou raspador controlado para sites externos;
- armazenamento de documentos;
- ambientes de execução isolados;
- sistemas internos expostos com permissões estritas.
A parte complicada é que um catálogo de ferramentas sem políticas é apenas uma forma mais elegante de criar o caos.
A quarta peça: identidade e permissões
Esta é a área onde muitas demonstrações fecham os olhos.
Um agente atua em nome de alguém. Portanto, deve ficar claro quem é o sujeito da ação.
Está usando permissões de usuário? De uma conta de serviço? De um espaço de trabalho? Você tem acesso temporário ou permanente? Você consegue ler tudo ou apenas alguns recursos? Você pode escrever? Você pode cancelar? Ele pode enviar mensagens para pessoas reais?
Se você não responder bem a essas perguntas, mais cedo ou mais tarde construirá um assistente com as chaves de casa e sem memória de quem as deu a ele.
A regra que gosto é esta: o agente deve ser capaz de fazer menos que o humano, e não mais que o humano. E quando ele tem que fazer algo mais arriscado, ele tem que parar e perguntar.
Isso significa OAuth, escopo de token, gerenciamento de segredos, log de auditoria, política de ferramentas, lista de permissões, etapa de aprovação. Coisas não muito românticas. Coisas necessárias.
A quinta peça: memória e contexto, mas sem acumular lixo
Os agentes precisam de memória, mas a memória é perigosa quando se transforma num sótão.
Existem pelo menos três tipos de memória:
- memória de execução: o que aconteceu nesta execução;
- memória de projeto: convenções, decisões, restrições;
- memória pessoal ou de equipe: preferências, tom, rituais, processos.
Colocar tudo no prompt é o atalho. Funciona até não funcionar mais. A memória útil deve ser cuidada: indexada, atualizada, expirada, verificada, tornada citável.
Um agente que se lembra mal é pior do que um agente que não se lembra. Porque ele fala com confiança.
Portanto, a infra-estrutura deve incluir recuperação, arquivos de instruções, base de conhecimento, incorporação quando necessário, mas também limpeza. Precisamos de uma cultura da memória: o que entra, quem aprova, quando decai, como faço para corrigir.
A sexta peça: observabilidade, avaliação e repetição
Se um agente cometer um erro, o log “chamado de modelo” não será suficiente.
Você quer ver a rota. Que contexto ele recebeu? Quais ferramentas estavam disponíveis? Qual ferramenta você escolheu? Com que argumentos? Que resposta você obteve? Quanto custou? Onde ele ficou preso? O humano aprovou alguma coisa? O erro é um erro de modelo, ferramenta, prompt, dados ou permissão?
Aqui os agentes são mais parecidos com sistemas distribuídos do que chatbots.
Você precisa de rastreamentos legíveis, não apenas de registros de texto. Você precisa ser capaz de reproduzir uma corrida. É necessário comparar duas versões do mesmo agente em tarefas conhecidas. Precisamos medir as regressões: não apenas "responde melhor", mas também "fecha o ticket certo sem tocar em arquivos não solicitados".
As avaliações de agente são mais difíceis do que as avaliações de texto porque incluem ações. Não é suficiente comparar uma string esperada. É preciso observar as sequências, os efeitos colaterais, a qualidade do artefato, o tempo, o custo, o número de intervenções humanas.
O engraçado é que sempre voltamos lá: engenharia de software. Testes, ambientes, rastreamentos, reversões. Só que o código agora também decide o que fazer a seguir.
A sétima peça: interfaces humanas
O agente não precisa apenas viver em um chat.
Alguns agentes precisam de um conselho. Outros uma página com status e log. Outros de um botão "aprovar". Mais comentários embutidos. Ainda outros de uma CLI.
A IU muda o comportamento. Se a única maneira de controlar um agente for escrever uma mensagem longa, o usuário dará instruções vagas ao agente. Se, no entanto, ele vir o plano, as diferenças, as fontes, os riscos e a próxima ação, ele poderá intervir com precisão.
Uma infraestrutura de agente decente inclui superfícies de controle:
- situação atual;
- plano editável;
- artefatos produzidos;
- diferença;
- solicitações de aprovação;
- cronologia;
- botão parar;
- botão de tentar novamente;
- permissões visíveis.
Parece trivial, mas não é. A diferença entre “IA assustadora” e “assistente confiável” geralmente é apenas que o último mostra onde está as mãos.
A pilha mental
Se eu comprasse hoje, o stack mínimo do agente seria este:
- Modelo: raciocínio, geração, chamada de ferramenta, multimodal se necessário.
- Orquestração: loop, etapa, planejador, política, humano no circuito.
- Tempo de execução durável: fluxo de trabalho, fila, nova tentativa, pausa, retomada.
- Sandbox: execução de código, sistema de arquivos isolado, limitações, artefatos.
- Camada de ferramentas: MCP, API interna, navegador, banco de dados, repositório.
- Camada de identidade: OAuth, escopo, segredo, auditoria, política.
- Camada de memória: contexto do projeto, recuperação, instruções, expiração.
- Observabilidade: métricas de rastreamento, repetição, avaliação, custo e qualidade.
- Superfície do produto: converse quando for suficiente, painel quando necessário, revise quando for importante.
A estrutura de agência cobre principalmente os pontos 2 e uma parte do ponto 1. O resto é o verdadeiro trabalho.
O que eu faria na prática
Se uma equipe me dissesse “queremos agentes em produção”, eu não começaria com dez agentes.
Eu começaria com um fluxo de trabalho pequeno, repetitivo e observável. Por exemplo: abrir PRs de manutenção, atualizar a documentação de problemas fechados, preparar uma revisão semanal, fazer triagem de bugs duplicados, gerar testes para arquivos afetados.
Então eu estabeleceria limites muito claros:
- não é permitido escrever sem ramificações ou sandbox;
- sem segredos no prompt;
- ferramentas na lista de permissões;
- aprovação humana para ações externas;
- registro e rastreamento obrigatórios;
- orçamento por execução;
- saída sempre inspecionável.
Só então eu expandiria.
Os agentes não falham só porque os modelos erram. Eles falham porque os colocamos em ambientes vagos, com permissões confusas e expectativas teatrais.
Minha leitura
A infraestrutura agente é entediante da melhor maneira.
Não é a parte que te faz bater palmas na demo. É a parte que permite que você realmente use a demonstração na manhã de segunda-feira, com pessoas reais, dados reais e consequências reais.
O futuro dos agentes não será decidido apenas por quem tiver o melhor modelo. Será decidido por quem construir o melhor lugar para fazê-lo trabalhar: isolado quando experimenta, conectado quando necessário, sempre observável, autorizado com critério e humilde o suficiente para parar quando não sabe.
É aí que os agentes deixam de ser um brinquedo e passam a ser infraestrutura.