Kit-DienstDein Agent bekommt einen Körper
Jeder Kit-Service ist ein HTTPS-Endpunkt. Einen Container starten, 14 HTTP-Tools erhalten. Dein Agent kennt curl und JSON bereits.
$ ws connect wss://proj-1-abc.srv.containers.hoody.com/api/v1/agent/ws
[tool_use] { tool: "terminal_exec", command: "npm install" }
[tool_use] { tool: "write_file", path: "/app/src/auth.ts" }
[tool_result] { output: "3 tests passed" }
[tool_use] { tool: "daemon_start", service: "api-server" }
[completed] task finished in 4m 12s
Ein POST. Drei Muster.
Sende eine Aufgabe, überwache den WebSocket-Stream, rolle ein fehlgeschlagenes Experiment zurück — alles über Standard-HTTP-Aufrufe.
Sende eine Aufgabe und streame Events
POST eine natürlichsprachige Beschreibung, um eine Aufgabe zu erstellen, dann öffne den WebSocket, um jeden Tool-Aufruf und jedes Ergebnis in Echtzeit zu streamen.
# 1. Create task
POST /api/v1/agent/tasks
'{'
"description": "Install deps, write auth.ts, run tests",
"mode": "code"
'}'
→ '{' "id": "task-abc123", "status": "running" '}'
# 2. Open WebSocket stream
WS wss://.../api/v1/agent/ws
> '{' "type": "tool_use", "tool": "terminal_exec", "command": "npm install" '}'
> '{' "type": "tool_use", "tool": "write_file", "path": "/app/src/auth.ts" '}'
> '{' "type": "tool_result", "output": "3 tests passed" '}'
> '{' "type": "tool_use", "tool": "daemon_start", "service": "api-server" '}'
> [completed] task finished in 4m 12s
Jedem Agent einen vollständigen Computer geben
Ein Container-Erstellungsaufruf stellt 14 HTTP-Services bereit. Kein Setup, kein Treiber-Management, keine Auth-Zeremonie ausser einem Bearer-Token.
Agents spawnen Agents. Kein Koordinator nötig.
Agent A erstellt Agent Bs Container per HTTP, weist Aufgaben über die Agent-Service-URL zu, liest seine Dateien direkt. Nur HTTP.
// Agent A spawns Agent B and assigns work
const worker = await client.api.containers.create(PROJECT_ID, {
name: "ai-worker-backend",
server_id: "us-east-1",
container_image: "hoody-kit:latest",
hoody_kit: true,
});
await fetch(
`https://${PROJECT_ID}-${worker.id}-agent-1.${SRV}/api/v1/agent/tasks`,
{ method: "POST", body: JSON.stringify({
description: "Build payment module", mode: "code"
})}
);
Netzwerk-Topologie
Agents sind Gleichgestellte. Jeder Container ruft jeden anderen per HTTP auf. Kein Bus, kein Koordinator.
Parallele Worker
10 Spezialisten-Agents gleichzeitig einsetzen. Frontend, Backend, Tests — alles parallel.
Container-übergreifende Lesevorgänge
Agent A liest Agent Bs Dateien per Kit-Files-Service. Inspizieren ohne den Worker zu stoppen.
Isolierte Fehler
Der Absturz eines Agents zerstoert nur seine eigene Sandbox. Fehler können sich nicht ausbreiten.
Jeden Prompt steuern. Kein Proxy-Code nötig.
Sieben Event-Hooks, fünf Aktionstypen, deklarative JSON-Regeln. Die Regel-Engine läuft innerhalb von hoody-agent selbst — keine Latenz.
chat.system.transform
Jeder Prod-Session-System-Prompt vor dem LLM um eine Sicherheitsregel ergaenzen.
tool.execute.before
Einen Menschen benachrichtigen, bevor ein Agent bash ausführt. In-Loop, kein Proxy.
session.error
Einen Webhook an PagerDuty senden, wenn eine Session flottenweit fehlschlaegt.
{
"mitm": {
"rules": [
{
"id": "safety-guardrail",
"enabled": true,
"trigger": {
"event": "chat.system.transform",
"tags": ["prod"]
},
"action": {
"type": "prompt-inject",
"position": "append",
"target": "system"
}
}
]
}
}
Zwei Superkräfte, keine Konfiguration.
Jede KI mit Web-Zugriff kann dein Agent-Programm über @hoody.com erreichen. Jedes Experiment kann sicher in ca. 2 Sekunden zurückgerollt werden.
@hoody.com Skill-Erkennung
Jeder KI-Agent mit Web-Zugriff sendet @hoody.com und erhält eine Skill-Beschreibung deiner gesamten HTTP-API — kein Plugin, kein SDK, kein Custom-Endpoint.
Snapshot vor jedem Agent-Lauf
Niemals einen Agent einen Container verändern lassen ohne Snapshot. Ein API-Aufruf. Sofortiger Rollback in ca. 2 Sekunden.
hoody snapshots create-snapshot $AGENT_ID \
--alias "before-experiment"
6 Endpoints. Vollständige Agent-Kontrolle.
Aufgaben-Lebenszyklus, Echtzeit-Überwachung und MCP-Anhängen — alles Standard-HTTP und WebSocket.
Aufgaben
{count, plural, =1 {# Endpoint} other {# Endpoints}'}POST /api/v1/agent/tasks
Überwachen
{count, plural, =1 {# Endpoint} other {# Endpoints}'}wss://.../api/v1/agent/ws
MCP + Web UI
{count, plural, =1 {# Endpoint} other {# Endpoints}'}POST /api/v1/agent/mcp/servers
Was der Agent tatsächlich tun kann
Drei Möglichkeiten, die keine Menge an Prompt-Engineering dir geben kann — sie sind in der Plattform.
5 Task Modes, während der Sitzung schaltbar
code, architect, debug, ask, orchestrator — jeder ist auf eine andere Absicht ausgerichtet. Wechsle via PATCH /api/v1/agent/tasks/{id}/mode ohne die Aufgabe zu stoppen.
MCP Runtime Tool Discovery
Stelle jeden MCP-kompatiblen Server an — GitHub, Slack, Jira — zur Laufzeit an. Der Agent erkennt und fusioniert die neuen Tools in seiner aktiven Sitzung sofort.
Terminal-Seiten-Panel-Einbettung
Bette den Agent als Seiten-Panel in jede hoody-terminal-URL via ?panel=AGENT_URL ein. Der Agent teilt den Container-Dateisystem und -Prozessstatus mit dem Terminal.
Dein erster Agent ist einen Container entfernt
Container mit hoody-kit starten. 14 HTTP-Services starten sofort auf wenn der Agent es tut. URL an Claude, GPT oder einen beliebigen Agent übergeben, der HTTP spricht.