Der Anfang

Der erste Anschreiben-Generator, im Mai, war eine einzige undifferenzierte Bewegung: Stellenbeschreibung plus Kontext, hinein in Claude, heraus kommt ein Brief. Bis Capability-Normalisierung, Evidenzbewertung, Personas und Retry-mit-Eskalation alle existierten, war aus dieser einen Bewegung fünf geworden, jede mit einem Namen. Niemand hat diese Form im Voraus über alle drei KI-Domänen dieser Plattform hinweg geplant — Anschreiben, der Fotografie-Assistent und Ask Vikram sind alle unabhängig voneinander dort angekommen, Monate auseinander, aus demselben zugrunde liegenden Grund.

Die erste Lösung

Ein einzelner Prompt-Aufruf fühlt sich wie die naheliegende Arbeitseinheit an, weil er direkt darauf abbildet, wie man das Feature laut beschreiben würde: "Nimm eine Stellenbeschreibung, schreib ein Anschreiben." Eine Anweisung, ein Aufruf, ein Output. An dieser Form ist nichts falsch für ein Feature, das nur plausibel klingenden Text produzieren muss. Der Ärger beginnt in dem Moment, in dem das Feature auch richtig sein muss.

Was kaputtging

Ein einzelner Aufruf hat keine Naht. Extraktion, Retrieval und Generierung waren in eine einzige undifferenzierte Anfrage zusammengequetscht, was bedeutete, dass es keine Stelle gab, um eine deterministische Prüfung auf irgendeinen dieser Schritte zu legen — keine Stelle, an der scoreCandidateEvidence() vor der Generierung laufen konnte, kein gedeckeltes Evidenzpaket zum Übergeben, kein Gate, das ein Zitat zu einem Foto abfängt, das nie in der Evidenz war. Als der Output des Modells existierte, waren alle Entscheidungen, die es über Relevanz, Einbeziehung und Wahrheit getroffen hatte, bereits unsichtbar geschehen, innerhalb des einen undurchsichtigen Aufrufs, ohne etwas zu inspizieren und ohne etwas zu verwerfen.

Die Entscheidung

Die Lösung war kein klügerer Prompt. Es war, den einzelnen Aufruf in benannte Stufen aufzuteilen, jede mit einem Job und — entscheidend — einer Stelle danach, um ein Gate zu platzieren:

Extraktion — Schlüsselwörter und Capability-Kandidaten aus einer Stellenbeschreibung ziehen, oder Konzepte aus einer öffentlichen Frage. Vollständig deterministisch, noch kein Claude beteiligt.

Retrieval — bewerten und ranken, was tatsächlich relevant ist: scoreCandidateEvidence() für Anschreiben, searchPhotos() für den Assistenten, das sechsstufige Hybrid-Retrieval für Ask Vikram. Maßgeblich, nie vom nachfolgenden Modell überstimmt.

Planung — entscheiden, wie das Abgerufene gerahmt wird, ohne etwas hinzuzufügen: Persona-Auswahl und der Rhetorik-Plan für Anschreiben, der Evidence Relationship Builder für die Fotografie. Diese Stufe darf Betonung umordnen. Sie darf keinen Inhalt erfinden.

Generierung — der eine Punkt, an dem Claude tatsächlich schreibt, auf einem begrenzten, vorab ausgewählten Input, den es nicht selbst erweitern kann.

Validierung — die Stufe, die sich über alle drei Domänen hinweg am meisten unterscheidet, weil "was geprüft werden muss" wirklich domänenspezifisch ist. Die Anschreiben-Generierung fragt bei verbotener Formulierung oder Einstiegsregel-Verstößen erneut an, eskaliert bei jedem Retry mit dem genauen anstößigen Text, bis sie etwas Sauberes produziert oder aufgibt. Der Fotografie-Assistent lässt ein Citation Gate laufen, das jede zitierte Foto-ID gegen das Paket prüft, das er tatsächlich bekommen hat, dann einen Claim Validator, der jede strukturierte Beziehungsbehauptung gegen denselben Evidenzgraphen prüft — und beide verwerfen bei einem Fehler die gesamte Antwort und ersetzen sie durch eine feste Ablehnungsnachricht, keine Teilreparatur. Ask Vikram entfernt den internen Retrieval-Graphen, bevor irgendetwas den öffentlichen Aufrufer erreicht. Drei verschiedene Fehlerreaktionen — reparieren-und-erneut-versuchen gegenüber komplett-verwerfen gegenüber entfernen-und-weiterleiten —, weil eine Validierungsstufe kein einzelnes Verhalten ist, sondern was auch immer das jeweilige Risiko einer Domäne tatsächlich verlangt.

Dieser letzte Punkt war mir wichtig genug, ihn zu einer bewussten Entscheidung zu machen statt zu einem Standard: Retry-mit-Eskalation kostet jedes Mal Latenz und Tokens, wenn ein Verstoß auslöst, aber es verschafft dem Nutzer einen brauchbaren Brief statt einer flachen Ablehnung. Komplett-verwerfen ist billiger zu durchdenken und leichter als korrekt zu beweisen — es gibt keine Teilreparatur-Logik, die subtil falsch werden könnte —, aber es gibt dem Nutzer nichts, wenn ein Zitat aus dem Paket herausrutscht, nur eine feste Ablehnung. Ich habe nicht versucht, alle drei Domänen auf denselben Kompromiss festzulegen. Anschreiben-Text ist es wert, erneut zu versuchen; ein halluziniertes Zitat ist es nicht wert, gerettet zu werden — es ist es wert, rundweg abgelehnt zu werden.

Die neue Architektur

Nicht das: Prompt → LLM → Output (keine Naht — jede Entscheidung über Relevanz, Einbeziehung und Wahrheit geschieht unsichtbar, innerhalb eines einzigen undurchsichtigen Aufrufs) Sondern das: Extraktion → Retrieval → Planung → Generierung → Validierung (deterministisch) (maßgeblich) (nur Rahmen) (begrenzter Input) (domänenspezifisches Gate) Anschreiben: Schlüsselwörter/Capabilities → scoreCandidateEvidence → Persona/Rhetorik → Claude → Retry bei Verstoß Foto-Assistent: (via searchPhotos) → buildEvidencePack → Beziehungsgraph → Claude → Citation Gate + Claim Validator Ask Vikram: Konzeptextraktion → Hybrid-Retrieval → (entfällt) → Claude → internen Graphen entfernen

Drei Domänen, fünfstufige Form, drei unterschiedliche Validierungsverhalten am Ende — die Stufe existiert überall, ihre Reaktion auf einen Fehler muss es nicht.

Was ich gelernt habe

Ich habe diese Form nicht entworfen und dann dreimal angewendet. Jede Domäne hat sie separat neu erfunden, unter ihrem eigenen Druck, und erst der Rückblick über alle drei hinweg machte die Konvergenz offensichtlich. Das ist ein Beleg dafür, dass die Form keine Stilentscheidung ist — sie ist nah dran, die einzige Form zu sein, die den Kontakt mit "lass das Modell nicht entscheiden, was wahr ist" überlebt, ehrlich angewendet, unabhängig von der Domäne.

Die andere Lektion widerspricht der Ordentlichkeit: Alle drei Domänen-Validierungsstufen auf einen Mechanismus zu zwingen, wäre derselbe Fehler gewesen wie Engineering Behaviors Retrieval in die gemeinsame src/lib/ai/-Schicht zu zwingen — ein Fehler, den ich schon einmal gemacht und rückgängig gemacht hatte. Eine Retry-Schleife und ein Komplett-Verwerfen-Gate lösen dieselbe Kategorie von Problem, aber sie sind nicht derselbe Code mit anderen Namen; sie zu vereinheitlichen hätte bedeutet, eines von beiden zu schwächen, damit es in die Form des anderen passt.

Der Blick nach vorn

Eine Pipeline mit benannten Stufen gibt einem etwas, das ein einzelner Prompt-Aufruf strukturell nicht kann: Zwischenwerte, auf die man tatsächlich zeigen kann — ein Score, ein gedeckeltes Paket, eine Zitatmenge, ein Behauptungsgraph. Das ist kein bloßes Implementierungsdetail. Es ist der Unterschied zwischen einem System, das eine Antwort produziert, und einem System, das zeigen kann, warum es diese Antwort produziert hat — und genau darauf ruhen die eigentlichen Garantien dieser Plattform.

Fazit

Pipelines schlagen Prompts nicht, weil sie cleverer sind. Sie schlagen Prompts, weil sie Nähte haben — meist fünf — und eine Naht ist der einzige Ort, an dem man je ein Gate platzieren kann. Ein einzelner Prompt-Aufruf ist eine Black Box, die zufällig selbstbewusst wirkt. Eine Pipeline ist dieselbe Intelligenz mit Kontrollpunkten, und Kontrollpunkte sind der einzige Grund, warum irgendetwas davon vertrauenswürdig genug ist, um es auszuliefern.