Zum Inhalt springen
TypNeues PrimitivePhaseProduktionSchwierigkeitMittelAufgabeAufgabe automatisierenFürKI-BuilderFürBackend-DevsServicesCronServicesAgentWarum HoodyKI-nativWarum HoodyHTTP-nativ
TypNeues PrimitivePhaseProduktionSchwierigkeitMittelAufgabeAufgabe automatisierenFürKI-BuilderFürBackend-DevsServicesCronServicesAgentWarum HoodyKI-nativWarum HoodyHTTP-nativ
TypNeues PrimitivePhaseProduktionSchwierigkeitMittelAufgabeAufgabe automatisierenFürKI-BuilderFürBackend-DevsServicesCronServicesAgentWarum HoodyKI-nativWarum HoodyHTTP-nativ
TypNeues PrimitivePhaseProduktionSchwierigkeitMittelAufgabeAufgabe automatisierenFürKI-BuilderFürBackend-DevsServicesCronServicesAgentWarum HoodyKI-nativWarum HoodyHTTP-nativ
Zurück zu Use Cases
use-cases / schedule-the-agent / hero
CRON · AGENT · 0 7 * * *

Plane den Agenten, nicht das Skript

Eine traditionelle Cron-Zeile führt um 2 Uhr reconcile.sh aus. Eine Hoody-Cron-Zeile POSTet einen Prompt an hoody-agent. Der Zeitplan ist fix. Die Arbeit nicht. Edge Cases sind keine Branches mehr, die du wartest — sie werden zu Kontext, über den der Agent reasoniert.

Cron- + Agent-Docs lesen
use-cases / schedule-the-agent / mechanism

Zwei URLs, ein Prompt

Hoody Cron ist eine verwaltete crontab auf jedem Container. Hoody Agent ist ein eingebauter autonomer Agent auf demselben Container. Der Cron-Eintrag curlt den Agenten. Der Agent liest das Datum, liest die Daten, und entscheidet, was der Tag verlangt. Beide Oberflächen sind HTTP — der Cron lebt unter /api/v1/cron/users/me/entries, der Agent unter /api/v1/agent/tasks. Es gibt keinen Glue-Code zwischen ihnen.

cron-1.containers.hoody.com · entry
POST · cron/users/me/entries
# POST /api/v1/cron/users/me/entries
{
  "schedule": "0 7 * * *",
  "command": "curl -X POST $AGENT/api/v1/agent/tasks \
     -d @prompt.json",
  "comment": "morning-reports"
}
agent-1.containers.hoody.com · task
POST · agent/tasks
# prompt.json — the body of the POST
{
  "description": "Reconcile gestrige Bestellungen. Remap, falls Schema gedriftet ist. Halt und page On-Call, falls Anomalie-Score > 3. Wenn heute der letzte Tag des Monats ist, schließe den monatlichen Abschluss auf dem steuerangepassten Hauptbuch ein.",
  "mode": "code"
}

Zwei POSTs und du bist fertig. Die crontab-Zeile ändert sich nie wieder — die einzige Datei, die du wartest, ist der Prompt. Neuer Edge Case? Füge einen Satz hinzu. Neue Anomalie-Regel? Füge einen Satz hinzu. Der Zeitplan feuert weiter; der Agent merkt, was jedes Feuern bedeutet.

use-cases / schedule-the-agent / powers

Drei Dinge, die ein Prompt tut, die ein Skript nicht kann

Die Form der Arbeit, die der Agent erhält, ist immer dieselbe — ein Datum, ein Datensatz, ein Ziel. Was sich ändert, ist, was der Agent damit zu tun entscheidet.

REASONING

Liest das Datum, liest die Daten, entscheidet

Der Agent läuft, nachdem der Cron feuert. Er checkt den Kalender — Monatsende, Feiertag, Fiskalabschluss. Er sampelt den Datensatz — Schema, Volumen, Anomalie-Score. Er pickt die nächste Aktion mit diesem Kontext, nicht aus einem statischen if-Tree, den du vor sechs Monaten geschrieben hast.

ANPASSUNG

Neue Spalten? Neue Währungen? Gleicher Prompt.

Wenn der gestrige Export eine refund_reason-Spalte hinzufügt, bricht ein Skript und paged dich. Der Agent liest das Schema, mappt es auf das Legacy-Feld, und vermerkt die Änderung in der Run-Zusammenfassung. Die crontab-Zeile musste es nie wissen.

BEOBACHTBARKEIT

Jeder Run ist ein Absatz, kein Return-Code

Jeder Run postet zurück, was der Agent entschieden hat und warum. Die Historie ist Klartext — „übersprungen: keine neuen Daten", „angepasst: refund-Spalte hinzugefügt", „Anomalie: refund-Spike +412 %, On-Call gepaged" — kein exit code 0 / exit code 1. Die Logs des Crons werden zu einem Tagebuch.

use-cases / schedule-the-agent / flow

Vom Zeitplan zur Entscheidung

Drei Schritte — der Cron feuert, der Agent reasoniert, die Entscheidung landet. Der mittlere Schritt ist der, den du früher selbst in einem 400-zeiligen Shell-Skript mit siebzehn Edge-Case-Branches geschrieben hast. Jetzt ist es ein Prompt.

Drei-Schritt-TageschleifeEIN PROMPT · UNENDLICH VIELE EDGE CASES
07:00

Der Cron feuert

Hoody Cron führt den Eintrag aus. Die crontab-Zeile ist ein curl: POST /api/v1/agent/tasks mit dem Prompt-Body. Keine von dir geschriebenen Retries, kein Logging-Plumbing — der Cron-Service injiziert den Eintrag in die System-crontab und trackt den Run.

07:00 + ε

Der Agent reasoniert

Der Agent erhält die Beschreibung, öffnet seine Tools — Terminal, Files, sqlite, Browser, Exec — und pickt einen Aktionsplan. Er könnte laufen, überspringen, anpassen oder pagen. Die Picks ändern sich täglich. Die Anweisungen nicht.

07:00 — 07:04

Die Entscheidung landet

Der Run endet. Der Agent postet eine Zusammenfassungszeile zurück: Reports neu generiert, übersprungen wegen keiner neuer Daten, gestoppt wegen Anomalie. Du liest sie auf deinem Telefon beim Frühstück.

Der Zeitplan hat sich nicht geändert. Das Skript hat sich nicht geändert. Was sich geändert hat, ist, ob du, der Mensch, aufwachen musstest, um damit umzugehen. Mit dem Agenten in der Schleife ist die Antwort fast immer nein — und die Run-Historie sagt dir warum.

use-cases / schedule-the-agent / capacity

Was du vom Cron-+-Agent-Paar bekommst

Hoody Cron und Hoody Agent sind zwei Services auf demselben Container, beide über HTTP erreichbar. Zahlen kommen aus den dokumentierten Oberflächen — nicht aus erfundenen Benchmarks.

  1. CRONTAB-GRÖSSE1 Zeile

    Ein curl in der crontab, für immer. Der Prompt-Body ist das einzige, was du je umschreibst — und das machst du in einer JSON-Datei, nicht durch crontab -e.

  2. AGENT-ENDPOINTS100+

    hoody-agent exponiert die volle Oberfläche — Terminal Exec, File Read/Write, sqlite Query, Browser-Automation, Daemon-Steuerung — für die Aufgabe des Agenten als reine HTTP-Calls.

  3. GLUE-ZEILEN0

    Kein SDK zwischen Cron und Agent. POST eine URL, lese eine andere. Beide Services leben auf demselben Container, also ist der Call Local-Network-schnell.

Hoody Cron unterstützt Standard-5-Feld-Ausdrücke (* * * * *) und Makros (@hourly, @daily, @weekly, @monthly, @yearly). Hoody-Agent-Task-Erstellung ist ein POST /api/v1/agent/tasks; Live-Updates streamen über /api/v1/agent/ws.

use-cases / schedule-the-agent / punchline

Der Cron-Eintrag führt den Job nicht aus — er bittet einen Agenten, den Job herauszufinden.

vorher · verzweigendes Skriptnachher · verzweigender Prompt
WORAUF DER ALTE CRON-EINTRAG ZEIGTE0 2 * * * /usr/local/bin/reconcile.sh # 412 Zeilen · 17 Edge Casesjede neue Monatsend-Regel hieß, das Skript zu editieren und zu beten
WORAUF ER JETZT ZEIGT0 7 * * * curl POST agent/tasks -d @prompt.jsoneine Zeile, für immer — der Prompt ist das einzige Artefakt, das du wartest
Agent-Task-Spec lesen
use-cases / schedule-the-agent / replaces

Was das ersetzt

Die Menge der Dinge, die du früher in reconcile.sh geschrieben hast, weil Cron nur Dateien ausführen konnte. Jedes ist ein Branch, ein Flag, eine Config — von keinem davon muss der Zeitplan tatsächlich wissen. Der Agent liest den Tag und entscheidet.

  • brüchige skriptbasierte Cron-JobsBash-Branches, die crashen, wenn sich eine Eingabespalte verschiebt
  • manuelle Wartung für sich ändernde Schematareconcile.sh zu editieren, jedes Mal wenn der Upstream-Export ein Feld bekommt
  • handgeschriebene ETL-SkripteEin Ordner mit .sh-Dateien, den nur eine Person im Team versteht
  • if X then Y else Z Cron-LogikMonatsende, Feiertag, Anomalie — drei Flags in einem Skript verdrahtet
  • Polling-für-Änderungen-SkripteEin separates Cron, das den Output des ersten Crons beobachtet und entscheidet
  • handcodierte if-else-SchedulerEin 200-zeiliger Dispatcher, dessen einziger Job es ist zu picken, welches Skript laufen soll
use-cases / schedule-the-agent / cta

Hör auf, Cron-Skripte zu warten. Fang an, Prompts zu warten. Der Zeitplan feuert; der Agent merkt es.

Cron- + Agent-Docs lesen
use-cases / schedule-the-agent / related

Lies die anderen