Harness Engineering: Was ein KI-Agent außer dem Modell braucht

Was ist Harness Engineering?

Ein Sprachmodell kann denken und schreiben. Handeln kann es erst, wenn etwas um das Modell herum gebaut ist: Es braucht Zugriff auf Daten, die Erlaubnis, etwas zu tun, einen Ablauf von Schritt zu Schritt und jemanden, der hinsieht. Dieses Gerüst heißt Agent Harness. Das Wort kommt vom Geschirr eines Zugpferds: Das Pferd bringt die Kraft, das Geschirr lenkt sie dorthin, wo sie nützt.

Harness Engineering heißt, dieses Gerüst bewusst zu bauen, statt es dem Zufall zu überlassen. Die Frage lautet dann nicht mehr „Welches Modell ist das beste?“, sondern „Was braucht dieses Modell, um diese Aufgabe sicher zu erledigen?“.

Weniger ist mehr: Wie aus einer API ein Laser wird

Ein Agent arbeitet besser, wenn er weniger sieht. Jedes Werkzeug, das er nicht braucht, ist eine Gelegenheit, das falsche zu wählen, und belegt Platz im Kontext. Mit Harness Engineering ist der Zuschnitt von Rechten deshalb nicht mehr nur ein Sicherheits-Argument, sondern auch ein Qualitäts-Argument. Ein Schnitt gibt dem Agenten Leitplanke und Fokus zugleich. Aus dem breiten Licht einer API wird ein gebündelter Strahl aus wenigen, präzisen Werkzeugen für genau eine Aufgabe. Wie man dabei vorgeht, zeigt MCP-Tools zuschneiden.

Vom Prompt Engineering zum Harness Engineering

Die drei Begriffe beschreiben einen wachsenden Blickwinkel. Prompt Engineering feilt an der einzelnen Anfrage, also an Wortlaut, Beispielen und Rolle. Context Engineering fragt, was das Modell in seinem Arbeitsspeicher sieht: Dokumente, Verlauf und die Beschreibungen seiner Werkzeuge. Harness Engineering betrachtet das ganze System um das Modell, auch das, was der Agent tun darf, und wie man im Nachhinein sieht, was er getan hat. Keiner der Schritte ersetzt den vorigen. Ein gutes Harness enthält gute Prompts und guten Kontext.

Die fünf Bausteine eines Agent-Harness

Ein Agent-Harness hat fünf Bausteine. Fehlt einer, merkt man es im Betrieb: Der Agent rät, findet das falsche Werkzeug, hört nicht auf, darf zu viel, oder niemand kann erklären, was passiert ist.

Kontext (Context Engineering)

Der Agent soll wissen, was er für die Aufgabe braucht, und nicht mehr. Zu wenig Kontext lässt ihn raten. Zu viel verwässert die Aufmerksamkeit und kostet Geld.

Guter Kontext besteht aus drei Teilen:

• Wissen über das Vorgehen: Regeln, Zuständigkeiten, Muster, wie die Aufgabe im Haus erledigt wird.
• Zustand aus früheren Läufen: was schon erledigt ist, was offen ist, was ein Mensch entschieden hat.
• Frische Daten aus den Systemen: nicht vorab in den Prompt kopiert, sondern bei Bedarf über ein Werkzeug abgerufen.

Der dritte Punkt verbindet Kontext und Werkzeuge. Ein Agent, der Daten selbst nachschlagen kann, braucht keinen überfüllten Prompt.

Werkzeuge (Tools)

Werkzeuge sind die Hände des Agenten. Das Modell ruft sie über Tool Calling auf, heute meist über das Model Context Protocol als MCP-Werkzeuge. Wie gut ein Agent arbeitet, hängt stark daran, wie die Werkzeuge geschnitten und beschrieben sind. Fünf Regeln haben sich bewährt:

1. Nach Aufgaben schneiden, nicht nach der API. „Offene Posten eines Kunden lesen“ ist ein Werkzeug. Drei rohe Endpunkte, die der Agent selbst zusammensetzen muss, sind drei Gelegenheiten für Fehler.
2. Wenige Werkzeuge je Aufgabe. Weniger ist mehr, das ist der Laser von oben. Ein Agent für die Buchhaltung braucht die Werkzeuge der Buchhaltung, nicht die des Vertriebs. Zuschneiden lässt sich das etwa mit Sichten, die je Zweck nur die passenden Werkzeuge zeigen. Wie man dabei vorgeht, zeigt MCP-Tools zuschneiden.
3. Präzise Parameter. Typen, erlaubte Werte und ein Beispiel in der Beschreibung. Die Beschreibung ist Teil des Werkzeugs: Der Agent muss allein aus ihr erkennen, wann er es benutzt.
4. Schlanke Rückgaben. Nur die Felder, die die Aufgabe braucht, lange Listen in Seiten. Was zurückkommt, landet im Kontext und kostet dort Platz.
5. Fehler, die weiterhelfen. Eine gute Fehlermeldung sagt, was schiefging, warum, und was der Agent als Nächstes tun kann.

Ob die Werkzeuge taugen, misst man: Wie viele Aufrufe braucht eine Aufgabe, wie oft scheitert ein Aufruf, wie groß sind die Rückgaben, wie lange dauern sie?

Schleifen (Loops)

Ein Agent arbeitet in Schritten: planen, handeln, das Ergebnis prüfen, korrigieren oder weitermachen. Die Arbeit an diesem Ablauf heißt auch Loop Engineering. Das Harness legt fest, wann diese Schleife endet. Dafür braucht es ein Kriterium für „fertig“, eine Obergrenze für die Zahl der Schritte und eine Regel, wann der Agent an einen Menschen übergibt, statt es ein weiteres Mal zu versuchen.

Zwei Dinge machen Schleifen im Betrieb verlässlich:

• Zustand außerhalb des Modells. Eine Arbeitsliste, in der steht, welcher Vorgang in welchem Stand ist. Dann weiß der Lauf von morgen, was heute passiert ist, und ein Mensch kann jederzeit eingreifen.
• Feste Schritte ohne KI. Nicht jeder Schritt braucht ein Modell. Was immer gleich abläuft, etwa eine Buchung in einer Fachsoftware oder das Umwandeln einer Datei, erledigt ein Skript schneller, günstiger und nachvollziehbarer. Die KI denkt, das Skript klickt. Wie das im Betrieb aussieht, zeigt der automatische Zahlungsabgleich.

Leitplanken (Guardrails)

Leitplanken legen fest, was ein Agent darf, und sorgen dafür, dass er nie mehr darf. Sie machen ein Modell nicht fehlerfrei. Sie begrenzen, was ein Fehler anrichten kann.

Zu den Leitplanken gehören:

• Eine eigene Identität je Agent mit Rechten je Werkzeug, nach dem Prinzip „deny by default“: Erlaubt ist nur, was ausdrücklich freigegeben ist.
• Zugangsdaten, die der Agent nie sieht. Der API-Schlüssel des Zielsystems bleibt auf der Server-Seite. Der Agent ruft ein Werkzeug auf, nicht das System direkt.
• Schreibende Werkzeuge einzeln freigeben. Lesen und Schreiben sind getrennte Rechte, und Schreibendes ist als solches gekennzeichnet, damit der KI-Client vorher nachfragen kann.
• Sensible Felder vor dem Modell schützen. Namen oder Kontonummern lassen sich durch Kürzel ersetzen, bevor sie beim KI-Anbieter ankommen, und auf dem Rückweg wieder zurückverwandeln.

MCP absichern: Ein MCP-Server, der einen API-Schlüssel mit vollen Rechten hält, gibt jedem verbundenen Agenten volle Rechte. Absichern heißt: Der Schlüssel bleibt beim Server, jedes Werkzeug wird einzeln freigegeben, Schreiben wird getrennt erlaubt, und jeder Aufruf landet im Protokoll. Bei vielen Systemen hilft ein MCP-Gateway, das diese Regeln an einer Stelle durchsetzt, statt dass jeder Server sie für sich regelt.

Beobachtung (Observability)

Beobachtung beantwortet drei Fragen: Was hat der Agent getan, mit welchem Recht, und mit welchem Ergebnis? Ohne Antwort darauf lässt sich kein Agent verantwortlich betreiben.

Dazu gehören:

• Ein Protokoll je Werkzeugaufruf: wer, welches Werkzeug, wann, mit welchem Ergebnis.
• Fehler mit Grund: nicht nur „rot“, sondern warum der letzte Aufruf gescheitert ist.
• Kennzahlen je Aufgabe: Aufrufe, Fehlerquote, Größe der Rückgaben, Dauer.
• Eine Aufbewahrungsfrist, die zu Ihren Regeln passt.

Ein guter Test: Wie schnell können Sie beantworten, welcher Agent vergangene Woche auf Kundendaten zugegriffen hat?

Warum Werkzeuge und Leitplanken im Mittelstand entscheiden

Im Mittelstand ist selten das Modell der Engpass, sondern die Freigabe. Die IT fragt, wo die Zugangsdaten liegen und was der Agent darf. Der Datenschutz fragt, welche Daten beim KI-Anbieter ankommen. Der Betriebsrat fragt, was über Personen protokolliert wird. Alle drei Fragen werden in zwei Bausteinen beantwortet: in den Werkzeugen und in den Leitplanken.

Deshalb lohnt es sich, diese Schicht einmal ordentlich zu bauen und für alle Agenten zu nutzen, statt sie in jedem Projekt neu zu erfinden. Modelle und KI-Clients wechseln in Monaten. Die Regeln, wer im Unternehmen was darf, bleiben.

Wo JanuaPort im Harness steht

JanuaPort ist die Schicht für Werkzeuge und Leitplanken im Harness Ihrer KI-Agenten. Das selbst gehostete MCP-Gateway steht zwischen Ihren Agenten und Ihren Systemen und macht aus einer mächtigen API den Laser für eine Aufgabe: Integrationen beschreiben die Werkzeuge, Zugänge und Sichten schneiden sie je Agent zu, der Skript-Läufer bündelt feste Abläufe (ab Werk ausgeschaltet, auf unserer Showcase live erprobt). Dort werden Werkzeuge geschnitten, berechtigt, protokolliert und betrieben. Dazu liefert es Kontext aus Ihren Systemen und die Beobachtung.

JanuaPort ist kein Modell und kein Agent-Framework, und es führt die Schleife nicht aus. Modell und Client wählen Sie selbst, etwa Claude, ChatGPT oder n8n.

Mehr dazu: JanuaPort als MCP-Gateway · Was heute gebaut ist: der Stufenweg

Die Reihe

• MCP-Tools zuschneiden: Warum weniger Werkzeuge einen Agenten besser machen und wie aus einer API ein Laser wird.

Prüffragen für Ihr Agent-Harness

1. Kontext: Kann der Agent fehlende Daten selbst nachschlagen, statt zu raten?
2. Kontext: Weiß der Lauf von heute, was der Lauf von gestern erledigt hat?
3. Werkzeuge: Sieht jeder Agent nur die Werkzeuge, die seine Aufgabe braucht?
4. Werkzeuge: Sagt eine Fehlermeldung, was der Agent als Nächstes tun kann?
5. Schleifen: Gibt es eine feste Regel, wann der Agent an einen Menschen übergibt?
6. Leitplanken: Liegen die Zugangsdaten außerhalb der Reichweite des Agenten?
7. Leitplanken: Ist Schreiben getrennt von Lesen freigegeben, Werkzeug für Werkzeug?
8. Beobachtung: Können Sie für jeden Aufruf sagen, wer ihn mit welchem Recht ausgelöst hat?