Compétence Agent du SDK Python Failproof AI Observability

​

L’instrumentation est facile à écrire et facile à rater silencieusement

​

Ce qu’elle fait, dans l’ordre

1. Planifier. Elle lit votre boucle d’agent et pose les deux questions auxquelles vous seul pouvez répondre : ce qui constitue une exécution (votre session_id), et qui sont les acteurs distinguables (votre agent_id). Elle obtient un accord sur ces points avant d’écrire du code, car les modifier plus tard divise votre historique et casse les tendances.
2. Écrire. Elle lie l’identité une seule fois par exécution plutôt que de la propager à travers chaque point d’appel, et elle choisit une forme sûre pour la concurrence — un détail qui compte, car le raccourci évident mélange silencieusement deux exécutions simultanées en une seule session.
3. Vérifier. Elle exécute votre agent et lit les fichiers d’événements résultants, en vérifiant que agent_start est présent, que l’environnement est correct et qu’une exécution a produit une session.

​

Son rapport aux autres compétences

​

Prérequis

1. Python 3.10+ et la base de code de l’agent que vous souhaitez instrumenter.
2. Le SDK. Il est distribué aux clients sous forme de wheel privé plutôt que depuis un index public — votre intégration couvre comment l’obtenir et l’installer. La compétence connaît le chemin d’installation et vous demandera plutôt que de deviner si elle ne le trouve pas.
3. Rien d’autre. Pas de connexion au tableau de bord, pas de clé API, pas de réseau. La compétence vérifie à partir des fichiers d’événements que le SDK écrit, elle peut donc terminer et prouver son travail hors ligne.

​

Où l’obtenir

npx skills add FailproofAI/skills --skill agenteye-python-sdk -a claude-code

​

Installation manuelle

• Claude Code : copiez le dossier agenteye-python-sdk/ dans ~/.claude/skills/ (tous les projets) ou <votre-dépôt>/.claude/skills/ (ce dépôt uniquement). Claude Code le découvre automatiquement — vérifiez la liste /skills, ou posez simplement une question qui lui correspond.
• Codex : Codex lit le même SKILL.md. Le fichier agents/openai.yaml inclus définit allow_implicit_invocation: true, il est donc auto-sélectionné quand une tâche lui correspond ; sinon invoquez-le avec $agenteye-python-sdk.

​

À quoi ressemble une session

vous  ▸ Ajoute Failproof AI Observability à cet agent.

agent ▸ J'ai lu votre boucle — un dispatcheur d'outils dans tools.py, un
        wrapper Anthropic dans llm.py. Deux questions avant d'écrire quoi
        que ce soit.

        Qu'est-ce qui constitue une exécution ? Vous gérez les requêtes
        en parallèle, donc j'utiliserais l'id de requête que vous avez
        déjà dans ctx.request_id — ainsi une session ici et une requête
        dans vos logs sont la même chaîne.

        Et qui sont les acteurs ? Je vois un chemin planificateur et un
        chemin chercheur. Les étiqueter séparément, ou c'est un seul
        agent pour vous ?

vous  ▸ L'id de requête, c'est bon. C'est un seul agent, appelez-le "assistant".

agent ▸ Terminé. J'ai enveloppé le dispatcheur et le client LLM ;
        agent_start et agent_end encadrent handle_request, y compris le
        chemin d'erreur. J'ai utilisé un contexte local pour l'identité
        — votre dispatcheur exécute les outils dans un pool de threads,
        et l'approche plus simple aurait mélangé des exécutions
        simultanées en une seule session sans se plaindre.

        Vérifié sur une vraie exécution : 11 événements dans 4 fichiers —
        agent_start, model_request/response, tool_use/tool_result x3,
        agent_end (outcome=success). environment=production, une session
        par requête, durées appariées.

        Une chose que je n'ai PAS faite : votre pool de workers dans
        batch.py soumet directement à l'executor, donc les événements
        venant de là seraient perdus. Voulez-vous que je corrige ça aussi ?

​

Ce que vous pouvez lui demander

• « Pourquoi mon agent n’apparaît pas sur le tableau de bord ? » → parcourt l’échelle : les événements sont-ils écrits, agent_start est-il présent, l’environnement est-il correct, le collecteur lit-il au bon endroit.
• « Tout arrive sous dev. » → l’environnement n’a jamais été défini, ou a été réinitialisé par un appel ultérieur.
• « Ajoute le suivi des tokens. » → trouve votre wrapper LLM et enregistre le modèle, la raison d’arrêt et l’utilisation.
• « Instrumente aussi les sous-agents. » → une session, des étiquettes d’agent distinctes, imbriqués sous leur parent.
• « Écris des tests pour l’instrumentation. » → pointe le SDK vers un répertoire temporaire et effectue des assertions sur les événements qu’il a écrits.

​

Points de vigilance

​

Étapes suivantes

• SDK Python : la référence complète des événements — chaque type d’événement et chaque champ — derrière ce que cette compétence automatise.
• Sessions : ce que produit votre instrumentation une fois les événements reçus.
• Agent Skill Evaluator : l’étape suivante une fois que les exécutions arrivent — les noter.
• Agent Skill CLI : relire votre télémétrie.