Inari : vos agents dans la poche

Dès que des agents travaillent seuls, la question n'est plus « comment les lancer » mais « comment savoir ce qu'ils font, et dire oui ou non depuis le canapé ». Inari est notre réponse : une appli Android native qui est la console de toute la pile. Elle est libre ; voici comment elle est construite, pour que vous construisiez la vôtre.

Ce que vous y gagnez. Tout votre labo dans la poche : des sessions suivies en direct, un orchestrateur qui lit tout, et chaque décision d'un seul tap. Simple à construire : une petite API et une appli native.

1. Une petite API, pas une ligne directe

Le téléphone ne parle jamais directement à un agent ni à une base. Une petite API HTTP tourne sur l'hôte qui porte déjà la table des événements du parc. Elle :

• n'écoute que sur une adresse, celle de votre réseau privé ;
• refuse toute route sauf /v1/health sans son jeton porteur ;
• lit ses sources avec des accès en lecture seule : les événements, les issues de la Forge, quel modèle tourne sur quelle carte ;
• n'a qu'une écriture : poser l'étiquette go sur une issue, ce qui lance un agent dessus.

Chaque source tombe seule : si la Forge ne répond pas, le résumé porte une erreur dans ce champ, jamais une page blanche.

La règle « aucun code ne pose go » reste vraie : cette route porte le tap d'un humain, authentifié, depuis le téléphone. La décision de dépenser la soirée d'un modèle sur une tâche vous appartient.

2. Les onglets qui ont gagné leur place

• Sessions : les sessions de code d'OpenFox, suivies en direct, avec votre accord demandé quand l'agent veut lancer quelque chose de sensible.
• Essaim : un chat avec un orchestrateur local qui lit le parc tout seul et propose des actions sur des cartes.
• Runs et Contrôle : les journaux des agents pendant qu'ils écrivent, la file, quel modèle est sur quelle carte.
• Issues : les tâches qui vous attendent, avec le bouton Go.
• Salles : des conversations longues qui survivent à l'appli fermée (voir salles et FoxDesk).

3. L'orchestrateur désigne, le code agit

L'orchestrateur local est un modèle de 9B à 27B avec une liste fermée d'outils. Les outils de lecture s'exécutent seuls. Les outils d'action (lancer une session, changer de modèle, relancer un workflow) ne s'exécutent jamais : ils renvoient une carte, et seul votre tap l'exécute. La carte dit exactement ce qu'elle va faire, y compris ce qu'elle va décharger.

Mesuré sur un 9B : il a annoncé une action sans appeler l'outil une fois sur trois, et lisait des compteurs à l'envers. Les corrections étaient dans les outils, pas dans le prompt : chaque outil renvoie son propre mode de lecture, et le filtrage par date est fait par le code. Avant de croire à une nouvelle capacité, un banc de dix cas joués trois fois, toute action refusée.

4. Sans Google

• Kotlin natif et Jetpack Compose, sans bibliothèque réseau : le client HTTP et le parseur JSON de la plateforme.
• Le jeton chiffré par le Keystore Android, l'appli verrouillée par l'empreinte, HTTPS seulement.
• Notifications par ntfy, pas Firebase. Une notification porte un lien qui ouvre précisément la session qui vous attend.
• Publiée par le serveur lui-même, hors de tout magasin.

Pièges

Ne décidez pas seul du périmètre d'une version 1. Notre première version était un tableau de bord ; ce qui était voulu, c'était « un agent de code dans la poche, en local seulement ». Montrez une esquisse avant de construire.

Un double tap ne doit pas lancer deux tâches. Générez un identifiant de requête sur le téléphone, et laissez le serveur renvoyer le même reçu pour le même identifiant.

Utile ? Dites-nous ce qu'il faut mesurer ensuite.