Was ist Prompt-Versionierung? Ein vollständiger Leitfaden für Engineering-Teams im Jahr 2026

Ein Prompt ist ein bereitgestelltes Artefakt. Viele Teams behandeln ihn jedoch immer noch wie eine einfache Zeichenfolge. Dieser Unterschied wird kostspielig, sobald LLM-Anwendungen in die Produktion gehen und Änderungen am Prompt die Ausgabequalität, die Nutzerzufriedenheit, die Fehlerraten und die Geschäftsprozesse beeinträchtigen.

Das Problem ist meist bekannt: Jemand optimiert am Donnerstag den Wortlaut eines System-Prompts. Über das Wochenende steigen die Ablehnungsraten. Am Montag kann niemand mehr sagen, welche der sechs Änderungen die Ursache war, da der Prompt-Text über Anwendungscode, Notion-Seiten und Slack-Threads verstreut ist.

Gartner prognostizierte, dass bis 2026 mehr als 80 % der Unternehmen generative KI-APIs nutzen oder GenAI-gestützte Anwendungen bereitstellen werden – ein Anstieg von unter 5 % im Jahr 2023. In diesem Maßstab werden nicht nachverfolgte Prompt-Updates zu einem Problem für die Verfügbarkeit, Qualität und Compliance von KI-Systemen.

Prompt-Versionierung stellt die Nachvollziehbarkeit wieder her. Dieser Leitfaden erklärt, was Prompt-Versionierung ist, wie Registries sie implementieren, warum Produktionsteams sie benötigen und wo Teams immer noch Fehler machen. Zudem wird erläutert, wie TrueFoundry das Prompt-Management mit Gateway-Governance, Evaluierung, Guardrails und Audit-Trails verknüpft.

A Prompt Change Without Version Control Is a Regression Waiting to Be Discovered

TrueFoundry governs every model call, guardrail, and agent action so prompt changes are traceable, auditable, and reversible inside your own VPC

Book a Demo

Was ist Prompt-Versionierung?

Prompt-Versionierung ist die Anwendung von Prinzipien der Software-Versionskontrolle auf KI-Prompts in LLM-Anwendungen. Anstatt Prompts direkt im Produktionscode zu bearbeiten, speichern Teams jede Prompt-Version mit Autor, Zeitstempel, Beschreibung und einer klaren Änderungshistorie.

Die Bedeutung von Prompt-Versionierung geht über eine einfache Versionshistorie hinaus. Ein produktionsreifes Versionierungssystem behandelt jeden Prompt als unveränderliches Artefakt. Jede Version kann getestet, bereitgestellt, verglichen, zurückgesetzt und mit Evaluierungsergebnissen verknüpft werden, ohne auf ein vollständiges Release der Anwendung warten zu müssen.

Diese Unabhängigkeit ist entscheidend. Ein in Quelldateien gespeicherter oder über Dokumente kopierter Prompt liefert Teams nur Text ohne Herkunftsnachweis. Wenn die Qualität des Prompts sinkt, können Teams vier Fragen nicht klar beantworten: Was wurde geändert, wer hat es geändert, wann wurde es geändert und was war der letzte bekannte funktionierende Zustand?

Eine Registry beantwortet diese Fragen von Grund auf. In TrueFoundrys Prompt-Managementkann ein Prompt die Systemnachricht, die Benutzernachricht, Eingabevariablen, die Modellauswahl, Guardrails und das strukturierte Ausgabeschema als ein versioniertes Objekt enthalten.

Warum Prompt-Versionierung für LLM-Produktionsteams wichtig ist

Die Notwendigkeit für Prompt-Versionierung ist selten theoretischer Natur. Sie wird meist durch einen Vorfall deutlich. Eine kleine Änderung am Wortlaut führt zu anderen Ausgaben, erhöht die Fehlerraten und verhindert, dass Teammitglieder das Problem auf eine bestimmte Prompt-Version oder einen Überprüfungsprozess zurückführen können.

Nicht nachverfolgte Änderungen führen zu schwer zu behebenden Qualitätsverlusten

Kleine Änderungen können sich ohne Versionsverfolgung in System-Prompts ansammeln. Die Ausgabequalität sinkt, und um die verantwortliche Änderung zu finden, muss die Prompt-Historie mühsam aus dem Gedächtnis, Code-Kommentaren, Screenshots oder Chat-Verläufen rekonstruiert werden.

Die Angriffsfläche für Fehler wächst schnell. Eine RAG-Pipeline kann einen Prompt zur Abfrageumformulierung, einen Reranking-Prompt und einen Prompt zur Antwortsynthese enthalten. Ohne eine Versions-ID für jeden einzelnen Prompt müssen Teams Änderungen eher durch Raten als durch Beweise eingrenzen.

Rollbacks werden zum Glücksspiel statt zum kontrollierten Vorgang

Eine Prompt-Änderung beeinträchtigt das Produktionsverhalten. Ohne Prompt-Versionierung bedeutet ein Rollback, dass man rekonstruieren muss, wie der vorherige Prompt aussah. Das birgt Risiken, da die rekonstruierte Version von der tatsächlich funktionierenden Version abweichen kann.

Die Rekonstruktion unter Zeitdruck führt zu neuen Fehlern. Jemand erinnert sich nur noch vage an die ursprüngliche Formulierung, veröffentlicht eine Annäherung, und das System führt nun einen dritten Prompt aus, der nie getestet wurde. Eine Registry macht aus einem Rollback eine Konfigurationsänderung statt eines Notfall-Hotfixes.

Nicht-Entwickler können nicht an der Prompt-Iteration teilnehmen

Die meisten Teams, die Prompts verbessern, bestehen aus Produktmanagern, Fachexperten, QA-Analysten und Entwicklern. Ohne ein System, das KI-Prompts vom Anwendungscode trennt, erfordert jede Iteration ein Engineering-Release und einen Pull Request.

Der Engpass ist struktureller Natur. Prompt-Engineering verbessert sich durch viele kostengünstige Experimente, relevante Beispiele und Testfälle. Ein wöchentlicher Release-Zyklus verlangsamt diesen Prozess, während eine Prompt-Registry kontrollierte Aktualisierungen ermöglicht, ohne von Codeänderungen abhängig zu sein.

Wie funktioniert Prompt-Versioning?

Vier Mechanismen unterstützen das Prompt-Versioning in der Produktion: eine Registry, Umgebungstrennung, Evaluierungs-Gates und Rollback-Strategien. Gemeinsam schaffen sie einen strukturierten Ansatz für Prompt-Änderungen, ohne die Zuverlässigkeit, Governance oder Benutzererfahrung zu beeinträchtigen.

Versions-Registry

Jeder Prompt landet als unveränderliches Artefakt in einer zentralen Registry. Jede Version enthält eine eindeutige Kennung, einen Zeitstempel, den Autor, eine Änderungsbeschreibung sowie den vollständigen Inhalt des Prompts zum jeweiligen Zeitpunkt.

TrueFoundry erstellt bei jedem Bearbeiten und Speichern automatisch eine neue Version. Der Versionsverlauf listet alle Versionen mit Commit-Nachrichten und Autoren auf. Der Tab „Versionsunterschied“ zeigt einen Diff im GitHub-Stil zwischen zwei beliebigen Versionen an.

Anwendungen rufen Prompts zur Laufzeit aus der Registry ab, anstatt hartcodierte Strings zu lesen. Die Änderung der Version, die eine Umgebung auflöst, kann das Anwendungsverhalten ohne Code-Release verändern.

Die Adressierung erfolgt über einen vollqualifizierten Namen. TrueFoundry dokumentiert das Format als `chat_prompt:{tenant_name}/{ml_repo_name}/{prompt_name}` mit einem optionalen `:{version}`-Suffix. So bezeichnet `chat_prompt:acme/support-prod/triage-router:7` spezifisch Version 7.

Der Aufruf einer fixierten Version über das Gateway erfordert nur ein Feld. Übergeben Sie `prompt_version_fqn` im Request-Body, und das Gateway rendert die Vorlage und führt den Aufruf aus:

rom openai import OpenAI

client = OpenAI(
    api_key="your_truefoundry_api_key",
    base_url="https://gateway.truefoundry.ai",
)

response = client.chat.completions.create(
    messages=[],
    model="",
    extra_body={
        "prompt_version_fqn": "chat_prompt:acme/support-prod/triage-router:7",
        "prompt_variables": {
            "ticket_body": "My invoice shows a duplicate charge.",
            "tier": "enterprise",
        },
    },
)

print(response.choices[0].message.content)

Drei Verhaltensweisen überraschen Teams immer wieder, und die Dokumentation von TrueFoundry weist jeweils darauf hin. Ein im Request-Body übergebenes Modell überschreibt das in der Prompt-Version gespeicherte Modell.

Alle von Ihnen gesendeten `messages` werden an die Nachrichten der Version angehängt, anstatt sie zu ersetzen. Das sorgt für Überraschungen, wenn eine versehentliche Systemnachricht in der Produktion landet. Zudem benötigt eine ohne Modell gespeicherte Version zwingend eines im Request-Body.

Client-seitiges Rendering ist die Alternative. Rufen Sie die Vorlage ab, rendern Sie sie lokal und behalten Sie die volle Kontrolle darüber, wie Nachrichten zusammengestellt werden:

from truefoundry import client, render_prompt
from openai import OpenAI

prompt_template = client.prompt_versions.get_by_fqn(
    fqn="chat_prompt:acme/support-prod/triage-router:7",
).data.manifest

prompt = render_prompt(prompt_template, variables={"tier": "enterprise"})

response = OpenAI().chat.completions.create(
    messages=prompt["messages"],
    model=prompt.get("model") or "gpt-4o-mini",
    **(prompt.get("parameters") or {}),
)

Wählen Sie serverseitiges Rendering, wenn das Gateway Guardrails, Caching und Logging für diesen Prompt übernehmen soll. Wählen Sie den SDK-Weg, wenn Ihre Anwendung Nachrichten dynamisch erstellt und die Vorlage als Daten benötigt.

Umgebungsbasierte Bereitstellung

Jede Umgebung sollte eine spezifische Prompt-Version auflösen. Entwickler und Produktmanager iterieren in der Entwicklung. Staging spiegelt die Produktionsbedingungen für die finale Validierung wider. Die Produktion akzeptiert nur Versionen, die Überprüfungen und Qualitätskontrollen bestanden haben.

TrueFoundry bietet Teams zwei kombinierbare Mechanismen. Der erste ist die Trennung von Repositories über verschiedene Umgebungen hinweg.

• Separate Repositories pro Umgebung. Prompts befinden sich in Repositories, und die Dokumentation empfiehlt als Standardmuster eine Aufteilung der Umgebungen, wie etwa `checkout-dev` und `checkout-prod`. Die Zugriffskontrolle erfolgt auf Repository-Ebene, sodass ein Prompt diese erbt, ohne dass eine Richtlinie pro Prompt erforderlich ist.
• Tags für Prompt-Versionen. Ein Tag, wie zum Beispiel `production`, ist jeweils genau einer Version zugeordnet. Um ein Tag, das bereits einer anderen Version zugewiesen ist, neu zu vergeben, ist das `force`-Flag erforderlich. Dadurch verhält sich das Tag wie ein einzelner, beweglicher Zeiger und nicht wie ein Label, das beliebig oft dupliziert werden kann.

Die Trennung der Repositories regelt, wer veröffentlichen darf. Tags legen fest, welche Version aktuell ist. Zusammen sorgen sie dafür, dass sich ein Prompt in aktiver Entwicklung nicht auf Produktionsanwender auswirkt, während die Produktion von Experimenten in niedrigeren Umgebungen ungestört bleibt.

Die Beförderung (Promotion) erfolgt über einen API-Aufruf. Das SDK ermöglicht das Tagging direkt:

from truefoundry import TrueFoundry

client = TrueFoundry(
    api_key="YOUR_API_KEY",
    base_url="https://app.truefoundry.com",
)

# Find the candidate version that passed evaluation
candidate = next(iter(client.prompt_versions.list(name="triage-router", version=8)))

# Move the production pointer onto it
client.prompt_versions.apply_tags(
    prompt_version_id=candidate.id,
    tags=["production"],
    force=True,
)

# Confirm what production now resolves to, and who authored it
live = next(iter(client.prompt_versions.list(name="triage-router", tag="production")))
print(live.fqn, live.created_by_subject, live.created_at)

Jede `PromptVersion` liefert `id`, `fqn`, `created_by_subject` und `created_at` zurück – dies bildet den Nachweispfad, auf den sich der unten stehende Compliance-Abschnitt stützt.

Derselbe Vorgang ist über REST unter `PUT /api/svc/v1/prompt-versions/tags` verfügbar, und `GET /api/svc/v1/prompt-versions` ermöglicht Filterungen nach `tag`, `fqn`, `prompt_id`, `ml_repo_id`, `name` oder `version`. Release-Pipelines können daher eine Beförderung ohne manuellen Eingriff in der Konsole durchführen.

Evaluierungsschleusen

Vor der Beförderung in die Produktion sollte eine Kandidatenversion eine automatisierte Evaluierung durchlaufen. Diese Schleusen sollten die für die Anwendung relevanten Aspekte messen: Groundedness, Verweigerungsrate, Formatkonformität, Sicherheitsbewertungen, Ergebnisgenauigkeit oder aufgabenspezifische Benchmarks.

Qualitätsmessung gehört in den Beförderungsschritt. Eine mit der Beförderung verknüpfte Schleuse stoppt Regressionen direkt an der Grenze. Ein Dashboard, das erst nach dem Rollout geprüft wird, zeigt dem Team lediglich, wie viele Nutzer die Regression bereits bemerkt haben.

Der entscheidende Vergleich ist der mit der aktuellen Produktionsversion. Ein Kandidat mit einem Groundedness-Wert von 0,82 ist für sich genommen wenig aussagekräftig. Wenn die Produktion bei 0,89 liegt, ist dieser Wert ein klares Signal, die neue Prompt-Version nicht weiter zu befördern.

TrueFoundry dokumentiert Workflows, bei denen Kandidaten das AI Gateway und Evaluierungstools vor der Beförderung durchlaufen. Dies verknüpft die LLM-Evaluierung mit Versionsverfolgung, Produktionsprotokollen und der Rollback-Bereitschaft.

Rollback-Fähigkeit

Ein Produktions-Prompt beginnt sich fehlerhaft zu verhalten. Ein Rollback bedeutet, die aktive Version auf die letzte bekannte, funktionierende Version zurückzusetzen. Die Anwendungen übernehmen die Änderung bei der nächsten Anfrage oder nach einem kontrollierten Neustart, je nach Laufzeitstrategie.

Geschwindigkeit ist der Grund, warum Teams das Prompt-Management vom Anwendungscode trennen. Eine Regression, deren Behebung früher Stunden dauerte, kann in Minuten gelöst werden, wenn die vorherige Version als gespeichertes Artefakt mit einer stabilen Kennung vorliegt.

Ein wichtiger Hinweis: Die Auflösung des Production-Tags bei jeder Anfrage ermöglicht zwar ein schnelles Rollback, allerdings kann die laufende Version während der Propagation implizit sein. Die Auflösung des Tags zum Zeitpunkt der Bereitstellung und das Pinnen der ganzzahligen Version liefern eine klarere Antwort darauf, was aktuell ausgeführt wird.

Die Vorteile von Prompt-Versionierung für Unternehmensteams

Vergleicht man einen versionierten Workflow mit einem nicht versionierten, wird die operative Lücke deutlich. Eine gute Prompt-Versionierung bietet Teams eine zentrale Informationsquelle für Prompt-Texte, Änderungen, Bewertungsergebnisse und Rollback-Strategien.

Nachweise für Compliance-Anforderungen verdienen besondere Aufmerksamkeit, da die Kosten bei Fehlern hoch sind. Wenn ein Prüfer wissen möchte, welche Anweisungen für eine Modellentscheidung im März maßgeblich waren, benötigt er die Prompt-Version, deren Inhalt, das Freigabeprotokoll und die Änderungshistorie.

Ein Team ohne Registry muss diese Antwort mühsam durch die Analyse von Commits und Chat-Verläufen rekonstruieren. Eine solche Rekonstruktion ist kein belastbarer Nachweis. Eine gute Prompt-Versionierung gibt Teams direkten Zugriff auf Versionshistorie, Autor, Zeitstempel und den Kontext der Überprüfung.

Best Practices für die Prompt-Versionierung in Produktionsteams

Registries ermöglichen gute Praktiken, erzwingen aber nicht automatisch jede Gewohnheit. Die folgenden Praktiken unterscheiden Teams, die Prompt-Änderungen gelassen ausrollen, von solchen, die dies mit Nervosität tun.

Semantische Versionierung zur Kommunikation des Änderungsumfangs nutzen

Wenden Sie Prinzipien der semantischen Versionierung auf Prompt-Änderungen an. Eine größere Änderung betrifft das Ziel oder das Ausgabeformat des Prompts. Eine kleinere Änderung verfeinert die Formulierung. Ein Patch behebt einen spezifischen Sonderfall. So verstehen Prüfer den erwarteten Wirkungsbereich, bevor sie sich den Diff ansehen.

Registries bieten oft fortlaufende Ganzzahlen, und TrueFoundry folgt diesem Muster mit Versionen wie v1, v2 und v3. Eine Ganzzahl ist eine Identität, kein Signal für das Ausmaß einer Änderung.

Übermitteln Sie das Signal dort, wo die Ganzzahl es nicht kann. Schreiben Sie die Commit-Nachricht als `major: switch output to strict JSON schema` oder `patch: handle empty ticket body`, damit die Versionsliste auf einen Blick lesbar wird. Tags dienen dem gleichen Zweck, wenn Ihr Überprüfungsprozess eine maschinenlesbare Kennzeichnung erfordert.

Prompts in einer dedizierten Registry vom Anwendungscode trennen

Prompts, die fest im Anwendungscode verankert sind, erfordern für jede Änderung ein technisches Release. Eine dedizierte Registry entkoppelt beides und ermöglicht es Produkt- und Fachteams, Verbesserungen bereitzustellen, ohne auf ein Deployment-Fenster warten zu müssen.

Diese Entkopplung hilft auch bei der Reaktion auf Vorfälle. Wenn Prompt-Änderungen nicht mehr zusammen mit Code-Änderungen erfolgen, werden die Release-Diffs kleiner. Auch die Zeitpläne bei Vorfällen werden übersichtlicher, da eine Prompt-Regression und eine Code-Regression nicht mehr im selben Deployment auftreten.

Teams, die Anforderungen an eine Registry evaluieren, können den Leitfaden für Prompt-Management-Tools bei der Auswahl der wichtigsten Funktionen heranziehen. Das ideale System sollte die Versionierung von Prompts, Bewertungsschwellen, rollenbasierte Veröffentlichung, Vergleichsansichten und Rollbacks über eine zentrale Schnittstelle unterstützen.

Versionsfreigabe mit der Bewertungsinfrastruktur verknüpfen

Die Beförderung von der Staging- in die Produktionsumgebung sollte nicht nur eine manuelle Freigabe, sondern auch das Bestehen einer Qualitätsprüfung erfordern. Eine menschliche Freigabe bestätigt lediglich, dass jemand drübergeschaut hat. Sie bestätigt nicht, dass die Änderung tatsächlich eine Verbesserung darstellt.

Eine automatisierte Bewertung, die den Kandidaten mit der aktuellen Produktions-Baseline vergleicht, liefert ein objektives Signal. Verknüpfen Sie diese Prüfung mit dem Pipeline-Schritt, der das `production`-Tag setzt. So blockiert ein negatives Ergebnis die Zuweisung des Tags, anstatt nur ein Ticket zu erstellen, das am Freitag ohnehin jemand schließt.

Versions-Pins pro Umgebung mit expliziten Freigabeprotokollen pflegen

Jede Umgebung sollte eine spezifische Versionskennung festlegen, anstatt einen variablen Zeiger wie `latest` zu verwenden. Eine explizite Festlegung stellt sicher, dass die Version, die den Produktionsverkehr bedient, jederzeit bekannt ist. Dies macht die Untersuchung von Vorfällen und die Erstellung von Compliance-Berichten zu einer einfachen Abfrage statt zu einer mühsamen Rekonstruktion.

Bewahren Sie das Bereitstellungsprotokoll zusammen mit der Versionskennung auf. Das Protokoll sollte enthalten, welche Version verschoben wurde, wer sie verschoben hat, welche Evaluierung dies autorisiert hat und wann dies geschah. Dieser Kontext macht die Untersuchung von Vorfällen zu einer Abfrage statt zu einer Rekonstruktion.

TrueFoundry Audit-Logs erfassen Plattformaktionen, einschließlich des Akteurs, des Zeitstempels, der Ressource und der Diffs bei Ressourcenänderungen. Dies unterstützt einen saubereren Überprüfungsprozess, ohne dass zusätzliche Tracking-Tabellen erforderlich sind.

Prompt Versioning Controls Quality, TrueFoundry Governs Every Call That Uses the Prompt

Sign up for TrueFoundry and add VPC-native access controls, cost enforcement, and audit logging to every production AI workload your teams run

Sign Up Free

Prompt-Versionierung und KI-Governance in der Produktion mit TrueFoundry

Die Prompt-Versionierung ist eine Disziplin für Qualität und Zuverlässigkeit. Sie beantwortet jedoch nicht alle Governance-Fragen, die ein produktiver Einsatz aufwirft. Teams müssen weiterhin wissen, wer ein Modell aufrufen darf, welche Daten hineinfließen, wie hoch die Ausführungskosten sind und welche Nachweise bei einer Prüfung vorliegen.

Diese Fragen gehören in die Ebene zwischen Anwendung und Modell. TrueFoundry besetzt diese Ebene durch sein AI Gateway, während das Prompt-Management die Versionierung innerhalb derselben Steuerungsebene hält, die bereits Anforderungsrichtlinien durchsetzt.

Die Zugriffskontrolle erfolgt über das Repository. Prompts erben Berechtigungen von ihrem übergeordneten Repository, sodass festgelegt ist, wer einen Prompt lesen, veröffentlichen oder verwalten darf. Der Inhalt des Repositorys liegt in Ihrem eigenen Blob-Speicher, wodurch der Prompt-Text in einer Infrastruktur verbleibt, die Ihre Organisation kontrolliert.

Guardrails werden direkt an den Prompt angehängt. Eingabe- und Ausgabeschutzmechanismen laufen bei jeder Ausführung eines gespeicherten Prompts mit. Sie können Payloads validieren, blockieren oder verändern, sodass PII-Schwärzungen und Injection-Prüfungen mit der Version übernommen werden.

Kosten- und Log-Zuordnung erfordern einen bewussten Schritt. Das Metrik-Dashboard von TrueFoundry kann nach Modell, virtuellem Modell, Benutzer, virtuellem Konto und Team gefiltert werden. Um eine Prompt-Version direkt zuzuordnen, übergeben Sie diese über die Anforderungs-Metadaten.

extra_headers={
    "X-TFY-METADATA": '{"prompt_version": "triage-router:7", "environment": "production"}',
}

Metadaten-Schlüssel und -Werte sind Strings mit einer Länge von jeweils maximal 128 Zeichen. Sobald das Tag an die Anfrage angehängt ist, können Budgetregeln und Protokollierungsregeln darauf angewendet werden.

Die Budgetbegrenzung filtert nach Subjekt, Modell oder Metadaten und blockiert Anfragen, sobald das Limit überschritten wird. Das bedeutet, dass eine fehlerhafte Version das Budget nicht überziehen kann. Die Logging-Konfiguration kann dieselben Metadaten lesen, um zu entscheiden, ob ein Body gespeichert und welche Muster geschwärzt werden sollen.

Zwei Log-Ebenen beantworten unterschiedliche Fragen. Plattform-Audit-Logs zeichnen auf, wer einen Prompt bearbeitet oder bereitgestellt hat, inklusive eines Diffs. Gateway-Anfrage-Logs zeichnen auf, was bei jeder Ausführung gesendet und zurückgegeben wurde, zusammen mit Kosten, Latenz und Status.

Die Untersuchung fehlerhafter Ausgaben erfordert oft beide Datensätze. Die Prompt-Versionskennung verbindet den Änderungsdatensatz der Plattform mit dem Laufzeit-Anfragedatensatz. Ohne diese Verknüpfung wissen Teams zwar, dass ein Fehler aufgetreten ist, verfügen aber nicht über einen lückenlosen Nachweis.

Governance geht auch über einzelne Modellaufrufe hinaus. Das LLM Gateway wendet identitätsbasierten Zugriff und Kostenüberwachung über verschiedene Anbieter hinweg an. Das MCP Gateway hilft bei der Steuerung des Tool-Zugriffs, wenn Prompts tool-gestützte Agenten steuern.

Das Agent Gateway bietet eine workflow-spezifische Governance für KI-Agenten, unabhängig davon, welche Prompt-Version sie verwenden. Dies ist entscheidend, wenn ein Prompt die Aufgabenplanung, Tool-Aufrufe, Wiederholungsversuche oder das mehrstufige Verhalten von Agenten steuert.

TrueFoundry lässt sich in VPC-, On-Premise-, SaaS- oder Air-Gapped-Umgebungen bereitstellen, sodass Prompt-Nachweise und Governance-Daten innerhalb der genehmigten Infrastruktur verbleiben. Buchen Sie noch heute eine Demo, um loszulegen.