Gini Agent : un runtime qui garde l'état à la place du chat

Le problème visé : un agent qui agit sans noyer l'utilisateur

La plupart des agents personnels se présentent comme une interface de conversation. Gini Agent part d'un constat différent, formulé dans son README : le chat est une surface d'interaction, pas le système d'enregistrement. Ce qui compte, ce sont les conversations, les exécutions, les tâches, les approbations, la mémoire, les compétences, les jobs, les outils, les traces et les événements d'audit, et tout cela doit vivre quelque part de persistant. Le public visé est donc précis : quelqu'un qui fait tourner un agent chez lui, qui veut qu'il exécute des tâches planifiées et des travaux en plusieurs étapes, et qui refuse de surveiller une sortie de terminal pour savoir si l'agent attend une réponse. Le README insiste sur un point de conception : quand l'agent a besoin de vous, il affiche un contrôle interactif dédié à l'endroit où le travail se fait, plutôt qu'une instruction en prose vous demandant d'aller faire quelque chose ailleurs. C'est une position défendable, et elle a un coût en complexité que le reste de l'article détaille.

Un gateway Bun par instance, et des clients interchangeables

L'architecture tient en une phrase, reprise du README : le runtime est le gateway, un seul processus Bun par instance détient l'état et effectue le travail. Le schéma fourni montre ce processus au centre, avec sous lui l'application Next.js (qui sert de BFF pour le navigateur), la CLI et les scripts qui s'authentifient par jeton bearer, puis les autres clients : mobile, MCP, ponts de messagerie. Tous parlent le même contrat authentifié sous /api/*. Cette décision a une conséquence pratique : il n'existe pas de chemin privilégié pour l'interface web. Le README précise que le BFF Next.js n'utilise pas de jeton côté navigateur, ce qui évite d'exposer un secret dans la page. La documentation renvoie à docs/architecture-overview.md pour la carte gateway/clients et à docs/gateway.md pour le processus, l'authentification, les instances, les ports et l'agencement disque. Le projet assume aussi plusieurs instances parallèles avec état, ports et journaux isolés, ce qui laisse deviner un modèle d'exploitation où l'on fait tourner plusieurs agents côte à côte plutôt qu'un seul processus partagé.

Mémoire, compétences et récompense à deux étages

Deux documents décrivent la partie apprentissage. docs/memory.md couvre la rétention, le rappel, les embeddings, le reranking, la revue et le stockage. docs/skill-learning.md décrit comment Gini améliore ses propres compétences à partir des résultats de tâches, avec ce que le README appelle une récompense à deux étages, une attribution, une revue quotidienne et une barrière humaine. Le détail exact de ces mécanismes n'est pas dans le matériel fourni, seulement leur existence et leur emplacement. On peut en revanche noter ce que le README affirme sur les dépendances : embeddings locaux, reranking local et transcription vocale locale par défaut. C'est un choix qui pèse sur la machine, puisqu'il faut de la puissance de calcul sur place, mais il évite d'envoyer vos souvenirs à un service tiers. La barrière humaine mentionnée pour l'apprentissage des compétences est cohérente avec le reste du projet : l'agent propose, vous validez. Reste à savoir à quelle fréquence cette revue quotidienne vous sollicite, et le matériel ne permet pas de répondre.

Installation et premiers pas

Le README donne une commande d'installation unique :

curl -fsSL https://raw.githubusercontent.com/Open-Curiosity/gini-agent/main/scripts/install.sh | bash

Sur macOS, l'installateur active le démarrage automatique via des LaunchAgents par utilisateur pour le runtime et l'application web, attend que l'application soit disponible, puis ouvre la page /setup dans le navigateur. Le formulaire de configuration propose le catalogue complet des fournisseurs. C'est un point à ne pas négliger : le choix du fournisseur se fait à cet endroit, et le README liste Codex OAuth, les clés API OpenAI, Azure OpenAI, DeepSeek et OpenRouter, l'API Anthropic Claude, Amazon Bedrock en mode Converse avec signature AWS SigV4 (Claude, Nova, Llama, Mistral, DeepSeek) et tout serveur local compatible OpenAI. Chaque fournisseur a son guide dans docs/providers/README.md, avec les identifiants et les prérequis. Pour l'exploitation, docs/operations.md couvre l'installation, le démarrage, l'arrêt, le test de fumée, le diagnostic et le nettoyage. Le déploiement conteneurisé est traité dans docs/deployment-docker.md, qui décrit l'exécution sans interface avec un vrai navigateur sous Xvfb. L'accès distant passe par des tunnels, avec un document par fournisseur (Gini Relay, Tailscale, ngrok, Cloudflare) et une confirmation à l'activation.

Les contrôles en ligne, et ce qu'ils excluent

Le README détaille quatre primitives d'interaction, chacune adossée à un ADR. Les secrets sont saisis dans une carte sécurisée qui va directement au gateway et ne traverse ni le modèle, ni la transcription, ni la piste d'audit. L'agent peut vous passer la main sur son propre navigateur quand une tâche bute sur une authentification. Les choix multiples remplacent une décision silencieuse. Et rien ne part en votre nom sans une confirmation explicite, message, réponse, publication ou achat. Le même protocole alimente l'application web et l'application iOS, et les cartes atteignent le téléphone hors du réseau local via un tunnel. Il faut prendre cette liste pour ce qu'elle est : un périmètre. Les outils fichier, terminal et code sont soumis à approbation, ce qui signifie que l'agent ne peut pas, par conception, modifier votre système sans validation. C'est rassurant, et c'est aussi une limite : un agent qui doit être approuvé à chaque étape convient mal à des tâches longues et répétitives que vous voulez oublier. Le compromis est assumé dans le README, mais il faut le mesurer avant adoption.

Limites et cas où le projet n'est pas le bon outil

Le matériel fourni ne contient ni mesures de performance, ni nombre d'utilisateurs, ni rapport de test. On ne peut donc rien affirmer sur la latence du gateway, la consommation des embeddings locaux ou la robustesse de la boucle d'agent. Autre point : le projet est en version 0.3.0, publiée le 8 juin 2026, après 0.2.0 et 0.1.0 en mai de la même année. Trois versions mineures en quelques semaines, c'est un rythme de développement actif, et cela veut dire que les interfaces bougent. Le README mentionne d'ailleurs un document de migration depuis openclaw, ce qui suggère que le format d'état a déjà changé une fois de façon suffisamment notable pour justifier un guide. Si vous cherchez une bibliothèque à importer dans une application existante, Gini Agent n'est pas cela : il impose un processus gateway, un contrat /api/* et des clients. De même, si vous voulez un agent qui travaille en autonomie complète sans validation, les approbations et la barrière humaine de l'apprentissage des compétences vont vous gêner à chaque étape. Enfin, l'exécution d'un navigateur sous Xvfb dans un conteneur ajoute une couche d'exploitation qui n'est pas anodine.

Face à une bibliothèque d'orchestration comme LangGraph

La comparaison la plus utile n'est pas avec un autre agent clé en main mais avec une bibliothèque d'orchestration. LangGraph, par exemple, vous donne des graphes d'états et des points de contrôle que vous intégrez dans votre propre service : c'est vous qui décidez où vit l'état, qui l'authentifiez et qui exposez l'interface. Gini Agent prend la décision inverse. L'état vit dans le gateway, l'authentification est fournie, l'interface est fournie, et les clients sont fournis. Vous gagnez du temps sur tout ce qui entoure l'agent (approbations, mémoire, jobs, traces, audit) et vous perdez la liberté de composer l'ensemble avec votre pile existante. Un autre point de différence : LangGraph ne présuppose rien sur la façon dont un humain intervient, alors que Gini Agent impose ses primitives de contrôle, cartes de secret, choix, confirmation avant envoi, comme seul chemin d'interaction. C'est plus cohérent, c'est aussi plus fermé. Si votre besoin est d'orchestrer des appels de modèles dans un backend que vous maîtrisez déjà, la bibliothèque est le bon choix. Si votre besoin est de faire tourner un agent personnel complet sur votre machine, avec une interface web et mobile, le gateway apporte ce que la bibliothèque ne fournit pas.

Maintenance, licence et coût de mise à jour

La licence est MIT, ce qui autorise la modification et la redistribution avec conservation de la notice de copyright. Le matériel fourni ne contient pas de fichier LICENSE lisible, seulement l'identifiant de licence déclaré, donc il faut vérifier le texte exact dans le dépôt avant tout usage en entreprise. Sur la maintenance, le dépôt n'est pas archivé, la dernière poussée date du 18 juillet 2026, et le README renvoie à docs/releases.md pour le versionnement, les conventions de CHANGELOG et le processus de publication. Le coût de mise à jour se concentre à deux endroits : les migrations d'état, puisque le projet documente déjà un chemin de migration depuis openclaw, et les fournisseurs de modèles, dont les guides sont séparés par fournisseur dans docs/providers/. Un changement d'API chez un fournisseur se traduit donc par une modification localisée, ce qui limite la casse. Le ROADMAP.md liste les surfaces livrées et ce qui est prévu, avec l'intention de conception : c'est le document à lire pour juger si le rythme de développement correspond à ce que vous pouvez suivre.

Conclusion éditoriale

Gini Agent convient à qui veut un agent personnel auto-hébergé, avec un état persistant et des approbations explicites, et accepte de faire tourner un processus Bun par instance. Il ne convient pas si vous cherchez une bibliothèque d'orchestration à intégrer dans un service existant : le projet impose son gateway, son contrat /api/* et ses clients. Avant d'adopter, vérifiez la page /setup et le catalogue de fournisseurs, puis les commandes de diagnostic listées dans docs/operations.md, parce que c'est là que se joue la question du fournisseur de modèles.

Sources officielles

1. Issues
2. License: MIT
3. Open-Curiosity/gini-agent on GitHub
4. README
5. Releases