ainess

ainess est une application de bureau (Tauri 2, licence MIT) qui transforme les CLI de codage IA déjà installées sur votre machine en une équipe coordonnée. Plutôt que d'intégrer un modèle ou une clé API, elle détecte et pilote les outils existants — Claude Code, Antigravity, GitHub Copilot CLI, Gemini CLI, Codex CLI, opencode, Ollama et Aider — et peut en installer la plupart via un panneau de configuration. Un type d'agent « personnalisé » peut exécuter n'importe quelle commande, avec {prompt} substitué dans ses arguments. Les sessions et les identifiants restent là où chaque CLI les conserve ; l'application précise qu'elle ne demande, ne stocke ni ne lit jamais de clé. Windows est la plateforme sur laquelle elle est développée et testée. Fonctionnement de l'orchestration Les agents sont des processus CLI à exécution unique. Chaque invocation est un « run », et les conversations persistent entre les exécutions car chaque fournisseur est repris via son propre identifiant de session. Les agents sont organisés selon une hiérarchie de rôles : un planificateur qui raisonne, divise le travail et délègue sans implémenter ; des exécutants qui effectuent le travail ; et des réviseurs qui le vérifient. La délégation s'effectue via un bloc délimité dans la réponse du planificateur, que l'orchestrateur analyse en exécutions et renvoie comme résultats — un cycle appelé « round », avec un maximum configurable. Les tâches doivent être autonomes, car un agent enfant ne voit pas la conversation du planificateur. Un agent peut également faire une pause et poser une question à l'utilisateur avec des options, et l'exécution reprend dans la même session une fois la réponse donnée. À l'intérieur de l'application Les projets pointent vers des dossiers de workspace et conservent leur propre équipe, état, historique et chats ; une « formation » sauvegardée peut être appliquée à de nouveaux projets avec ses compétences et ses serveurs MCP. Un tableau kanban à six colonnes (du backlog à terminé) est alimenté automatiquement : un prompt crée une tâche, les délégations y sont rattachées, les approbations attendent dans « needs you », et les exécutions terminées passent en révision ou prêtes. Ces mêmes tâches s'affichent sous forme de graphe de dépendances stratifié où les connexions glissées déclarent des relations de blocage. Les autres vues incluent un fil de discussion avec l'orchestrateur (utilisation d'outils, délégations repliables, « ordres » de prompts sauvegardés), un graphe hiérarchique montrant qui délègue à qui et le quota restant, un dock à droite avec des flux d'événements bruts et des terminaux PTY réels, des approbations pouvant être requises par agent ou globalement, des chats multi-agents directs et partagés, des notifications, l'état du dépôt git (branche, fichiers modifiés, avance/retard, pull requests ouvertes avec statut CI) et des menus contextuels au clic droit. Des worktrees git par agent avec leur propre branche permettent à deux exécutants de travailler simultanément sans conflit sur l'index git ; un panneau permet de les ouvrir, les fusionner ou les supprimer, refusant la fusion en cas de travail non commité. Accès distant et CLI Un serveur intégré publie la même interface React sous forme de page unique autonome sur le LAN, protégée par un jeton dans l'URL (401 sans celui-ci), permettant ainsi à un téléphone de visualiser le tableau, d'envoyer des tâches, d'arrêter des exécutions et de répondre aux questions. Des URL publiques optionnelles sont disponibles via cloudflared ou ngrok, avec support pour les domaines statiques. La page propose également des notifications de navigateur lorsqu'elle est active en arrière-plan, ce qui nécessite un contexte sécurisé. Une API HTTP avec authentification par jeton expose l'état, un flux d'événements SSE, et des points de terminaison pour le prompt, l'instruction, l'arrêt, l'approbation et le chat. Le même orchestrateur est disponible sans interface via une CLI, avec des commandes pour exécuter des tâches, gérer les projets, les agents et les formations, détecter les installations, vérifier le quota et l'usage, parcourir l'historique, gérer les approbations, chatter et servir la page mobile. Extras et données Des compétences, des serveurs MCP, un contexte partagé et un profil sont injectés dans les prompts des agents. Des hooks réagissent aux événements de l'orchestrateur tels que task.started, task.finished, delegation ou approval.requested via Slack/Discord ou des webhooks génériques, des commandes locales, des notifications système, ou des instructions chaînées vers un autre agent, en utilisant des variables templatisées. Toute la configuration, l'historique, les chats, les tableaux de tâches, les marques de quota et les logs résident dans des fichiers texte sous les dossiers AppData de l'utilisateur ; l'historique conserve les 300 dernières exécutions et 3000 messages par projet, les logs tournent quotidiennement et sont conservés 14 jours, et les jetons sont masqués avant l'écriture. L'interface est traduite en espagnol, anglais, portugais brésilien, chinois simplifié, japonais, français et allemand, commutable sans redémarrage, avec l'espagnol comme dictionnaire de base. Les versions sont construites et signées via GitHub Actions à partir d'un bump de version sur la branche main, et les applications installées se mettent à jour automatiquement.