LLMs kennen HTTP bereits. Das ist das gesamte Substrat.
Jede Hoody-Fähigkeit ist ein HTTP-Aufruf. Ein LLM, das auf dem öffentlichen Internet trainiert wurde, kennt curl, JSON und REST-Konventionen bereits. Kein SDK-Bridge. Kein MCP-Adapter zu schreiben.
HTTP überall · 100+ Endpunkte pro Container · Peer-Architektur · Agenten, die Agenten spawnen
Kein SDK. Nur curl.
LLMs wurden auf Milliarden von curl-Beispielen, OpenAPI-Spezifikationen und REST-Tutorials trainiert. HTTP ist die Sprache, die sie bereits kennen.
Kein SDK-Generierungsschritt
Hoody-Clients brauchen kein SDK. Das LLM liest die OpenAPI-Spec oder einfach die Docs und gibt curl aus. Funktioniert mit jedem Modell, jeder Version.
MCP-Adapter werden optional
Der MCP-Client (/platform/mcp) erweitert das Toolset des Agents mit Drittanbieter-Servern. Aber die Hoody-Plattform selbst ist per HTTP vollständig erreichbar.
OpenAPI ist der Vertrag
Jeder Kit-Service stellt /openapi.json bereit. Agents lesen die Spec, kennen die Schemas und rufen die Endpunkte auf. Selbstdokumentierend.
Menschenlesbare Fehlersuche
Agent hat einen Fehler gemacht? Schau dir das curl an, das er erzeugt hat. Die Spur hat das gleiche Format, das ein menschlicher Operator von Hand schreiben würde.
Jeder Container gibt einem Agent beim Ankommen hundert Werkzeuge.
Die Kit-Services stellen ~100+ dokumentierte HTTP-Endpunkte pro Container bereit. Terminal-Ausführung, Dateioperationen, SQL-Abfragen und mehr.
Befehle ausführen, Ausgabe streamen, Sessions aufnehmen, Verlauf exportieren
Lesen, schreiben, suchen, komprimieren, über 60+ Cloud-Backends übertragen
Skripte als HTTP-APIs deployen, mit Auth ausführen, Ergebnisse cachen
Abfragen, mutieren, Schemas introspektieren, concurrent-sichere Schreibvorgaenge
Navigieren, Screenshots machen, interagieren, scrapen, Formulare ausfuellen
X11 screenshotten, Fenster auflisten, GUI-Zustand beobachten
Agenten und Menschen nutzen dieselben Endpunkte.
Kein spezieller Agent-Modus. Kein reservierter API-Schlüssel für KI. Der Agent macht dieselben HTTP-Aufrufe wie dein Monitoring-System oder dein Dashboard.
Agent-Kaskade
Agent A löst Agent B per HTTP aus. B erledigt spezialisierte Arbeit und kehrt zurück. Hierarchie entsteht aus Funktion, nicht aus Architektur.
Fan-Out-Parallelismus
Agent A lässt 10 Kopien einer Aufgabe in 10 Containern laufen. Jede ist ein unabhaengiger Agent, der isoliert arbeitet.
Review-Kette
Agent A entwirft Code. Agent B reviewt durch Öffnen von As Dateien. Agent C führt Tests aus, indem er an exec POSTet.
Spezialisierte Agents
Ein Agent für Dateisystem-Arbeit. Einer für Datenbank. Einer für Browser. Sie kommunizieren über HTTP, nicht in-process.
Der Agent schlägt nicht vor. Er liefert.
Legacy-Agent-Setups hören bei 'dem Menschen sagen, was er ausführen soll' auf. Hoody-Agents führen den Befehl selbst aus. Der Fehlerpfad ist real.
Reason
Agent liest, denkt, plant — wie jede LLM-Schleife.
Act
Agent POSTet an terminal / exec / files / sqlite. Der Befehl läuft in der Produktion.
Beobachten
Agent liest die Antwort, den Exit-Code, die Dateisystemveraenderung, das stderr. Echte Rueckmeldung aus der Welt.
Recover
Etwas ging schief? PATCH auf einen Snapshot (/methods/data-state) macht es rueckgaengig. Risiken können eingegangen werden.
Agents erstellen Container. Container betreiben Agents.
Weil das Erstellen eines Containers ein einzelner HTTP-POST ist, kann ein Agent bei Bedarf neue Container anlegen. Das Multi-Agent-System ist selbsterweiternd.
Agent entscheidet zu parallelisieren
Aufgabe ist das Testen von 10 Hypothesen-Aesten. Agent erkennt die Fan-Out-Möglichkeit.
POST /projects/ID/containers × 10
Zehn neue Container, jeder mit seiner eigenen Agent-Instanz.
Dispatch
Jeder Worker bekommt einen anderen Ast. Agents arbeiten parallel und berichten an den Eltern-Container zurück.
Teardown
Gewinner läuft weiter. Verlierer werden per DELETE entfernt. Kosten: nahezu null pro Wegwerf-Container.
Jeder HTTP-Aufruf ist künftige Trainingsdaten.
Wenn alle Operationen HTTP-Anfragen sind, werden sie standardmäßig alle als Proxy-Logs aufgezeichnet. Der Workflow eines Users wird zu strukturierten Daten.
Jede Aktion in Proxy-Logs
Proxy-Logs erfassen Methode, Pfad, Body (optional), Antwort. Jede Operation ist nachverfolgbar.
Standardmäßig strukturiert
JSON-Anfragen und -Antworten sind bereits in der richtigen Form für Supervised-Fine-Tuning oder RLHF-Pipelines.
Deine Daten, dein Training
Logs bleiben auf deinem Bare Metal. Hoody sieht nichts davon, ausser du exportierst es.
Selbst-buildende Infrastruktur
MITM-Skripte können Dokumentation generieren, Endpunkte optimieren oder naechste haeufigste Anfragen aus dem Log-Verlauf vorhersagen.
Dein Agent kann Hoody sofort steuern.
@hoody.com zu deinem Agenten hinzufügen. Er holt die Skill-Datei und lernt alle Endpunkte. Kein SDK, kein Setup.
Siehe auch — /platform/ai-gateway für die Modell-Seite, /platform/mcp für externe Tool-Integration, /kit/agent für den Agent-Service.