Context Lattice: coordenar vários squads de IA sem perder o fio

Quando você coloca o segundo agente, descobre que IA é um problema de contexto. Quando coloca o quinto, descobre que é um problema de coordenação de contexto. O primeiro se resolve com prompt melhor. O segundo, não.

A pergunta que aparece é simples: como dois ou mais agentes trabalham em paralelo na mesma feature sem que o trabalho de um sobrescreva o do outro, e sem que cada um precise reler tudo o que aconteceu antes para entender o estado atual?

A resposta que tenho usado é o que passei a chamar de context lattice: uma grade de arquivos lat.md versionados que servem de fonte canônica de contexto. Não é original. É um remix de design docs, ADRs¹ e do que o pessoal de spec-driven development chama de “cérebro compartilhado”. Mas a ideia ganha dentes quando você põe vários agentes do Claude Code (ou Codex, ou Cursor, tanto faz) lendo e escrevendo no mesmo lattice em paralelo.

O problema concreto

Imagine este cenário, que é real: você está implementando uma feature de PIX no e-commerce. A feature toca quatro áreas:

1. Backend: endpoint de criação da cobrança, webhook de confirmação, idempotência.
2. Frontend: fluxo de checkout, polling de status, fallback de timeout.
3. Operação: observabilidade, alarme de taxa de falha, dashboard.
4. Integração: adapter do PSP, política de retry, dead letter queue.

Cada uma pode ser atacada por um agente diferente, em paralelo. Mas todas têm que concordar sobre:

• O formato do payload em trânsito.
• A chave de idempotência (e como ela é gerada).
• Os estados possíveis da cobrança e as transições válidas entre eles.
• O que acontece quando o webhook chega antes da resposta do POST de criação.

Se cada agente decide isso por conta própria, você termina com quatro implementações que conversam entre si como quem acabou de se conhecer.

A estrutura do lattice

Um arquivo lat.md tem três seções, sempre nesta ordem:

# Lattice — feature/pix-checkout

## Intent
What we're building, in one sentence. Why. For whom.
No epic, no JIRA, no story points.

## Decisions
Decisions made that affect more than one piece.
Each decision is one line: "[2026-04-21] Idempotency via SHA256(orderId+psp).
Reason: PSP X returns 502 sometimes, we want retry with no side effect."

## Open questions
Things we haven't decided yet but will need to.
Named, not vague. "Q1: webhook arrives before the POST — ignore or
buffer 30s?"

Todo agente, antes de começar, lê o lat.md da feature. Todo agente, ao tomar uma decisão que afeta as outras áreas, registra em Decisions. Todo agente, ao esbarrar numa pergunta cuja resposta afeta as outras áreas, registra em Open questions e espera: não decide sozinho.

A regra de ouro: nada em Decisions muda sem você anunciar a mudança. Decisão é commit. Dá para revogar, mas você tem que escrever uma linha nova registrando a revogação.

Por que isso funciona melhor que o JIRA

Três motivos. Primeiro, está em Markdown, no repositório, versionado pelo mesmo Git que versiona o código. Contexto e código viajam juntos. Segundo, está num formato que agentes leem nativamente: não é adapter de API, é só um arquivo. Terceiro, obriga as decisões a serem explícitas. Não dá para “implementar” sem registrar o que você decidiu, porque o próximo agente vai ler.

Comparado com o Slack, o mecanismo de coordenação padrão da maioria dos times, a vantagem é absurda. O Slack é só escrita para o futuro: o que se discutiu ontem está enterrado debaixo de mil mensagens, e ninguém vai garimpar. O lat.md é leitura primeiro.

O detalhe que ninguém menciona

Você precisa de um humano (ou de um meta-agente) revisando os lat.md de tempos em tempos. A pilha de Open questions cresce mais rápido do que você imagina. Sem alguém limpando, fechando e promovendo Open → Decision, o lattice vira um cemitério de TODOs.

No meu setup, o último passo de cada ciclo de trabalho é um agente específico, que chamo de lattice-curator. Ele lê todos os lat.md ativos e me pergunta: quais Open questions já podem ser resolvidas com base no que está implementado? Quais Decisions conflitam com o código que foi escrito? É um agente de manutenção, e é a peça mais subestimada do sistema.

Onde isso encosta no real

Se você está no Claude Code, o jeito mais barato de testar é colocar um arquivo lat.md na raiz da feature e instruir cada subagente a ler antes de começar e escrever ao terminar. A documentação de subagentes do Claude Code explica como o despacho funciona; o lattice é o que deixa o despacho coerente.

Se você está direto no SDK, a documentação do Agent SDK tem exemplos de passagem de contexto compartilhado. Adapte: passe o conteúdo do lat.md como mensagem de sistema inicial e dê ao agente uma ferramenta update_lattice(section, content) que grava de volta no arquivo.

Não é mágica. É só reconhecer que contexto compartilhado precisa morar em algum lugar, e esse lugar não pode ser a memória individual de cada agente, porque agentes não compartilham memória. Compartilham um sistema de arquivos.