Agentes de IA generativa escrevem trechos de código excelentes, mas frequentemente tropeçam em tarefas longas. Refatorações massivas, migrações de banco de dados, auditorias de conformidade: qualquer tarefa que cruze centenas de arquivos expõe uma fraqueza fundamental dos modelos atuais. Quanto mais informação você empurra para dentro do contexto, pior o desempenho fica.
A comunidade chama esse fenômeno de Zona Burra (Lost in the Middle). Quando um sistema entra nessa zona, o desempenho cai, implantações travam e recursos computacionais vão pelo ralo. Resolver isso deixou de ser um problema acadêmico, é uma prioridade de engenharia.
Por que os limites de contexto importam na prática
Imagine um banco que pede para um agente de IA refatorar um sistema legado de faturamento. O software precisa preservar centenas de regras de negócio enquanto navega por milhares de linhas espalhadas em dezenas de arquivos. Uma falha de memória no meio do processo não é só um bug técnico, é um risco de conformidade real. Se o agente descarta os requisitos iniciais de governança de dados por compressão de contexto, o trabalho automatizado inteiro é invalidado, e ninguém percebe até a auditoria.
A engenharia de software se parece com um jogo de tabuleiro em aberto: exige tanto estratégia de longo prazo quanto execução tática precisa. Memorizar um flag do git é tático. Projetar um esquema de banco retrocompatível é estratégico. Um bom agente precisa das duas coisas, simultaneamente, por horas a fio.
Como a indústria tenta resolver, e onde falha
As arquiteturas existentes tentam contornar o problema, mas impõem concessões pesadas. Um método comum usa compressão periódica: o sistema descarta contexto considerado irrelevante. O problema é que essa compressão não é determinística, ela pode silenciosamente jogar fora informações críticas de forma imprevisível.
Outra abordagem delega tarefas a subagentes isolados. Como cada um opera em seu próprio silo, eles dependem de troca de mensagens para se sincronizar com o sistema principal, criando gargalos e pontos de falha. Há ainda o padrão planejador + executor, onde um agente de alto nível delega a um executor, comprime os resultados e os devolve ao principal. Cada compressão na transferência é uma oportunidade de perder detalhes de estado importantes.
A arquitetura de enxame como solução
A abordagem mais promissora abandona a metáfora de um único agente “pensando” em sequência. Em vez disso, opera como uma mente coletiva: um orquestrador central despacha threads de trabalho em paralelo. Cada thread executa exatamente uma ação e então pausa, devolvendo o controle ao orquestrador. Sem passagem de mensagens. Sem silos. O estado global nunca se fragmenta.
Essa é a lógica por trás do Slate, agente lançado pela Random Labs, que coordena enxames de subagentes diretamente via ambiente de código. A plataforma seleciona automaticamente o modelo certo para cada tipo de tarefa, times podem usar Claude para conversação enquanto geram código com Codex, por exemplo. O sistema coordena modelos como Sonnet, Codex e GLM de forma programática, usando o GLM especialmente para operações de busca agêntica.
O conceito de episódio e memória tratável
Em vez de guardar o rastro completo de cada passo, cada thread gera um episódio, uma representação comprimida que retém apenas as tool calls que contribuíram para o sucesso daquela ação. O orquestrador retém apenas os resultados relevantes de cada episódio, não o rastro tático completo.
O resultado é uma memória episódica tratável que contorna os limites tradicionais de contexto. A analogia com sistemas operacionais é direta: o LLM principal age como CPU e kernel, gerenciando contexto como se fosse RAM. Cada thread tem seu próprio espaço de memória. O time de desenvolvimento originalmente chamou essas threads de “atores”, inspirados na máquina virtual BEAM do Erlang.
O que isso muda para times de engenharia
A separação explícita entre conhecimento estratégico e execução tática é o ganho real. Ao coordenar o enxame via uma DSL em TypeScript, o sistema acessa o conhecimento latente do modelo para planejar, e usa threads para executar, sem misturar as duas camadas no mesmo contexto.
Outro benefício prático é o custo. A reutilização de subthreads maximiza o cache, mantendo o custo computacional baixo mesmo com execução paralela massiva. Times que adotam esse padrão conseguem avançar em tarefas que antes exigiam supervisão humana constante: refatorações em larga escala, geração de testes de regressão abrangentes, migrações de schema com retrocompatibilidade garantida.
Os limites de contexto dos agentes de IA não são um detalhe de implementação, são uma restrição arquitetural com consequências reais em produção. As abordagens tradicionais de compressão e silos de subagentes tratam o sintoma, não a causa. Arquiteturas baseadas em enxame com memória episódica apontam para um caminho mais robusto: paralelismo real, contexto controlado e separação clara entre planejamento e execução. Para times de engenharia que levam automação a sério, entender esse modelo é o próximo passo.