/always-on-agent-inputs — Alimenter le Contexte d'un Agent Persistant

Vous concevez ce qu'un agent toujours actif voit, entend et sait. La compétence d'architecture gère où vit la mémoire. Cette compétence gère ce qui y entre — les signaux bruts, leur structuration, quand l'agent se réveille, et comment garder la fenêtre de contexte honnête.

---\n

POINTS DE DÉCISION

SÉLECTION DE LA STRATÉGIE DE RÉCUPÉRATION

Type de Tâche de l'Agent → Stratégie de Récupération

IF conversationnel/chat :
  ├─ Utiliser priorité à la récence (70% temporel, 30% sémantique)
  ├─ Budget : 15K historique conversation + 4K rappel récent
  └─ Ignorer archives sauf si utilisateur demande "tu te souviens quand..."

IF résolution de problème/débogage :
  ├─ Utiliser priorité à la pertinence (60% sémantique, 40% temporel)
  ├─ Budget : 8K archives + 4K rappel + 2K ambiant
  └─ Inclure les schémas d'erreur des solutions passées

IF changement de contexte détecté :
  ├─ Utiliser basé sur la fréquence (sur quoi l'utilisateur travaille-t-il le plus ?)
  ├─ Budget : 6K contexte projet + 2K récent + 4K objectifs
  └─ Tirer l'historique des entités pour les fichiers/personnes actifs

IF déclencheur programmé (briefing matinal) :
  ├─ Utiliser ordre du jour structuré (calendrier + tâches + mises à jour)
  ├─ Budget : 4K calendrier + 4K tâches non terminées + 2K modifications
  └─ Aucun historique de conversation nécessaire

IF déclencheur réactif (échec CI, réunion qui commence) :
  ├─ Utiliser chargement de contexte spécifique à l'événement
  ├─ Budget : 8K contexte événement + 4K historique associé
  └─ Ignorer la conversation générale sauf si pertinente

FILTRAGE DES DONNÉES AMBIANTES

Observation Écran/Audio → Décision de Filtrage

IF même application + même texte pendant >5 minutes :
  └─ JETER (pas de changement, bruit)

IF changement d'application détecté :
  ├─ GARDER l'enregistrement de transition
  └─ Noter la pertinence du contenu de la nouvelle application

IF mots-clés à fort signal trouvés :
  ├─ Vérifier par rapport aux projets/objectifs actifs
  ├─ IF score de correspondance >0.6 → STOCKER dans archives + rappel
  ├─ IF score de correspondance 0.3-0.6 → STOCKER dans rappel uniquement
  └─ IF score de correspondance <0.3 → JETER

IF erreur technique/exception visible :
  ├─ TOUJOURS STOCKER (contexte de débogage)
  └─ Étiqueter avec niveau d'urgence

IF événement de calendrier mentionné :
  ├─ TOUJOURS STOCKER (ancrage temporel)
  └─ Recouper avec le calendrier réel

ASSIGNATION DE L'URGENCE DES DÉCLENCHEURS

Type d'Événement + Contexte → Niveau d'Urgence

IF échec CI :
  ├─ Branche de production → ACTIF (notifier l'utilisateur)
  ├─ Branche de fonctionnalité + utilisateur code actuellement → PASSIF (mentionner quand l'utilisateur revient)
  └─ Ancienne branche/PR → SILENCIEUX (journaliser uniquement)

IF réunion qui commence :
  ├─ <5 minutes → ACTIF (interrompre avec préparation)
  ├─ 5-15 minutes → BADGE (afficher préparation disponible)
  └─ >15 minutes → SILENCIEUX (préparer en arrière-plan)

IF changement de code détecté :
  ├─ Premier commit sur nouvelle branche → PASSIF (noter nouveau travail)
  ├─ Commit corrige une erreur précédente → PASSIF (noter résolution)
  └─ Commits réguliers → SILENCIEUX (suivre progression)

IF mentionné dans Slack :
  ├─ Message direct → ACTIF (réponse nécessaire)
  ├─ Mention de canal + mots-clés urgents → ACTIF
  └─ Mention de canal, normal → BADGE (revoir quand pratique)

MODES DE DÉFAILLANCE

Gonflement des Schémas

Symptômes : Fenêtre de contexte constamment saturée, réponses lentes, coûts de tokens élevés malgré le filtrage
Cause Racine : Les schémas d'observation capturent tous les champs au lieu de seulement ce dont l'agent a besoin pour raisonner
Règle de Détection : Si la taille moyenne du contexte >50K tokens ou le stockage d'observation >1MB/jour, vous avez un gonflement des schémas
Correctif : Auditer les schémas chaque mois. Supprimer les champs qui n'ont pas influencé une décision depuis 30 jours. Utiliser la synthèse plutôt que le stockage brut.

Agitation de la Récupération

Symptômes : L'agent mentionne des informations obsolètes, manque le contexte récent, ou récupère des souvenirs non pertinents de façon répétée
Cause Racine : Recherche vectorielle en un seul passage sans reclassement, ou pondération temporelle/sémantique mal réglée
Règle de Détection : Si >30% du contexte récupéré reste inutilisé dans les réponses, ou l'utilisateur corrige l'agent sur des événements récents
Correctif : Implémenter une récupération en deux étapes (recherche large + reclassement). Tester A/B différents ratios de pondération temporelle/sémantique.

Spam de Déclencheurs

Symptômes : L'utilisateur désactive les notifications de l'agent, se plaint des interruptions, ou l'agent est ignoré
Cause Racine : Pas de hiérarchisation de l'urgence, ou seuils trop bas pour les déclencheurs actifs/interruptifs
Règle de Détection : Si l'utilisateur rejette >50% des notifications actives, ou le temps moyen entre les interactions utilisateur >4 heures
Correctif : Tout mettre en silencieux par défaut. Laisser l'utilisateur configurer explicitement ce qui mérite une notification active. Suivre les taux de rejet.

Obsolescence du Contexte

Symptômes : L'agent agit sur des informations obsolètes, ne voit pas que l'utilisateur a changé de focus/projet
Cause Racine : Pas de dégradation de fraîcheur du contexte, ou les poids de récupération ne tiennent pas assez compte de la récence
Règle de Détection : Si l'agent référence des informations vieilles de >7 jours alors qu'un contexte récent existe, ou mentionne des projets terminés
Correctif : Ajouter une décroissance exponentielle aux scores de pertinence. Ponderer les observations récentes 2-3x plus que les archives.

Inondation de Bruit Ambiant

Symptômes : Coûts élevés, mauvaise qualité des réponses, l'agent mentionne un contexte d'écran non pertinent
Cause Racine : Les données ambiantes brutes contournent le filtrage, ou les seuils de pertinence sont trop permissifs
Règle de Détection : Si les observations ambiantes représentent >30% des souvenirs stockés, ou les coûts de tokens >10$/jour
Correctif : Reserrer le scoring de pertinence. Regrouper les observations ambiantes par fenêtres de 5 minutes. Exiger 2+ signaux pour confirmer la pertinence.

EXEMPLES TRAVAILLÉS

Scénario : Investigation d'un Bug de Facturation avec Contrainte de Budget Token

L'utilisateur signale : "Le calcul de facturation est erroné pour les clients entreprise."

Étape 1 : Allocation du Budget Contexte (40K total)

Système + Identité : 4K tokens (fixe)
Mémoire Principale : 2K tokens (préférences utilisateur, projets actifs)
DÉCISION : Tâche de résolution de problème → utiliser récupération priorité à la pertinence
Alloué : 8K archives + 4K rappel + 2K ambiant + 15K conversation + 5K tampon de sortie

Étape 2 : Exécution de la Stratégie de Récupération

# Recherche sémantique large pour les souvenirs liés à la facturation
candidats_archives = recherche_vectorielle(
    requete="erreur bug de calcul facturation client entreprise",
    top_k=20,
    filtres={"projet": ["facturation", "paiements"]}
)

# Reclasser par pertinence réelle (pas seulement similarité d'embedding)
reclasses = reclasser_resultats(candidats_archives, requete, top_k=5)
# Résultat : Obtient "bug logique de réduction entreprise d'il y a 3 semaines" 
# que la recherche vectorielle pure classait #12

# Recherche temporelle pour le travail récent sur la facturation
travail_recent = recherche_temporelle(
    intervalle_temps="7_derniers_jours",
    filtres_entite=["facturation", "entreprise"],
    max_resultats=3
)
# Résultat : L'utilisateur débogait les niveaux de prix hier

Étape 3 : Intégration du Contexte Ambiant

# Vérifier ce que l'utilisateur fait actuellement
resume_ecran = obtenir_resume_ambiant(30_dernieres_minutes)
# Résultat : "L'utilisateur a billing_calculator.py ouvert, regarde 
# la fonction calculate_enterprise_discount()"

# Vérification budget : 8K archives + 4K récent + 2K ambiant = 14K (sous le budget)

Étape 4 : Compromis Rapide vs Complet L'agent a deux options :

Récupération rapide (actuelle) : 14K de contexte, se concentre sur les schémas de bugs récents
Contexte complet : Ajouter l'historique git, les discussions de PR associées (+8K tokens, dépasse le budget)

Décision : Rester sur une récupération rapide pour la réponse initiale. Si l'utilisateur demande une enquête plus approfondie, déclencher un suivi avec un budget de contexte élargi.

Qualité de la Réponse de l'Agent :

Approche novice : Viderait tout le contexte lié à la facturation, dépasserait le budget, obtiendrait une réponse confuse
Approche experte : Contexte organisé de 14K du plus pertinent, mentionne le bug spécifique de réduction entreprise d'il y a 3 semaines que la seule recherche vectorielle aurait manqué, reste sous le budget

GARANTIES DE QUALITÉ

LIMITES D'APPLICATION

Utiliser /always-on-agent-inputs pour :

Décider quelles données capturer depuis l'environnement utilisateur
Structurer les déclencheurs et les schémas d'observation
Budgétisation de la fenêtre de contexte et sélection de la stratégie de récupération
Filtrer les données ambiantes avant qu'elles n'atteignent l'agent

Ne PAS utiliser pour :

Conception de l'architecture mémoire (bases vectorielles, bases de données, niveaux de mémoire) → utiliser /always-on-agent-architecture
Idéation d'applications et cas d'usage → utiliser /always-on-agent-applications
Confidentialité et sécurité des données capturées → utiliser /always-on-agent-safety
Techniques générales d'ingénierie des prompts → utiliser /prompt-engineer
Schémas de raisonnement de l'agent → utiliser /agentic-patterns

curiositech/windags-skills

Qu'est-ce que windags-skills ?

Demander à votre IA préférée