Wissen nutzen.
Arbeit wirksam verbinden.

Ein Agent ist für ein Unternehmen zunächst eine mögliche Arbeitsteilung. Ein Mensch beschreibt ein Ziel; das System wählt innerhalb eines definierten Rahmens nächste Schritte, nutzt Werkzeuge und prüft Zwischenergebnisse. Der Unterschied zu einer einzelnen Chatantwort liegt im Ablauf über mehrere Schritte. Wie viel Entscheidungsspielraum sinnvoll ist, hängt von der Aufgabe ab. Es muss möglich bleiben, einen Vorgang zu stoppen, zu korrigieren oder an einen Menschen zu übergeben.

Ein guter Einstieg ist ein wiederkehrender Vorgang mit unterschiedlichen Eingaben und einem klar erkennbaren Ergebnis. Im Service treffen beispielsweise Anfragen mit Produktnamen, Fotos, früheren Nachrichten und unvollständigen Versionsangaben ein. Die Mitarbeitenden suchen Daten, vergleichen Dokumente und übertragen das Ergebnis in ein Ticketsystem. Ein Agent kann diese Vorbereitung zusammenführen. Der erwartete Vorteil ist weniger Wechsel zwischen Anwendungen und ein vollständigerer Arbeitsstand für die fachliche Entscheidung.

Der Auftrag darf dabei nicht nur „Service automatisieren“ lauten. Präziser wäre: Für berechtigte Anfragen die Produktversion feststellen, freigegebene Unterlagen sammeln, fehlende Angaben benennen und einen Antwortentwurf mit Belegen erstellen. Damit werden Umfang und Abschluss sichtbar. Versand, Preiszusage oder eine technische Freigabe sind eigene Handlungen, die nicht stillschweigend zum Rechercheauftrag gehören.

Nicht jede Aufgabe braucht diesen Spielraum. Wenn Eingaben und Schritte eindeutig sind, kann ein fester Workflow leichter zu betreiben sein. Wenn vor allem eine Person bessere Antworten oder Formulierungen braucht, genügt möglicherweise eine Assistenz. Agentisches Verhalten ist besonders dann interessant, wenn der nächste sinnvolle Schritt erst aus einem Zwischenergebnis hervorgeht. Die Entscheidung richtet sich nach dem Prozess, nicht nach der Bezeichnung des Werkzeugs.

Für die Auswahl hilft ein kurzer Blick auf die tatsächliche Arbeit: Wie viele Varianten gibt es, welche Informationen fehlen regelmäßig und woran erkennt ein Bearbeiter einen fertigen Vorgang? Besonders interessant sind Aufgaben, deren Vorbereitung viel Aufmerksamkeit bindet, obwohl das Ergebnis gut überprüfbar ist. Ein Prozess mit unklarer Verantwortung oder ständig wechselnden Regeln wird durch einen Agenten nicht automatisch stabiler. Manchmal entsteht der größere Nutzen zunächst durch bessere Daten, eine verständlichere Oberfläche oder eine saubere Schnittstelle zwischen zwei bestehenden Anwendungen.

Unser fiktives Beispiel beginnt mit einer Frage: „Welcher Adapter passt zu unserem Modul M-20, und welche Unterlagen benötigen wir?“ Die Produktfreigabe D-01 nennt A-4 für Version 2. Eine Dokumentenzuordnung D-02 verweist auf den Anschlussplan P-11. Eine weitere Notiz erwähnt A-5 nur als unbestätigte Möglichkeit. Das Arbeitsziel ist eine belegte Antwortvorlage, keine neue Produktfreigabe.

Zuerst ordnet das System die Anfrage einem berechtigten Vorgang zu. Fehlt die Produktversion, wird sie aus einer zulässigen Quelle ermittelt oder gezielt nachgefragt. Anschließend sucht es passende Dokumente und vergleicht deren Geltungsbereich. Die Notiz zu A-5 darf dabei nicht denselben Stellenwert erhalten wie die ausdrückliche Freigabe. Der vorbereitete Entwurf nennt deshalb A-4 für die dokumentierte Version und weist auf P-11 hin.

Der Agent kann anschließend die Angaben in die Felder eines Vorgangsentwurfs übertragen: Produkt, Version, Anliegen, verwendete Unterlagen und offene Punkte. Die zuständige Person sieht so ein Ergebnis, das sich direkt weiterbearbeiten lässt. Sie muss nicht aus einem langen Chatverlauf rekonstruieren, welche Schritte stattgefunden haben. Der Vorteil liegt in der Verbindung von Recherche und strukturierter Vorbereitung.

Eine Freigabe bezieht sich auf diesen konkreten Entwurf und die vorgesehene Handlung. Wird der Inhalt danach verändert, muss das Verfahren erkennen, ob eine erneute Prüfung erforderlich ist. Bei einer unklaren Version endet der Lauf mit einer Rückfrage. Bei einem ausgefallenen Werkzeug bleibt der Vorgang offen. Beide Zustände können fachlich richtig sein; eine erfundene Vollständigkeit wäre kein Erfolg.

Der Unterschied zeigt sich bei der Übergabe: Bisher erhält eine Fachperson möglicherweise eine weitergeleitete Nachricht und beginnt die Suche erneut. Im vorbereiteten Vorgang stehen Anfrage, bestätigte Version, relevante Freigabe und passender Plan bereits zusammen. Die Person kann ihre Aufmerksamkeit auf die verbleibende Entscheidung richten. Für eine spätere Rückfrage bleibt erkennbar, auf welcher Grundlage die Antwort entstanden ist. Ob diese Vorbereitung tatsächlich Arbeit spart, wird mit den beteiligten Mitarbeitenden am vollständigen Vorgang geprüft.

Der Ablauf braucht ein verständliches Ergebnisprotokoll: Welche Quellen wurden verwendet, welche Felder wurden vorbereitet und welche Entscheidung fehlt noch? Diese kurze Übergabe macht den Agenten im Team nutzbar. Eine detaillierte technische Spur kann zusätzlich für Betrieb und Fehleranalyse vorgehalten werden, ohne die Fachanwender mit jedem internen Modellschritt zu belasten.

Eine Wissensdatenbank hält freigegebene Inhalte vor. Retrieval findet passende Ausschnitte für eine Frage. Ein Knowledge Graph beschreibt ausdrückliche Beziehungen, etwa zwischen Produkt, Version, Adapter und Anleitung. Ein Agent nutzt solche Zugänge, um eine Aufgabe zu bearbeiten. Diese Bausteine erfüllen unterschiedliche Funktionen und sollten auch dann unterscheidbar bleiben, wenn sie in derselben Oberfläche erscheinen.

Im Servicebeispiel kann ein Graph den Zusammenhang M-20 → Version 2 → Freigabe A-4 → Anschlussplan P-11 erschließen. Eine reine Stichwortsuche findet möglicherweise alle Dokumente, überlässt den Zusammenhang aber dem Bearbeiter. Ein gepflegter Graph macht die fachlichen Verbindungen gezielt abfragbar. Daraus entsteht ein konkreter Nutzen: erforderliche Unterlagen lassen sich gemeinsam bereitstellen, und Bedingungen wie eine Produktversion werden weniger leicht übergangen.

Der Agent entscheidet innerhalb seines Auftrags, ob er eine Produktsuche, einen Dokumentabruf oder eine strukturierte Abfrage benötigt. Er kann eine fehlende Version als Hindernis erkennen und eine Rückfrage vorbereiten. Der Graph selbst erstellt dadurch noch keinen Vorgang, und das Sprachmodell erhält keine zusätzliche Berechtigung. Die Handlung entsteht erst durch ein freigegebenes Werkzeug mit klaren Eingaben und überprüfbarem Ergebnis.

Nicht jeder Agent benötigt einen Knowledge Graph. Bei einem kleinen, klar geordneten Dokumentbestand kann ein gut begrenzter Suchzugang ausreichen. Ein Graph wird dort interessant, wo mehrere Beziehungen regelmäßig Teil der Frage sind. Entscheidend ist die Pflege dieser Beziehungen: veraltete oder falsch extrahierte Verknüpfungen können den Ablauf ebenso fehlleiten wie unzuverlässige Dokumente.

Die gleiche Wissensbasis kann mehrere Abläufe unterstützen. Eine bestätigte Beziehung zwischen Produktversion und Anleitung ist für Service, Vertrieb und interne Schulung relevant. Dafür müssen nicht drei Agenten dieselbe Verbindung unabhängig aus Texten erraten. Ein gemeinsam gepflegter Wissenszugang kann die Konsistenz verbessern. Die Freigabe einer Beziehung macht aber nicht jede Nutzung identisch: Ein Vertriebsvorgang kann andere Dokumentrechte und andere Ausgaberegeln haben als die interne technische Recherche.

Ein Agent besteht aus mehr als einem Modell und einem Prompt. In der hier beschriebenen Architektur hält eine Laufzeitumgebung den Auftrag, den aktuellen Bearbeitungsstand und die zulässigen nächsten Schritte zusammen. Sie stellt Werkzeuge bereit, setzt Grenzen durch und erfasst Ergebnisse. Für diese Steuerungs- und Ausführungsschicht wird häufig der Begriff Agent Harness verwendet. Ihre Qualität entscheidet mit darüber, ob aus einem Modellaufruf ein betreibbarer Prozess wird.

Der Zustand eines Vorgangs enthält beispielsweise die bestätigte Produktversion, bereits gelesene Quellen, offene Rückfragen und eine ausstehende Freigabe. Er ist von einer längerfristigen Wissensbasis zu trennen. Eine vorläufige Annahme aus einem einzelnen Lauf sollte nicht automatisch als dauerhaftes Unternehmenswissen gespeichert werden. Auch eine Zusammenfassung früherer Arbeit braucht einen Gültigkeits- und Herkunftsbezug.

Im hybriden Aufbau können Quellen, Suche und Vorgangszustand in einer selbst kontrollierten Umgebung bleiben. Für einen einzelnen Verarbeitungsschritt lässt sich ein lokales oder ein freigegebenes externes Modell wählen. Diese Auswahl erfolgt vor der Übermittlung und berücksichtigt den konkreten Kontext. Ein leistungsfähigeres Modell ist kein Grund, ungeprüft mehr Daten weiterzugeben. Ebenso muss bekannt sein, ob ein Werkzeug selbst einen externen Dienst verwendet.

Die Werkzeuge bilden die Grenze zu den Fachsystemen. Ein eng gefasster Dokumentabruf oder die Anlage eines bestimmten Entwurfs lässt sich besser kontrollieren als ein allgemeiner Zugang zur gesamten Anwendung. Lesende und schreibende Funktionen erhalten getrennte Rechte. Der Agent darf einen gewünschten Schritt vorschlagen; die ausführende Schicht prüft, ob genau dieser Schritt mit diesen Daten zulässig ist.

Für Werkzeuge wird festgelegt, welche Angaben verpflichtend sind und welche Antwort sie liefern. Ein Suchergebnis braucht zum Beispiel Dokumentkennung und Version; ein Schreibaufruf braucht eine eindeutige Zielkennung und einen bestätigten Inhalt. Ungültige oder unvollständige Ergebnisse führen in einen definierten Fehlerzustand. Der Agent soll nicht aus einer allgemeinen Fehlermeldung improvisieren müssen, ob ein Vorgang bereits angelegt wurde. Gut gestaltete Schnittstellen verringern diese Mehrdeutigkeit und erleichtern die Prüfung.

Eine belastbare Rechtevergabe orientiert sich am Auftrag. Ein Rechercheagent braucht nicht automatisch Versand-, Änderungs- oder Löschrechte. Werkzeugzugriffe sollten mit der erforderlichen Identität und dem passenden Datenbereich erfolgen. Der ausführende Dienst prüft die Berechtigung erneut, auch wenn das Modell den Aufruf überzeugend begründet. Eine Formulierung im Prompt ersetzt diese technische Kontrolle nicht.

Für Freigaben muss klar sein, was eine Person entscheidet. „Fortfahren?“ ist oft zu unbestimmt. Eine geeignete Ansicht nennt den vorgesehenen Empfänger oder Datensatz, die Änderung und deren Inhalt. Im Beispiel würde sie den konkreten Vorgangsentwurf zeigen. Eine Zustimmung zur Recherche ist keine Zustimmung zum Versand einer Nachricht oder zur Änderung von Stammdaten.

Dokumente und Werkzeugantworten können irreführende Anweisungen enthalten. Sie werden als Arbeitsmaterial behandelt und dürfen die Regeln des Ablaufs nicht neu definieren. Das System begrenzt deshalb unabhängig vom Modell die erreichbaren Werkzeuge, Datenbereiche und Netzwerkziele. Zusätzlich braucht es Fälle, in denen der Agent die Bearbeitung sicher beendet oder an eine Person übergibt.

Datenschutz und Vertraulichkeit betreffen auch Zwischenstände: ausgelesene Textstellen, Freigabedaten, Fehlerprotokolle und gespeicherte Gesprächszusammenfassungen. Für jeden dieser Bestände werden Zweck, Zugriff und Aufbewahrung festgelegt. Beim Cloud-Pfad muss die Prüfung die gesamte übermittelte Anfrage umfassen. Das schließt Anhänge, Metadaten und Ergebnisse vorheriger Werkzeugaufrufe ein.

Die Prüfung beginnt mit einem Bestand realistischer Aufgaben. Neben den häufigen Fällen gehören unvollständige Angaben, widersprüchliche Dokumente, fehlende Berechtigungen und nicht erreichbare Systeme dazu. Für jeden Fall wird festgelegt, welches Ergebnis erwartet wird: ein korrekter Entwurf, eine Rückfrage, eine Ablehnung oder die Übergabe an das zuständige Team. So lässt sich fachlicher Erfolg von bloßer Aktivität unterscheiden.

Eine Bewertung betrachtet mehrere Ebenen. Wurden die richtigen Quellen gefunden? Sind Bedingungen in der Antwort erhalten geblieben? Wurden Werkzeuge mit gültigen Parametern aufgerufen? Stimmt der abschließende Zustand im Fachsystem? Ein flüssiger Text kann gleichzeitig einen falschen Artikel nennen oder eine unzulässige Änderung vorbereiten. Diese Fehlerarten brauchen unterschiedliche Prüfungen.

Wiederholungen müssen geplant sein. Bei einer abgebrochenen Datenbankabfrage kann ein erneuter Leseversuch sinnvoll sein. Bei einer unklaren Antwort auf eine Schreiboperation ist dagegen zuerst zu prüfen, ob die Änderung bereits erfolgt ist. Eine eindeutige Vorgangskennung und idempotente Schnittstellen können verhindern, dass ein Wiederanlauf denselben Auftrag doppelt anlegt. Sie müssen im Zielsystem tatsächlich unterstützt und getestet werden.

Auch ein gespeicherter Zwischenstand löst nicht jeden Fehler. Vor dem Fortsetzen kann sich eine Berechtigung geändert haben oder ein Dokument überholt sein. Der Wiederanlauf muss deshalb festlegen, welche Voraussetzungen erneut geprüft werden. Lang laufende Prozesse brauchen außerdem einen klaren Umgang mit abgelaufenen Freigaben, offenen Rückfragen und Zuständigkeiten.

Ein guter Testsatz hält auch die fachliche Grenze fest. Bei einer Anfrage zu M-20 ohne Version wäre die Rückfrage das erwartete Ergebnis. Beim Adapter A-5 wäre eine bestätigte Kompatibilitätszusage falsch, selbst wenn die Antwort freundlich und vollständig klingt. Bei einer nicht berechtigten Person dürfte auch eine inhaltlich richtige Auskunft nicht erscheinen. Solche Fälle machen sichtbar, ob der Ablauf die Aufgabe verstanden und seine Grenzen eingehalten hat. Die Prüfung sollte gemeinsam mit den Menschen entstehen, die diese Situationen heute bearbeiten.

Eine Wirtschaftlichkeitsbetrachtung beginnt mit dem heutigen Ablauf. Wie oft tritt die Aufgabe auf? Welche aktive Bearbeitungszeit entsteht? Wo warten Vorgänge auf andere Teams? Welche Nacharbeit fällt an? Bearbeitungszeit und Durchlaufzeit sind unterschiedliche Größen. Ein Agent kann die Recherche verkürzen, während eine notwendige fachliche Freigabe weiterhin auf Verfügbarkeit wartet.

Der relevante Vergleich ist der gesamte neue Ablauf. Zur maschinellen Vorbereitung kommen menschliche Prüfung, Korrekturen, Übergaben und gelegentliche vollständige Neubearbeitung. Nur die Differenz zur bisherigen aktiven Arbeit ist zunächst eine mögliche Zeitentlastung. Ob daraus weniger Kosten, zusätzliche Kapazität oder bessere Erreichbarkeit entsteht, hängt davon ab, wie das Unternehmen diese Zeit tatsächlich nutzen kann.

Auf der Kostenseite stehen neben Modellaufrufen auch Integration, Betrieb, Pflege der Wissensbasis und fachliche Betreuung. Ein hoher Anteil komplexer Sonderfälle kann die Rechnung verändern. Deshalb sollte ein Pilot mehrere Aufgabentypen getrennt betrachten. Ein günstiger Durchschnitt kann verdecken, dass gerade die wichtigen oder häufig eskalierten Vorgänge weiter viel manuelle Aufmerksamkeit benötigen.

Für die Bewertung lohnt sich ein Blick auf die Verteilung. Neben der durchschnittlichen Bearbeitungszeit werden besonders lange Vorgänge und die Gründe für Übergaben betrachtet. Außerdem muss der Nenner stimmen: Kosten pro gestarteter Anfrage sind etwas anderes als Kosten pro fachlich akzeptiertem Abschluss. Werden abgebrochene oder vollständig manuell neu bearbeitete Fälle ausgelassen, wirkt ein Pilot besser als der spätere Alltag. Der Vergleich sollte denselben Aufgabenbestand und dieselben Qualitätsanforderungen umfassen.

Das interaktive Modell dient der Größenordnung. Seine Eingaben sind Annahmen, keine gemessenen Leistungswerte. Für eine Investitionsentscheidung werden sie durch Pilotdaten ersetzt und um Einführungskosten, laufende Betreuung, Qualitätsanforderungen und Risiken ergänzt. Ein rechnerisch positives Ergebnis reicht nicht aus, wenn fachliche Mindestanforderungen verfehlt werden.

Ein funktionierender Prozess hat eine fachlich verantwortliche Person oder Rolle. Sie entscheidet, welche Aufgaben geeignet sind, was als korrektes Ergebnis gilt und wann ein Mensch übernimmt. Die technische Verantwortung kümmert sich um Integration, Zugriffe, Betrieb und Änderungen. Beide Perspektiven müssen zusammenarbeiten, weil ein fachlich missverständlicher Auftrag nicht allein durch eine stabilere Anwendung besser wird.

Für die Mitarbeitenden ist entscheidend, wie der Agent Arbeit übergibt. Ein übersichtlicher Vorgang nennt den vorgeschlagenen nächsten Schritt, seine Grundlage und die offenen Punkte. Korrekturen sollten an der Stelle möglich sein, an der sie ohnehin arbeiten. Müssen Beschäftigte zwischen einem zusätzlichen Chat und mehreren Fachsystemen hin- und herkopieren, kann ein Teil des erwarteten Nutzens wieder verloren gehen.

Feedback braucht einen nachvollziehbaren Weg. Ein falscher Adapter kann auf veraltete Stammdaten, eine unklare Quelle, einen Suchfehler oder einen ungeeigneten Modellschritt zurückgehen. Ein allgemeiner Daumen-nach-unten-Knopf reicht zur Verbesserung häufig nicht aus. Hilfreicher sind wenige fachliche Fehlerkategorien und die Zuordnung zum betreffenden Vorgang, ohne unnötige personenbezogene Inhalte zu vervielfachen.

Agenten verändern zudem Zuständigkeiten. Wenn vorbereitende Arbeit schneller wird, kann die Freigabe zum Engpass werden. Wenn neue Informationen automatisch zusammenlaufen, müssen ihre Verantwortlichen die Qualität sichern. Solche Auswirkungen werden im Pilot beobachtet und in Arbeitsorganisation, Schulung und Servicevereinbarungen aufgenommen. Einführung bedeutet deshalb immer auch Prozessgestaltung.

Die Einführung sollte Raum für beobachtete Arbeit lassen. In einer gemeinsamen Erprobung wird sichtbar, welche Hinweise Fachanwender tatsächlich benötigen und an welchen Stellen sie einem Entwurf nicht vertrauen. Daraus können andere Eingabefelder, eine kompaktere Belegansicht oder eine gezielte Rückfrage entstehen. Eine Mitarbeiterschulung erklärt deshalb neben der Bedienung auch den zulässigen Aufgabenbereich, die Grenzen der Wissensbasis und den vorgesehenen Weg für Korrekturen. Das schafft eine klare Zusammenarbeit statt zusätzlicher Kontrollarbeit im Verborgenen.

Ein Pilot beginnt mit einem klaren Ausschnitt: ein Anliegen, ein definierter Nutzerkreis und wenige notwendige Systeme. Für das Servicebeispiel könnte der erste Umfang ausschließlich die Vorbereitung von Anfragen zu einer Produktfamilie sein. Das Team dokumentiert den bisherigen Ablauf und einigt sich auf Qualitätskriterien, Bearbeitungsgrenzen und die erwartete Entlastung. Damit wird ein Vergleich möglich.

Danach werden Wissenszugänge und Werkzeuge unabhängig vom Agenten geprüft. Stimmen Produktkennungen und Versionen? Lassen sich Quellen eindeutig referenzieren? Können Entwürfe im Zielsystem sicher angelegt werden? Erst wenn diese Grundlagen funktionieren, verbindet die Agentenlogik die Schritte. Ein Pilot sollte sichtbar machen, welche Probleme in der Datenbasis oder im Prozess liegen und welche tatsächlich durch Modellauswahl und Orchestrierung entstehen.

Vor der operativen Freigabe stehen eine begrenzte Erprobung mit Fachanwendern, die Prüfung von Fehlerfällen und ein vereinbarter Übernahmepfad. Es wird festgelegt, wer auf Störungen reagiert, wie Änderungen getestet werden und wie das Team ohne Agent weiterarbeiten kann. Erfolg bedeutet einen nutzbaren Ablauf unter realen Bedingungen, nicht eine möglichst beeindruckende Demonstration.

Scalevity verbindet dafür Prozessberatung, Wissensarchitektur und Softwareentwicklung: den passenden Anwendungsfall bestimmen, Daten und Fachsysteme anbinden, die Oberfläche gestalten und die Anwendung in einen kontrollierbaren Betrieb überführen. Die Arbeit endet nicht beim Prompt. Sie umfasst die Übergaben zwischen Menschen, Wissen und Werkzeugen, an denen der wirtschaftliche Nutzen entsteht.

Eine Entscheidung zum Ausbau braucht vorher vereinbarte Kriterien. Dazu zählen fachlich nutzbare Ergebnisse, vertretbarer Prüfaufwand, beherrschte Fehlerfälle und eine zuständige Betriebsorganisation. Werden diese Kriterien nicht erreicht, kann der nächste Schritt auch eine kleinere Aufgabe, eine bessere Wissensbasis oder ein festerer Workflow sein. Diese Entscheidung ist kein Scheitern des Piloten. Sein Zweck ist, den geeigneten Zuschnitt der Lösung zu finden, bevor ein größerer Teil des Unternehmens davon abhängig wird.