bereit.ai | Damit KI im Unternehmen funktioniert.

Der erste KI-Agent sollte langweilig sein

Tue, 23 Jun 2026 00:00:00 GMT

„Eng gefasst und prüfbar“ schlägt „beeindruckend und autonom“

Demos autonomer Agenten sind häufig beeindruckend, scheitern dann aber im Übergang in den Produktivbetrieb. Gute erste Agenten sind eng gefasst und prüfbar: Ticket-Triage und Release Notes, keine digitalen Mitarbeiter.

Wir alle kennen diese Demo. Ein Agent nimmt eine vage Anweisung entgegen, plant ein Projekt, durchsucht das Web, schreibt den Code, aktualisiert drei Systeme und stellt eine Zusammenfassung in Slack ein. Das ist wirklich beeindruckend. Es weckt zugleich eine Erwartung, die den meisten KI-Roadmaps in Unternehmen unbemerkt schadet.

Denn die Demo überspringt jede Frage, die tatsächlich darüber entscheidet, ob ein Agent erfolgreich im produktiven Betrieb ist: Worauf darf er zugreifen? Was darf er verändern? Wer haftet, wenn er falsch liegt? Woher weiß man überhaupt, dass er falsch liegt? In einer Keynote lässt sich das vom Tisch wischen. In einem regulierten, auditierten, echten Unternehmen sind diese Fragen die eigentliche Einführung eines KI-Agenten.

Für die meisten Organisationen ist der richtige erste Agent nicht die autonome Wunderwaffe, die „meine Arbeit macht“. Es ist ein eingegrenzter, etwas langweiliger Workflow, der ohnehin jeden Tag stattfindet, klare Ein- und Ausgaben hat, sich in Sekunden prüfen lässt und so scheitert, dass man einfach – und ohne Schaden – eingreifen kann.

Das Wort „Agent“ weckt hohe Erwartungen

Ein Teil des Problems ist das Wort selbst. Mal meint „Agent“ einen Chatbot mit Werkzeugzugriff. Mal eine Automatisierung mit einem Modell in der Mitte. Mal ein System, das schlussfolgert, plant, APIs aufruft und über seinen nächsten Schritt selbst entscheidet. Häufig erwarten Stakeholder die autonomste Variante. Eine Erwartung, die viele Organisationen – für einen ersten Schritt – überfordert.

Mir ist wichtig zu betonen: Autonome Agenten werden zukünftig eine wichtige Rolle in Unternehmen spielen und ich rechne damit, dass sie über weite Teile der Wissensarbeit hinweg zu einer echten Produktivitätsschicht werden. Aber ein nützlicher Agent im Unternehmen definiert sich nicht darüber, wie autonom er wirkt. Er definiert sich darüber, ob er eine wertvolle Aufgabe zuverlässig erledigt, innerhalb klarer Grenzen. Viele Demos zielen aktuell auf ersteres ab und scheitern dann im produktiven Betrieb an zu hohen – oder unklar definierten – Erwartungen.

Zwei Begriffe entscheiden alles: „eng gefasst“ und „prüfbar“

Ein guter erster Agenten-Use-Case ist eng gefasst und prüfbar.

Eng gefasst heißt: Der Umfang ist klein und ausdrücklich benannt. Nicht „den Kundensupport übernehmen“, sondern eingehende Tickets gegen die Taxonomie klassifizieren, die wir ohnehin verwenden. Nicht „Releases verwalten“, sondern Release Notes aus den gemergten Pull Requests entwerfen. Je enger, desto besser; erweitern lässt sich immer, und über die Erweiterung einer funktionierenden Basis lässt sich weit einfacher reden als über die Korrektur eines breit angelegten, gescheiterten Agenten.

Prüfbar heißt: Ein Mensch kann das Ergebnis ansehen und in Sekunden entscheiden, ob es richtig, nützlich und freigabefähig ist – und daran hängt alles: Der Agent spart auch mit dieser Prüfung noch Zeit. Wenn die Prüfung der Agentenarbeit so lange dauert wie die Arbeit selbst, ist es eher ein Spielzeug als ein Produktivitätsboost.

Fast alles andere, was einen Workflow zum guten ersten Kandidaten macht, folgt aus diesen beiden Prinzipien:

eine klare Form der Eingabe
eine festgelegte Form der Ausgabe
Ein Set an historischen Fällen, die zeigen, was ein gutes Ergebnis ist
behebbare Fehler
eine Möglichkeit, Qualität zu messen
ein Eskalationsweg für den Fall, dass der Agent unsicher ist

Wer diese Punkte abhaken kann, hat einen Use-Case, der bescheiden aussieht, aber ein guter Kandidat für einen erfolgreichen ersten KI-Einsatz ist: Eine Automation dieses Use-Cases erledigt ein sich wiederholendes Stück Denkarbeit schneller und gleichmäßiger.

Zwei langweilige Workflows, die mehr wert sind, als sie aussehen

Ich möchte das anhand zweier Praxis-Beispiele, die so oder so ähnlich in vielen Unternehmen vorkommen, erläutern:

Ticket-Triage. Viele Teams verlieren echte Stunden damit, Support-, IT- oder Security-Tickets zu sortieren: Kategorie, Dringlichkeit, betroffenes System, zuständiges Team. Ein Agent kann den ersten Durchgang übernehmen und markieren, was in der Anfrage fehlt. Das klingt zwar nicht nach dem großen Wurf auf Vorstandsfolien, aber eine bessere Triage verkürzt Übergabezeiten und macht die Auslastungsberichte ehrlich, und risikoärmer lässt sich kaum anfangen: Ein falsch zugewiesenes Ticket ist sichtbar und mit einem Handgriff korrigiert.

Release Notes. Nahe am perfekten ersten Agenten. Die Eingaben sind strukturiert und liegen bereits vor: gemergte PRs, Issue-Einträge, Commit-Nachrichten, Labels. Die Ausgabe folgt einer festen Form: Features, Fixes, Breaking Changes, Migrationshinweise. Die endgültige Formulierung verantwortet weiterhin ein Release Manager, aber man startet nicht bei Null, und weniger Änderungen fallen unter den Tisch. Eng gefasste Eingaben, prüfbare Ausgabe, behebbare Fehler. Wie aus dem Lehrbuch.

Das Muster hinter beiden: Die manuellen Aufwände sind real, und fast nichts davon verlangt jedes einzelne Mal kreatives Urteilsvermögen. Genau dort lohnt sich der Einsatz. Dafür braucht es keinen digitalen Mitarbeiter, wohl aber die sorgfältige Einbettung in Arbeitsprozesse. Daher eignen sich solche Use Cases ideal um erster Erfahrungen zu sammeln und die Organisation an das Thema „AI Agenten“ heranzuführen.

Erst Grenzen, dann Autonomie

Agenten im Unternehmen brauchen Grenzen, in denen sie autonom tätig werden können. Eine Grenze beantwortet drei Fragen klar: Worauf darf der Agent zugreifen, was darf er tun, und wann muss er stoppen? Die meisten Agenten der ersten Generation sollten im einfachen Modus „ein Mensch gibt frei“ („Human in the Loop“) laufen: Sie bereiten die Arbeit vor, zeigen ihre Begründung oder ihre Quellen, und eine Person bestätigt, korrigiert oder verwirft. Das ist ein notwendiger Zwischenschritt zu mehr Autonomie. So lernt eine Organisation sicher, und so entwickeln Security, Recht und Betrieb ein echtes Gespür für Zugriff, Protokollierung und Datenverarbeitung, am konkreten Fall statt im Abstrakten.

Ein weiteres wichtiges Thema, das viele Teams überspringen: Evaluation. „Die Ausgabe sieht gut aus“ ist kein Qualitäts-Gate. Wie bei jeder Software braucht es eine passende Test-Suite, die sich jederzeit wiederholen lässt. Klassifikationsagenten lassen sich an den eigenen bereits klassifizierten Altfällen messen. Zusammenfassungsagenten lassen sich auf Vollständigkeit prüfen und auf Aussagen, die die Quelle nicht deckt. Release-Notes-Agenten lassen sich mit der Menge der tatsächlich ausgelieferten Änderungen abgleichen.

Das ist dieselbe Disziplin, die KI-Workflows brauchen Tests, nicht nur Intuition beschreibt: einen stabilen Satz realistischer Beispiele pflegen und ihn ausführen, sobald sich Prompt, Modell oder Daten ändern. Agenten bewegen sich in einem sehr variablen Umfeld, umso wichtiger ist es, kontinuierlich zu testen und zu monitoren. Modelle werden aktualisiert. Prompts werden nachjustiert. Quellsysteme verändern sich. Ohne Regressionsprüfung wird der zuverlässige Agent von gestern zur stillen Fehlerquelle von morgen. Ein eng gefasster, gut evaluierter Agent scheitert bemerkbar und behebbar.

Langweilig ist der Weg, auf dem Vertrauen wächst

Vertrauen in KI im Unternehmen entsteht nicht durch eine beeindruckende Demo. Es entsteht dadurch, dass derselbe klar definierte Workflow sichtbar auch beim fünfzigsten Mal funktioniert.

Langweilige Agenten lassen sich leicht beobachten, und genau deshalb bauen sie Vertrauen auf. Ihr Umfang ist klein genug, um ihn zu verstehen, ihre Ausgabe prüfbar, ihre Fehlerfälle dokumentierbar, ihr Nutzen messbar. Und jeder Agent, der in Betrieb geht, lehrt die Organisation etwas, das bleibt: wie sich solche Workflows entwerfen lassen, wie man sie evaluiert, wie sich Zugriff und Freigabe im produktiven Betrieb tatsächlich verhalten. Mitarbeiter erleben KI nicht länger als vage Bedrohung ihrer Rolle, sondern als das, was ihre Release Notes entwirft. Das ist eine weit einfachere Geschichte für die Einführung als „hier ist der Agent, der eure Funktion ersetzt“.

Dann, und erst dann, wird der Umfang erweitert: mehr Quellen, mehr Aktionen, mehr Automatisierung, weil die Belege dafür erarbeitet sind. Autonomie muss man sich mit Belegen verdienen; niemand darf sie voraussetzen, nur weil die Technik aufregend ist.

Mit langweiligen Workflows anzufangen heißt nicht, klein zu denken. Es heißt, den richtigen ersten Schritt zu wählen.

Die Frage sollte nicht lauten „wie autonom können wir das machen?“. Sie sollte lauten: „Wo können wir einen echten Workflow zuverlässiger, schneller und vertrauenswürdiger machen?“.

Fragen und Antworten

Was macht einen guten ersten Use-Case für einen KI-Agenten im Unternehmen aus?: Ein guter erster Agenten-Use-Case ist eng gefasst und prüfbar. Sein Umfang ist klar umrissen, und ein Mensch beurteilt das Ergebnis in Sekunden: Der Agent spart selbst mit dieser Prüfung noch Zeit.
Welche Workflows sollte ein Unternehmen zuerst mit einem KI-Agenten automatisieren?: Beispiele für gute erste Kandidaten sind: Ticket-Triage oder der Entwurf von Release Notes. Sie haben strukturierte Eingaben, sichtbare und behebbare Fehler und Ergebnisse, die ein Mensch schnell prüfen kann.
Wie misst man, ob ein KI-Agent gute Arbeit leistet?: Mit Testfällen, die sich wiederholen lassen, sobald sich Prompts, Modelle oder Daten ändern: die eigenen bereits klassifizierten Altfälle bei Klassifikation, Vollständigkeitsprüfungen gegen die Quelle bei Zusammenfassungen.
Sollten KI-Agenten im Unternehmen autonom laufen?: Für den Start empfiehlt es sich, weiterhin Freigaben durch einen Menschen („Human in the Loop“) vorzusehen. Grenzen legen fest, worauf sie zugreifen dürfen, was sie tun dürfen und wann sie stoppen müssen. In weiteren Ausbaustufen kann das Autonomie-Level weiter erhöht werden.

KI-Workflows brauchen Tests, nicht nur Intuition

Mon, 01 Jun 2026 00:00:00 GMT

Prompts, Skills und Agenten-Workflows als Softwareverhalten behandeln

Ein KI-Workflow, den jemand nur durch das Lesen einiger Antworten prüft, ist weiterhin ein reines Experiment. Es braucht realistische Datensätze, strenge Assertions und eine Testsuite, die bei jeder Änderung an Prompt, Modell oder Workflow läuft.

Wenn ein KI-Workflow nur dadurch geprüft und getestet wird, dass jemand ein paar Antworten liest und „sieht gut aus“ sagt, ist er vermutlich noch kein Workflow für den Unternehmenseinsatz. Er ist weiterhin ein Experiment.

Derzeit versuchen viele Unternehmen den Sprung von „klassischen“ KI-Chat-Interaktionen hin zu einer KI-Nutzung, die auf den eigenen Bedarf zugeschnitten ist: eigene Skills, spezialisierte Agenten und zentrale automatisierte Workflows.

Doch je weiter man sich von dem Chat-Interface entfernt, desto deutlicher wird ein praktisches Problem: Intuition skaliert nicht.

Eine kleine Anpassung an einem zentralen KI-Setup sieht immer harmlos aus:

Man passt eine Skill-Definition an, damit ein Randfall besser funktioniert.
Man wechselt auf ein neueres Modell, weil die Benchmarks vielversprechend aussehen.
Man wechselt auf ein kleineres Modell, um API-Kosten zu senken.

Aber wenn im Prompt eines Agenten ein Fehler behoben wird, kann das leicht negative Auswirkungen auf den Use Case haben, der in der vorherigen Woche noch funktioniert hat. In der KI-Welt kann eine kleine Prompt-Änderung an einer Stelle eine überraschend große Regression an einer vollkommen anderen Stelle auslösen.

Wenn wir in klassischer Software eine gemeinsam genutzte Bibliothek anfassen, lassen wir Tests laufen. Bei KI verlassen sich viele Teams weiterhin auf manuelle Prüfung und Bauchgefühl. Sie testen ein paar Beispiele, sehen, was sie sehen wollen, und liefern aus.

Prompts, Systemanweisungen und Agenten-Workflows sind nicht bloß Konfiguration. Sie definieren Softwareverhalten. Und Verhalten kann Regressionen entwickeln.

Diese Seiteneffekte allein mit manuellen Prüfungen zu verfolgen, ist praktisch unmöglich. Wer den Schritt vom Herumprobieren mit KI zum professionellen Einsatz gehen will, für den wird Zuverlässigkeit zu einem der entscheidenden Faktoren. Ein Geschäftsprozess lässt sich nicht auf der Grundlage von Versuch und Irrtum skalieren.

Eine KI-Testsuite aufsetzen

Das Claude-Plugin meines Bereichs mit mehreren zugeschnittenen Skills muss zuverlässig funktionieren. Menschen nutzen es in ihrer täglichen Arbeit, und die Akzeptanz hängt stark von verlässlichen Ausgaben ab.

Um Änderungen mit mehr Sicherheit vorzunehmen, nutze ich automatisierte Tests mit promptfoo.

Die Assets: die konkreten Prompts, Skills und Modelle benennen, die evaluiert werden sollen.
Die Datensätze: realistische Eingabedateien oder Szenarien vorab festlegen.
Die Assertions: strenge, automatisierte Regeln für die Ausgabe aufstellen. Hält die Ausgabe das geforderte JSON-Schema ein? Verweigert das System die Antwort, wo es sie verweigern soll? Wurden die richtigen Tool-Calls aufgerufen?

Woran man auf Organisationsebene merkt, dass sich das auszahlt:

Sicherere Iteration: Wenn sich ein KI-Skill falsch verhält, nimmt man zuerst den fehlschlagenden Fall in die Testsuite auf, danach passt man den Prompt an. So entsteht der Nachweis, dass die Korrektur wirkt, ohne unbemerkt altes Verhalten auszuhebeln.
Belegte Kostenoptimierung: Man möchte ein leistungsfähiges Modell gegen ein günstigeres tauschen? Die Testsuite kann verschiedene Modelle miteinander vergleichen. Erfüllt das günstigere Modell dieselben Assertions, erfolgt der Wechsel mit Belegen statt bloßem Bauchgefühl.

Die Hype-Phase der KI hinter sich zu lassen heißt, die eigenen KI-Setups mit derselben Disziplin zu behandeln wie jedes andere Software-Artefakt.

Dabei kann man jederzeit klein anfangen: ein paar realistische Beispiele sammeln, klare Erwartungen an die Ausgaben festlegen und diese Beispiele bei jeder Änderung am Setup erneut durchlaufen lassen.

Damit lassen sich weit mehr Fehler finden, als es mit Bauchgefühl je möglich wäre, und es entsteht die Grundlage dafür, KI über einen ganzen Bereich zu skalieren: die Sicherheit, iterieren zu können, ohne die Qualität zu verschlechtern.

Über das Testen hinaus: Verantwortung

In größeren Organisationen wird daraus auch eine Frage des Betriebsmodells. Wer ist Owner eines gemeinsam genutzten KI-Skills? Wie werden Änderungen geprüft? Welche Beispiele stehen für akzeptables Verhalten? Und wann ist ein Modellwechsel gut genug für den Rollout?

Tests beantworten all das nicht, aber sie geben Teams eine belastbare Faktengrundlage für die Diskussion.

Beispiel: promptfoo im Einsatz

Hier ein einfaches Beispiel, wie eine promptfooconfig.yaml aufgebaut ist.

promptfoo lässt sich an viele Formen der Evaluation anpassen. Das Werkzeug zählt weniger als die Gewohnheit: einen stabilen Satz von Testfällen pflegen und ihn ausführen, sobald sich das KI-Setup ändert.

providers:
  - id: anthropic:messages:claude-sonnet-4-6
  - id: anthropic:messages:claude-opus-4-8

prompts:
  - |-
    Analysiere dieses Support-Ticket und gib ein JSON-Objekt mit sentiment
    (positive, neutral, negative) und summary zurück: {{ticket}}

tests:
  - vars:
      ticket: "Ich warte seit drei Tagen auf meine Rückerstattung. Das ist inakzeptabel."
    assert:
      - type: contains-json
        value:
          required:
            - sentiment
            - summary
          type: object
          properties:
            sentiment:
              type: string
              enum: ["positive", "neutral", "negative"]
            summary:
              type: string
      - type: contains
        value: "negative"

  - vars:
      ticket: "Können Sie mir bitte meinen Kontostand nennen?"
    assert:
      - type: contains-json
        value: file://./path/to/schema.json
      - type: contains
        value: "neutral"

Fragen und Antworten

Wie testet man einen KI-Prompt auf Regressionen?: Einen stabilen Satz realistischer Testfälle pflegen und ihn ausführen, sobald sich Prompt, Skill-Definition oder Modell ändern. Den fehlschlagenden Fall in die Testsuite aufnehmen, bevor der Prompt angepasst wird, damit die Korrektur älteres Verhalten nicht unbemerkt aushebelt.
Wofür wird promptfoo verwendet?: promptfoo automatisiert die Evaluation von Prompts, Skills und Modellen mit vordefinierten Datensätzen und Assertions, die Ausgaben maschinell prüfen.
Was sollten Assertions in einer KI-Testsuite prüfen?: Eigenschaften, die sich verifizieren lassen: Einhaltung des Schemas, notwendige Verweigerungen, erwartete Werkzeugaufrufe, belegte Aussagen und Vollständigkeit gegenüber der Quelle.
Wie entscheidet man, ob man auf ein günstigeres KI-Modell wechselt?: Die bestehende Testsuite gegen das Modell laufen lassen. Erfüllt es dieselben Abnahmekriterien, stützt sich der Wechsel auf Belege statt auf Annahmen.

Nutzbares Wissen aus verstreuten Daten generieren

Sun, 10 May 2026 00:00:00 GMT

Vom Dokumentenabruf zur strukturierten Synthese

Das Wissen einer Organisation liegt verstreut in Tickets, Dokumenten und Chats. Es reicht nicht, die Daten lediglich durchsuchbar zu machen. Nur wenn man die Rohdaten zu aktuellen, verknüpften und belegten Kontext verdichtet, kann die KI damit sinnvoll interagieren und das Wissen nutzen.

Daten haben wir im Überfluss, Wissen nicht. In den meisten Organisationen existiert die „Source of Truth“ nicht an einem Ort. Sie liegt in Bruchstücken über JIRA-Tickets, Chat-Verläufe, veraltete Confluence-Seiten und E-Mails verteilt.

Klassisches RAG (Retrieval-Augmented Generation) versucht das zu lösen, indem es Rohdaten in einer Vektordatenbank ablegt. Nur hat das einen Haken: Ist die Eingabe ein Durcheinander, kommt auch die KI an ihre Grenzen: Welche Information ist aktuell? Welche überholt?. Um das eigentliche Potenzial von LLMs zu erschließen, müssen wir vom Abrufen zur strukturierten Synthese übergehen.

Zwei Skills, eine Source of Truth

Ich entwickle gerade einen Workflow, der die Dokumentationsschulden umgeht, indem er zwei spezialisierte KI-Rollen einsetzt: den Archäologen und den Bibliothekar.

Skill 1: der Archäologe

Der Archäologe liest nicht nur, er rekonstruiert. Über das Model Context Protocol (MCP) verbindet er sich direkt mit JIRA, Confluence und weiteren Dokumenten, um die Historie aufzuarbeiten.

Statt nur ein Suchergebnis zurückzugeben, verdichtet er den zeitlichen Verlauf:

Historie zusammenführen: Er erkennt verschiedene Versionen eines Projektplans und führt sie in einer einzigen Datei mit dem aktuellen Stand zusammen.
Das Warum: Er extrahiert die Begründung hinter Entscheidungen, die oft verloren geht, sobald ein Ticket geschlossen wird.
Quellentreue: Jede Aussage wird auf die ursprüngliche Datenquelle zurückverlinkt, damit Menschen sie prüfen können.

Das Ergebnis ist eine saubere, fachlich abgegrenzte Markdown-Datei, die den aktuellen Stand eines Themas abbildet und ein Änderungsprotokoll mit den wichtigen Meilensteinen enthält.

Skill 2: der Bibliothekar

Eine reine Sammlung von Dateien ist nur die halbe Miete. Damit Wissen nutzbar wird, muss die KI Beziehungen verstehen. Der Bibliothekar verarbeitet die Dateien des Archäologen und baut daraus einen Wissensgraphen.

Er erkennt geschäftskritische Verbindungen, zum Beispiel:

Produkt A ist der Nachfolger von Produkt B.
Funktion X ist eine Erweiterung, die Service Y voraussetzt.
Vertriebskampagne Z richtete sich an die Nutzer von Produkt B.

Sind diese Themen in einem strukturierten Markdown-Wiki verlinkt, bewegt sich die KI im Geschäftsumfeld wie ein erfahrener Mitarbeiter und nicht wie eine Suchmaschine, die die Zusammenhänge nicht kennt.

Werkzeuge wie Obsidian machen dieselben Dateien auch für Menschen einfach nutzbar und zeigen, wie die Themen zusammenhängen.

Der praktische Nutzen: von der Suche zum Schlussfolgern

Angenommen, jemand fragt eine KI: „Warum ist unser Umsatz mit Produkt B im dritten Quartal zurückgegangen?“ Ein klassisches RAG-System liefert vielleicht einen Vertriebsbericht. Eine KI, hinter der sauber strukturierte Informationen stehen, weiß:

welche Änderungen es im dritten Quartal gab
welche Vertriebskampagnen liefen
welche Produkte betroffen waren
welche verwandten Produkte indirekt betroffen sein könnten

Damit geht es nicht mehr darum, Informationen zu finden, sondern Wirkungen zu erklären: nicht bei den offensichtlichen Treffern stehen bleiben, sondern den Ursachen nachgehen.

Der Vorteil dieses Ansatzes: Daten werden bereits beim Einlesen vorstrukturiert, irrelevante Informationen entfernt, Konflikte erkannt - und wenn möglich: gelöst. Will die KI die Informationen nun nutzen, kann es auf qualitativ hochwertigeren Daten arbeiten. So reduziert man das Risiko, dass sich die KI auf veraltete Informationen stützt.

Wie es weitergeht

Das ist keine einmalige Aufräumaktion, sondern ein fortlaufender, automatisierter Prozess. Mit jedem neuen Ticket und jedem aktualisierten Dokument verändert sich der aktuelle Stand der Wissensbasis. Dieselben Skills können die Wissensbasis initial aufbauen und aktuell halten.

Aktuell lesen wir die verlinkten Markdown-Dateien direkt. Das funktioniert gut, weil Agenten immer besser darin werden, Dateisysteme zu durchsuchen; für Coding-Agenten ist das eine gängige Aufgabe. Die nächste Frage ist, wie sich dieses Wissen über Teams hinweg teilen lässt: über eine Vector-Datenbank oder weiterhin über versionierte Markdown-Repositories.