Vier Arten, eine Aufgabe zu beschreiben

Was ein Job tut, bestimmt sein Werkzeug. Alle vier werden gleich geplant, gleich verteilt und gleich berichtet — der Unterschied liegt darin, was auf dem Agenten passiert. Und darin, was der Agent dafür zulassen muss: er entscheidet, nicht der Job.

Welche Stufe was erlaubt, steht unter „Was die Stufen können“.

process — ein Programm starten

Der Alltagsfall. Der Agent startet ein Programm mit Argumenten, wartet, und der Rückgabewert entscheidet über Erfolg oder Misserfolg.

Was der Agent braucht

Nichts Besonderes. Jeder Agent kann das, und keine Lizenzstufe schränkt es ein.

Beispiel

{
  "job_id": "nightly-report",
  "job_type": "process",
  "tool": {
    "kind": "process",
    "program": "bin/report.sh",
    "args": ["--full", "--region", "eu-west"],
    "result": "exit_code"
  }
}

Was zurückkommt

Standardmässig zählt der Rückgabewert: 0 heisst erfolgreich. Mit "result": "contract" schreibt das Programm stattdessen ein JSON-Objekt nach stdout und kann damit Variablen, eine Entscheidung und Kennzahlen zurückgeben. Diese Wahl gibt es nur bei process.

Wo die Grenze liegt

Das Programm läuft mit den Rechten des Agenten auf dessen Rechner. Womit es das darf, begrenzt der Agent über erlaubte Wurzelverzeichnisse.

plugin — eine Bibliothek laden

Eine .so beziehungsweise .dll, die der Agent in sich selbst lädt. Für Aufgaben, die keinen eigenen Prozess rechtfertigen — kein Start, kein Interpreter, kein Prozesswechsel je Lauf.

Was der Agent braucht

Der Agent braucht die Lizenzfunktion plugin_executor. Eintragen muss er nichts: die Bibliothek kommt aus dem Job, wie ein Programm bei process.

Beispiel

{
  "job_id": "nightly-aggregate",
  "job_type": "aggregate",
  "tool": {
    "kind": "plugin",
    "program": "/opt/z5-plugins/libaggregate.so"
  },
  "params": { "region": "eu-west" }
}

Was zurückkommt

Die Bibliothek bekommt das volle Contract-Objekt hinein und gibt eines zurück — Variablen, Entscheidung, Kennzahlen inbegriffen.

Wo die Grenze liegt

Geladener Code läuft im selben Prozess wie der Agent. Ein Absturz dort nimmt den Agenten mit. Das ist der Preis dafür, dass kein Prozess gestartet wird, und der Grund, warum es eine eigene Lizenzfunktion gibt.

wasm — abgeschottet rechnen

Ein WebAssembly-Modul, das der Agent ausführt, ohne ihm den Rechner zu öffnen. Kein Verzeichnis, keine Umgebungswerte, kein Netz.

Was der Agent braucht

Die Lizenzfunktion wasm_executor und ein Agent, der mit WASM-Unterstützung gebaut wurde. Letzteres ist eine Entscheidung beim Bauen, keine Einstellung.

Beispiel

{
  "job_id": "nightly-sandbox",
  "job_type": "sandbox",
  "tool": {
    "kind": "wasm",
    "program": "/opt/z5-modules/report.wasm"
  }
}

Was zurückkommt

Nur der Rückgabewert des Exports z5_execute: 0 heisst erfolgreich, jeder andere Wert ist der Exitcode des Fehlschlags.

Wo die Grenze liegt

Und hier liegt die wichtigste Einschränkung: es geht nichts hinein und nichts heraus ausser dieser einen Zahl. Das Modul sieht weder params noch env oder args, und seine Ausgabe wird verworfen. Wer Daten übergeben will, nimmt plugin. Die Standardbibliothek von C++ steht im Modul zur Verfügung.

ai — ein Modell fragen

Der Job stellt eine Frage, und die Antwort des Modells ist das Ergebnis. Auf dem Agenten läuft dabei nichts — es gibt kein Programm, nur eine Frage und eine Antwort.

Was der Agent braucht

Der Agent muss es ausdrücklich erlauben und meldet dem Master, dass er ein Modell fragen kann; nur dann bekommt er überhaupt einen Schlüssel. Dazu die Lizenzfunktion plugin_executor — dieselbe wie für Plugins, aus demselben Grund: in beiden Fällen lässt ein Rechner etwas zu, das er nicht selbst geschrieben hat.

Beispiel

{
  "job_id": "build-einordnen",
  "job_type": "ask",
  "tool": {
    "kind": "ai",
    "result": "contract",
    "ai": {
      "purpose": "Einen gescheiterten Build einordnen.",
      "task": "Woran ist der Build gescheitert, und was ist der naechste Schritt?",
      "context_files": ["build.log"],
      "variables": [
        { "name": "decision", "format": "GO oder STOP" },
        { "name": "grund", "format": "ein Satz" }
      ],
      "key": "groq",
      "mode": "answer"
    }
  }
}

Was zurückkommt

Die Antwort landet in der Ausgabe des Laufs. Verlangt der Job benannte Werte, kommen sie als Variablen zurück und einer davon kann die Entscheidung des Laufs sein — damit verzweigt ein Ensemble anhand dessen, was das Modell geantwortet hat.

Auf Wunsch antwortet das Modell mit einem Befehl, den der Agent dann ausführt. Dafür gelten dieselben Grenzen wie für jeden anderen Befehl — das Modell ist kein Weg daran vorbei. Der vollständige Aufruf wird im Lauf festgehalten.

Wo die Grenze liegt

Zwei Dinge, die anders sind als bei den übrigen: Ein KI-Schritt ist nicht wiederholbar — dieselbe Frage kann morgen anders beantwortet werden. Und die Frage verlässt das Haus, wenn das Modell nicht im eigenen Netz steht. Was mitgeschickt wird, zählt der Job einzeln auf; Geheimnisse sind nie dabei.