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

Stand: 24. Oktober 2026

**Harness Engineering ist die Arbeit an allem, was ein KI-Modell zum Agenten macht: am Kontext, den es bekommt, an den Werkzeugen, die es aufrufen darf, an der Schleife, in der es arbeitet, an den Leitplanken, die es begrenzen, und an der Beobachtung, die zeigt, was es getan hat. Kurz: Agent = Modell + Harness. Ob ein Agent im Alltag verlässlich arbeitet, hängt zum größten Teil am Harness. Der wirksamste Hebel ist oft der Schnitt: Weniger Werkzeuge machen einen Agenten nicht nur sicherer, sondern auch besser.**

Gemeint ist das Harness eines KI-Agenten, nicht der Kabelbaum aus der Elektrotechnik und nicht ein Test-Harness, mit dem man Modelle bewertet.

## 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](/ratgeber/harness-engineering/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](/ratgeber/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](/gateway/buendelung), die je Zweck nur die passenden Werkzeuge zeigen. Wie man dabei vorgeht, zeigt [MCP-Tools zuschneiden](/ratgeber/harness-engineering/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](/anwendungsfaelle/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](/gateway/governance), 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.

| Baustein | Was JanuaPort beiträgt | Stand |
| --- | --- | --- |
| Kontext | Wissen mit Vorgehensmodell und Mustern, Memory für Notizen, Kartei als gemeinsame Arbeitsliste von KI, Mensch und Skript | Wissen: Vorgehensmodell und Muster im Produkt (zwei Lese-Werkzeuge auf jedem Zugang), Ansprechpartner und Best Practices des Kunden als mitgelieferte Kartei-Vorlagen: Gebaut; Memory: persönliche und Team-Notizen, zeilengenau berechtigt: Gebaut; Kartei: strukturierte Satzarten mit Feldern, Filtern, Rechten, Freigabe-Ebene; vom Betreiber als Datei, vom Agenten selbst oder von Team-Mitgliedern mit dem Recht „Karteien anlegen" in der Oberfläche angelegt; Ändern führt zusammen (nicht genannte Felder bleiben stehen); Sätze-Ansicht mit Filterzeile und Sortierung (nie nach Person) und CSV-Export für den Betreiber: Gebaut |
| Werkzeuge | Integrationen für REST-APIs, Datenbanken, Dateiablagen und andere MCP-Server. Ein Token sieht nur die Werkzeuge, die er darf; Sichten schneiden zusätzlich je Zweck zu | Integrationen in vier Arten: REST-Connector, Datenbank, Datei (camt-Kontoauszüge lesen, Ablage lesen und beschreiben), Upstream-MCP: Gebaut; Tokens je Abnehmer (Mensch, Agent, Bot, Skript) mit werkzeuggenauen Rechten, deny-by-default: Gebaut; Sichten: eigene Endpunkte je Team (/mcp/v/<name>), exklusive Integrationen: Gebaut |
| Werkzeuge | Schlanke Rückgaben: JanuaPort begrenzt, wie viel es von der Antwort einer REST- oder Datenbank-Integration liest; das Blättern regelt die Vorlage | Antworten in der Größe begrenzt: JanuaPort liest von einer REST-Antwort höchstens 1 MiB (eine Datei höchstens 10 MiB), eine Datenbank-Abfrage standardmäßig höchstens 500 Zeilen, je Integration bis 5000: Gebaut |
| Werkzeuge | Wo eine Eingabe nicht passt, sagt JanuaPort, welche Werte erlaubt sind; die Regeln stehen vorab in den Werkzeugbeschreibungen | REST-Connector: eine API, die auch Lesen als POST mit JSON-Body verlangt (Odoo ab 19, GraphQL, Suche per POST), als Lese-Werkzeug anbinden (read_via_post, nur mit ausdrücklicher Deklaration in der Spec; eine Aussage des Spec-Autors, JanuaPort prüft sie nicht gegen den Anbieter); erlaubte Werte (enum) an Parametern werden erzwungen, bevor ein Request entsteht: Gebaut |
| Werkzeuge | Prüfung aller Parameter gegen das Schema jedes Werkzeugs | Eingaben der zur Laufzeit angebundenen Werkzeuge gegen ihr Schema geprüft, bevor ein Aufruf das Zielsystem erreicht; ungültige Argumente werden mit einer klaren Meldung abgewiesen, ohne den abgelehnten Wert zu nennen (Werkzeuge eines Upstream-MCP prüft der Upstream selbst): Gebaut |
| Werkzeuge | Skript-Läufer: mehrere feste Schritte als ein Werkzeug, in einer Sandbox | Skripte sicher ausführen: der Beisteller „Skript-Läufer“ führt Skripte (z. B. Python) aus einem Git-Repo aus, festgelegt auf einen Commit, den der Admin freigibt, in einer Sandbox ohne Netz (gVisor oder gehärtetes runc). Jeder Lauf bekommt einen eigenen Zugang, der nie mehr darf als der Aufrufer und nur die deklarierten Werkzeuge; nie im Gateway selbst. Grenzen je Lauf (Wandzeit, Ausgabe, Werkzeugaufrufe) unter einer Obergrenze je Anlage; Python-Bibliotheken je Pin; Lauf-Protokoll an den Aufrufer, bereinigt: gebaut, ab Werk aus, auf der Showcase live erprobt |
| Schleifen | Zustand zwischen den Läufen in Kartei und Memory, Problemmeldung des Agenten, letzter Fehler einer REST- oder Datenbank-Integration mit Grund | Kartei: strukturierte Satzarten mit Feldern, Filtern, Rechten, Freigabe-Ebene; vom Betreiber als Datei, vom Agenten selbst oder von Team-Mitgliedern mit dem Recht „Karteien anlegen" in der Oberfläche angelegt; Ändern führt zusammen (nicht genannte Felder bleiben stehen); Sätze-Ansicht mit Filterzeile und Sortierung (nie nach Person) und CSV-Export für den Betreiber: Gebaut; Memory: persönliche und Team-Notizen, zeilengenau berechtigt: Gebaut; Katalog-Werkzeug (welche Integrationen gibt es), Problemmeldung, Ping — auf jedem Zugang: Gebaut; Letzter Fehler an der Integration: Gebaut |
| Leitplanken | Zugangsdaten im Tresor, Tokens je Agent mit Rechten je Werkzeug (deny by default), schreibende Werkzeuge einzeln freigegeben, Pseudonymisierung je Integration | Zugangsdaten im Tresor (nie in Logs, Antworten oder beim KI-Anbieter): Gebaut; Tokens je Abnehmer (Mensch, Agent, Bot, Skript) mit werkzeuggenauen Rechten, deny-by-default: Gebaut; Schreibende Werkzeuge werkzeug-genau freigegeben und als schreibend gekennzeichnet (der KI-Client kann nachfragen, JanuaPort selbst fragt nie): Gebaut; Pseudonymisierung je Integration mit Hauptschalter, Rückwandlung zum Zielsystem: Gebaut |
| Beobachtung | Audit jedes Werkzeugaufrufs mit einstellbarer Protokolltiefe und Aufbewahrungsfrist. Das Protokoll hält Dauer und Ergebnis jedes Aufrufs fest. Dazu Leitstand und Benachrichtigung per Mail | Audit jedes Werkzeugaufrufs, Export: Gebaut; Einstellbare Protokolltiefe: Metadaten (Standard), Abfragen oder Antworten — je für Tokens und SSO-Nutzer; Inhalte nur für Aufrufe an Zielsysteme (REST, MCP-Upstream, Datenbank, Datei), mit eigener Frist, nur für Menschen in der Verwaltung lesbar, jeder Abruf selbst im Protokoll; REST erhöht/verlängert mit frischer Anmeldung; Admin-MCP kann Protokolltiefe und Inhaltsfrist hinter der Betreiber-Freigabe raise_audit_depth auch anheben, mit Protokoll und Betreiber-Mail; Senken und Verkürzen bleiben immer möglich (Anheben über den Admin-MCP seit 0.75.0): Gebaut; Leitstand: Gebaut; Benachrichtigung per Mail: Gebaut |
| Beobachtung | Puls je Use Case: letzter Aufruf, Aufrufe und Fehler der letzten 24 Stunden; Fälligkeiten von Tokens | Puls je Use Case: Gebaut; Fälligkeiten: Token-Ablauf: Gebaut; Fälligkeiten: Zugangsdaten-Fristen: Geplant |

Mehr dazu: [JanuaPort als MCP-Gateway](/ratgeber/mcp-gateway) · [Was heute gebaut ist: der Stufenweg](/docs/stufenweg)

## Die Reihe

- [MCP-Tools zuschneiden](/ratgeber/harness-engineering/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?

## Häufige Fragen

### Was ist Harness Engineering?
Harness Engineering ist die Arbeit an allem, was ein KI-Modell zum Agenten macht: Kontext, Werkzeuge, Schleifen, Leitplanken und Beobachtung. Die Formel lautet Agent = Modell + Harness.

### Was ist ein Agent Harness?
Ein Agent Harness ist das Gerüst um ein Sprachmodell, das es handlungsfähig und kontrollierbar macht. Es liefert Kontext, stellt Werkzeuge bereit, steuert den Ablauf in Schritten, begrenzt die Rechte und protokolliert, was geschieht.

### Was ist der Unterschied zwischen Prompt Engineering, Context Engineering und Harness Engineering?
Prompt Engineering verbessert die einzelne Anfrage. Context Engineering bestimmt, was das Modell in seinem Arbeitsspeicher sieht. Harness Engineering umfasst das ganze System um das Modell, einschließlich Rechten, Ablauf und Beobachtung.

### Welche Bausteine gehören zu einem Agent-Harness?
Fünf: Kontext, Werkzeuge, Schleifen, Leitplanken und Beobachtung. Fehlt einer, rät der Agent, wählt das falsche Werkzeug, hört nicht auf, darf zu viel, oder niemand kann nachvollziehen, was er getan hat.

### Wie sichert man die Werkzeuge eines KI-Agenten ab?
Mit einer eigenen Identität je Agent und Rechten je Werkzeug, mit Zugangsdaten, die der Agent nie sieht, mit getrennt freigegebenen schreibenden Werkzeugen und mit einem Protokoll jedes Aufrufs. Ein MCP-Gateway setzt diese Regeln für viele Systeme an einer Stelle durch. Der Schnitt nützt doppelt: Ein Agent, der nur seine Werkzeuge sieht, ist sicherer und wählt treffsicherer.

### Braucht ein Agent-Harness MCP?
Nein. Ein Harness funktioniert auch mit Werkzeugen, die direkt im Code eines Agenten stehen. Das Model Context Protocol ist aber der verbreitete Standard für die Werkzeug-Schicht, weil viele KI-Clients ihn verstehen und Werkzeuge so nur einmal gebaut werden müssen.

### Lohnt sich Harness Engineering, wenn wir keine eigenen Agenten programmieren?
Ja. Auch ein Ablauf mit Claude, ChatGPT oder n8n hat ein Harness, nur hat es dann oft niemand bewusst gebaut. Wer seine Werkzeuge, Rechte und das Protokoll selbst festlegt, bleibt unabhängig vom Client und kann ihn wechseln, ohne die Regeln neu zu bauen.