Ein Agent erkennt, dass eine Rechnung nicht zu den vereinbarten Vertragskonditionen passt. Die relevanten Vertragsdaten liegen vor, die Rechnung wurde korrekt zugeordnet und die Abweichung ist eindeutig. Was passiert jetzt? Darf der Agent die Rechnung stoppen? Informiert er die zuständige Person? Darf er selbstständig weitere Daten aus dem ERP-System abrufen? Und was passiert, wenn Vertragsdaten und hinterlegte Konditionen nicht übereinstimmen? An diesem Beispiel wird ein Punkt deutlich, der bei der Entwicklung von AI Agents schnell in den Hintergrund gerät: Ein Agent braucht nicht nur Informationen, um eine Situation richtig einzuordnen. Er braucht auch einen klar definierten Rahmen, in dem er auf Basis dieser Informationen handeln kann. Genau hier treffen Context Engineering und Harness Engineering aufeinander. Context Engineering entscheidet, was ein Agent wissen muss. Harness Engineering entscheidet, wie daraus verlässliches Handeln wird. Für den produktiven Einsatz von AI Agents betrachten wir deshalb nicht nur das Sprachmodell. Wir unterscheiden fünf Ebenen, die zusammenspielen müssen.
1. Business Domain & Agent Boundary: Was soll der Agent eigentlich tun?
Am Anfang sollte nicht die Auswahl eines Modells oder Agent Frameworks stehen. Zuerst muss klar sein, welche Aufgabe der Agent im Unternehmen übernimmt. Bleiben wir beim Beispiel der Rechnungsprüfung. Ein Agent könnte Rechnungen mit Vertragsdaten abgleichen und Abweichungen erkennen. Damit ist aber noch nicht geklärt, welche Verantwortung er im anschließenden Prozess übernimmt. Darf er eine Rechnung lediglich kennzeichnen? Darf er eine Freigabe verhindern? Kann er Rückfragen anstoßen? Darf er Daten in einem angebundenen System verändern? Diese Grenzen bezeichnen wir als Agent Boundary. Sie beschreibt den Handlungsraum des Agenten und sollte bereits bei der Konzeption eines Use Cases festgelegt werden. Das ist besonders wichtig, wenn ein Agent mit der Zeit Zugriff auf weitere Datenquellen, Systeme und Tools erhält. Ohne eine klare Boundary wächst nicht nur der Funktionsumfang. Es wird auch zunehmend schwieriger zu beantworten, wofür der Agent eigentlich verantwortlich ist.
2. Semantic Model: Daten brauchen fachliche Bedeutung
Innerhalb dieses Handlungsraums muss ein Agent verstehen können, womit er arbeitet. Ein Kunde ist nicht einfach ein Datensatz in einem CRM. Ein Vertrag ist nicht nur ein PDF. Und eine Rechnung ist nicht lediglich eine Reihe von Feldern mit Rechnungsnummer, Betrag und Datum. Diese Objekte stehen in fachlichen Beziehungen zueinander. Ein Vertrag gehört zu einem bestimmten Kunden. Für ihn gelten Konditionen, Laufzeiten und Vereinbarungen. Eine Rechnung kann sich auf diesen Vertrag beziehen und muss wiederum bestimmten Regeln entsprechen. In den beteiligten Systemen sind diese Zusammenhänge häufig nicht einheitlich abgebildet. Begriffe unterscheiden sich, Datenmodelle sind historisch gewachsen und fachliche Regeln stecken teilweise in Anwendungen, Dokumentationen oder im Wissen einzelner Mitarbeitender. Ein Semantic Model bildet diese Zusammenhänge explizit ab. Dazu gehören zentrale Business Objects, ihre Beziehungen, einheitliche Definitionen, Taxonomien und Business Rules. Für einen Agenten entsteht damit eine fachliche Orientierung: Er kann Informationen nicht nur abrufen, sondern in ihrem geschäftlichen Zusammenhang einordnen.
3. Context Engineering: Was muss der Agent jetzt wissen?
Ein semantisches Modell beschreibt die fachliche Welt, in der sich der Agent bewegt. In einer konkreten Situation braucht er daraus jedoch nur einen bestimmten Ausschnitt. Bei einer Rechnungsprüfung könnten beispielsweise die konkrete Rechnung, der zugehörige Vertrag, vereinbarte Konditionen, der aktuelle Freigabestatus und interne Richtlinien relevant sein. Bei einem anderen Vorgang benötigt derselbe Agent möglicherweise einen völlig anderen Kontext. Genau darum geht es beim Context Engineering. Die Aufgabe besteht nicht darin, möglichst viele verfügbare Informationen in das Kontextfenster eines LLMs zu übertragen. Vielmehr muss für die jeweilige Situation entschieden werden, welche Informationen relevant sind, woher sie kommen und wie sie bereitgestellt werden. Dazu können strukturierte Daten aus operativen Systemen ebenso gehören wie Dokumente, Policies, Rolleninformationen, Prozesszustände oder historische Entscheidungen. Die zentrale Frage lautet: Was muss der Agent in dieser Situation wissen, um die Aufgabe fachlich korrekt bearbeiten zu können? Damit wird Context Engineering zu einem wesentlichen Teil der Agentenarchitektur. Die Qualität eines Agenten hängt schließlich nicht nur davon ab, wie leistungsfähig das verwendete Modell ist, sondern auch davon, auf welcher Informationsgrundlage es arbeitet.
4. Harness Engineering: Vom Verstehen zum Handeln
Mit dem richtigen Kontext kann ein Agent eine Situation einordnen. Für den produktiven Einsatz reicht das noch nicht. Sobald ein Agent Aktionen ausführen soll, entstehen weitere Anforderungen. Welche Tools und APIs darf er verwenden? Auf welche Systeme kann er zugreifen? Welche Berechtigungen gelten? Welche Aktionen dürfen automatisch ausgeführt werden und welche benötigen eine Freigabe? Diese operative und technische Umgebung ist Gegenstand des Harness Engineering. Ein Harness verbindet das Modell mit den Komponenten, die für die tatsächliche Ausführung einer Aufgabe notwendig sind. Dazu gehören unter anderem Tools, APIs, Unternehmenssysteme, Berechtigungen und Mechanismen zur Orchestrierung mehrstufiger Abläufe. Besonders relevant wird das außerhalb des Idealprozesses. Ein angebundenes System ist nicht erreichbar. Zwei Datenquellen liefern unterschiedliche Informationen. Ein notwendiger Wert fehlt. Oder der Agent kann nicht eindeutig feststellen, ob eine bestimmte Aktion innerhalb seiner Berechtigungen liegt. Für solche Fälle muss definiert sein, wie sich das System verhält. Eine Aktion kann abgebrochen, erneut versucht oder an einen Menschen eskaliert werden. In bestimmten Prozessschritten kann grundsätzlich eine Freigabe erforderlich sein. Harness Engineering schafft damit den Rahmen, innerhalb dessen ein Agent seine Fähigkeiten einsetzen darf. Die entscheidende Frage lautet hier: Wie kann der Agent auf Basis seines Kontextes handeln, ohne die definierten fachlichen und technischen Grenzen zu verlassen?
5. Evaluation & Observability: Was hat der Agent getan – und warum?
Bei klassischen LLM-Anwendungen wird häufig die Qualität einer Antwort bewertet. Bei Agenten greift diese Betrachtung zu kurz. Wenn ein Agent auf Unternehmenssysteme zugreift und Aktionen ausführt, muss der gesamte Ablauf nachvollziehbar sein. Hatte der Agent die notwendigen Informationen? Welche Daten wurden für die Entscheidung herangezogen? Welches Tool wurde ausgewählt? Wurde eine Aktion erfolgreich ausgeführt? Wurden Berechtigungen und Policies eingehalten? Gab es einen Punkt, an dem eine menschliche Freigabe erforderlich gewesen wäre? Evaluation und Observability müssen deshalb bereits in der Architektur berücksichtigt werden. Das hilft nicht nur bei der technischen Fehlersuche. Es ist auch notwendig, um die fachliche Qualität eines Agenten zu beurteilen und sein Verhalten im laufenden Betrieb gezielt verbessern zu können. Gerade bei Prozessen mit größerer geschäftlicher Relevanz muss im Nachhinein nachvollziehbar sein, wie eine Entscheidung zustande gekommen ist und welche Aktionen daraus entstanden sind.
Das LLM ist nicht die Agentenarchitektur
Die Auswahl des Sprachmodells ist wichtig. Aber sie ist längst nicht mehr der einzige entscheidende Faktor. Sprachmodelle sind mittlerweile so leistungsfähig, dass auch kleinere Modelle für viele klar abgegrenzte Aufgaben gute Ergebnisse liefern können. Gleichzeitig wird die Architektur um das Modell herum wichtiger. Ein gut aufgebautes Harness stellt sicher, dass der Agent den richtigen Kontext erhält, Tools gezielt nutzt, Berechtigungen einhält und mit Fehlern oder unklaren Situationen umgehen kann. Dadurch wird die Architektur auch weniger abhängig von einem einzelnen Modell. Sind Kontext, Tool-Nutzung, Schnittstellen und Evaluation sauber aufgebaut, lassen sich Modelle vergleichbarer Leistungsfähigkeit teilweise austauschen, ohne dass sich die Qualität des gesamten Prozesses wesentlich verändert. Das ist besonders relevant, weil sich der Markt für Sprachmodelle schnell entwickelt. Unternehmen müssen sich so nicht unnötig an ein bestimmtes Modell binden und können neue oder kleinere Modelle leichter einsetzen.
Die wichtigere Frage ist deshalb nicht nur:
„Welches Modell verwenden wir?“
Sondern:
„Wie bauen wir den Agenten so, dass er verlässlich arbeitet?“
Das LLM bleibt ein wichtiger Baustein. Die Zuverlässigkeit des Agenten entsteht aber vor allem durch das Zusammenspiel von Modell, Kontext und Harness.
Autoren: Moritz Huhle und Claudia Caruso
