3.1 — Silver Platters

📋 O que é um Silver Platter

Um Silver Platter é um arquivo de texto estruturado — geralmente Markdown — que resume uma área de negócio em formato pronto para consumo por agentes. É pré-processado por humanos ou por código determinístico, não gerado on-the-fly pelo LLM. É a bandeja pronta: você coloca na frente do agente e ele tem tudo que precisa para raciocinar sem precisar varrer arquivos brutos.

🍽️ A metáfora da bandeja

Imagine um chef de cozinha. Ele não vai ao mercado durante o serviço — a mise en place já está pronta. Silver Platter é a mise en place do agente:

•Dado já processado — números calculados por Python, não estimados pelo LLM.
•Estrutura previsível — o agente sabe exatamente onde encontrar o KPI de vendas.
•Contexto relevante — só o que o agente precisa, sem ruído de arquivos irrelevantes.
•Timestamp explícito — o agente sabe se o dado é de hoje ou de uma semana atrás.

📊 Por que isso importa

Sem Silver Platters, agentes cometem erros previsíveis:

Alucinação numérica — LLM inventa KPIs que não existem no dado bruto.
Perda de contexto — janela de contexto explode tentando ler CSVs inteiros.
Dado desatualizado — agente usa memória de treino, não dado real do negócio.
Latência — cada chamada precisa reprocessar tudo do zero.

🔄 Bruto → Silver Platter → Agente

O fluxo tem três estágios claramente separados. Dados brutos (vendas.csv, campanhas.xlsx, contratos.pdf, logs de sistema) passam por uma etapa de preparação (Python, SQL, scripts) e geram Silver Platters estruturados que o agente consome. Esses estágios não devem se misturar.

Dados Brutos (Pantry)

Fontes originais — não tocar diretamente no contexto do agente

vendas.csv, meta_ads.json, contratos.pdf, planilha_rh.xlsx, logs.jsonl — dados como vieram dos sistemas.

Preparação (Prep Table)

Python, SQL, scripts determinísticos — nunca LLM para números

# Exemplo: gerar silver platter de marketing
df = pd.read_csv('meta_ads.csv')
kpis = {
  'cac': df['gasto'].sum() / df['conversoes'].sum(),
  'roas': df['receita'].sum() / df['gasto'].sum(),
  'melhor_campanha': df.sort_values('roas').iloc[-1]['nome']
}
# Escreve o .md com timestamp
write_platter('marketing.md', kpis, datetime.now())

Silver Platter (Plate)

O arquivo .md que o agente lê — compacto, preciso, timestampado

marketing.md, financeiro.md, operacoes.md, clientes.md — um arquivo por domínio.

📐 Estrutura padrão de um Silver Platter

Um Silver Platter bem estruturado tem seções fixas que o agente aprende a navegar. Sem padronização, cada platter vira uma surpresa — o agente perde tempo inferindo onde está o dado. Schema implícito é débito técnico.

📄 Template canônico

# Silver Platter: Marketing
**Gerado em:** 2026-05-15 08:00 BRT
**Fonte:** meta_ads.csv, google_analytics.json
**TTL:** 24h (regenerar às 07:00)

## Resumo Executivo
CAC atual: R$ 87 (meta: R$ 90 ✅)
ROAS: 3.2x (meta: 3.0x ✅)
Leads mês: 1.847 (meta: 2.000 ⚠️)

## KPIs Principais
| Métrica | Valor | Δ vs mês ant | Status |
|---------|-------|--------------|--------|
| CAC | R$87 | -8% | ✅ |
| ROAS | 3.2x | +5% | ✅ |
| CTR | 2.4% | -0.3pp | ⚠️ |

## Alertas
- CTR caindo há 3 semanas seguidas
- Budget de remarketing 92% consumido

## Oportunidades
- Campanha "Verão" tem ROAS 4.1x — candidata a escalar

## Perguntas em Aberto
- Por que CTR caiu em mobile específico?

💡 Regra de ouro

O Resumo Executivo deve ser suficiente para 80% das perguntas. As seções seguintes são drill-down. Marco (e-commerce) usa essa estrutura para seu CMO Bot consumir todas as manhãs sem depender de dados brutos do Shopify.

🤖 Determinístico vs Generativo

Existe uma linha clara que separa o que deve ser calculado por código e o que pode ser gerado por LLM. Números são determinísticos — Python calcula, nunca o LLM. Narrativa é generativa — o LLM interpreta e explica os números calculados.

✓ Python/SQL faz

✓Somatório de receita, CAC, ROAS
✓Contagem de registros, médias, percentuais
✓Ranking e ordenação de campanha
✓Detecção de anomalia com threshold fixo
✓Timestamp e TTL

✗ LLM NÃO calcula

✗Somar linhas de CSV diretamente
✗Inferir KPIs sem dado estruturado
✗Estimar porcentagens "de cabeça"
✗Decidir se dado está atualizado

💡 O que o LLM faz bem no Silver Platter

Após o Python preencher os KPIs, o LLM escreve o "Resumo Executivo" em linguagem natural, identifica padrões entre métricas e gera as "Perguntas em Aberto". Divisão clara: código computa, LLM interpreta.

⏰ Frescor, TTL e Versionamento

Um Silver Platter sem timestamp é uma bomba-relógio. Dado velho mata análise — o agente responde com segurança usando informação obsoleta. Cada platter deve declarar explicitamente quando foi gerado e quando expira.

📅 TTL por tipo de dado

•KPIs de marketing — TTL 24h. Cron 07:00 diário.
•Pipeline de vendas — TTL 4h. Cron a cada 4 horas em dias úteis.
•Relatório financeiro — TTL 7 dias. Gerado às sextas após fechamento.
•Briefing de cliente (Sally) — TTL por sessão de caso. Regenerado ao abrir novo processo.
•Sumário clínico (Sana) — TTL por visita. Regenerado a cada nova consulta.

📊 Versionamento simples

Não é necessário git para platters. Padrão suficiente:

platters/
  marketing_20260515_0800.md   # versão com timestamp
  marketing_current.md          # symlink para o mais recente
  marketing_20260514_0800.md   # versão anterior (retenção 7 dias)

🌟 Karpathy LLM Wiki — a versão evoluída

Andrej Karpathy propôs em 2025 que agentes deveriam manter uma wiki Markdown viva — compilada incrementalmente a cada nova observação. É o Silver Platter que se autoenriquece: entidades, contradições, sínteses e cross-links crescem com o uso.

📖 Diferença: Platter estático vs Wiki viva

•Platter estático — gerado por script, substitui o anterior. Snapshot.
•LLM Wiki — o agente lê novo dado e atualiza a página relevante, preserva histórico.
•Cross-links — "Campanha A → relacionada a Cliente B → ver também: Contrato C".
•Contradições rastreadas — quando dado novo contradiz antigo, a página registra o conflito.

💡 Quando usar qual

Silver Platters estáticos para operações repetitivas (relatórios diários, KPIs semanais). LLM Wiki para domínios ricos em entidades com histórico longo — casos legais (Sally), histórico clínico (Sana), carteira de clientes (Marco). Comece com Platters, evolua para Wiki quando o volume de entidades cresce.

⚠️ Armadilha da wiki sem governança

Wiki sem TTL e sem curador vira swamp. Defina: quem pode escrever, qual TTL por página, como resolver conflito. Sem isso, o agente confia em dado contraditório e a qualidade degrada silenciosamente.

📋 Resumo do Módulo

✓

Silver Platter = arquivo .md pré-processado — dado pronto para o agente, sem processamento on-the-fly

✓

Fluxo: Bruto → Prep → Platter → Agente — três estágios que nunca se misturam

✓

Estrutura padrão — executivo, KPIs, alertas, oportunidades, perguntas em aberto

✓

Python calcula, LLM interpreta — nunca pedir ao LLM para somar planilhas

✓

TTL e timestamp obrigatórios — dado sem validade declarada é dado não confiável

✓

Karpathy LLM Wiki = evolução — platter que se autoenriquece para domínios com muitas entidades

Próximo Módulo:

3.2 — Pantry / Prep Table / Plate — mapa de dados

← Módulo Anterior Próximo Módulo →