Les LLM 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 piloter la plateforme dès son premier tour de raisonnement.
HTTP partout · 100+ endpoints par conteneur · architecture peer · agents qui lancent des agents
Le protocole sur lequel les LLM 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 connaissent la grammaire nativement. Hoody expose la plateforme à travers cette grammaire pour que rien n'ait besoin d'être ponté.
Pas d'étape de génération SDK
Les clients Hoody n'ont pas besoin de SDK. Le LLM lit la spec OpenAPI ou simplement la doc, puis émet du curl. Fonctionne avec chaque modèle — aujourd'hui et demain.
Les adaptateurs MCP deviennent optionnels
Le client MCP (/platform/mcp) étend la palette d'outils de l'agent avec des serveurs tiers. Mais la plateforme Hoody elle-même est joignable 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.
Debug lisible par un humain
L'agent a fait une erreur ? Regarde 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 container. Exécution terminal, opérations de fichiers, requêtes SQL, automatisation navigateur, déploiement de scripts, captures d'écran, notifications. Un agent qui se connecte à un conteneur Hoody a immédiatement un accès programmatique à tout ce qu'a un développeur humain.
Lancez des commandes, streamez la sortie, capturez les sessions, exportez l'historique
Lis, écris, cherche, compresse, transfère sur 60+ backends cloud
Déployez des scripts en API HTTP, exécutez avec auth, mettez en cache les résultats
Requêtez, mutez, introspectez les schémas, écritures concurrent-safe
Naviguez, prenez des screenshots, interagissez, scrapez, remplissez les formulaires
Screenshot X11, liste les fenêtres, observe l'état du GUI
Les conteneurs sont des peers. 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, requêter son SQLite — tant qu'il a 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 fait un travail spécialisé, retourne. La hiérarchie naît de la fonction, pas de l'architecture.
Parallélisme fan-out
L'agent A lance 10 copies d'une tâche sur 10 conteneurs. Chacun est un agent indépendant qui opère en isolation.
Chaîne de review
L'agent A rédige du code. L'agent B fait la review en ouvrant les fichiers de A. L'agent C lance les tests via POST sur exec.
Agents spécialistes
Un agent dédié au filesystem. Un autre à la base. Un autre au navigateur. Ils parlent en HTTP, pas en in-process.
L'agent ne suggère pas. Il livre.
Les setups d'agents legacy s'arrêtent à "dis à l'humain ce qu'il doit lancer". Les agents Hoody lancent la commande eux-mêmes. La voie de récupération, c'est le rollback via snapshot, pas la peur de faire des changements — ce qui transforme l'utilité réelle d'un agent.
Raisonner
L'agent lit, pense, planifie — comme n'importe quelle boucle LLM.
Agir
L'agent POST sur terminal / exec / files / sqlite. La commande tourne en production.
Observer
L'agent lit la réponse, le code de sortie, le changement filesystem, le stderr. Feedback du monde réel.
Récupérer
Quelque chose a cassé ? PATCH sur un snapshot (/methods/data-state) fait le rollback. Sûr de prendre des risques.
Les agents créent des conteneurs. Les conteneurs exécutent des agents.
Comme la création de conteneur est un seul POST HTTP, un agent peut créer de nouveaux conteneurs à la demande. Le système multi-agents est émergent — pas besoin d'orchestrateur. Les conteneurs peuvent être des workers jetables courts, des spécialistes long-running, ou tout ce qui se trouve entre.
L'agent décide de paralléliser
La tâche teste 10 hypothèses. L'agent reconnaît l'opportunité de fan-out.
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, rapportent au conteneur parent.
Démontage
Le gagnant continue à tourner. Les perdants sont DELETE. Coût : quasi nul par conteneur jetable.
Chaque appel HTTP est une donnée d'entraînement future.
Quand toutes les opérations sont des requêtes HTTP, elles sont toutes capturées dans les logs proxy par défaut. Le workflow d'un utilisateur devient un dataset structuré de tuples (prompt, action, résultat) — sans aucune instrumentation. C'est ce qui rend la plateforme AI-native, pas seulement AI-compatible.
Chaque action dans les logs proxy
Les logs proxy capturent méthode, chemin, body (optionnel), réponse. Chaque opération est traçable.
Structurées par défaut
Les requêtes et réponses JSON ont déjà la bonne forme pour les pipelines de fine-tuning supervisé ou RLHF.
vos données, votre entraînement
Les logs restent sur votre bare-metal. Hoody ne voit rien à moins que vous n'exportes.
Infra auto-construite
Les scripts MITM peuvent générer la doc, optimiser les endpoints, ou prédire les prochaines requêtes les plus fréquentes à partir de l'historique des logs.
Donne curl à un LLM et il sait déjà s'en servir.
Passez à votre agent une URL de conteneur Hoody et un token. Il peut maintenant exécuter des commandes, écrire des fichiers, requêter des bases, lancer plus de conteneurs — tout depuis le protocole sur lequel il a été entraîné.
Voir aussi — /platform/ai-gateway pour le côté modèle, /platform/mcp pour l'intégration d'outils externes, /kit/agent pour le runtime agent.