Der KI-Agent ist nicht das Produkt

Auf X wird gerade viel über Claude Code, Coding Agents, Kontext-Komprimierung, Sandboxes, Tool-Aufrufe und Agenten-Infrastruktur diskutiert.

Das klingt auf den ersten Blick nach Tool-Nerdtum.

Für Unternehmen ist es aber ein sehr praktischer Hinweis: Ein produktiver KI-Agent ist nicht einfach ein gutes Modell mit Zugriff auf ein paar Werkzeuge.

Ein produktiver KI-Agent ist ein System.

Und wie bei jedem ernsthaften System entscheidet nicht nur der intelligente Kern über die Qualität. Entscheidend ist die Architektur drumherum: Welche Informationen darf der Agent sehen? Welche Aktionen darf er ausführen? Wie werden Tool-Aufrufe validiert? Wer sieht, was passiert ist? Wann muss ein Mensch zustimmen? Wie wird ein Fehler gestoppt, zurückgerollt oder untersucht?

Der Agent selbst ist nur ein Teil des Produkts.

Der Rest ist der Harness: die Laufzeitumgebung, die den Agenten zuverlässig, begrenzt, beobachtbar und nützlich macht.

Warum das Thema jetzt wichtig wird

Viele Teams haben die erste Phase der KI-Entwicklung bereits hinter sich.

Sie haben ChatGPT, Claude, Cursor, Copilot, Replit, Lovable oder andere Werkzeuge ausprobiert. Sie haben gesehen, dass KI Code schreiben, Komponenten erzeugen, Dokumentation zusammenfassen und Fehler erklären kann. Sie haben vielleicht auch gesehen, wie schnell ein Prototyp entsteht.

Jetzt beginnt die zweite Phase.

Die Frage lautet nicht mehr nur: Kann das Modell diese Aufgabe lösen?

Die Frage lautet: Können wir diese Fähigkeit sicher in unseren Alltag, unsere Produkte und unsere internen Prozesse einbauen?

Das ist eine andere Art von Problem.

Ein Chat kann falsch liegen und trotzdem harmlos sein. Ein Agent mit Repository-Zugriff, Kundendaten, Deployment-Rechten oder Schreibzugriff auf interne Tools ist etwas anderes. Dort zählt nicht nur, ob die Antwort plausibel klingt. Dort zählt, ob das Gesamtsystem verantwortbar ist.

Der häufige Denkfehler: Modell gleich System

Viele Diskussionen über KI drehen sich um Modelle.

Welches Modell ist besser? Welches ist schneller? Welches kann längere Kontexte verarbeiten? Welches schreibt den saubereren Code? Welches ist billiger?

Diese Fragen sind nicht unwichtig. Aber sie sind nicht genug.

In einem produktiven Agenten-Workflow ist das Modell nur eine Komponente. Es entscheidet nicht allein über Zuverlässigkeit. Es arbeitet innerhalb einer Umgebung, die Kontext auswählt, Werkzeuge anbietet, Antworten prüft, Aktionen ausführt und Ergebnisse speichert.

Wenn diese Umgebung schwach ist, hilft auch ein starkes Modell nur begrenzt.

Typische Probleme sehen so aus:

• Der Agent bekommt zu viel Kontext und verwechselt relevante mit irrelevanten Informationen.
• Werkzeuge sind zu grob berechtigt und erlauben mehr, als für die Aufgabe nötig ist.
• Tool-Aufrufe werden nicht sauber validiert.
• Fehlgeschlagene Aktionen werden automatisch wiederholt, obwohl ein Mensch prüfen müsste.
• Logs zeigen nur, was am Ende passiert ist, aber nicht, warum der Agent so entschieden hat.
• Ein erfolgreicher Prototyp wird direkt in einen operativen Prozess gehoben.

Das Problem ist dann nicht “KI ist unzuverlässig”.

Das Problem ist: Der Agent wurde nicht wie ein produktives System gebaut.

Was ein Agent-Harness leisten muss

Der Begriff Harness klingt technisch, aber die Idee ist einfach.

Ein Harness ist die strukturierte Umgebung, in der der Agent arbeitet. Er verbindet Modell, Kontext, Werkzeuge, Regeln, Validierung, Sicherheit und Betrieb.

Für client-facing Software oder interne Unternehmensprozesse sollte dieser Harness mindestens sieben Aufgaben erfüllen.

1. Kontext bewusst begrenzen

KI-Agenten leben von Kontext. Aber mehr Kontext ist nicht automatisch besser.

Ein Agent muss wissen, was für die aktuelle Aufgabe relevant ist. Er muss aber nicht jede Datei, jede Slack-Nachricht, jedes Ticket und jede alte Entscheidung sehen.

Guter Kontext ist kuratiert.

Das bedeutet:

• klare Quellen;
• nachvollziehbare Herkunft;
• Trennung zwischen vertrauenswürdigen und untrusted Informationen;
• begrenzte Sicht auf sensible Daten;
• bewusste Zusammenfassungen statt beliebiger Historie;
• Regeln für Speicherung und Vergessen.

Gerade Kontext-Komprimierung und persistente Memory-Funktionen sind praktisch. Aber sie sind auch Architekturentscheidungen. Wenn wichtige Details verloren gehen oder falsche Informationen verdichtet werden, arbeitet der Agent später mit einer scheinbar sauberen, aber tatsächlich beschädigten Sicht auf das System.

2. Werkzeuge wie APIs behandeln

Ein Agent, der Werkzeuge nutzt, ist im Grunde ein Client für interne APIs.

Er liest Dateien, öffnet Tickets, ruft Datenbanken ab, erstellt Pull Requests, startet Deployments oder schreibt in Systeme.

Diese Werkzeuge dürfen nicht als lose Hilfsfunktionen behandelt werden. Sie brauchen Verträge.

Ein gutes Tool-Design beantwortet:

• Welche Eingaben sind erlaubt?
• Welche Ausgaben sind zuverlässig strukturiert?
• Welche Fehler können auftreten?
• Welche Aktionen sind reversibel?
• Welche Aktionen brauchen Zustimmung?
• Welche Daten dürfen in welchem Kontext zurückgegeben werden?

Wenn Tool-Aufrufe nur ungefähr definiert sind, entstehen schwer sichtbare Fehler. Das Modell ruft vielleicht das richtige Werkzeug mit leicht falschen Parametern auf. Oder es interpretiert eine Antwort falsch. Oder es erhält zu viele Daten und baut daraus eine plausible, aber falsche Entscheidung.

Für produktive Systeme reicht “das klappt meistens” nicht.

3. Berechtigungen eng schneiden

Der wichtigste Sicherheitsgrundsatz für Agenten ist langweilig und bewährt:

Least privilege.

Ein Agent sollte nur die Rechte haben, die er für die aktuelle Aufgabe wirklich braucht. Nicht für alle möglichen Aufgaben. Nicht für den bequemsten Workflow. Nicht für das, was während der Demo praktisch war.

Für Softwareentwicklung kann das bedeuten:

• Leserechte auf definierte Repository-Bereiche;
• Schreibrechte nur auf Arbeitsbranches;
• kein direkter Zugriff auf Secrets;
• keine Produktion-Deployments ohne Approval;
• getrennte Rollen für Analyse, Änderung, Review und Release;
• zeitlich begrenzte Berechtigungen.

Für interne Tools kann es bedeuten:

• Kundendaten nur in benötigten Feldern;
• Schreiboperationen nur nach expliziter Bestätigung;
• keine Kombination aus “alles lesen” und “alles ändern”;
• Audit-Logs für jeden Tool-Aufruf.

Ein Agent braucht keine pauschale Vollmacht, um nützlich zu sein. Er braucht gute Grenzen.

4. Validierung zwischen Modell und Aktion setzen

Ein Modell kann Absichten formulieren. Ein produktives System muss Aktionen prüfen.

Zwischen “der Agent möchte X tun” und “X passiert wirklich” sollte eine Validierungsschicht liegen.

Diese Schicht prüft zum Beispiel:

• Ist der Tool-Aufruf syntaktisch gültig?
• Passen die Parameter zum erlaubten Schema?
• Verändert die Aktion kritische Daten?
• Ist die Änderung im erwarteten Umfang?
• Gibt es Tests oder Checks, die vorher laufen müssen?
• Muss ein Mensch zustimmen?

Das ist besonders wichtig, weil viele Agenten-Fehler nicht spektakulär aussehen. Sie sind kleine Abweichungen: falsche Datei, falscher Kunde, falscher Filter, falsche Annahme über einen Zustand.

Gute Validierung verhindert, dass kleine Modellfehler direkt zu echten Systemfehlern werden.

5. Beobachtbarkeit von Anfang an einbauen

Wenn ein normaler Backend-Service ausfällt, braucht man Logs, Metriken und Traces.

Bei Agenten ist das nicht anders. Eher wichtiger.

Ein Team muss nachvollziehen können:

• Welchen Kontext hat der Agent genutzt?
• Welche Werkzeuge wurden aufgerufen?
• Welche Daten kamen zurück?
• Welche Entscheidung wurde daraus abgeleitet?
• Welche Aktion wurde ausgeführt?
• Wer hat wann zugestimmt?
• Was wurde automatisch wiederholt?

Ohne diese Informationen wird Debugging fast unmöglich. Man sieht nur das Ergebnis, aber nicht die Kette dorthin.

Für Unternehmen ist das nicht nur ein technisches Thema. Es betrifft Vertrauen, Compliance, Support und Verantwortlichkeit.

6. Fallbacks und Rollback planen

Agenten werden Fehler machen.

Die richtige Frage ist nicht, ob man jeden Fehler verhindern kann. Die richtige Frage ist, ob ein Fehler begrenzt bleibt.

Ein guter Agent-Harness hat deshalb klare Fallbacks:

• Abbruch statt riskanter Fortsetzung;
• Übergabe an einen Menschen;
• sichere Standardantworten;
• Wiederholung nur bei wirklich transienten Fehlern;
• getrennte Staging- und Produktionspfade;
• Rollback für Änderungen;
• klare Incident-Spuren.

Das unterscheidet experimentelle Automatisierung von produktiver Automatisierung.

Ein Demo-Agent beeindruckt, wenn er selbstständig weitermacht.

Ein produktiver Agent beeindruckt, wenn er rechtzeitig stoppt.

7. Den Menschen sinnvoll platzieren

Human-in-the-loop darf kein Alibi sein.

Wenn jeder Schritt manuell bestätigt werden muss, ist der Agent langsam. Wenn nie ein Mensch eingreifen muss, ist das Risiko oft zu hoch.

Der sinnvolle Punkt liegt dazwischen.

Routine, reversible und gut validierbare Aktionen können automatisiert laufen. Kritische, irreversible oder fachlich unklare Entscheidungen brauchen menschliche Zustimmung. Besonders bei Produktentscheidungen, Architekturänderungen, Kundendaten, Zahlungen, Deployments und rechtlich relevanten Prozessen sollte klar sein, wer Verantwortung trägt.

Ein guter Agent ersetzt nicht Verantwortung.

Er macht bestimmte Arbeit schneller, während Verantwortung sichtbar bleibt.

Was das für Gründer und CTOs bedeutet

Für Gründer, Product Owner und CTOs ist die praktische Konsequenz einfach:

Bewerten Sie KI-Agenten nicht nur nach der Demo.

Eine Demo zeigt, was möglich ist. Eine Architektur zeigt, ob es tragfähig ist.

Vor dem Einsatz in echten Prozessen sollten Teams einige Fragen beantworten:

• Welche Aufgabe soll der Agent wirklich übernehmen?
• Welche Daten braucht er dafür?
• Welche Daten darf er ausdrücklich nicht sehen?
• Welche Werkzeuge darf er nutzen?
• Welche Aktionen darf er selbst ausführen?
• Welche Aktionen brauchen Review oder Approval?
• Wie werden Fehler erkannt?
• Wie wird ein falsches Ergebnis zurückgenommen?
• Wer ist verantwortlich, wenn etwas schiefgeht?

Diese Fragen bremsen KI nicht aus. Sie machen sie nutzbar.

Warum das besonders für den Mittelstand zählt

Viele Mittelstandsunternehmen haben keine Lust auf KI-Theater.

Sie brauchen Systeme, die funktionieren: Angebote, interne Prozesse, Kundenportale, Integrationen, Datenflüsse, Berichte, Backoffice-Automatisierung, operative Software.

Gerade dort können Agenten sehr wertvoll sein. Sie können Informationen bündeln, Routinearbeit reduzieren, Schnittstellen bedienen, interne Tools verbessern und Softwareentwicklung beschleunigen.

Aber diese Unternehmen leben von Vertrauen, Prozessen und Kontinuität. Ein Agent, der beeindruckend wirkt, aber nicht kontrollierbar ist, passt nicht dazu.

Deshalb ist die Architektur des Agenten wichtiger als die Schlagzeile über das Modell.

Wo McDougall Digital helfen kann

Bei McDougall Digital betrachten wir KI-Agenten nicht als Magie, sondern als Software mit besonderen Eigenschaften.

Das ist ein Vorteil.

Denn dann kann man sie auch wie Software gestalten: mit Systemgrenzen, Datenmodellen, Berechtigungen, Tests, Review-Prozessen, Deployment-Regeln, Monitoring und klarer Verantwortung.

Wir helfen Teams zum Beispiel dabei:

• bestehende KI-Workflows auf Produktionsrisiken zu prüfen;
• sinnvolle Agent-Use-Cases von riskanter Automatisierung zu trennen;
• Kontext- und Datenzugriff sauber zu modellieren;
• Tool-Verträge und Berechtigungen zu gestalten;
• Review-, Test- und Approval-Prozesse einzubauen;
• interne Agenten oder AI-gestützte Entwicklungssysteme wartbar umzusetzen.

Der Punkt ist nicht, möglichst viel Autonomie zu verkaufen.

Der Punkt ist, echte Entlastung zu schaffen, ohne Kontrolle, Sicherheit und Produktqualität zu verlieren.

Die Kernbotschaft

Ein KI-Agent ist nicht einfach ein Modell.

Er ist ein produktives System aus Modell, Kontext, Werkzeugen, Berechtigungen, Validierung, Beobachtbarkeit und menschlicher Verantwortung.

Wer nur das Modell bewertet, übersieht den Teil, der im Alltag über Erfolg oder Risiko entscheidet.

Die aktuelle Diskussion um Claude Code, Kontext-Komprimierung und Agenten-Harnesses zeigt deshalb etwas Wichtiges: Die nächste Qualitätsstufe in der KI-Entwicklung liegt nicht nur in besseren Modellen.

Sie liegt in besserer Architektur um die Modelle herum.

Nächster Schritt

Wenn Sie überlegen, KI-Agenten in Softwareentwicklung, internen Tools oder operativen Prozessen einzusetzen, lohnt sich ein Architektur-Check vor dem breiten Rollout.

McDougall Digital kann helfen, die richtigen Grenzen, Werkzeuge, Freigaben und Betriebsregeln zu definieren, bevor aus einem starken Prototyp ein schwer kontrollierbares System wird.