Você montou o workflow agêntico perfeito. Servidores MCP conectados, funções documentadas, e as primeiras chamadas ao Claude saem impecáveis. Aí chega a sétima chamada: os resultados começam a divagar, alucinações aparecem, e você fica depurando por que a IA “esqueceu” instruções críticas que você passou horas atrás.
Isso é context rot (algo como apodrecimento de contexto) — a degradação da qualidade do raciocínio do modelo à medida que as janelas de contexto enchem, comprimem e reiniciam em sistemas multi-agente. É arquitetural, não acidental. E escala de forma previsível.
O problema: três mecanismos de context rot
1. Saturação de contexto
Esquemas de ferramentas MCP (47k+ tokens), histórico da conversa, resultados intermediários, system prompts — tudo se acumula. Na sétima chamada, sua janela de 200k tokens está 70% ocupada. O modelo tem 30% do espaço restante para raciocinar sobre problemas novos. É sufocamento arquitetural.
2. Degradação semântica
Quando o contexto passa de 70–80%, os LLMs comprimem de forma agressiva. A “devolução” de tokens remove informação “redundante” — exceto que seus system prompts cuidadosos, documentos de referência externos e padrões de raciocínio passados não eram redundantes. Eram âncoras semânticas. Depois que saem, o modelo perde integridade posicional. Os resultados ficam inconsistentes; as alucinações disparam.
3. Cascatas do ciclo de compactação
Cada reset de contexto muda a ordem de inicialização. Um servidor MCP carrega em sequência diferente de uma chamada para a outra. Seu registro de ferramentas se realinha. Essas micro mudanças viram um drift quase impossível de depurar — a causa raiz é estrutural, não lógica.
O paradoxo: você otimizou tudo menos a própria arquitetura.
Três padrões que combatem o context rot
Padrão 1: arquitetura de memória externa
Pare de guardar tudo no contexto do modelo. Guarde fora.
graph TD
A["🔵 Pedido do usuário<br/>workflow_id=abc123"] -->|Decomposição de tarefas| B["🟡 Agente 1<br/>Contexto: 2-3KB<br/>Tarefa + 2 últimos resultados"]
B -->|Consulta| D["🟣 Armazenamento PostgreSQL<br/>Artefatos versionados<br/>Histórico de execução"]
B -->|Busca semântica| E["🔴 RAG no vector DB<br/>Contexto sob demanda<br/>Só documentos relevantes"]
B -->|Resultados em stream| C["🟡 Agente 2<br/>Contexto: 2-3KB<br/>Tarefa + 2 últimos resultados"]
C -->|Consulta| D
C -->|Busca semântica| E
C -->|Saída final| F["✅ Resultado<br/>Consistente<br/>Rastreável"]
style A fill:#e1f5ff
style B fill:#fff3e0
style C fill:#fff3e0
style D fill:#f3e5f5
style E fill:#fce4ec
style F fill:#e8f5e9
Como funciona:
- Cada agente mantém contexto mínimo: tarefa atual + 2 últimos resultados (2-3k tokens)
- Todos os artefatos vivem no PostgreSQL (versionados, consultáveis)
- Contexto semântico vem do vector DB sob demanda (nunca pré-carregado)
- Agentes se comunicam por streaming de resultados, não passando contexto adiante
- O ID de workflow percorre cada operação para auditoria
Resultado: sem inchaço de contexto, sem drift, sem alucinações. Os agentes podem rodar indefinidamente sem saturação.
Padrão 2: delegação hierárquica de contexto
Achate a topologia na vertical. Crie micro-agentes com escopo delimitado.
graph TD
A["🎯 Orquestrador de topo<br/>Entrada de pedidos<br/>Decomposição de tarefas<br/>Síntese de resultados"]
A -->|Tópico Kafka: crm_domain| B["👤 Agente CRM<br/>Contexto: 3-5KB<br/>5-10 ferramentas<br/>Operações de contato/deal"]
A -->|Tópico Kafka: data_domain| C["👤 Agente de dados<br/>Contexto: 3-5KB<br/>5-10 ferramentas<br/>Query/transformação"]
A -->|Tópico Kafka: integration_domain| D["👤 Agente de integração<br/>Contexto: 3-5KB<br/>5-10 ferramentas<br/>Webhook/API"]
B -->|consume/produce| E["📊 Stream de eventos<br/>Tópicos Kafka<br/>Sem conexão direta<br/>entre agentes"]
C -->|consume/produce| E
D -->|consume/produce| E
E -->|Resultados via workflow_id| A
style A fill:#1976d2,color:#fff
style B fill:#ff9800,color:#fff
style C fill:#ff9800,color:#fff
style D fill:#ff9800,color:#fff
style E fill:#424242,color:#fff
Como funciona:
- O orquestrador de topo decompõe pedidos em sub-tarefas por domínio
- Cada agente de nível médio (CRM, Dados, Integração) começa limpo com 3-5k tokens
- Agentes folha (5-10 por nível médio) compartilham só o contexto do pai
- Toda comunicação entre agentes via Kafka (assíncrona, desacoplada)
- Sem inchaço de contexto compartilhado; cada camada dona do seu namespace
- Resultados reencadeados via IDs de workflow e timestamps de evento
Escalabilidade: um agente especialista novo? Registra o AgentCard, entra no consumer group, pronto. Sem reescrever a topologia toda.
Padrão 3: descoberta dinâmica + execução programática
Carregue só as ferramentas que precisar, na hora em que precisar.
graph LR
A["🤖 Invocação do agente<br/>Sem custo de startup"] -->|1. Consulta ao registro| B["🔍 Motor de busca de ferramentas<br/>Correspondência semântica<br/>~400 tokens"]
B -->|2. Devolve ferramentas relevantes| C["📝 Agente gera código<br/>import crm_server<br/>result = crm_server.get_contact..."]
C -->|3. Executa| D["⚡ Servidor MCP<br/>Schema sob demanda<br/>Executa a chamada"]
D -->|Resultado| E["✅ Agente recebe<br/>Sem acúmulo de contexto<br/>Estado novo"]
style A fill:#c8e6c9
style B fill:#a5d6a7
style C fill:#81c784
style D fill:#66bb6a
style E fill:#4caf50,color:#fff
F["📊 Comparação<br/>Estático: 47k tokens<br/>Dinâmico: 400 tokens<br/>Redução: 98%"]
style F fill:#fff9c4,stroke:#f57f17,stroke-width:2px
Como funciona:
- Nada de esquemas de ferramentas pré-carregados (elimina overhead de 47k tokens)
- O agente consulta a Tool Search em tempo de execução: “ferramentas que casem com ‘gestão de contatos’”
- A busca devolve matches semânticos: ~10 nomes de ferramentas + parâmetros chave
- O agente escreve código Python:
import crm; crm.get_contact(id=123) - O servidor MCP busca o schema completo só da ferramenta em uso
- Depois da execução, os schemas são liberados; o contexto nunca incha
Resultado: 98% a menos de tokens. Escalabilidade praticamente ilimitada. O contexto nunca enche.
Como isso vira arquitetura de IA em empresa
Esses padrões não “só” resolvem workflow — eles definem sistema agêntico de nível enterprise:
Memória externa vira fonte da verdade. Versiona, audita, reexecute a partir dela. Um agente que falhou retoma exatamente de onde parou, porque o estado do workflow fica em armazenamento imutável, não em contexto frágil.
Contexto hierárquico espelha a organização. Finanças tem seu cluster (agente AP, AR, conciliação). Vendas o delas. RH o deles. Sem poluição de contexto entre domínios. Cada cluster escala de forma independente para 50+ agentes.
Descoberta dinâmica permite escalar sem atrito. Amanhã entram 50 serviços MCP novos — todo agente os descobre via Tool Search. A arquitetura não quebra; ela se adapta.
Juntos, isso cria workflows resistentes ao context rot em que a consistência melhora ao escalar, em vez de degradar.
graph TB
A["Sistema agêntico em empresa<br/>200+ agentes entre domínios"]
A --> B["Camada 1: orquestração<br/>Topo + coordenadores por domínio"]
A --> C["Camada 2: agentes especializados<br/>50-100 agentes folha<br/>Cada um: 3-5KB de contexto"]
A --> D["Camada 3: estado externo<br/>PostgreSQL + vector DB<br/>streams de eventos Kafka"]
B --> E["✅ Resultado: consistência<br/>em escala"]
C --> E
D --> E
F["Métricas chave:<br/>• Inchaço de contexto: 0%<br/>• Taxa de sucesso: 99%+<br/>• Taxa de alucinação: menos de 1%<br/>• Escala: linear até 500+ agentes"]
style A fill:#1565c0,color:#fff
style E fill:#2e7d32,color:#fff
style F fill:#f57c00,color:#fff
A realidade prática
Vi times implementar cada padrão:
Só memória externa reduziu alucinações em cerca de 40%, mas não eliminou saturação de contexto — os agentes ainda consultavam o PostgreSQL dentro de contextos inchados.
Só delegação hierárquica distribuiu escopo, mas gerou complexidade de orquestração — coordenar 20 agentes em tópicos Kafka pedia gestão cuidadosa de estado.
Só descoberta dinâmica era elegante, mas insuficiente — sem hierarquia, descobrir 200 ferramentas ainda gerava paralisia de escolha.
Os três juntos? Aí a mágica acontece. Um time com que trabalho saiu de 5 para 120 agentes enquanto o contexto por agente caía de 45k para 3k tokens. A consistência melhorou. O debug ficou rastreável. Eles chegaram em escala de produção em semanas, não em meses.
O futuro dos sistemas agênticos
O futuro não está em janelas de contexto maiores. Os 200k tokens do Claude já são um absurdo de grande para a maioria dos fluxos.
O futuro é arquitetura que nunca enche a janela de contexto.
É memória externa como fonte da verdade. É agentes em hierarquia que refletem a complexidade da organização. É descoberta dinâmica que trata disponibilidade de ferramenta como consulta em tempo de execução, não carga no startup.
É sistemas que escalam além da saturação.
Se você está construindo sistemas agênticos, qual padrão usa? Bateu no teto dos 70%? Comenta o que funcionou (ou não) pro seu time.
Este post faz parte de uma série sobre padrões de arquitetura agêntica. Próximo: “IDs de workflow como linguagem de tracing distribuído em sistemas multi-agente”.