/always-on-agent-inputs — Alimentando Contexto para um Agente Persistente

Você está projetando o que um agente sempre ativo vê, ouve e sabe. A skill de arquitetura gerencia onde a memória reside. Esta skill gerencia o que entra nela — os sinais brutos, como são estruturados, quando o agente acorda e como manter a janela de contexto honesta.

PONTOS DE DECISÃO

SELEÇÃO DA ESTRATÉGIA DE RECUPERAÇÃO

Tipo de Tarefa do Agente → Estratégia de Recuperação

SE conversa/chat:
  ├─ Use prioridade por recência (70% temporal, 30% semântico)
  ├─ Orçamento: 15K histórico de conversa + 4K recall recente
  └─ Ignore arquivo a menos que o usuário peça "lembre quando..."

SE resolução de problemas/depuração:
  ├─ Use prioridade por relevância (60% semântico, 40% temporal)
  ├─ Orçamento: 8K arquivo + 4K recall + 2K ambiente
  └─ Inclua padrões de erro de soluções passadas

SE mudança de contexto detectada:
  ├─ Use prioridade por frequência (no que o usuário mais trabalha?)
  ├─ Orçamento: 6K contexto do projeto + 2K recente + 4K metas
  └─ Busque histórico de entidades para arquivos/pessoas ativos

SE acionador agendado (briefing matinal):
  ├─ Use agenda estruturada (calendário + tarefas + atualizações)
  ├─ Orçamento: 4K calendário + 4K tarefas inacabadas + 2K mudanças
  └─ Nenhum histórico de conversa necessário

SE acionador reativo (falha de CI, início de reunião):
  ├─ Use carregamento de contexto específico do evento
  ├─ Orçamento: 8K contexto do evento + 4K histórico relacionado
  └─ Ignore conversa geral a menos que relevante

FILTRAGEM DE DADOS AMBIENTE

Observação de Tela/Áudio → Decisão de Filtro

SE mesmo app + mesmo texto por >5 minutos:
  └─ DESCARTAR (sem mudança, ruído)

SE troca de app detectada:
  ├─ MANTER registro de transição
  └─ Pontuar relevância do conteúdo do novo app

SE palavras-chave de alto sinal encontradas:
  ├─ Verificar contra projetos/metas ativos
  ├─ SE pontuação de correspondência >0.6 → ARMAZENAR em arquivo + recall
  ├─ SE pontuação de correspondência 0.3-0.6 → ARMAZENAR apenas em recall
  └─ SE pontuação de correspondência <0.3 → DESCARTAR

SE erro/técnico exceção visível:
  ├─ SEMPRE ARMAZENAR (contexto de depuração)
  └─ Marcar com nível de urgência

SE evento de calendário mencionado:
  ├─ SEMPRE ARMAZENAR (âncora temporal)
  └─ Referência cruzada com calendário real

ATRIBUIÇÃO DE URGÊNCIA DE ACIONADOR

Tipo de Evento + Contexto → Nível de Urgência

SE falha de CI:
  ├─ Branch de produção → ATIVO (notificar usuário)
  ├─ Branch de funcionalidade + usuário codificando atualmente → PASSIVO (mencionar quando usuário engajar novamente)
  └─ Branch antigo/PR → SILENCIOSO (apenas registrar)

SE reunião iniciando:
  ├─ <5 minutos → ATIVO (interromper com preparação)
  ├─ 5-15 minutos → SELO (mostrar preparação disponível)
  └─ >15 minutos → SILENCIOSO (preparação em segundo plano)

SE mudança de código detectada:
  ├─ Primeiro commit em nova branch → PASSIVO (notar novo trabalho)
  ├─ Commit corrige erro anterior → PASSIVO (notar resolução)
  └─ Commits regulares → SILENCIOSO (acompanhar progresso)

SE mencionado no Slack:
  ├─ Mensagem direta → ATIVO (resposta necessária)
  ├─ Menção em canal + palavras-chave urgentes → ATIVO
  └─ Menção em canal, normal → SELO (revisar quando conveniente)

MODOS DE FALHA

Inchaço de Esquema

Sintomas: Janela de contexto constantemente no máximo, respostas lentas, altos custos de token apesar da filtragem
Causa Raiz: Esquemas de observação capturam todos os campos em vez de apenas o que o agente precisa para raciocinar
Regra de Detecção: Se o tamanho médio do contexto >50K tokens ou armazenamento de observação >1MB/dia, você tem inchaço de esquema
Correção: Auditar esquemas a cada mês. Remover campos que não influenciaram uma decisão em 30 dias. Usar sumarização em vez de armazenamento bruto.

Thrashing de Recuperação

Sintomas: Agente menciona informações desatualizadas, perde contexto recente ou recupera memórias irrelevantes repetidamente
Causa Raiz: Busca vetorial de passagem única sem reclassificação, ou pesos temporais/semânticos mal ajustados
Regra de Detecção: Se >30% do contexto recuperado não for usado nas respostas, ou o usuário corrigir o agente sobre eventos recentes
Correção: Implementar recuperação em dois estágios (busca ampla + reclassificação). Testar A/B diferentes proporções de peso temporal/semântico.

Spam de Acionadores

Sintomas: Usuário desativa notificações do agente, reclama de interrupções ou o agente é ignorado
Causa Raiz: Sem classificação de urgência, ou limites muito baixos para acionadores ativos/interromper
Regra de Detecção: Se o usuário dispensar >50% das notificações ativas, ou o tempo médio entre engajamentos do usuário >4 horas
Correção: Padrão para tudo como silencioso. Deixar o usuário configurar explicitamente o que merece notificação ativa. Rastrear taxas de dispensa.

Estagnação de Contexto

Sintomas: Agente age com base em informações desatualizadas, perde que o usuário mudou de foco/projetos
Causa Raiz: Sem decaimento de frescor no contexto, ou pesos de recuperação não consideram recência o suficiente
Regra de Detecção: Se o agente referencia informações com >7 dias quando existe contexto recente, ou menciona projetos concluídos
Correção: Adicionar decaimento exponencial às pontuações de relevância. Ponderar observações recentes 2-3x mais do que arquivo.

Inundação de Ruído Ambiente

Sintomas: Altos custos, baixa qualidade de resposta, agente menciona contexto de tela irrelevante
Causa Raiz: Dados ambiente brutos ignoram filtragem, ou portões de relevância definidos como muito permissivos
Regra de Detecção: Se observações ambiente compõem >30% das memórias armazenadas, ou custos de token >$10/dia
Correção: Apertar pontuação de relevância. Agrupar observações ambiente em janelas de 5 minutos. Exigir 2+ sinais para confirmar relevância.

EXEMPLOS PRÁTICOS

Cenário: Investigação de Bug de Faturamento com Restrições de Orçamento de Token

Usuário relata: "O cálculo de faturamento está errado para clientes empresariais."

Passo 1: Alocação de Orçamento de Contexto (40K total)

Sistema + Identidade: 4K tokens (fixo)
Memória Principal: 2K tokens (preferências do usuário, projetos ativos)
DECISÃO: Tarefa de resolução de problemas → usar recuperação por relevância primeiro
Alocado: 8K arquivo + 4K recall + 2K ambiente + 15K conversa + 5K buffer de saída

Passo 2: Execução da Estratégia de Recuperação

# Busca semântica ampla por memórias relacionadas a faturamento
candidatos_arquivo = busca_vetorial(
    consulta="cálculo faturamento cliente empresarial erro bug",
    top_k=20,
    filtros={"projeto": ["faturamento", "pagamentos"]}
)

# Reclassificar por relevância real (não apenas similaridade de embedding)
reclassificados = reclassificar_resultados(candidatos_arquivo, consulta, top_k=5)
# Resultado: Obtém "bug de lógica de desconto empresarial de 3 semanas atrás"
# que a busca vetorial pura classificou como #12

# Busca temporal por trabalho recente em faturamento
trabalho_recente = busca_temporal(
    intervalo_tempo="últimos_7_dias",
    filtros_entidade=["faturamento", "empresarial"],
    max_resultados=3
)
# Resultado: Usuário estava depurando níveis de preço ontem

Passo 3: Integração de Contexto Ambiente

# Verificar o que o usuário está fazendo atualmente
resumo_tela = obter_resumo_ambiente(últimos_30_minutos)
# Resultado: "Usuário tem billing_calculator.py aberto, olhando para
# função calculate_enterprise_discount()"

# Verificação de orçamento: 8K arquivo + 4K recente + 2K ambiente = 14K (dentro do orçamento)

Passo 4: Compensação entre Rápido vs Completo O agente tem duas opções:

Recuperação rápida (atual): 14K de contexto, foca em padrões de bug recentes
Contexto completo: Adicionar histórico git, discussões de PR relacionadas (+8K tokens, excede orçamento)

Decisão: Manter recuperação rápida para resposta inicial. Se o usuário pedir investigação mais aprofundada, acionar um acompanhamento com orçamento de contexto expandido.

Qualidade da Resposta do Agente:

Abordagem iniciante: Despejaria todo o contexto relacionado a faturamento, excederia orçamento, obteria resposta confusa
Abordagem especialista: 14K selecionados do contexto mais relevante, menciona o bug específico de desconto empresarial de 3 semanas atrás que a busca vetorial sozinha teria perdido, fica dentro do orçamento

GATES DE QUALIDADE

FRONTEIRAS DE NÃO USO

Use /always-on-agent-inputs para:

Decidir quais dados capturar do ambiente do usuário
Estruturar acionadores e esquemas de observação
Orçamento da janela de contexto e seleção de estratégia de recuperação
Filtrar dados ambiente antes de chegarem ao agente

NÃO use para:

Design de arquitetura de memória (armazenamentos vetoriais, bancos de dados, camadas de memória) → use /always-on-agent-architecture
Ideaçao de aplicativos e casos de uso → use /always-on-agent-applications
Privacidade e segurança dos dados capturados → use /always-on-agent-safety
Técnicas gerais de engenharia de prompt → use /prompt-engineer
Padrões de raciocínio do agente → use /agentic-patterns

curiositech/windags-skills

O que é windags-skills?

Perguntar na sua IA favorita