Inicio / Trilha 2 / Modulo 2.5
MODULO 2.5

🧠 Contexto Global vs por Agente

Neste modulo voce vai entender como o contexto define o comportamento de cada agente. Da hierarquia de system prompts ate estrategias de compactacao, o gerenciamento de contexto e o que separa um chatbot basico de uma plataforma de agentes inteligente que escala sem estourar custos.

6
Topicos
50
Minutos
Intermediario
Nivel
Teoria+Pratica
Tipo
1

💬 O que e Contexto em Sistemas de IA

Contexto e tudo que o modelo sabe no momento de gerar uma resposta. Nao e so o que o usuario acabou de digitar. E a soma de instrucoes do sistema, historico de conversa, dados do usuario, resultados de ferramentas e qualquer informacao que molde o comportamento do modelo. Controlar o contexto e controlar o agente.

Conceito Principal

O contexto de um modelo de linguagem e composto por quatro camadas distintas, cada uma com um papel na formacao da resposta:

System Prompts: As instrucoes fundamentais que definem quem o agente e, como ele se comporta, o que ele pode e nao pode fazer. Sao carregadas antes de qualquer interacao com o usuario. Um system prompt bem escrito e como um briefing detalhado para um funcionario novo: define o papel, as regras e as expectativas.

Conversation History: O registro de mensagens trocadas entre usuario e agente na sessao atual. Cada mensagem anterior consome tokens da context window. Uma conversa com 50 turnos pode facilmente consumir 20.000+ tokens so em historico, antes de qualquer novo processamento.

User Data: Informacoes sobre o usuario que nao vem da conversa: nome, preferencias, plano de assinatura, timezone, idioma, historico de interacoes anteriores. Esses dados enriquecem as respostas sem que o usuario precise repetir informacoes a cada sessao.

Tool Results: Quando um agente chama uma ferramenta (buscar email, consultar banco, pesquisar na web), o resultado entra no contexto como uma mensagem do tipo "tool". O modelo usa esse resultado para formular a resposta final. Um unico resultado de busca pode adicionar 5.000+ tokens ao contexto.

// Anatomia completa de um request a API
const messages = [
  // 1. System Prompt (~500-2000 tokens)
  {
    role: 'system',
    content: `Voce e o assistente da plataforma AgentSaaS.
    Regras: responda em portugues, seja direto, nunca invente dados.
    Usuario: ${user.name}, plano ${user.plan}, timezone ${user.tz}.`
  },

  // 2. Historico de conversa (~100-500 tokens por turno)
  { role: 'user', content: 'Quantos emails recebi hoje?' },
  { role: 'assistant', content: 'Deixa eu verificar seus emails.' },

  // 3. Tool Results (~200-5000 tokens por resultado)
  {
    role: 'tool',
    tool_call_id: 'call_abc123',
    content: JSON.stringify({
      total: 12,
      unread: 3,
      important: ['Reuniao amanha 14h', 'Fatura vencendo']
    })
  },

  // 4. Nova mensagem do usuario (~10-500 tokens)
  { role: 'user', content: 'Algum urgente?' }
];

// Token budget: model_limit - system - history - tools = disponivel
// Ex: 128K - 1K - 8K - 3K = 116K disponivel para resposta

Dados e Pesquisa

A context window dos modelos evoluiu de 4K tokens (GPT-3.5 original) para 200K tokens (Claude 3.5) e 1M tokens (Gemini 1.5 Pro) em apenas 2 anos. Porem, pesquisa de Stanford ("Lost in the Middle", 2023) demonstrou que modelos perdem ate 30% de accuracy quando a informacao relevante esta no meio de contextos longos. O "sweet spot" para qualidade de resposta esta entre 2K e 32K tokens de contexto efetivo. Cada token de contexto custa dinheiro: a $3/MTok de input, uma conversa com 100K tokens de contexto custa $0.30 por request.

Dica Pratica

Monitore o consumo de tokens por request. Adicione um log que registra quantos tokens de contexto cada chamada usa. Quando o contexto passar de 50% do limite do modelo, e hora de compactar. Em producao, mantenha um "token budget" por agente: o agente de pesquisa pode usar ate 50K tokens (precisa de muito contexto), mas o agente de classificacao nao deve passar de 4K (precisa ser rapido e barato).

Fazer

Entender exatamente o que compoe o contexto de cada request. Monitorar consumo de tokens. Definir token budgets por tipo de agente. Colocar informacao critica no inicio e no final do contexto, nunca no meio.

Evitar

Tratar contexto como infinito. Jogar toda informacao disponivel no prompt sem filtrar relevancia. Ignorar o custo de tokens de contexto. Nao monitorar quanto contexto cada agente esta consumindo.

2

📋 Hierarquia de System Prompts

System prompts nao sao um unico bloco de texto. Em uma plataforma multi-agente, eles formam uma hierarquia de instrucoes que herdam, sobrescrevem e especializam comportamento. Pensar em system prompts como camadas de heranca e o que permite escalar de 1 para 20 agentes sem copiar e colar instrucoes.

Conceito Principal

A hierarquia de prompts funciona em tres niveis, do mais geral para o mais especifico:

Nivel 1 - Global Instructions: Regras que se aplicam a todos os agentes sem excecao. Identidade da plataforma, politicas de seguranca, formato padrao de resposta, restricoes legais. Esse nivel vive em um arquivo unico (ex: prompts/global.md) e e carregado para todo agente.

Nivel 2 - Agent Role: Instrucoes especificas de cada agente. O agente de pesquisa sabe buscar na web e citar fontes. O agente de comunicacao sabe escrever emails e formatar mensagens. Cada agente tem seu arquivo (ex: prompts/agents/research.md) com dominio, tom, ferramentas e restricoes locais.

Nivel 3 - Task-Specific: Instrucoes injetadas dinamicamente com base na tarefa atual. Se o usuario pede "resuma este PDF", o sistema injeta instrucoes especificas de sumarizacao. Se pede "agende uma reuniao", injeta instrucoes de calendario. Esse nivel e montado em runtime.

// prompts/global.md
# Regras Globais da Plataforma

Voce faz parte da plataforma AgentSaaS.
- Responda sempre em portugues brasileiro
- Nunca invente informacoes. Se nao sabe, diga
- Nunca execute acoes destrutivas sem confirmacao
- Formate respostas para Telegram (texto limpo, sem markdown pesado)
- Proteja dados do usuario. Nunca exponha dados de outros usuarios

---

// prompts/agents/research.md
# Agente de Pesquisa

Voce e o agente de pesquisa da plataforma.
Seu dominio: buscar, analisar e sintetizar informacoes.

## Ferramentas disponiveis
- web_search: buscar na web
- read_url: ler conteudo de uma URL
- summarize: resumir textos longos

## Regras especificas
- Sempre cite a fonte das informacoes
- Priorize fontes oficiais e recentes
- Se os resultados sao ambiguos, apresente as opcoes

---

// prompts/tasks/summarize.md
# Tarefa: Sumarizacao

Para esta tarefa especifica:
- Extraia os 3-5 pontos principais
- Use bullet points
- Limite a resposta a 200 palavras
- Inclua uma frase de conclusao

A composicao acontece em runtime. O sistema carrega global + agent + task e concatena na ordem. Se houver conflito, o nivel mais especifico vence. Se o global diz "responda em portugues" e o agent role diz "for technical terms, keep English", o agente vai responder em portugues usando termos tecnicos em ingles.

// lib/prompt-builder.ts
import { readFileSync } from 'fs';
import { join } from 'path';

const PROMPTS_DIR = join(process.cwd(), 'prompts');

export function buildSystemPrompt(
  agentId: string,
  taskType?: string,
  userContext?: Record<string, string>
): string {
  const layers: string[] = [];

  // Nivel 1: Global (sempre presente)
  layers.push(readFileSync(join(PROMPTS_DIR, 'global.md'), 'utf-8'));

  // Nivel 2: Agent role
  const agentPromptPath = join(PROMPTS_DIR, 'agents', `${agentId}.md`);
  try {
    layers.push(readFileSync(agentPromptPath, 'utf-8'));
  } catch {
    // Agent sem prompt especifico usa apenas o global
  }

  // Nivel 3: Task-specific (se aplicavel)
  if (taskType) {
    const taskPromptPath = join(PROMPTS_DIR, 'tasks', `${taskType}.md`);
    try {
      layers.push(readFileSync(taskPromptPath, 'utf-8'));
    } catch {
      // Sem prompt de tarefa especifica
    }
  }

  // Injetar contexto do usuario
  let prompt = layers.join('\n\n---\n\n');
  if (userContext) {
    for (const [key, value] of Object.entries(userContext)) {
      prompt = prompt.replace(`{{${key}}}`, value);
    }
  }

  return prompt;
}

Dados e Pesquisa

A Anthropic documenta que system prompts sao processados com "prioridade elevada" pelo modelo, tendo mais influencia que mensagens do usuario no comportamento geral. OpenAI reporta que system prompts com instrucoes estruturadas (headers, listas, delimitadores claros) geram aderencia 40% maior do que blocos de texto corrido. O padrao de heranca de prompts e usado por plataformas como AutoGPT, CrewAI e Microsoft Semantic Kernel. Manter prompts versionados em arquivos separados permite A/B testing de instrucoes sem alterar codigo.

Dica Pratica

Trate prompts como codigo: versione no git, faca review, teste antes de deployar. Uma mudanca de uma palavra no system prompt pode alterar drasticamente o comportamento do agente. Use delimitadores claros (--- ou headers markdown) entre as camadas para que o modelo saiba onde cada bloco comeca e termina. Teste cada prompt isoladamente antes de compor. Se o prompt global ja funciona bem, adicione o agent role e teste novamente. Adicione complexidade incremental.

Fazer

Criar prompt global com regras universais. Criar prompt por agente com especializacao. Compor em runtime com funcao reutilizavel. Versionar prompts no git como arquivos markdown. Usar delimitadores claros entre camadas.

Evitar

Hardcodar prompts dentro do codigo TypeScript. Copiar as mesmas instrucoes em multiplos arquivos de agente. Criar prompts enormes sem estrutura ou delimitadores. Mudar prompts em producao sem testar primeiro.

3

🔗 Contexto Compartilhado

Em uma plataforma multi-agente, alguns dados precisam ser acessiveis por todos os agentes. O perfil do usuario, seu plano de assinatura, suas preferencias de idioma. Se cada agente mantivesse sua propria copia desses dados, a plataforma viraria um caos de informacoes desatualizadas e inconsistentes.

Conceito Principal

O contexto compartilhado e o estado que multiplos agentes precisam ler (e as vezes escrever). Ele funciona como uma area comum em um escritorio: todos podem consultar, mas as regras de acesso sao claras.

Os tipos mais comuns de contexto compartilhado sao:

User Profile: Nome, email, plano, timezone, idioma preferido. Todos os agentes precisam saber quem esta falando para personalizar respostas. Armazenado no banco de dados, carregado uma vez por sessao.

Subscription & Limits: Qual plano o usuario tem, quantos requests ja usou no mes, quais features estao disponiveis. O agente de pesquisa precisa saber se o usuario tem cota de busca. O agente de codigo precisa saber se pode usar modelos premium.

User Preferences: Formatacao preferida, topicos de interesse, horarios de notificacao. Detectadas ao longo do tempo e armazenadas para enriquecer respostas futuras.

// context/shared.ts - Global Context Store
interface SharedContext {
  user: {
    id: string;
    name: string;
    email: string;
    plan: 'free' | 'pro' | 'enterprise';
    timezone: string;
    locale: string;
  };
  limits: {
    requestsRemaining: number;
    tokensRemaining: number;
    canUseTools: boolean;
    canUsePremiumModels: boolean;
  };
  preferences: {
    responseFormat: 'concise' | 'detailed';
    notifyVia: 'telegram' | 'email' | 'both';
    topics: string[];
  };
}

// Implementacao com diferentes backends
class ContextStore {
  // Em memoria (dev, single-instance)
  private cache = new Map<string, SharedContext>();

  // Redis (producao, multi-instance)
  // private redis: Redis;

  async get(userId: string): Promise<SharedContext> {
    // 1. Verificar cache em memoria (mais rapido)
    if (this.cache.has(userId)) return this.cache.get(userId)!;

    // 2. Verificar Redis (compartilhado entre instances)
    // const cached = await this.redis.get(`ctx:${userId}`);
    // if (cached) return JSON.parse(cached);

    // 3. Carregar do banco (source of truth)
    const context = await this.loadFromDB(userId);
    this.cache.set(userId, context);
    return context;
  }

  async update(userId: string, partial: Partial<SharedContext>) {
    const current = await this.get(userId);
    const updated = { ...current, ...partial };
    this.cache.set(userId, updated);
    // await this.redis.set(`ctx:${userId}`, JSON.stringify(updated), 'EX', 3600);
    await this.saveToDB(userId, updated);
  }
}

Dados e Pesquisa

Redis e usado como cache de contexto por 85% das plataformas multi-agente em producao, com latencia media de 0.1ms para leitura. A arquitetura CQRS (Command Query Responsibility Segregation) usada por plataformas como Discord e Slack separa leitura de escrita de contexto, permitindo que milhares de agentes leiam simultaneamente sem conflito. O padrao de eventual consistency (onde diferentes agentes podem ver versoes ligeiramente diferentes do contexto por breves periodos) e aceitavel para a maioria dos casos. Para dados criticos como saldo de tokens, strong consistency via transacoes do banco e obrigatorio.

Dica Pratica

Comece com um Map em memoria para desenvolvimento. Quando o projeto precisar de multiplas instancias (mais de um servidor), migre para Redis. A interface do ContextStore nao muda. Para o contexto injetado no prompt, gere um texto resumido em vez de jogar o JSON inteiro. "Usuario: Joao, plano Pro, timezone BRT, prefere respostas concisas" e mais eficiente em tokens e mais facil para o modelo processar do que um JSON com 20 campos.

Fazer

Centralizar dados do usuario em um ContextStore unico. Cachear contexto em memoria com TTL. Converter para texto resumido antes de injetar no prompt. Definir claramente quais dados sao compartilhados vs privados.

Evitar

Cada agente carregar dados do usuario do banco independentemente. Jogar o objeto JSON inteiro no prompt. Compartilhar dados que deveriam ser privados de um agente. Nao ter cache (carregar do banco a cada request).

4

🔐 Contexto Isolado por Agente

Se o contexto compartilhado e o que todos precisam saber, o contexto isolado e o que so um agente especifico deve saber. Isolamento de contexto e um principio de seguranca e eficiencia: cada agente opera no seu dominio, com suas ferramentas e suas memorias, sem poluir ou ser poluido por outros.

Conceito Principal

O isolamento de contexto opera em quatro dimensoes:

API Keys Isoladas: Cada agente pode ter suas proprias credenciais. O agente de pesquisa tem sua propria chave de busca com limite de rate separado. O agente de email tem seu proprio OAuth token. Se uma chave vaza, o dano e contido ao escopo daquele agente.

Memorias Separadas: Cada agente tem seu proprio namespace de memoria. O que o agente de pesquisa descobriu em sessoes anteriores nao contamina a memoria do agente de comunicacao. Isso evita que um agente "alucine" com contexto de outro dominio.

Capabilities Restritas: Cada agente so tem acesso as ferramentas que precisa. O agente de leitura nao pode escrever. O agente de email nao pode executar codigo. O principio do minimo privilegio aplicado a ferramentas de IA.

Namespace Isolation: Todas as operacoes de um agente sao prefixadas com seu ID. Chaves no Redis: agent:research:memory:user123. Tabelas no banco: agent_memories com coluna agent_id. Logs: [research] Processing query....

// agents/base.ts - Agent com contexto isolado
interface AgentConfig {
  id: string;
  name: string;
  provider: AIProvider;
  tools: Tool[];
  memoryNamespace: string;
  apiKeys: Record<string, string>;
}

class Agent {
  constructor(private config: AgentConfig) {}

  // Cada agente tem suas proprias credenciais
  private getApiKey(service: string): string {
    return this.config.apiKeys[service]
      || env[`${this.config.id.toUpperCase()}_${service}_KEY`]
      || env[`${service}_KEY`]; // fallback global
  }

  // Memoria isolada por namespace
  async getMemories(userId: string): Promise<Memory[]> {
    return db.query(
      'SELECT * FROM agent_memories WHERE agent_id = ? AND user_id = ?',
      [this.config.id, userId]
    );
  }

  async saveMemory(userId: string, content: string): Promise<void> {
    await db.insert('agent_memories', {
      agent_id: this.config.id,
      user_id: userId,
      content,
      created_at: new Date(),
    });
  }

  // Apenas as tools autorizadas
  getAvailableTools(): Tool[] {
    return this.config.tools; // Nao tem acesso a tools de outros agentes
  }
}

// Configuracao dos agentes com isolamento
const researchAgent = new Agent({
  id: 'research',
  name: 'Agente de Pesquisa',
  provider: openrouter, // Provider mais barato para pesquisa
  tools: [webSearch, readUrl, summarize],
  memoryNamespace: 'research',
  apiKeys: { SERPER: env.RESEARCH_SERPER_KEY },
});

const commsAgent = new Agent({
  id: 'comms',
  name: 'Agente de Comunicacao',
  provider: ollama, // Local, privado
  tools: [sendEmail, readEmail, formatMessage],
  memoryNamespace: 'comms',
  apiKeys: { GMAIL: env.COMMS_GMAIL_TOKEN },
});

Dados e Pesquisa

O principio do minimo privilegio (PoLP) e um dos fundamentos de seguranca da informacao, formalizado pelo Departamento de Defesa dos EUA nos anos 70 e adotado como padrao por NIST, ISO 27001 e SOC 2. Em sistemas multi-agente, pesquisa da DeepMind mostra que agentes com escopo restrito de ferramentas cometem 60% menos erros do que agentes com acesso total. A Microsoft usa isolamento de namespace por agente no Copilot para garantir que dados de um usuario nunca vazem para o contexto de outro. O padrao de "sandbox per agent" e recomendado pela OWASP para LLM Applications.

Dica Pratica

Comece restritivo e abra conforme necessario. Crie cada agente com zero tools e adicione uma por vez, testando se funciona corretamente. E muito mais facil adicionar uma permissao do que descobrir qual permissao excessiva causou um problema. Para comunicacao entre agentes (quando um precisa de dados do outro), use um message bus explicito em vez de acesso direto ao contexto. O agente de pesquisa envia o resultado para o orquestrador, que decide se e quando repassar ao agente de comunicacao.

Fazer

Dar a cada agente apenas as tools que precisa. Isolar memorias por namespace. Usar chaves de API separadas quando possivel. Comunicar entre agentes via orquestrador, nunca diretamente.

Evitar

Dar todas as tools para todos os agentes. Compartilhar o mesmo namespace de memoria entre agentes diferentes. Permitir que agentes acessem credenciais de outros agentes. Criar um "super agente" com acesso a tudo.

5

📊 Context Window Management

A context window e finita e cara. Toda mensagem, todo resultado de tool, todo dado do usuario consome tokens desse espaco limitado. Gerenciar a context window e uma habilidade de engenharia: decidir o que entra, o que sai, e quando compactar a conversa para manter qualidade sem estourar custos.

Conceito Principal

Existem quatro estrategias principais para gerenciar a context window, cada uma apropriada para cenarios diferentes:

1. Sliding Window: Manter apenas as N ultimas mensagens da conversa. Simples e previsivel. Funciona bem para conversas curtas e diretas. Desvantagem: perde completamente o contexto de mensagens mais antigas. Se o usuario mencionou algo 20 mensagens atras, o agente nao vai lembrar.

2. Summarization (Compactacao): Quando o historico atinge um threshold (ex: 60% da context window), o sistema gera um resumo das mensagens mais antigas e substitui as mensagens originais pelo resumo. O resumo captura decisoes, fatos e contexto importante em uma fracao dos tokens. E a estrategia mais usada em producao.

3. RAG (Retrieval-Augmented Generation): Em vez de manter todo o historico no contexto, armazene as mensagens em um vector database e recupere apenas as partes relevantes para a pergunta atual. Ideal para conversas longas e recorrentes. O usuario pode perguntar sobre algo discutido semanas atras e o sistema encontra o trecho relevante.

4. Reset Strategico: Para certos agentes, comecar uma sessao limpa e a melhor opcao. O agente de classificacao nao precisa de historico. O agente de pesquisa web pode funcionar melhor sem contexto anterior enviesando os resultados. O reset nao e falha. E design intencional.

// context/manager.ts - Context Window Manager
import { encode } from 'gpt-tokenizer'; // Token counting

interface ContextManagerConfig {
  maxTokens: number;       // Limite do modelo (ex: 128000)
  compactThreshold: number; // Quando compactar (ex: 0.6 = 60%)
  strategy: 'sliding' | 'summarize' | 'rag' | 'reset';
  keepLastN: number;       // Mensagens recentes que nunca sao removidas
}

class ContextManager {
  constructor(private config: ContextManagerConfig) {}

  async manage(messages: Message[]): Promise<Message[]> {
    const totalTokens = this.countTokens(messages);
    const threshold = this.config.maxTokens * this.config.compactThreshold;

    if (totalTokens < threshold) return messages; // Dentro do budget

    switch (this.config.strategy) {
      case 'sliding':
        return messages.slice(-this.config.keepLastN);

      case 'summarize':
        return this.compactWithSummary(messages);

      case 'rag':
        return this.retrieveRelevant(messages);

      case 'reset':
        return [messages[0], ...messages.slice(-2)]; // System + last exchange
    }
  }

  private async compactWithSummary(messages: Message[]): Promise<Message[]> {
    const system = messages[0]; // Preservar system prompt
    const recent = messages.slice(-this.config.keepLastN);
    const old = messages.slice(1, -this.config.keepLastN);

    // Pedir ao modelo para resumir as mensagens antigas
    const summary = await this.summarize(old);

    return [
      system,
      { role: 'system', content: `[Resumo da conversa anterior]\n${summary}` },
      ...recent,
    ];
  }

  private countTokens(messages: Message[]): number {
    return messages.reduce((sum, m) => sum + encode(m.content).length, 0);
  }
}

Dados e Pesquisa

A compactacao por sumarizacao reduz o consumo de tokens em 70-90% com perda de informacao estimada em apenas 5-15% (segundo benchmarks do LangChain). RAG com vector databases (Pinecone, Weaviate, pgvector) consegue recuperar o trecho relevante com 85-95% de accuracy para conversas com milhares de turnos. O custo de processar 128K tokens de contexto e aproximadamente $0.38 na Anthropic e $0.64 na OpenAI. Compactar para 20K tokens reduz esse custo para $0.06 e $0.10 respectivamente. Para um SaaS com 1000 usuarios ativos, a diferenca anual e de milhares de dolares.

Dica Pratica

Use a biblioteca tiktoken (OpenAI) ou gpt-tokenizer (npm) para contar tokens antes de enviar ao modelo. Nunca estime. A contagem real evita erros de "context length exceeded" em producao. Para compactacao, use o modelo mais barato disponivel para gerar o resumo. Nao gaste GPT-4o para resumir historico quando GPT-4o-mini ou um modelo local faz o mesmo com qualidade suficiente. Defina o threshold de compactacao em 60%, nao 90%. Compactar cedo e melhor do que compactar tarde e perder informacao porque o modelo cortou o contexto.

Fazer

Contar tokens reais antes de cada request. Implementar compactacao automatica. Preservar system prompt e mensagens recentes na compactacao. Monitorar tokens por sessao e alertar quando consumo e alto.

Evitar

Enviar historico completo a cada request sem verificar tamanho. Compactar descartando mensagens sem resumir. Usar o modelo mais caro para gerar resumos. Esperar atingir 100% da context window para agir.

6

🛠️ Exercicio: Projetar Contexto do seu SaaS

Hora de aplicar tudo. Neste exercicio voce vai projetar o sistema de contexto completo da sua plataforma: definir o que e global, o que e por agente, como os dados sao compartilhados e qual estrategia de compactacao usar para manter custos sob controle.

Conceito Principal

O exercicio e dividido em 4 entregas que juntas formam o documento de design de contexto da sua plataforma:

Entrega 1 - Mapa de Contexto Global: Escreva o prompt global da sua plataforma (prompts/global.md). Inclua: identidade, regras de seguranca, formato de resposta, restricoes. Teste com pelo menos 2 perguntas diferentes e verifique se o modelo segue as regras.

Entrega 2 - Prompts por Agente: Para cada agente do seu SaaS (minimo 2), crie o arquivo de prompt especifico (prompts/agents/[nome].md). Defina dominio, tom, ferramentas e restricoes. Teste a composicao global + agent e verifique que nao ha conflito.

Entrega 3 - Regras de Compartilhamento: Crie uma tabela que define para cada tipo de dado quem pode ler e quem pode escrever. Exemplo: "user_profile: todos leem, nenhum escreve (vem do auth)". Implemente o SharedContext store com os campos definidos.

Entrega 4 - Estrategia de Compactacao: Defina o token budget por agente, o threshold de compactacao e a estrategia (sliding, summarize, rag, reset) para cada agente. Justifique cada escolha. Implemente o ContextManager basico.

// docs/context-design.md - Template do documento de design

# Design de Contexto - [Nome do SaaS]

## 1. Contexto Global
- Identidade: [Quem e a plataforma]
- Regras universais: [Lista de regras]
- Formato padrao: [Como respostas devem ser formatadas]

## 2. Agentes e seus Contextos
| Agente | Provider | Token Budget | Tools | Estrategia |
|--------|----------|-------------|-------|------------|
| research | openrouter | 50K | web_search, summarize | RAG |
| comms | ollama | 8K | send_email, read_email | sliding |
| coding | claude | 100K | file_read, file_write | summarize |
| classifier | ollama | 4K | - | reset |

## 3. Regras de Compartilhamento
| Dado | Leitura | Escrita | Storage |
|------|---------|---------|---------|
| user_profile | todos | auth service | DB |
| user_preferences | todos | qualquer agente | DB + cache |
| conversation_history | agente da sessao | agente da sessao | DB |
| agent_memories | agente dono | agente dono | DB (namespaced) |

## 4. Compactacao
- Threshold global: 60% da context window
- Modelo para sumarizacao: [modelo barato]
- Frequencia de compactacao: a cada N turnos ou ao atingir threshold
- Dados que nunca sao compactados: system prompt, user profile

Dica Pratica

Nao precisa implementar tudo de uma vez. Comece com o prompt global e um agente. Teste extensivamente. Adicione o segundo agente e verifique que o contexto nao conflita. So entao implemente o SharedContext store e a compactacao. O documento de design e tao importante quanto o codigo. Quando voce tiver 10 agentes e precisar debugar por que um deles esta se comportando estranho, a primeira coisa que vai consultar e o mapa de contexto.

Entregavel

Documento context-design.md com o mapa completo de contexto do seu SaaS. Arquivo prompts/global.md funcional e testado. Pelo menos 2 arquivos prompts/agents/[nome].md com prompts especificos. Funcao buildSystemPrompt() que compoe as camadas. ContextManager basico com pelo menos uma estrategia implementada (recomendado: summarize). Tabela de regras de compartilhamento definindo quem acessa o que.

Resumo Final

✓ Entendeu as quatro camadas de contexto: system prompts, historico, dados do usuario e resultados de tools.

✓ Dominou a hierarquia de system prompts: global, agent role e task-specific com composicao em runtime.

✓ Aprendeu quando e como compartilhar contexto entre agentes usando stores centralizados.

✓ Implementou isolamento de contexto por agente: credentials, memoria, tools e namespace separados.

✓ Conheceu as estrategias de context window management: sliding, summarize, RAG e reset.

✓ Projetou o sistema de contexto completo para seu SaaS com documento de design.