Agent-Harness-Design: Das richtige Modell wählen

Model Routing ist eine betriebliche Kontrollaufgabe, kein Leaderboard-Vergleich. Datenschutz und Datenresidenz bestimmen zuerst den zulässigen Modellpool; Aufgabenerfolg und Ausgabequalität entscheiden innerhalb dieses Pools; erst danach optimieren wir Tokens, Latenz und Kosten. Lokale Modelle können wirksam sein, benötigen jedoch meist stärkere Zerlegung, Retrieval und deterministische Verifikation.

Der Harness ist die produktive Einheit

Ein Enterprise Agent ist kein Modell mit langem System Prompt. Er ist ein Harness aus Intake, Kontextaufbau, Policy Gates, Modellausführung, Werkzeugzugriff, Zustand, Verifikation, Retry-Logik, Observability und Eskalation. Das Modell ist darin eine austauschbare Komponente.

Außerhalb dieses Systems durchgeführte Modellvergleiche sagen Produktionsergebnisse schlecht voraus. Ein Modell kann im Benchmark überzeugen und an unternehmenseigenen Formaten, Rechten oder Abläufen scheitern. Ein anderes wirkt im offenen Chat schwächer, erfüllt aber sauber zerlegte Aufgaben mit gezielter Evidenz und deterministischen Kontrollen zuverlässig.

Wir wählen daher kein „bestes Modell“, sondern einen zulässigen Ausführungspfad für eine definierte Aufgabe. Erfolg liegt erst vor, wenn die Aufgabe einen verifizierten Geschäftszustand erreicht. Eine thread-basierte KI-Operations-Schicht trennt Nutzerkontext und Executor, sodass Routing, Zustand, Autorisierung und Verifikation bei einem Modellwechsel stabil bleiben.

Gate eins: Datenschutz, Residenz und vertragliche Zulässigkeit

Routing beginnt mit der Frage, ob ein Endpoint die Daten erhalten und die Aktion ausführen darf. Für jede Aufgabenklasse definieren wir ein Zulässigkeitsprofil:

Datenklasse und Anteil personenbezogener, vertraulicher, regulierter oder exportkontrollierter Informationen;
vorgeschriebene Verarbeitungs- und Speicherregionen;
Bedingungen für Aufbewahrung, Logging, Trainingsnutzung und Löschung;
Unterauftragsverarbeiter und grenzüberschreitende Übertragung;
Verschlüsselung, Identität und Zugriffskontrolle;
Audit-Log- und Incident-Meldepflichten;
Lese- oder Schreibrechte auf Produktionssystemen;
Zulässigkeit extern verarbeiteter Retrieval-Dokumente.

Das sind ausführbare Routing-Regeln. Bei eingeschränkten Daten schließt der Router unzulässige Endpoints aus. Redaction kann eine weniger sensible Folgeaufgabe erzeugen, muss aber für reale Formate getestet und protokolliert sein. Ein entfernter Name nützt wenig, wenn eindeutige Kontoangaben oder kommerziell sensible Fakten erhalten bleiben.

Residenz betrifft den gesamten Harness: Intake, temporäre Dateien, Retrieval, Inferenz, Tool-Ergebnisse, Traces, Review-Queues und Backups. Ein regionaler Modellendpunkt allein genügt nicht. Dieses Gate erzeugt erlaubte Routen; es wählt noch keinen Gewinner. Policy begrenzt, Evidenz entscheidet.

Gate zwei: Aufgabenerfolg, dann Qualität

Im zulässigen Pool prüfen wir zuerst den Aufgabenerfolg. Eine Recherche braucht eine belegte Antwort mit auflösbaren Quellen; Extraktion einen schemakonformen Datensatz mit Quellenspannen; eine operative Aktion einen validen Dry Run, genehmigte Mutation und erfolgreichen Readback.

Elegante Prosa mit nicht auflösbarer Evidenz, verbotenem Tool Call oder ungültigem Schema ist ein Fehler. Für repräsentative, schwierige und seltene Fälle definieren wir Eingabe, zulässige Evidenz, erwarteten Zustandsübergang, harte Fehler und Rubrik. Das Set umfasst:

häufige Standardfälle;
Grenzfälle nahe einer Policy- oder Qualitätsgrenze;
fehlende, veraltete, doppelte oder widersprüchliche Eingaben;
Tool- und Abhängigkeitsausfälle;
Prompt Injection in nicht vertrauenswürdigen Inhalten;
Fälle mit zwingender Abstention oder Eskalation;
relevante Sprach- und Formatvariation.

Harte Grenzen werden vor Stilpräferenzen bewertet: Schema, Werkzeugwahl, Autorisierung, Quellenbezug und nötige Eskalation sind Pass/Fail. Vollständigkeit, Klarheit und Nutzen folgen einer Rubrik. Domänenspezifische Agent Skills stabilisieren diese Tests, weil Verfahren und Kontrollen explizite Artefakte sind.

Gate drei: Tokens, Latenz und Kosten

Erst nach erfüllter Erfolgs- und Qualitätsgrenze optimieren wir Effizienz. Die Einheit ist Kosten je verifizierter Aufgabe, nicht Preis je Input-Token. Ein günstiges Modell wird teuer, wenn Retries, lange Traces, Review und Nacharbeit steigen. Eine schnelle Erstantwort kann langsame End-to-End-Latenz verbergen.

Dimension	Kennzahl auf Harness-Ebene
Erfolg	verifizierte Abschlüsse je zulässigem Versuch
Qualität	First-Pass-Abnahme, Fehlerschwere und Escape-Rate
Tokens	Input-, Cache-, Output- und Retry-Tokens je Abschluss
Latenz	Median und Perzentile vom Trigger bis zum verifizierten Zustand
Kosten	Inferenz, Retrieval, Tools, Review und Nacharbeit je Abschluss
Stabilität	Variation über Zeit, Formate und Nachfrageklassen

Wir setzen die aktuelle Route für qualitätsbereinigte Kosten und Latenz auf Baseline = 100. Ein niedrigerer Kostenindex ist nur wertvoll, wenn er keine schlechtere Erfolgsquote, höhere Ausnahmelast oder mehr Review-Zeit verdeckt. Optimiert werden dann gezielt Caching, Evidenzpakete, parallele Reads, Modellkaskaden oder der Ersatz einer Inferenz durch deterministischen Code.

Aufgaben routen, nicht Nutzer

Statisches Routing nach Abteilung verschwendet Fähigkeit und Budget. Dieselbe Person kann öffentliche Zusammenfassung, vertraulichen Vergleich, Abstimmung und Production Write verlangen – Aufgaben mit unterschiedlichen Grenzen.

task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batch

Der Router sollte weitgehend deterministisch sein. Datenklasse, Residenz und Autorisierung dürfen nicht davon abhängen, ob ein Modell eine Anfrage als „sensibel“ empfindet. Ein Klassifikator kann unterstützen; Unsicherheit wählt den sichereren Pfad. Pro Route speichern wir Policy-, Modell-, Prompt- oder Skill-Version, Evidenzkennungen, Tool Calls, Verifier-Ergebnisse und Endzustand.

Warum lokale Modelle einen anderen Harness benötigen

Lokale Inferenz bietet Datenschutzkontrolle, kalkulierbare Grenzkosten, Offline-Betrieb und geringe Latenz für begrenzte Aufgaben. Sie kann zugleich bei Instruction Following, Tool-Auswahl, Langkontext oder Mehrsprachigkeit schwächer sein. Deshalb passen wir den Harness an.

Stärker zerlegen

Dokumentauswahl, Extraktion, Klassifikation, Entwurf und Verifikation werden getrennt. Jede Stufe besitzt einen engen Ein- und Ausgabevertrag. Ein lokaler Pfad kann zuerst Abschnitte wählen, dann Claims in ein Schema extrahieren, sie Quellenspannen zuordnen und nur aus akzeptierten Claims formulieren. Mehr Orchestrierung schafft prüfbare Haltepunkte.

Weniger, aber besser abrufen

Ein gesamtes Repository in den Kontext zu laden ist kein Retrieval. Strukturierte Indizes, Metadatenfilter, Freshness-Regeln und kurze Evidenzpakete reduzieren Ablenkung. Source IDs und Spans ermöglichen Grounding-Prüfungen. Die Muster für einen lokalen KI-Assistenten mit Retrieval und Websuche zeigen, warum lokale Inferenz eine Werkzeug- und Evidenzschicht benötigt.

Deterministisch verifizieren

Schemas, Parser, Allow-Lists, Datenbank-Constraints, Berechnungen, Policy Engines und Readback prüfen Pflichtfelder, Kennungen, Summen, Rechte und Post-Action-Zustand. Semantische Kontrollen nutzen eine unabhängige Rubrik; dieselbe Ausführung sollte nicht erzeugen, bewerten und freigeben. Ein Modell-Evaluator wird gegen menschliche Urteile kalibriert und bleibt außerhalb der finalen Autoritätsgrenze.

Kaskaden, Fallbacks und Abstention

Eine Kaskade startet mit der günstigsten bereits qualifizierten Route und eskaliert bei beobachtbaren Fehlern: ungültigem Schema, fehlender Evidenz, Quellenkonflikt, kalibrierter Unsicherheit, Tool-Ausfall, Policy-Grenze oder Verifier-Fehler. Tokenzahl und verbale Unsicherheit sind allein keine Qualitätsmaße.

Fallbacks müssen alle Grenzen bewahren. Residenz darf nicht umgangen, fehlende Ausführung nicht vorgetäuscht und veraltete Evidenz nicht durch ein stärkeres Modell „frisch“ gemacht werden. Korrektes Verweigern oder Eskalieren zählt als Erfolg, wenn der Aufgabenvertrag es verlangt.

Zustand, Versionen und Reproduzierbarkeit

Wir versionieren den gesamten Ausführungsvertrag:

Task und Policy;
Provider, Region und Modellversion;
Prompt, Skill und Tool-Schema;
Retrieval-Abfrage, Source IDs und Freshness;
Sampling und Timeouts;
Verifier und Ergebnisse;
Retry-, Fallback- und Review-Ereignisse;
finale Aktion und Readback-Nachweis.

Reproduzierbarkeit entsteht aus Eingaben, Konfiguration, externen Aktionen und Evidenz, nicht aus uneingeschränkter Chain-of-Thought-Speicherung. Sensible Traces folgen Minimierungs- und Aufbewahrungsregeln. Die Disziplin beim Tuning eines projektspezifischen Agenten ist relevant: persistente Workspaces helfen nur, wenn Änderungen, Parallelität und Fehler sichtbar bleiben.

Ein praktischer Auswahlprozess

Aufgabenklassen definieren. Extraktion, Synthese, Planung, Aktion und Verifikation getrennt bewerten.
Zulässigkeits-Gates anwenden. Datenschutz-, Residenz-, Vertrags- und Rechteverletzungen ausschließen.
Evaluationsset aufbauen. Standard-, Grenz-, Angriffs- und Must-escalate-Fälle mit eingefrorener Evidenz verwenden.
Im echten Harness testen. Retrieval, Tools, Timeouts, Retries und Verifier einbeziehen.
Harte Fehler prüfen. Schema-, Evidenz-, Rechte- oder Abstention-Verstöße verwerfen.
Erfolg und Qualität bewerten. Durchschnitt und Tail schwerer Defekte betrachten.
Gesamteffizienz messen. Tokens, Latenz, Kosten, Review, Retries und Nacharbeit je Abschluss.
Im Shadow- oder Dry-Run-Modus pilotieren. Live-Variation ohne ungeprüfte Writes beobachten.
Je Aufgabenklasse freigeben. Route, Grenzen, Fallback und Ablaufdatum dokumentieren.
Kontinuierlich neu prüfen. Bei Modellwechsel, Drift, neuen Datenklassen oder wiederholten Ausnahmen.

Das Ergebnis ist eine versionierte, evidenzbasierte Routing Policy, kein dauerhaftes Ranking.

Die Entscheidungsregel

Die Reihenfolge ist entscheidend: Datenschutz, Residenz und Vertrag bestimmen, was erlaubt ist. Verifizierter Aufgabenerfolg und Qualität bestimmen, was geeignet ist. Tokens, Latenz und Gesamtkosten bestimmen, was unter den verbleibenden Routen effizient ist.

Wir bauen den Harness so, dass Modelle wechseln können, ohne Policy, Zustand oder Evidenz aufzulösen. Hosted Models, lokale Modelle und deterministische Services haben jeweils eine Rolle. Richtig ist das kleinste zulässige System, das die Aufgabe innerhalb der Qualitätsgrenze abschließt und das Ergebnis beweist.