Clyro

Le cœur de Clyro, c'est clyro.wrap(). Vous passez votre agent plus un objet de configuration, et il renvoie une version gouvernée qui trace l'exécution, suit le coût et applique des limites sans modifier la logique de votre agent. Cette dernière partie est le vrai argument de vente. Ajouter des garde-fous à un agent qui fonctionne est en général pénible, et la conception de Clyro réduit la modification à une poignée de lignes.

Clyro regroupe ses contrôles en une pile de quatre parties : limites d'étapes, limites de coût, détection de boucles et garde-fous de logique métier. Les limites d'étapes plafonnent le nombre d'actions qu'un run peut prendre. Les limites de coût arrêtent un run quand la dépense franchit un seuil. La détection de boucles surveille les chemins d'exécution répétés. Pourquoi est-ce important ? Un agent bloqué peut brûler un budget en une nuit. Les garde-fous confrontent les actions aux règles avant qu'elles ne se déclenchent. Ce sont des garde-fous pour agents d'IA qui agissent pendant un run et non après, et ils visent des défaillances que les outils d'observabilité ne signalent qu'une fois les dégâts faits.

Les politiques vivent en YAML, et chaque règle associe une condition à une décision. Vous pouvez bloquer une action d'emblée, l'autoriser ou exiger une validation humaine avant qu'elle ne se poursuive. Les règles viennent avec huit opérateurs pour comparer des champs, et chaque règle échoue en mode ouvert, si bien qu'une politique cassée n'entraîne pas votre agent dans sa chute. Pour les équipes qui ont besoin d'une traçabilité, ce comportement par règle mérite d'être compris avant le déploiement.

Clyro embarque cinq adaptateurs : LangGraph, CrewAI, le SDK Claude Agent, le SDK Anthropic et une option générique pour n'importe quelle fonction Python. Cette diversité compte parce que les piles d'agents se fragmentent vite, et un outil de gouvernance qui ne prend en charge qu'un framework vous force soit à changer, soit à vous en passer. L'adaptateur générique est la porte de sortie pour ce que vous avez construit à la main.

Au-delà du SDK, Clyro embarque un wrapper MCP qui agit comme proxy JSON-RPC pour Claude Desktop, Cursor et VS Code, ainsi qu'un ensemble de hooks Claude Code pour les événements PreToolUse et PostToolUse. Les hooks gouvernent Bash, Edit et Write, ce qui veut dire que vous pouvez bloquer quelque chose comme DROP TABLE avant même que l'outil ne s'exécute. C'est une surface différente de la gouvernance des runs d'agents, et cela élargit les endroits où le produit s'applique.

Clyro tourne entièrement hors ligne avec des politiques YAML locales et n'a pas besoin de clé d'API. Le cloud est optionnel et ajoute des tableaux de bord partagés, la synchronisation des politiques, la détection de dérive, des flame graphs et la comparaison de traces à mesure que vous montez de palier. Cette conception local d'abord convient aux équipes dont les politiques de données rendent inenvisageable l'envoi de traces d'exécution à un tiers, et elle signifie que vous pouvez évaluer l'outil sans vous inscrire.

Le SDK calcule automatiquement les coûts LLM pour les modèles OpenAI et Anthropic, donc les chiffres derrière vos limites de coût viennent de l'usage réel et non d'une estimation. Si votre pile utilise d'autres fournisseurs, comptez fournir vous-même les données de coût, puisque le calcul automatique se limite à ces deux familles.