/always-on-agent-inputs — Alimentando Contexto a un Agente Persistente

Estás diseñando lo que un agente siempre activo ve, escucha y conoce. La habilidad de arquitectura maneja dónde vive la memoria. Esta habilidad maneja lo que entra en ella: las señales en bruto, cómo se estructuran, cuándo se despierta el agente y cómo mantener honesta la ventana de contexto.

---\n

PUNTOS DE DECISIÓN

SELECCIÓN DE ESTRATEGIA DE RECUPERACIÓN

Tipo de Tarea del Agente → Estrategia de Recuperación

SI conversacional/charla:
  ├─ Usar prioridad por recencia (70% temporal, 30% semántico)
  ├─ Presupuesto: 15K historial de conversación + 4K recuerdo reciente
  └─ Omitir archivo a menos que el usuario pregunte "recuerda cuando..."

SI resolución de problemas/depuración:
  ├─ Usar prioridad por relevancia (60% semántico, 40% temporal)
  ├─ Presupuesto: 8K archivo + 4K recuerdo + 2K ambiente
  └─ Incluir patrones de error de soluciones pasadas

SI se detecta cambio de contexto:
  ├─ Usar basado en frecuencia (¿en qué trabaja más el usuario?)
  ├─ Presupuesto: 6K contexto del proyecto + 2K reciente + 4K objetivos
  └─ Extraer historial de entidades para archivos/personas activas

SI disparador programado (resumen matutino):
  ├─ Usar agenda estructurada (calendario + tareas + actualizaciones)
  ├─ Presupuesto: 4K calendario + 4K tareas pendientes + 2K cambios
  └─ Sin necesidad de historial de conversación

SI disparador reactivo (fallo de CI, comienzo de reunión):
  ├─ Usar carga de contexto específica del evento
  ├─ Presupuesto: 8K contexto del evento + 4K historial relacionado
  └─ Omitir conversación general a menos que sea relevante

FILTRADO DE DATOS AMBIENTALES

Observación de Pantalla/Audio → Decisión de Filtro

SI misma app + mismo texto durante >5 minutos:
  └─ DESCARTAR (sin cambio, ruido)

SI se detecta cambio de app:
  ├─ CONSERVAR registro de transición
  └─ Puntuar relevancia del contenido de la nueva app

SI se encuentran palabras clave de alta señal:
  ├─ Verificar contra proyectos/objetivos activos
  ├─ SI puntuación de coincidencia >0.6 → ALMACENAR en archivo + recuerdo
  ├─ SI puntuación de coincidencia 0.3-0.6 → ALMACENAR solo en recuerdo
  └─ SI puntuación de coincidencia <0.3 → DESCARTAR

SI error técnico/excepción visible:
  ├─ SIEMPRE ALMACENAR (contexto de depuración)
  └─ Etiquetar con nivel de urgencia

SI se menciona evento de calendario:
  ├─ SIEMPRE ALMACENAR (ancla temporal)
  └─ Referencia cruzada con calendario real

ASIGNACIÓN DE URGENCIA DE DISPARADOR

Tipo de Evento + Contexto → Nivel de Urgencia

SI fallo de CI:
  ├─ Rama de producción → ACTIVO (notificar al usuario)
  ├─ Rama de funcionalidad + usuario programando actualmente → PASIVO (mencionar cuando el usuario vuelva a interactuar)
  └─ Rama antigua/PR → SILENCIOSO (solo registrar)

SI comienza reunión:
  ├─ <5 minutos → ACTIVO (interrumpir con preparación)
  ├─ 5-15 minutos → INSIGNIA (mostrar preparación disponible)
  └─ >15 minutos → SILENCIOSO (preparación en segundo plano)

SI se detecta cambio de código:
  ├─ Primer commit en nueva rama → PASIVO (notificar nuevo trabajo)
  ├─ Commit corrige error anterior → PASIVO (notificar resolución)
  └─ Commits regulares → SILENCIOSO (seguir progreso)

SI es mencionado en Slack:
  ├─ Mensaje directo → ACTIVO (se necesita respuesta)
  ├─ Mención en canal + palabras clave urgentes → ACTIVO
  └─ Mención en canal, normal → INSIGNIA (revisar cuando sea conveniente)

MODOS DE FALLO

Inflado de Esquema

Síntomas: Ventana de contexto constantemente al máximo, respuestas lentas, altos costos de tokens a pesar del filtrado
Causa Raíz: Los esquemas de observación capturan cada campo en lugar de solo lo que el agente necesita para razonar
Regla de Detección: Si el tamaño promedio de contexto >50K tokens o el almacenamiento de observaciones >1MB/día, tienes inflado de esquema
Solución: Auditar esquemas cada mes. Eliminar campos que no hayan influido en una decisión en 30 días. Usar resumen en lugar de almacenamiento bruto.

Thrashing de Recuperación

Síntomas: El agente menciona información desactualizada, pierde contexto reciente o recupera recuerdos irrelevantes repetidamente
Causa Raíz: Búsqueda vectorial de paso único sin reordenamiento, o pesos temporales/semánticos mal ajustados
Regla de Detección: Si >30% del contexto recuperado no se usa en respuestas, o el usuario corrige al agente sobre eventos recientes
Solución: Implementar recuperación de dos etapas (búsqueda amplia + reordenamiento). Probar A/B diferentes proporciones de peso temporal/semántico.

Spam de Disparadores

Síntomas: El usuario desactiva las notificaciones del agente, se queja de interrupciones o ignora al agente
Causa Raíz: Sin niveles de urgencia, o umbrales demasiado bajos para disparadores activos/de interrupción
Regla de Detección: Si el usuario descarta >50% de las notificaciones activas, o el tiempo promedio entre interacciones del usuario >4 horas
Solución: Predeterminar todo a silencioso. Dejar que el usuario configure explícitamente qué merece notificación activa. Rastrear tasas de descarte.

Estancamiento del Contexto

Síntomas: El agente actúa con información desactualizada, no nota que el usuario cambió de enfoque/proyecto
Causa Raíz: Sin decaimiento de frescura en el contexto, o los pesos de recuperación no tienen en cuenta suficiente la recencia
Regla de Detección: Si el agente referencia información >7 días de antigüedad cuando existe contexto reciente, o menciona proyectos completados
Solución: Agregar decaimiento exponencial a las puntuaciones de relevancia. Ponderar observaciones recientes 2-3x más que archivo.

Inundación de Ruido Ambiental

Síntomas: Costos altos, mala calidad de respuesta, el agente menciona contexto de pantalla irrelevante
Causa Raíz: Datos ambientales en bruto eluden el filtrado, o las puertas de relevancia están demasiado permisivas
Regla de Detección: Si las observaciones ambientales constituyen >30% de los recuerdos almacenados, o los costos de tokens >$10/día
Solución: Ajustar la puntuación de relevancia. Agrupar observaciones ambientales en ventanas de 5 minutos. Requerir 2+ señales para confirmar relevancia.

EJEMPLOS TRABAJADOS

Escenario: Investigación de Error de Facturación con Restricciones de Presupuesto de Tokens

El usuario informa: "El cálculo de facturación es incorrecto para clientes empresariales."

Paso 1: Asignación de Presupuesto de Contexto (40K total)

Sistema + Identidad: 4K tokens (fijo)
Memoria Principal: 2K tokens (preferencias del usuario, proyectos activos)
DECISIÓN: Tarea de resolución de problemas → usar recuperación con prioridad por relevancia
Asignado: 8K archivo + 4K recuerdo + 2K ambiente + 15K conversación + 5K búfer de salida

Paso 2: Ejecución de Estrategia de Recuperación

# Búsqueda semántica amplia para recuerdos relacionados con facturación
candidatos_archivo = busqueda_vectorial(
    consulta="cálculo facturación cliente empresarial error bug",
    top_k=20,
    filtros={"proyecto": ["facturación", "pagos"]}
)

# Reordenar por relevancia real (no solo similitud de embedding)
reordenados = reordenar_resultados(candidatos_archivo, consulta, top_k=5)
# Resultado: Obtiene "error lógica descuento empresarial de hace 3 semanas"
# que la búsqueda vectorial pura clasificó en #12

# Búsqueda temporal para trabajo de facturación reciente
trabajo_reciente = busqueda_temporal(
    rango_tiempo="últimos_7_días",
    filtros_entidad=["facturación", "empresarial"],
    max_resultados=3
)
# Resultado: El usuario estaba depurando niveles de precios ayer

Paso 3: Integración de Contexto Ambiental

# Verificar qué está haciendo el usuario actualmente
resumen_pantalla = obtener_resumen_ambiental(últimos_30_minutos)
# Resultado: "El usuario tiene billing_calculator.py abierto, mirando
# la función calculate_enterprise_discount()"

# Verificación de presupuesto: 8K archivo + 4K reciente + 2K ambiente = 14K (dentro del presupuesto)

Paso 4: Compensación Rápido vs Completo El agente tiene dos opciones:

Recuperación rápida (actual): 14K de contexto, se enfoca en patrones de error recientes
Contexto completo: Agregar historial de git, discusiones de PR relacionadas (+8K tokens, excede el presupuesto)

Decisión: Mantener recuperación rápida para la respuesta inicial. Si el usuario solicita una investigación más profunda, disparar un seguimiento con un presupuesto de contexto expandido.

Calidad de la Respuesta del Agente:

Enfoque novato: Volcaría todo el contexto relacionado con facturación, excedería el presupuesto, obtendría una respuesta confusa
Enfoque experto: 14K seleccionados del contexto más relevante, menciona el error específico de descuento empresarial de hace 3 semanas que la búsqueda vectorial sola habría pasado por alto, se mantiene dentro del presupuesto

PUERTAS DE CALIDAD

LÍMITES DE NO APLICACIÓN

Usar /always-on-agent-inputs para:

Decidir qué datos capturar del entorno del usuario
Estructurar disparadores y esquemas de observación
Presupuestar la ventana de contexto y seleccionar estrategias de recuperación
Filtrar datos ambientales antes de que lleguen al agente

NO usar para:

Diseño de arquitectura de memoria (almacenes vectoriales, bases de datos, niveles de memoria) → usar /always-on-agent-architecture
Ideación de aplicaciones y casos de uso → usar /always-on-agent-applications
Privacidad y seguridad de los datos capturados → usar /always-on-agent-safety
Técnicas generales de ingeniería de prompts → usar /prompt-engineer
Patrones de razonamiento del agente → usar /agentic-patterns

curiositech/windags-skills

¿Qué es windags-skills?

Preguntar en tu IA favorita