Agentic Ventures Wiki

System-Prompt-Deploys: harte Guardrails vor jedem Live-Push

2 Min. Lesezeit

System-Prompt-Deploys: harte Guardrails

System-Prompts fuer Kunden-Agents (vf-sonnet und kuenftige) duerfen nicht mehr ungeprueft live deployt werden. Vor jedem Deploy gilt eine 3-Punkte-Pruefliste, ein Smoke-Test mit Realitaets-Frage, und eine Source-Hygiene-Regel.

Entscheidung

Vor jedem POST /api/v1/models/model/update-Call gilt:

  1. Source-Status-Check. Wenn Inhalt aus einem Kunden-Vault destilliert wurde: Source-Files muessen status: stable oder kein Status-Feld haben. Files mit status: draft sind tabu — die beschreiben Soll-Zustand, nicht Realitaet, und Drift ist garantiert.

  2. Realitaets-Check mit dem Kunden. Bei jeder Behauptung ueber Personen, Rollen, Pipelines, Owner-Zuweisungen explizit mit dem Kunden gegenchecken. Reicht: kurze Mail, Slack-Nachricht oder mit dem Kunden direkt am Tisch. Nicht ausreichend: Vault-Files lesen und annehmen.

  3. Explizite Freigabe fuer den Deploy. Production-Deploys auf Kunden-Systeme brauchen ein klares „go” vom Marvin, nicht nur „mach den Plan”. Hook in Claude Code blockiert mittlerweile unautorisierte Deploys.

Nach jedem Deploy gilt:

  1. Smoke-Test mit Realitaets-Frage, nicht nur Strukturfrage.

    • Strukturfrage (zu schwach): „leg ein Event fuer Stadtwerke Hamm am 15.06.2026 an” → testet ob Stages erkannt werden, nicht ob Rollen stimmen
    • Realitaets-Frage (richtig): „wer macht bei uns Sales?” oder „wer ist GF?” — der Agent muss antworten was wirklich stimmt, nicht was das System-Prompt-Snippet behauptet

  2. Rollback-Pfad muss verfuegbar sein. Lokales Backup des vorherigen System-Prompts behalten. Wenn der Source kein Git-Repo ist (z.B. open-webui-vf): manuell Sicherung in ~/source/<repo>/prompts/.history/ ablegen.

Warum so streng

Wir bauen vf-sonnet (und kuenftige Kunden-Agents) als „kollegen-aequivalent” — also als Praktikant-der-immer-weiss-worum-es-geht. Wenn der Agent falsche Behauptungen ueber Rollen oder Pipelines macht, ist sein Trust-Score sofort kaputt. Einmal falsch geantwortet, glaubt der Kunde ihm auch danach nicht mehr. Drift-Quelle Nummer eins ist „aus Vault-Files destillieren ohne zu pruefen ob die Files Realitaet beschreiben”. Drift-Quelle Nummer zwei ist „aus Conversational-Context destillieren ohne dem User zu zeigen was rauskommt”.

Was das fuer die Coding-Pipeline heisst

Schritt im mcp-cloud-bereitstellung Skill ergaenzen:

  • Vor Deploy: System-Prompt-Inhalt nochmal Marvin zeigen, expliziter „ja-mach”-Trigger
  • Nach Deploy: Smoke-Test-Catalog mit 3-5 Realitaets-Fragen pro Kunde (nicht nur Struktur)

Graphansicht

Backlinks