Temporäre Spezialisten

Überblick

Temporäre Spezialisten* sind die dynamischen, rollenbasierten Agenten der Dynamic Workforce Engine (DWE)* — der Agenten-Engine hinter Ottili AI. Wenn du Ottili AI ein Ziel übergibst (eine Mission*), dann entwirft der DWE-Manager ein kleines Team aus Spezialisten, die diese Mission voranbringen. Jeder Spezialist ist temporär*: Er wird pro Mission erzeugt, arbeitet auf genau eine Rolle und ein Ziel hin und endet, sobald die Mission abgeschlossen ist.

Temporäre Spezialisten sind live (Live)* — öffentlich dokumentiert mit dem Reifestatus Live*. Sie sind Teil der Ottili AI Oberfläche und teilen sich wie die anderen Ottili AI Fähigkeiten einen gemeinsamen Unternehmenskontext, ein gemeinsames Credit-Konto und eine gemeinsame Audit-Spur.

Dieser Artikel beschreibt, was temporäre Spezialisten sind, wie sie entstehen, welche Rolle, welches Ziel und welche Werkzeuge sie tragen, was sie dürfen und nicht dürfen, wie ihr Lebenszyklus begrenzt ist und wie sie in Ottili ONE eingebettet sind.

Was temporäre Spezialisten sind

Ein temporärer Spezialist ist kein dauerhaftes, benanntes Benutzerkonto und kein starres Bot-Profil. Er ist eine dynamische Arbeitseinheit*, die pro Mission aus dem Plan des DWE-Managers erzeugt wird:

• Rollenbasiert* — jeder Spezialist hat genau eine Rolle (zum Beispiel „Deutscher B2B-SaaS-Google-Ads-Spezialist" oder „Lokaler Spezialist für SME-Vertriebs-Außenkontakt"), nie eine vage Bezeichnung wie „Marketing-Agent".
• Zielgerichtet* — jeder Spezialist hat genau ein Ziel und ein festgelegtes output_schema (die JSON-Schlüssel, die er zurückgeben muss).
• Temporär* — er existiert nur für die Dauer der Mission und wird mit deren Abschluss beendet.
• Unternehmensbezogen* — jeder Spezialist ist an genau ein Unternehmen (company_id) gebunden.

Die DWE zerlegt die Mission in Arbeitseinheiten und weist diese Einheiten den Spezialisten zu. Die Teilergebnisse werden zum Ziel der Mission zusammengeführt.

Wie ein Spezialist entsteht

Wenn du eine Mission übergibst, übernimmt die Dynamic Workforce Engine (DWE)*:

1. Ziel zerlegen* — die Mission wird in überschaubare Arbeitseinheiten unterteilt.

2. Team entwerfen* — der DWE-Manager entwirft ein kleines Team temporärer Spezialisten* (höchstens 8, nach Möglichkeit weniger). Doppelte Rollen werden vermieden.

3. Spezialist erzeugen* — jeder Spezialist wird mit Rolle, Ziel, Kontext, erlaubten Werkzeugen, Einschränkungen, Budget, output_schema, Beendigungsbedingungen und einer maximalen Iterationszahl erzeugt und unternehmensbezogen persistiert.

4. Werkzeuge aufrufen* — Spezialisten können Werkzeuge aufrufen, um auf deine Daten zuzugreifen und sie zu verändern.

5. Ergebnis zusammenführen* — die Teilergebnisse werden zum Ziel der Mission zusammengeführt.

Backend-seitig erzeugt der SpecialistFactoryService die Spezialisten gebunden an mission_id und company_id, mit Idempotenz-Schlüssel und Grenzenauflösung. Über die Unified API sind die Spezialisten unter /api/v1/ai/dwe/missions/{mission_id}/specialists auflistbar und über /api/v1/ai/dwe/missions/{mission_id}/specialists/generate erzeugbar.

Rolle, Ziel und Werkzeuge

Jeder temporäre Spezialist trägt einen klaren, kanonischen Vertrag:

• Rolle* — spezifisch und situativ, nie generisch.
• Ziel* — eine einzelne, klar umrissene Aufgabe.
• Kontext* — die für die Aufgabe relevanten Informationen.
• Erlaubte Werkzeuge* (allowed_tools) — nur was der Spezialist wirklich braucht.
• Werkzeug-Effekte* (tool_effects) — jedes Werkzeug ist einer kanonischen Effektklasse zugeordnet.
• Einschränkungen* (constraints) — was der Spezialist nicht tun darf.
• Budget* — Kostenobergrenzen.
• Ausgabeschema* (output_schema) — die JSON-Schlüssel, die zurückgegeben werden müssen.
• Beendigungsbedingungen* (termination_conditions) und maximale Iterationen* (Vorgabe: 2).

Welche Modelle die Spezialisten antreiben, wählst du nicht selbst: Das adaptive Routing (Ottili Auto)* verteilt jede Anfrage automatisch an das passende Modell — Alltagsarbeit an Ottili Vale*, anspruchsvolle Arbeit an Ottili Cairn*.

Was Spezialisten dürfen und nicht dürfen

Temporäre Spezialisten arbeiten innerhalb eines einzelnen Unternehmensmandanten*. Sie erfinden niemals Unternehmensdaten — fehlen Daten, führt der Spezialist sie unter unknowns auf.

Spezialisten führen keine externen oder schreibenden Aktionen selbst aus*. Wenn eine Aktion nötig ist (E-Mail senden, veröffentlichen, Geld ausgeben, Kunden aktualisieren, in sozialen Medien posten, eine Automatisierung starten), wird sie unter suggested_actions beschrieben, damit ein Mensch sie freigeben kann.

Jedes Werkzeug ist einer kanonischen Effektklasse* zugeordnet:

• Automatisch ausführbar (innerhalb des Kontexts)*: read_only, dry_run, simulation, internal_write, draft_write, business_document.
• Freigabe-pflichtig*: external_action, external_publication, money_action, destructive_action — kritische, externe Wirkung wartet auf Freigabe, bevor sie aus dem Unternehmenskontext herauswirkt.
• Verboten für temporäre Spezialisten*: forbidden und admin_action — ein Spezialist darf diese Effekte niemals selbst deklarieren; sie werden eskaliert, nicht stillschweigend akzeptiert.

Freigaben werden über Ottili Console* und Ottili Core* erzwungen.

Lebenszyklus und Begrenzung

Temporäre Spezialisten sind bewusst begrenzt:

• Begrenzte Anzahl* — der Manager erzeugt höchstens 8 Spezialisten, nach Möglichkeit weniger.
• Eine Rolle, ein Ziel* — keine generischen Mehrzweck-Agenten.
• Terminierung* — Beendigungsbedingungen und eine maximale Iterationszahl (Vorgabe 2) begrenzen die Laufzeit.
• Tenant-Scope* — jede persistierte Zeile ist an ein Unternehmen gebunden; eine abgeschlossene Mission erhält keine neuen Spezialisten mehr.
• Idempotenz* — bei einem stabilen Client-Schlüssel sind die Spezialisten-IDs deterministisch; ein Replay ist ein echtes No-Op (kein doppeltes Team).

Wiederverwendbare Kompetenz-Fragmente* beschreiben validierte Baussteine aus Werkzeugen, Einschränkungen und einem Standard-Ausgabeschema. Ein Roh-Spez referenziert Fragmente per ID; die Fragmente werden pro Mission zusammengesetzt und bleiben temporäre Spezialisten. Ein neues Kompetenz-Fragment ist eine Datenänderung, kein Code-Rewrite — und wird bei jeder Verwendung erneut validiert.

Status und Verfügbarkeit

Temporäre Spezialisten tragen den Reifestatus Live (Live)* aus der kanonischen Produkt-Status-Registry (config/product_truth/ai_feature_status.yaml):

Das kanonische Reifestatus-Vokabular umfasst CONCEPT, PLANNED, IN_DEVELOPMENT, PRIVATE_BETA, BETA, ROLLOUT, LIVE, DEPRECATED und DISABLED. Für temporäre Spezialisten sind die aktuellen Fähigkeiten LIVE; Ottili Spire* ist ein reserviertes Flaggschiff-Modell und noch nicht verfügbar*, Memory* ist geplant (PLANNED). Wir behaupten keine Fähigkeit, die noch nicht als live verifiziert ist.

Wie Ottili ONE Reifestatus öffentlich kennzeichnet, beschreibt der Artikel [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels).

Eingebettet in Ottili ONE

Temporäre Spezialisten sind nativ in Ottili ONE verankert. Sie teilen mit den anderen Ottili Oberflächen:

• ein Login* (One Login)
• einen Unternehmenskontext* (jeder Spezialist gehört zu genau einem Unternehmen, company_id)
• ein Credit-Konto*
• eine Audit-Spur*

Das bedeutet: Ein Spezialist läuft immer innerhalb deines Unternehmens; jede Aktion wird auf ein einzelnes Unternehmen aufgelöst und über Ottili Core Audit* protokolliert. Derselbe Mechanismus treibt Ottili Coder, Ottili LD3 und andere Oberflächen aus deinem Unternehmen heraus an. Die gemeinsame Kontostruktur beschreibt der Artikel [Was ist Ottili ONE?](/docs/what-is-ottili-one).

Verwandte Artikel

• [Dynamic Workforce Engine](/docs/dynamic-workforce-engine)
• [Chat- und Agenten-Modi](/docs/chat-and-agent-modes)
• [Ottili AI](/docs/ottili-ai)
• [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels)
• [Was ist Ottili ONE?](/docs/what-is-ottili-one)
• [Pläne und Credits verstehen](/docs/understand-plans-and-credits)