Soixante conteneurs sur un seul serveur
Une seule machine bare-metal fait tourner des dizaines à des centaines de conteneurs Hoody. La déduplication KSM et BTRFS rend le coût marginal quasi nul.
Un agent de recherche reçoit un prompt complexe. Au lieu de tout faire lui-même, il POST sur l'API conteneurs et récupère trois URLs de sous-agents. Chaque sous-agent peut lancer ses propres sous-agents. Aucun ne connaît d'orchestrateur. Ils s'appellent juste les uns les autres en HTTP.
Chaque nœud de l'arbre est un conteneur Hoody avec un service hoody-agent. Parents et enfants ne se connaissent que par URL. Aucun planificateur central ne regarde d'en haut.
Reçoit le prompt. Décide quelles sous-tâches fan-out. POST vers l'API conteneurs pour lancer un nouveau conteneur par sous-agent, puis appelle l'endpoint /api/v1/agent/tasks de chacun avec sa part de travail.
Chacun tourne dans son propre conteneur avec son filesystem, son terminal, sa SQLite. Aucun ne peut corrompre les autres. N'importe lequel peut décider qu'il a besoin d'aide et lancer ses propres enfants comme l'a fait le parent. Le protocole est symétrique.
Le fact-checker voit cinq claims, lance cinq conteneurs en parallèle, fait cinq requêtes HTTP, attend cinq réponses. Même pattern, un niveau plus bas. Les conteneurs idle ne coûtent rien — les arbres profonds sont économiquement gratuits.
Pas de runtime d'agent à installer, pas de bus de messages à configurer, pas d'état partagé à synchroniser. L'agent parent utilise la même API Conteneurs qu'un humain : POST pour créer, puis appeler l'URL de l'enfant.
// Agent parent (tournant dans son propre conteneur Hoody).
// Lancer trois sous-agents, donner à chacun une part de travail,
// attendre leurs résultats en parallèle.
const HOODY = 'https://api.hoody.com';
async function spawnChild(name) [
// 1. Créer un conteneur neuf avec le service agent en route.
const res = await fetch(HOODY + '/api/v1/projects/' + PROJECT + '/containers', [
method: 'POSVous ,
headers: [ authorization: 'Bearer ' + TOKEN ],
body: JSON.stringify([
name,
server_id: SERVER,
conteneur_image: 'debian-12',
hoody_kit: true,
ai: true,
]),
]);
const child = (await res.json()).data;
// 2. Tape l'URL agent de l'enfant comme n'importe quel autre service HTTP.
const agentUrl = 'https://' + PROJECT + '-' + child.id + '-agent-1.' + SERVER + '.containers.hoody.com';
return [ id: child.id, agentUrl ];
]
const [scrape, summarize, factCheck] = await Promise.all([
spawnChild('scrape'),
spawnChild('summarize'),
spawnChild('fact-check'),
]);
// 3. Dispatch des tâches. Chaque enfant tourne en autonome,
// peut lancer ses propres enfants de la même manière.
const results = await Promise.all([
fetch(scrape.agentUrl + '/api/v1/agent/tasks', [ method: 'POSVous , body: JSON.stringify([ description: scrapeBrief ]) ]),
fetch(summarize.agentUrl + '/api/v1/agent/tasks', [ method: 'POSVous , body: JSON.stringify([ description: summarizeBrief ]) ]),
fetch(factCheck.agentUrl + '/api/v1/agent/tasks', [ method: 'POSVous , body: JSON.stringify([ description: factCheckBrief ]) ]),
]);Les deux endpoints sont des APIs Hoody documentées : POST /api/v1/projects/$PID/containers lance un nouveau conteneur avec le service agent préinstallé ; POST $CHILD_URL/api/v1/agent/tasks dispatch une tâche. Le fact-checker peut faire tourner exactement le même code pour lancer ses propres vérificateurs par claim — la récursion est juste du HTTP.
Tous les frameworks d'agents sont une fine couche sur des appels de fonctions in-process. Ils supposent que les agents partagent la mémoire, le Python, un seul runtime. Hoody suppose le contraire : les agents sont des ordinateurs séparés, et HTTP est déjà le protocole qu'ils parlent.
POST /api/v1/projects/$PID/containers
fetch(child.url + '/api/v1/agent/tasks')
Deux appels HTTP par enfant. Le parent n'importe pas de framework, n'enregistre pas d'outil, ne partage pas d'état. Chaque sous-agent est un pair avec une URL — même forme que le parent, même forme que pour appeler n'importe quel autre service HTTP.
Chaque agent est un pair avec une URL. Ils s'appellent comme n'importe quel service HTTP appelle n'importe quel autre service HTTP.
Pas d'orchestrateur. Pas de bus de messages. Pas d'état partagé à synchroniser. La seule limite au nombre d'agents que vous faites tourner en parallèle est ce que vous voulez dépenser — et les conteneurs idle ne coûtent rien.
Les frameworks d'orchestration et services de runtime éphémère vers lesquels les gens se tournent quand un agent ne suffit pas. Chacun résout une part du problème. Le primitif HTTP-natif remplace la part et le framework qui l'entoure.
Arrêtez de câbler des graphes d'agents. Lancez-en un. Laissez-le lancer le reste.