🪟 Janela de Contexto
A janela de contexto é o que o agente lembra na sessão atual. GPT 5.5 Codex tem 1 milhão de tokens. Mas mesmo com isso, ela enche — e Codex compacta automaticamente quando enche. Saber ler os sinais de degradação é importante.
📊 Como o contexto preenche
🚨 Sinais de contexto degradado
- ⚠️Esquecimento de regra recente — agente reintroduz padrão que você corrigiu há 30 mensagens.
- ⚠️Contradição com decisão anterior — sugere abordagem que vocês tinham descartado juntos.
- ⚠️Perda de tom — começou direto, virou prolixo e pedindo confirmação a cada passo.
- ⚠️Re-leitura desnecessária — abre arquivos que já estavam no contexto.
📌 Quando abrir nova sessão
Sentiu 2 desses sinais? Faça handoff e abra sessão nova. Peça ao agente: "resuma o que foi feito, decisões, próximos passos". Cole isso na nova sessão. Você perde 2 minutos e ganha 2 horas de produtividade limpa.
💾 Memory Persistente
Memória que sobrevive entre sessões. Você salva fatos sobre você (preferências, atalhos, padrões); o agente recupera no próximo chat. Mas memória inchada vira ruído — gerenciar é parte do método.
✅ Bom de salvar
- • Stack preferida (Bun, Tailwind, Convex)
- • Tom de comunicação (direto, sem emoji)
- • Cliente recorrente e contexto comercial
- • Atalhos pessoais ("PR padrão" = template X)
- • Fuso horário, idioma, formato de data
❌ Ruim de salvar
- • Detalhes de tarefa pontual
- • Erros temporários ("hoje o servidor caiu")
- • Decisões de projeto específico (vão pro AGENTS.md)
- • Rascunhos de texto
- • Senhas, tokens, secrets (NUNCA)
você: lembre que eu uso Bun em todos os projetos novos
agente: ✓ salvo em memória global
você: o que você lembra sobre mim?
agente: 1. Usa Bun em projetos novos
2. Tom direto, sem emoji
3. Cliente principal: clínicas de estética em SP
4. Fuso BRT, formato data DD/MM/AAAA
você: esquece o item 3, mudei de nicho
agente: ✓ removido
📌 Auditoria mensal
Toda primeira segunda do mês, peça: "liste tudo o que você lembra sobre mim". Leia. O que está obsoleto, mande remover. Memória limpa = agente afiado. Memória poluída = sugestões fora de contexto.
🔒 Sandbox: Read-only / Edit / Full-access
Codex permite restringir o que o agente faz no sistema: só ler, editar arquivos, ou ter acesso total (rodar comandos, instalar). Calibrar por contexto é segurança operacional.
Read-only
Lê arquivos. Nada além disso.
Edit
Lê + edita arquivos. Não roda comando.
Full-access
Tudo: edita, roda shell, instala, deploya.
⚠️ Riscos de full-access em código de cliente
- →Agente roda
rm -rf node_modulese tira a app do ar. - →Instala lib aleatória que infla bundle e quebra deploy de produção.
- →Faz
git push --forceemmaine perde commits. - →Roda
drop tableem migration sem rollback testado.
📌 Heurística do blast radius
Pergunta: "se o agente fizer besteira agora, o que quebra?". Se a resposta é "nada — é projeto novo na minha pasta": full-access. Se é "produção do meu cliente paga R$ 197/mês": edit. Se é "código do cliente de outra agência": read-only.
🌳 Worktrees do Git
git worktree add cria uma nova pasta com uma branch checada. Cada agente trabalha numa worktree própria. Sem stash, sem trocar branch, sem conflito.
📁 Layout: 4 agentes, 4 worktrees
# criar uma worktree em pasta nova com branch nova
$ git worktree add ../inboxai-feature-auth feat/auth
# listar worktrees
$ git worktree list
/home/nei/projetos/inboxai abc1234 [main]
/home/nei/projetos/inboxai-feature-auth def5678 [feat/auth]
/home/nei/projetos/inboxai-feature-billing 9876fed [feat/billing]
# quando terminar, remover
$ git worktree remove ../inboxai-feature-auth
# prune se algo ficou orfao
$ git worktree prune
📌 Por que isso é game changer
Sem worktree, multiagente é teoria. Com worktree, é prática diária: você abre 4 abas do app Codex, cada uma apontando pra uma pasta diferente, cada uma com um agente trabalhando em paralelo. À noite, faz merge das 4 branches. Seu output 4x.
🤖 Sub-agents
Sub-agente é um agente filho que recebe uma tarefa fechada e devolve o resultado. Útil para paralelismo e isolamento de contexto. Tem overhead — saber a hora certa é a diferença entre 4x mais rápido e 2x mais lento.
🎯 Quando delegar a um sub-agent
| Cenário | Delegar? | Por quê |
|---|---|---|
| Pesquisar 5 arquivos em paralelo | ✓ sim | Paralelismo real, ganha tempo |
| Tarefa que polui contexto principal | ✓ sim | Sub-agent isola, devolve só resumo |
| Auditoria longa de codebase | ✓ sim | Resultado caberia em 30k tokens; resumo em 1k |
| Editar 1 arquivo simples | ✗ não | Overhead de delegar > benefício |
| Tarefa interativa que precisa de você | ✗ não | Sub-agent não te pergunta, vai assumir |
⚖️ Custo do sub-agent
- ⏱️Setup: ~5–10s para spin-up. Tarefa de 30s não compensa.
- 📡Sem contexto compartilhado: precisa receber tudo no prompt inicial.
- 💸Custo de tokens: sub-agent reabre contexto, AGENTS.md, skills.
- ✓Ganho: isolamento + paralelismo + contexto principal limpo.
📌 Regra dos 5 minutos
Tarefa que demoraria menos de 5 minutos no agente principal: faça lá. Tarefa que demoraria mais de 5 minutos e dá pra paralelizar ou poluiria contexto: delega pra sub-agent. É a heurística mais simples e funciona em 90% dos casos.
⚠️ Erros Caros Multiagente
Os três acidentes clássicos. Cada um pode custar horas de retrabalho ou pior — perda de dados de cliente. Reconhecer o padrão antes de cometer é proteção barata.
💥 Erro 1: Dois agentes na mesma branch
Dois agentes editam, fazem commit e push. O segundo recebe rejeição ou pior — sobrescreve trabalho.
1 agente = 1 worktree = 1 branch. Sempre. Sem exceção.
💥 Erro 2: Dois agentes no mesmo arquivo
Mesmo em worktrees diferentes, se ambos editam app/page.tsx, o merge vira pesadelo. Você perde 30 minutos resolvendo conflito.
Quebra a tarefa por área. Agente A em /billing, agente B em /dashboard. Sem overlap.
💥 Erro 3: Sandbox errado deleta coisa
Agente em full-access "limpa" arquivos achando que são lixo — apaga .env ou pasta de uploads do cliente.
Lista .env*, /uploads, /data em "Não Faça" do AGENTS.md. Use edit (não full) em código de cliente.
🛡️ Checklist anti-acidente multiagente
- ✓Cada agente tem worktree própria
- ✓Cada agente tem branch própria, nomeada por feature
- ✓Tarefas particionadas por área (sem overlap de arquivos)
- ✓Sandbox calibrado por blast radius do projeto
- ✓AGENTS.md tem seção "Não Faça" listando paths sensíveis
- ✓Pre-commit hook bloqueia
.env*e*.key - ✓Backup do
mainantes de mergear sessão multiagente
💡 A regra do "primeiro multiagente"
No seu primeiro projeto multiagente, faça 2 agentes em paralelo, não 4. Aprenda a coreografia. Quando 2 agentes funcionam fluidos, suba pra 4. Pular direto pra 4 multiplica os erros antes de você desenvolver intuição.
✅ O que Aprendemos
Próxima Trilha:
Trilha 3 — Frontend Agentic. Componentes, design system, animações, browser embutido pra QA visual, deploy de landing em 1h. A linguagem dos agentes vira produto vendável.