Le modèle de données
Événement La plus petite unité de données. Un événement enregistre une seule étape effectuée par votre agent : untool_use, un model_request, un hook_completed, une error, etc. Votre agent émet des événements via le Python SDK ; ils apparaissent en temps réel sur la page Events.
Session
Une exécution d’agent, identifiée par un session_id. Une session regroupe tous les événements partageant cet identifiant, consolidés en une seule ligne sur la page Sessions et représentés sous forme de graphe d’exécution sur sa page de détail. Une session commence généralement par agent_start et se termine par agent_end.
Agent
Un acteur nommé au sein d’une exécution, identifié par un agent_id. Une exécution peut impliquer plusieurs agents : par exemple, un planificateur qui instancie un sous-agent de synthèse. Les sous-agents portent un parent_id, ce qui permet à Failproof AI Observability de les représenter sur leurs propres pistes dans le graphe d’exécution.
Environnement
Un libellé indiquant où s’est déroulée l’exécution : production, staging, dev. Vous le définissez une seule fois lors de la configuration du SDK. Presque toutes les pages du tableau de bord permettent de filtrer par environnement.
Taux de remplissage de la fenêtre de contexte
Le pourcentage de la fenêtre de contexte d’un modèle consommé par une réponse. Failproof AI Observability l’horodate sur les événements model_response pour les modèles qu’il reconnaît, rendant ainsi visibles la croissance des prompts et les compactions imminentes directement dans le flux d’événements.
Qualité
Évaluation Un score de qualité pour une session terminée, produit par un service de notation que vous exécutez. Les évaluations sont optionnelles : tant que vous ne connectez pas d’évaluateur, les sessions sont enregistrées mais pas notées. Chaque évaluation peut comporter plusieurs scores nommés (par exemplehelpfulness, factuality, tool_efficiency), chacun accompagné d’une courte note explicative. Voir Evaluation suite.
Clé de score
Le nom d’une dimension rapportée par un évaluateur, comme helpfulness. Les alertes et les audits peuvent surveiller une clé de score spécifique dans le temps.
Évaluateur
Votre service de notation. Failproof AI Observability lui envoie via POST la transcription d’une exécution terminée et stocke les scores renvoyés. Aucun évaluateur par défaut n’est fourni ; la logique de notation vous appartient.
Identifier et corriger les défaillances
Hook Un garde-fou ou un effet secondaire que votre framework d’agent exécute autour d’une étape : une vérification de sécurité du contenu, une anonymisation des données personnelles, un contrôle budgétaire. Les hooks émettent des événementshook_triggered / hook_completed avec un outcome (allow, deny, modify) et disposent de leur propre page d’observation.
Règle d’alerte
Une règle qui se déclenche lorsqu’une métrique dépasse un seuil que vous définissez : taux d’erreur, latence p95, coût en tokens ou score d’un évaluateur. Lorsqu’une règle se déclenche, elle ouvre un incident et notifie les canaux que vous avez choisis (e-mail, Slack, webhook, tableau de bord). Voir Alerts.
Incident
Un problème ouvert créé lorsqu’une règle d’alerte se déclenche. Les incidents suivent un cycle de vie (accusé de réception, assignation, résolution) et disposent d’une chronologie d’activité enregistrant chaque action. Vous pouvez également en ouvrir un manuellement.
Audit
Une investigation récurrente (toutes les heures à une fois par semaine) qui analyse vos journaux à travers les sessions pour détecter des patterns de défaillance pour lesquels vous n’avez pas encore écrit de règle : clusters d’erreurs, scores faibles, valeurs aberrantes de latence, boucles d’appels d’outils et exécutions n’ayant jamais abouti. Là où une alerte surveille une métrique que vous connaissez déjà, un audit vous indique ce sur quoi vous devriez vous pencher ensuite. Voir Audits.
Finding
Un résultat classé et étayé par des preuves, issu d’une exécution d’audit. Un finding nomme un pattern, renvoie aux sessions exactes qui le sous-tendent et suit un cycle de vie de triage (accusé de réception, résolution, mise en sourdine, rejet). Failproof AI Observability déduplique les findings d’une exécution à l’autre, de sorte qu’un pattern connu est mis à jour plutôt que de s’accumuler.
L’assistant IA
Le chat intégré au tableau de bord qui répond en langage naturel à vos questions sur vos agents, en s’appuyant sur vos propres données. Il est en lecture seule par défaut ; tout ce qu’il crée (une requête sauvegardée, un tableau de bord) nécessite une approbation, et il ne peut jamais supprimer quoi que ce soit. Voir AI assistant.
Fonctionnement
Organisation (tenant) Un espace de travail isolé. Une instance Failproof AI Observability peut héberger plusieurs organisations, chacune avec ses propres utilisateurs, clés et données. Chaque URL du tableau de bord est rattachée à votre slug d’organisation (/<org-slug>/…).
Collector
agenteye-collector, le démon léger qui s’exécute sur chaque machine agent, regroupe les événements écrits sur disque par le SDK et les envoie au serveur.
Clé API
Un token à périmètre défini qui authentifie un client auprès du serveur. Les clés portent des permissions granulaires (par exemple events:add pour le collector, des périmètres en lecture seule pour une clé de tableau de bord). Voir API keys.
Serveur
Le service d’ingestion et d’API. Il ingère les événements, stocke l’état opérationnel dans vos bases de données et sert le tableau de bord ainsi que la CLI.
Tableau de bord
L’interface web. Chaque page est rattachée à une organisation et lit les données via l’API du serveur.
Étapes suivantes
- Overview : comment ces éléments s’articulent entre eux.
- Observability : les surfaces d’observation (Events, Sessions, Models, Tools, Hooks, Errors).