Les LLMs connaissent déjà HTTP. C'est tout le substrat.
Chaque capacité Hoody est un appel HTTP. Un LLM entraîné sur l'internet public connaît déjà curl, JSON et les conventions REST. Pas de pont SDK. Pas d'adaptateur MCP à écrire. L'agent peut opérer la plateforme dès son premier tour de raisonnement.
HTTP partout · 100+ endpoints par conteneur · architecture pair-à-pair · agents qui spawnent des agents
Le protocole sur lequel les LLMs ont déjà été entraînés.
Chaque GPT, Claude, Gemini et Llama a lu des millions d'exemples HTTP pendant le pré-entraînement — commandes curl, endpoints REST, corps JSON, codes de statut. Ils en connaissent la grammaire nativement. Hoody expose la plateforme via cette grammaire, sans rien à ponter.
Pas d'étape de génération de SDK
Les clients Hoody n'ont pas besoin de SDK. Le LLM lit la spec OpenAPI ou simplement la documentation, puis émet du curl. Fonctionne avec tous les modèles — aujourd'hui et demain.
Les adaptateurs MCP deviennent optionnels
Le client MCP (/platform/mcp) étend le jeu d'outils de l'agent avec des serveurs tiers. Mais la plateforme Hoody elle-même est accessible en HTTP brut — pas de couche de traduction.
OpenAPI est le contrat
Chaque service Kit expose /openapi.json. Les agents lisent la spec, connaissent les schémas et appellent les endpoints. Auto-documenté par construction.
Débogage lisible par l'humain
L'agent a fait une erreur ? Regardez le curl qu'il a généré. La trace est au même format qu'un opérateur humain écrirait à la main.
Chaque conteneur donne à un agent une centaine d'outils dès l'arrivée.
Les services Kit exposent ~100+ endpoints HTTP documentés par conteneur. Exécution de terminaux, opérations sur fichiers, requêtes SQL, automatisation de navigateur, déploiement de scripts, captures d'écran d'affichage, notifications. Un agent qui se connecte à un conteneur Hoody a immédiatement un accès programmatique à tout ce qu'un développeur humain possède.
Lancer des commandes, streamer la sortie, capturer des sessions, exporter l'historique
Lire, écrire, rechercher, compresser, transférer sur 60+ backends cloud
Déployer des scripts en APIs HTTP, exécuter avec auth, mettre en cache les résultats
Requêter, muter, introspecter des schémas, écritures concurrentes sécurisées
Naviguer, capturer des écrans, interagir, scraper, remplir des formulaires
Capture d'écran X11, liste des fenêtres, observation de l'état GUI
Les conteneurs sont des pairs. Les agents se parlent directement.
Il n'y a pas d'orchestrateur central. Un agent dans le conteneur A peut ouvrir l'URL du conteneur B, lire ses fichiers, lancer son terminal, interroger son SQLite — tant qu'il possède l'URL et l'auth. Les systèmes multi-agents émergent de HTTP, pas d'une couche de coordination par-dessus.
Cascade d'agents
L'agent A déclenche l'agent B via HTTP. B effectue un travail spécialisé et renvoie le résultat. La hiérarchie se forme par fonction, pas par architecture.
Parallélisme en éventail
L'agent A crée 10 copies d'une tâche sur 10 conteneurs. Chacun est un agent indépendant opérant en isolation.
Chaîne de revue
L'agent A rédige du code. L'agent B le révise en ouvrant les fichiers de A. L'agent C lance les tests en postant vers exec.
Agents spécialisés
Un agent dédié au travail sur le système de fichiers. Un autre à la base de données. Un autre au navigateur. Ils communiquent via HTTP, pas en in-process.
L'agent ne suggère pas. Il livre.
Les configurations d'agents classiques s'arrêtent à « dire à l'humain quoi lancer ». Les agents Hoody lancent eux-mêmes la commande. Le chemin d'échec est le rollback via snapshot, pas la peur d'effectuer des changements — ce qui change ce à quoi un agent est réellement utile.
Raisonner
L'agent lit, réfléchit, planifie — comme n'importe quelle boucle LLM.
Agir
L'agent poste vers terminal / exec / fichiers / sqlite. La commande s'exécute en production.
Observer
L'agent lit la réponse, le code de sortie, le changement dans le système de fichiers, le stderr. Retour du monde réel.
Récupérer
Quelque chose s'est cassé ? PATCH vers un snapshot (/methods/data-state) effectue un rollback. On peut prendre des risques en toute sécurité.
Les agents créent des conteneurs. Les conteneurs exécutent des agents.
La création d'un conteneur étant un simple HTTP POST, un agent peut créer de nouveaux conteneurs à la demande. Le système multi-agents est émergent — pas d'orchestrateur nécessaire. Les conteneurs peuvent être des workers éphémères, des spécialistes à longue durée de vie, ou tout ce qui se trouve entre les deux.
L'agent décide de paralléliser
La tâche est de tester 10 hypothèses en parallèle. L'agent reconnaît l'opportunité de parallélisation.
POST /projects/ID/containers × 10
Dix nouveaux conteneurs, chacun avec sa propre instance d'agent.
Dispatch
Chaque worker reçoit une branche différente. Les agents travaillent en parallèle et rendent compte au conteneur parent.
Démantèlement
Le gagnant continue à tourner. Les perdants sont supprimés avec DELETE. Coût : quasi nul par conteneur jetable.
Chaque appel HTTP est une future donnée d'entraînement.
Lorsque toutes les opérations sont des requêtes HTTP, elles sont toutes capturées dans les logs du proxy par défaut. Le workflow d'un utilisateur devient un ensemble de données structurées de tuples (prompt, action, résultat) — sans aucune instrumentation. C'est ce qui rend la plateforme AI-native, pas seulement compatible avec l'IA.
Chaque action dans les logs proxy
Les logs proxy capturent la méthode, le chemin, le corps (optionnel), la réponse. Chaque opération est traçable.
Structuré par défaut
Les requêtes et réponses JSON ont déjà la bonne forme pour le fine-tuning supervisé ou les pipelines RLHF.
Vos données, votre entraînement
Les logs restent sur votre bare metal. Hoody n'en voit rien à moins que vous n'exportiez.
Infrastructure auto-construite
Des scripts MITM peuvent générer de la documentation, optimiser des endpoints ou prédire les prochaines requêtes les plus courantes à partir de l'historique des logs.
Donnez curl à un LLM et il sait déjà comment l'utiliser.
Donnez à votre agent une URL de conteneur Hoody et un token. Il peut désormais exécuter des commandes, écrire des fichiers, interroger des bases de données, créer d'autres conteneurs — tout depuis le protocole sur lequel il a été entraîné.
Voir aussi — /platform/ai-gateway pour la partie modèle, /platform/mcp pour l'intégration d'outils externes, /kit/agent pour le runtime d'agent.