Der Agent Contract

Der Agent Contract ist die zentrale, versionierte Definition eines AI-Features. Er hält an einer Stelle alles fest, was ein Feature ausmacht: was es tun soll, in welcher Form das Ergebnis zurückkommt, welche Werkzeuge es benutzen darf, über welchen Anbieter es läuft, woran seine Qualität gemessen wird und wie hoch sein Risiko ist. Auf der Plattform wird der Contract gepflegt; ausgeführt wird das Feature später lokal in der eigenen Umgebung durch das SDK.

Der Kerngedanke ist eine klare Trennung: Der Contract ist das Interface zwischen der fachlichen Iteration am Prompt und dem Code, der das Ergebnis weiterverarbeitet. Fachexperten dürfen den Prompt frei verändern und verbessern, ohne dass davon der Code abhängt — solange das vereinbarte Ergebnisformat stabil bleibt. Genau diese Vereinbarung ist der Contract.

Die Bestandteile

Ein Agent Contract besteht aus sechs Teilen. Im Feature-Detail werden sie über die jeweiligen Tabs bearbeitet; jeder Teil hat eine eigene Anleitung.

Prompt. Die Anweisung an das Modell — Aufgabe, Kontext und Verhaltensregeln des Features. Der Prompt ist der Teil, an dem Fachexperten am häufigsten iterieren. Siehe Den Prompt schreiben.

Output-Schema (Ausgabe-Schema). Die verbindliche Beschreibung, in welcher Struktur das Ergebnis zurückkommt: welche Felder es gibt, welchen Typ sie haben und welche Pflicht sind. Das Output-Schema ist das stabile Interface zum Code (siehe unten). Siehe Das Output-Schema definieren.

Tool-Schemas und -Pins (Werkzeuge). Die Werkzeuge (Tools), die das Feature aufrufen darf, jeweils mit ihrer Schnittstellen-Beschreibung. Ein Pin hält dabei fest, auf welche Version eines Tools sich der Contract bezieht. Siehe Tools verwenden.

Provider-Konfiguration (Anbieter). Welcher Provider (Anbieter eines Sprachmodells) und welches Modell das Feature ausführen — als primäre Wahl und als Fallback, der einspringt, wenn die primäre Wahl nicht erreichbar ist. Siehe Modelle und Provider.

Eval-Kriterien und Baseline (Bewertung). Die Schwellwerte, an denen die Qualität des Features gemessen wird (Eval = automatisierte Bewertung), zusammen mit einer Baseline als Vergleichsmaßstab. Siehe Evaluation.

Risikoklasse (Risk Tier 1/2/3). Die Einstufung des Features nach Risiko, von Tier 1 (gering) bis Tier 3 (hoch). Die Risikoklasse steuert, wie streng ein Feature behandelt wird — etwa welche Bestätigungen bei einer Veröffentlichung verlangt werden. Sie ist ein zentraler Bezugspunkt für die Compliance.

Warum das Output-Schema das stabile Interface ist

Der Code, der ein Feature nutzt, verlässt sich auf die Form des Ergebnisses: Er liest bestimmte Felder aus und verarbeitet sie weiter. Bleibt das Output-Schema gleich, kann der Prompt beliebig oft verbessert werden, ohne dass der nutzende Code angefasst werden muss. Das Output-Schema ist damit die Vertragsgrenze, auf die sich beide Seiten verlassen.

Deshalb behandelt die Plattform Änderungen am Output-Schema unterschiedlich. Verträgliche Erweiterungen (etwa ein neues optionales Feld) sind unkritisch. Eine Breaking-Änderung dagegen — ein Pflichtfeld entfällt, ändert seinen Typ oder kommt neu hinzu — bricht den bestehenden Code. Solche Änderungen führen zu einem Major-Bump (Sprung der Hauptversionsnummer) und müssen ausdrücklich bestätigt werden, bevor eine neue Version entstehen kann. Welche Änderung als verträglich und welche als Breaking gilt, ist unter Das Output-Schema definieren beschrieben.

Versionierung und Lebenszyklus

Der Agent Contract ist versioniert. Dabei sind zwei Ebenen zu unterscheiden.

Feature-Lebenszyklus. Ein Feature durchläuft die Zustände Entwurf (draft), aktiv (active), veraltet (deprecated) und stillgelegt (sunset). Beim Übergang in den stillgelegten Zustand gilt eine Schonfrist, bevor das Feature endgültig abgeschaltet wird. Ist ein Feature stillgelegt, kann es niemand mehr bearbeiten.

Versions-Lebenszyklus. Jede einzelne Contract-Version durchläuft die Zustände Entwurf (draft), aktiv (active) und abgelöst (superseded). Es gibt zu jedem Zeitpunkt genau eine aktive Version pro Contract.

Die Arbeit an einem Contract folgt diesem Ablauf:

Bearbeiten im Entwurf. Solange eine Version ein Entwurf ist, lassen sich Prompt, Output-Schema, Modelle und die übrigen Bestandteile frei ändern.
Veröffentlichen. Beim Veröffentlichen prüft die Plattform den Entwurf (Linter und Reife-Kriterien als Fortschrittsleiste). Besteht der Entwurf, wird er zur aktiven Version; die zuvor aktive Version wird abgelöst. Eine veröffentlichte Version ist schreibgeschützt.
Neuen Entwurf anlegen. Um eine veröffentlichte Version zu ändern, wird ein neuer Entwurf angelegt. Er erbt den Stand der aktiven Version und kann frei bearbeitet werden.
Zurücksetzen. Eine frühere Version lässt sich wieder zur aktiven Version machen. Die Plattform stellt dabei die aktive Version in einem Schritt auf die gewählte frühere Version zurück.

Beim Veröffentlichen liefert die Plattform außerdem ein SDK-Code-Snippet, mit dem sich die freigegebene Version einbinden lässt. Den vollständigen Ablauf beschreibt Veröffentlichen.

Wie der Contract ausgeführt wird

Gepflegt wird der Contract zentral auf der Plattform, ausgeführt wird er dezentral. Das SDK lädt die freigegebene Version eines Features, hält sie zwischengespeichert vor und führt das Feature lokal in der eigenen Umgebung aus — provider-agnostisch, also unabhängig vom konkreten Anbieter. Dabei prüft es, ob das Ergebnis zum Output-Schema passt. So bleibt die Steuerung zentral, während Daten und Ausführung in der eigenen Umgebung verbleiben. Wie das SDK eingebunden und aufgerufen wird, steht unter SDK im Überblick.