O Agente que Mora no Seu HD

In partnership with

88% resolved. 22% stayed loyal. What went wrong?

That's the AI paradox hiding in your CX stack. Tickets close. Customers leave. And most teams don't see it coming because they're measuring the wrong things.

Efficiency metrics look great on paper. Handle time down. Containment rate up. But customer loyalty? That's a different story — and it's one your current dashboards probably aren't telling you.

Gladly's 2026 Customer Expectations Report surveyed thousands of real consumers to find out exactly where AI-powered service breaks trust, and what separates the platforms that drive retention from the ones that quietly erode it.

If you're architecting the CX stack, this is the data you need to build it right. Not just fast. Not just cheap. Built to last.

See the data

Acima temos o anunciante da News dessa semana  Se puder, clique no link do anunciante acima para deixar seu apoio (é grátis!) ❤️

Modelos com 1 milhão de tokens de contexto existem. E mesmo assim, seus agentes esquecem tudo entre sessões.

Liu et al. documentaram em 2023 o que virou consenso em 2025: modelos performam pior com mais contexto. O fenômeno "lost in the middle" causa 30%+ de perda de acurácia quando a informação relevante está no centro da janela. Mais recentemente, testes com 18 modelos mostraram quedas de 95% para 60% conforme o input crescia.

Todo mundo quer dar mais memória pro agente. Quase ninguém quer dar um endereço fixo.

1️⃣ O Problema: Agentes Sem Casa

O ciclo é familiar: contexto, resposta, sessão termina, esqueceu. Amanhã, do zero. A solução intuitiva — janelas maiores, RAG, vector databases — parece óbvia. Mas a atenção do modelo é finita. Cada token compete com os outros. Informação irrelevante não é neutra: ela dilui o sinal.

Na edição #76 falamos que "cada token precisa ganhar seu lugar." Mas existe um problema anterior ao retrieval: continuidade. Vector databases resolvem encontrar informação parecida. Não resolvem saber onde você parou, o que já decidiu, o que já tentou e falhou.

Retrieval responde perguntas. Continuidade mantém narrativa.

O que falta para o agente não é mais memória, é uma "casa".

2️⃣ Filesystem: O Endereço que Você Já Tem

O melhor sistema de memória para agentes de produtividade já existe no seu computador.

Não estou falando de jogar tudo numa pasta e rezar. Estou falando de tratar o diretório de trabalho como infraestrutura cognitiva.

Estude, por exemplo, Spec Kit — framework com 86 mil estrelas no GitHub. Cada fase de trabalho produz um arquivo:

spec.md → plan.md → tasks.md

A próxima fase lê o arquivo anterior. O filesystem é o state machine. Sem database, sem ORM, sem migration, sem schema. Markdown e Git. Pronto.

Eu descobri isso da forma mais cara possível. No começo da Olympus City, a gente passava todo o contexto do projeto via prompt — arquitetura, decisões passadas, padrões, restrições. O prompt do Mayor tinha 12 mil tokens antes de qualquer instrução real. Resultado? Respostas genéricas. Alucinações sobre decisões que nunca tomamos. O modelo perdia sinal no meio de tanto ruído.

A virada foi inverter a lógica: em vez de dar contexto, o agente busca contexto. O Mayor lê MEMORY.md na inicialização — um índice curado com ponteiros pros arquivos relevantes. Precisa de detalhes sobre a arquitetura? Lê the-city-architecture.md. Precisa do status? Lê status-05-april-2026.md. Contexto sob demanda, não por antecipação.

Tenho usado dois níveis de persistência:

1. Log diário — registro bruto do que aconteceu, decisões, erros

2. MEMORY.md — índice curado pelo próprio agente: o que importa, links pro resto

3. Vault P.A.R.A — todo contexto que os agentes podem precisar organizados em arquivos

O efeito colateral surpreendente? Conhecimento gerido por LLM compõe. Por humano, decai. Humanos abandonam wikis em duas semanas — manutenção cresce mais rápido que valor percebido. O agente não cansa. Não esquece de atualizar cross-references. Toca 15 arquivos numa passada sem reclamar.

Tiago Forte testou: Claude organizou duas semanas de arquivos acumulados (screenshots, PDFs, markdown, planilhas) usando P.A.R.A. com ~95% de precisão. Em 3-4 minutos. O insight: dê ao agente um sandbox contido — uma pasta — onde ele pode ler, mover e organizar. Não acesso total ao sistema.

O filesystem não é primitivo. É o primitivo certo.

3️⃣ O Morador e o Operário

Se o filesystem é a casa, quem mora nela?

Dois tipos de agente. Papéis distintos. Complementares.

O Morador é o agente persistente. Ele vive no diretório. Mantém contexto acumulado. Conhece a história. Não executa tarefas — coordena.

Na prática, são agentes como o Hermes — especializado em PKM, compila wikis, mantém cross-references, memória persistente de usuário — ou o OpenClaw — generalista, roda local ou VPS, 100+ skills nativas, interface via mensageria. O denominador comum: rodam continuamente e melhoram o próprio sistema.

O loop de auto-aprendizado é o que diferencia o morador de um script com cron. Ele roda um kaizen loop — revisão periódica automática. Escaneia o que mudou no vault. Detecta correções repetitivas ("toda vez que peço X, o usuário corrige pra Y"). Propõe ajustes: novas skills, regras atualizadas, reorganização de arquivos. O morador não só usa o filesystem — ele cuida dele.

É a diferença entre um inquilino e um síndico. O inquilino mora e usa. O síndico mora, usa, e mantém.

O Operário é efêmero. Nasce pra uma task, executa, morre. Sem overhead de estado. Sem amarras de sessões anteriores. Contexto vem do filesystem que o morador preparou.

No Gas City chamamos de polecat: ele clama um bead (unidade de trabalho), executa, commita, fecha. O reconciler spawna outro quando chega mais trabalho. Startup protocol:

bd list → bd ready → bd claim → bd show → execute → bd close

Se o coordenador fez bem seu trabalho, o operário performa como se já conhecesse o projeto inteiro.

4️⃣ A Cola Invisível

Como o morador delega pro operário sem microgerenciar? Na Olympus City, a resposta é uma camada fina. O princípio: Zero Framework Cognition — código cuida de transporte, LLM cuida de raciocínio. Qualquer julgamento no código é violação.

Na semana passada, a prova: Gas City construindo a si mesma.

Três operários. Nenhuma intervenção humana. O morador despachou, cada bead leu contexto do diretório e escreveu resultado de volta nele. Estudo MIPT com 25 mil tarefas confirmou: protocolo importa 3x mais que modelo.

O modelo é commodity. A arquitetura ao redor dele não é.

🔮 O Que Eu Realmente Penso

Filesystem-as-memory não é a solução universal. Pra scale enterprise, vector databases e knowledge graphs ainda fazem sentido. Mas a maioria dos builders que conheço está over-engineering antes de ter o básico: um diretório organizado que o agente sabe ler.

A evolução que estou vendo:

1. Agente que responde (chatbot)

2. Agente que mora (contexto persistente)

3. Agente que constrói onde mora (auto-melhoria do próprio sistema)

Estamos no passo 2 indo pro 3. E a casa é o seu HD.

🚀 Sua missão para os próximos 7 dias

1. Endereço fixo — Abra seu diretório de trabalho principal. Crie um MEMORY.md — um índice curado do que importa. Não é documentação. É o briefing que o agente lê quando "acorda."

1. Duas camadas — Separe um arquivo de log diário (bruto, tudo que acontece) e o MEMORY.md (curado, só o essencial). Dê ao agente permissão de escrever no curado. Observe o que ele escolhe manter.

1. Read before write — Antes de qualquer task, faça o agente ler o contexto relevante do filesystem. Não dê o contexto no prompt — faça ele buscar. Meça a diferença na qualidade.

📚 Conteúdos Recomendados

• 📄 Paper: Lost in the Middle: How Language Models Use Long Contexts — Liu et al. — O paper que documentou por que mais contexto pode significar menos qualidade.

• 📰 Newsletter anterior: #76 — GasCity & Gestão Multi-Agente — A edição sobre o orquestrador. Esta complementa com o substrato — o que os agentes leem e escrevem.

• 📄 Artigo: Effective Context Engineering for AI Agents — Anthropic — Guia oficial de como curar contexto. "Cada token precisa ganhar seu lugar."

• 📄 Artigo: Zero Framework Cognition — Steve Yegge — Por que raciocínio e decisão devem viver no modelo, não no código.

Forte abraço,

Equipe Olympus