Konfigurationsgesteuerte Agenten: Einen Laufzeitumfeld erstellen, schnell spezialisieren

Ein typisches Unternehmen benötigt nicht fünfzig unverbundene Agenten. Was es braucht, sind einige wenige Agentenmuster, die sich schnell an unterschiedliche Teams, Bereiche und Arbeitsabläufe anpassen lassen.

Das gilt insbesondere für unternehmensweite KI-Lösungen, die auf Daten, Berichterstattung, Analyse und Entscheidungsunterstützung basieren. Eine Gruppe wünscht sich einen Assistenten für Umsatzanalysen, eine andere einen Analysten für die Lieferkette und wieder eine andere einen Prüfer von Risiken. Sie erscheinen als separate Produkte, sind aber im Grunde Variationen desselben Systems:

• einen Orchestrierer, der eine Anfrage interpretiert und die Aufgaben zuweist,
• einen Daten- oder Erkenntnisagenten, der über das Problem nachdenkt,
• spezialisierte Funktionen für strukturierte Aufgaben wie die Erstellung von SQL-Abfragen, das Abrufen von Dokumenten, die Überprüfung von Richtlinien oder das Formatieren der Ausgabe sowie
• eine Antwortsschicht, die Rohdaten in etwas umwandelt, das Interessenten lesen können.

Diese Beobachtung gilt für konfigurationsgesteuerte Agenten. Anstatt jeden Anwendungsfall als individuellen Agenten mit fest programmierten Anweisungen, Werkzeugen und Steuerflüssen zu entwickeln, erstellt man einen leistungsstarken Basisagenten und macht sein Verhalten anpassbar. Die Konfiguration bestimmt, welche Fähigkeiten geladen werden, welche Werkzeuge aufgerufen werden dürfen, auf welche Datensätze zugegriffen werden kann, welche Form die Ausgabe annimmt und welche Regeln gelten. In einer ausgereiften Architektur befinden sich diese Konfigurationen außerdem außerhalb des bereitgestellten Images, in einem speziellen Katalog für Agentenkonfigurationen, wo sie eigenständig verwaltet und aktualisiert werden können. Der Vorteil ist ein Liefermodell, das schneller, sicherer und leichter skalierbar ist – zusammen mit Domain-Experten.

Für Organisationen, die von verstreuten Demonstrationen zu einem echten Portfolio an Produktionsagenten übergehen möchten, ist die Konfiguration mehr als nur eine Bequemlichkeit – sie ist einer der Hauptfaktoren für Geschwindigkeit.

Die Kernidee

Betrachten Sie einen konfigurationsgesteuerten Agenten als eine Laufzeitumgebung, die wiederverwendet werden kann, bei der die Konfiguration weitaus stärker als der Code bestimmt, was der Agent ist.

Der Code enthält die festen Mechanismen:

• Nachrichtenverarbeitung,
• Orchestrierung und Routing,
• Ausführung von Tools,
• Speicher und Zustand,
• Sicherheitsregeln,
• Protokollierung und Überwachbarkeit,
• Bewertungshooks sowie
• Sicherheitsgrenzen.

Die Konfiguration liefert alles, was variabel ist:

• die Systemanweisungen und Rollendefinitionen,
• die verfügbaren Fähigkeiten oder Unteragenten,
• welche Tools und Datenschnittstellen erlaubt sind,
• das Modell sowie seine Inferenzeinstellungen,
• das Ausgabeschema zusammen mit Formatierungsregeln,
• wann ein Eskalationsvorgang erforderlich ist,
• Grenzen, die aus dem jeweiligen Bereich stammen, sowie
• Parameter auf Tenant- und Umgebungs-Ebene.

Ebenso wichtig ist, dass die Konfiguration in der Regel außerhalb des Anwendungsbinärs oder der Container-Image liegt. Sobald mehrere Domains, Nutzergruppen und Agentenvarianten im Spiel sind, verlangsamt die eingebettete Konfiguration alles. Jede Anpassung des Verhaltens erfordert einen Neustart, jede Änderung der Eingabefelder eine neue Anwendungsveröffentlichung, und jede Verbesserung der Domäne muss mit den grundlegenden Entwicklungsarbeiten konkurrieren.

Der ausgereiftere Ansatz besteht darin, diese Definitionen in ein verwaltetes Katalogsystem zu externalisieren, auf das der Basisagent während des Betriebs zurückgreift. Dadurch wird die Konfiguration zu einem eigenständigen, gemanagten Asset und nicht mehr nur zu einem fest codierten Anhang des Laufzeitumfelds.

Die Trennung funktioniert, weil die größten Unterschiede zwischen Unternehmensagenten nicht architektonischer Natur sind. Sie sind verhaltensbedingt und kontextabhängig. Ein Vertriebsanalyse-Agent und ein Beschaffungsanalyse-Agent benötigen selten unterschiedliche Orchestrierungsmaschinen. Sie brauchen unterschiedliche Anweisungen, Zugriff auf Tools, Quellsysteme sowie Vorstellungen bezüglich der Formatierung – und all das sind Konfigurationsfragen.

Warum dieses Muster zur Unternehmensrealität passt

Die Anwendungsfälle für Unternehmensagenten lassen sich in Kategorien einteilen. Viele Organisationen wünschen hauptsächlich Daten- und Analyse-Agenten, die Fragen wie folgende beantworten können:

• Wohin hat sich die Konversionsrate in dieser Woche bewegt?
• Welche Kunden sind am stärksten vom Austritt bedroht?
• Warum ist die termingerechte Lieferung in der Südostregion zurückgegangen?
• Welche waren die wichtigsten betrieblichen Probleme in den letzten dreißig Tagen?
• Fassen Sie die neuesten Veränderungen der KPIs in einer für den Vorstand geeigneten Darstellung zusammen.

Die Fragen stammen aus verschiedenen Funktionen, doch die dahinterliegende Mechanik ist ähnlich:

1. Ermitteln, was der Benutzer möchte.
2. Wählen die geeigneten Such-, SQL- oder analytischen Funktionen aus.
3. Sammeln strukturierten und unstrukturierten Kontext.
4. Wenden die für das jeweilige Gebiet geltenden Schlussfolgerungsregeln an.
5. Formulieren die Antwort entsprechend dem Publikum.

Das Muster wiederholt sich immer wieder, nur die Konfiguration ändert sich. Deshalb ist ein Basis-Agent zusammen mit Konfiguration besser als ein separater Agent für jeden Anwendungsfall.

Vorteil der Bereitstellung: einmal entwickeln, schnell spezialisieren

Der größte strategische Vorteil ist die Geschwindigkeit der Bereitstellung. Sobald ein Plattformteam einen soliden Basis-Agent entwickelt hat, müssen Produktteams und Fachleute für das jeweilige Gebiet nicht bei jedem Antrag von Null anfangen. Sie erstellen ein neues Verhalten, indem sie ein Konfigurationspaket schreiben, das Folgendes definiert:

• die Geschäftsrolle, die der Agent einnimmt,
• das Fachvokabular, das er verstehen muss,
• die Datensquellen, auf die er zugreifen kann,
• die spezialisierten Fähigkeiten, die er einsetzen kann,
• die Antwortformate, die er zurückgeben muss, und
• die Compliance-Vorschriften, die er einhalten muss.

Auch die Diskussionen über Zeitpläne haben sich geändert. Ein Team, das früher versprach: „Vier Wochen für einen neuen Agenten für Finanzanalysen“, kann jetzt antworten: „Die technische Basis steht bereits zur Verfügung. Wir konfigurieren das Finanzprofil, integrieren zugelassene Datentools, legen die Ausgabebedingungen fest und testen mit dem Fachteam.“ Das ist eine andere Art der Lieferung.

Die Geschwindigkeit entsteht dadurch, dass die schwierigen Ingenieurprobleme nur einmal gelöst werden: Aufrufe von Tools, Routing, Protokollierung von Audits, Tracking, Wiederholungsversuche und Handhabung von Fehlern, Zustandsverwaltung, Durchsetzung von Richtlinien sowie Validierung der Ausgaben.

Warum Fachleute aus den jeweiligen Bereichen an Einfluss gewinnen

Ein praktischer Vorteil ist, dass Plattformingenieure und Fachexperten für bestimmte Bereiche eine klarere Kontaktperson haben. In vielen Unternehmensprojekten im Bereich KI liegt das Problem darin, dass jeder kleine Verhaltenswandel Zeit in der Entwicklung erfordert. Ein Interessengruppenmitglied gibt an, die Antwortstruktur sei falsch, es werde eine falsche Metrik verwendet oder man solle vor der Antwortung ein Richtliniedokument konsultieren. Wenn sich solches Verhalten im Code verbirgt, ist jede Änderung eine Softwareaufgabe.

Konfigurationsanpassungen gleichen das aus. Das Plattformteam ist für den dauerhaften Betrieb verantwortlich, während die Fachexperten das Verhalten durch strukturierte Eingaben gestalten:

• Vorlagen für Anfragen,
• Regeln des jeweiligen Bereichs,
• Definitionen von Metriken,
• zulässige Quellen,
• Bedingungen, die eine Eskalation auslösen, sowie
• Anforderungen an die Ausgabe.

Die Ingenieurwissenschaft verschwindet nicht. Sie wandelt sich zu einer wirksameren Form des Handelns: zur Entwicklung der Plattform, des Steuerungssystems, der Sicherheitsvorgaben sowie wiederverwendbarer Fähigkeiten, während Fachexperten bestimmen, wie diese Fähigkeiten in einem bestimmten Geschäftskontext eingesetzt werden. Genau diese Arbeitsteilung ist für eine schnelle Unternehmensauslieferung erforderlich.

Ein konkretes Unternehmensmuster

Für viele Organisationen besteht eine sinnvolle Ausgangsarchitektur aus vier Teilen.

1. Der Basis-Orchestrator

Der Orchestrator nimmt die Anfrage des Benutzers entgegen, klassifiziert die Aufgabe, entscheidet, welche Fähigkeiten benötigt werden, und verwaltet den gesamten Workflow. Seine Konfiguration kann Routingrichtlinien, Zuverlässigkeitstoleranzen, die dem jeweiligen Nutzer oder der Funktion zur Verfügung stehenden Unteragenten, Fallback-Verhalten sowie alle Anforderungen an Genehmigungen oder menschliches Eingreifen festlegen.

2. Der Daten- und Erkenntnisagent

Dies ist die allgemeine Analyse-Ebene, die für das Schlussfolgern, Aufteilen und Zusammenfassen zuständig ist. Ihre Konfiguration kann ihre Geschäftsrolle, ihr Domänenglossar, Definitionen von KPIs, analytische Playbooks sowie die Ausgabestruktur für verschiedene Zielgruppen festlegen.

3. Spezialistische Fähigkeiten oder Unteragenten

Diese übernehmen spezifische, wertvolle Aufgaben, bei denen präzisere Anweisungen und besserer Zugriff auf Tools von Vorteil sind. Typische Beispiele sind die Erstellung und Reparatur von SQL-Abfragen, semantische Suche in Dokumentationen, Spezifizierung von Diagrammen, Formatierung von Zusammenfassungen für Führungskräfte, Erklärung von Anomalien sowie Überprüfung von Richtlinien oder Compliance-Vorgaben. Die Spezialisten können selbst konfiguriert werden, doch ihr Zweck ist begrenzt und überprüfbar.

4. Der Ausgabenumformator

Viele Unternehmensworkflows scheitern, obwohl die grundlegende Antwort korrekt ist – einfach weil sie in der falschen Form vorliegt. Verschiedene Leser benötigen unterschiedliche Darstellungsformen: eine Analyse mit Annahmen und Abfragedetails, ein Executive Summary mit kurzen Empfehlungen, JSON für nachgelagerte Systeme, einen Markdown-Bericht für Wissensworkflows oder punktformulierte Inhalte für Updates an die Führungsebene. Daher ist die konfigurierbare Ausgabeschicht kein rein kosmetisches Extra – sie ist Teil des Produkts.

Was gehört in die Konfiguration?

Eine nützliche Regel: Stabile Mechanismen werden im Code festgelegt, kontextuelle Variationen in der Konfiguration. In der Praxis umfasst die Konfiguration in der Regel folgende Bereiche:

• Identität des Agenten: sein Name und seine Rolle, Systemanweisungen, Tonfall, Antwortstil sowie das Geschäftsziel, dem er dient.
• Was es leisten kann: welche Registrierungsfähigkeiten geladen werden sollen, welche Tool-Gruppen erlaubt oder verboten sind, das zu verwendende Modell sowie alle Parameteranpassungen.
• Kenntnisse im Bereich: Glossar-Einträge, Definitionen von Tabellen und Metriken, Geschäftsregeln, die relevanten Dimensionen und Filter sowie zuverlässige Quellen.
• Betriebsregeln: Wann ein Vorgehen eskaliert werden muss, welche Validierungen durchgeführt werden sollen, welche Schritte eine Genehmigung erfordern, sowie die Wiederholungspolitik, Zeitlimits und Aufgaben zur Verschleierung von Daten.
• Form der Antwort: Schema, Formatierungsstil, ob Zitate erforderlich sind, wie lang die Antworten sein sollten und für wen sie bestimmt sind.
• Wo es ausgeführt wird:Einstellungen pro Mieter, Richtlinien pro Region, Umgebungsflaggen, Connector-IDs sowie Schalter für Funktionen.

Angesichts dieser Aufteilung bedeutet das Einrichten neuer Anwendungsfälle häufig das Zusammenstellen bereits vorhandener Komponenten.

Externe Konfiguration als Designprinzip

Konfigurationsgesteuerte Agenten werden deutlich nützlicher, wenn die Konfiguration extern abgelegt wird – das heißt, das Verhalten des Agenten wird nicht ausschließlich durch in das bereitgestellte Service-Bild eingebundene Dateien definiert. Stattdessen bezieht das laufende System die Agentendefinitionen aus einer externen Quelle. Diese Quelle kann versionierte Dateien, eine Datenbank, ein Registry-Dienst oder eine Control-Plane-Anwendung sein; der entscheidende Punkt ist architektonischer Natur: Das Verhalten kann ohne Neubau des Laufzeitumfelds geändert werden.

Der Grund ist, dass zwei Veröffentlichungszyklen voneinander getrennt werden, die eigentlich nicht miteinander verbunden sein sollten: einer für den Laufzeitumfeld und einer für das Verhalten der Agenten. Das Laufzeitumfeld ändert sich, wenn Orchestrierungsfunktionen, Sicherheitsmechanismen, Anbindungen oder Kernfunktionen der Plattform aktualisiert werden. Das Verhalten ändert sich, wenn ein Fachteam Definitionen, Toolrechte, Anfragen, Ausgabeverträge oder Richtlinien für einen bestimmten Anwendungsfall überarbeitet. Wenn man sie zusammenfasst, führt jede Verbesserung des Verhaltens zu einer Verlangsamung für die gesamte Organisation.

Reifegradsschritt: Ein Katalog für Agentenkonfigurationen

Wenn es mehrere Varianten von Agenten gibt, wird ein Katalog für Agentenkonfigurationen nützlich. Es handelt sich dabei um ein verwaltetes Verzeichnis der auf einem gemeinsamen Laufzeitumfeld lauffenden Agentendefinitionen, an dem Teams Konfigurationen speichern, überprüfen, versionieren, freigeben und hochstufen können, ohne die Basisimage anzufassen. Ein Eintrag kann Folgendes enthalten:

• wer der Agent ist und wofür er dient,
• schichtweise Anweisungen, die als Prompt-Pakete zusammengefasst sind,
• die aktivierten Fähigkeiten und Unteragenten,
• zur Genehmigung vorgelegte Verbindungen und Tool-Gruppen,
• die Antwort-Schemata sowie Kontrakte für die Ausgabe,
• Business-Definitionen und weitere Domänenmetadaten,
• Eskalations- und Sicherheitsrichtlinien sowie
• die Versionsgeschichte und der Stand jeder Version in der Progression.

Der Basistestlauf führt anschließend eine einfache, aber effektive Aufgabe aus. Bei Aufruf wird die richtige Katalogeintragung abgerufen, die erlaubten Fähigkeiten geladen und alles innerhalb dieser Grenzen ausgeführt. Der Testlauf wird so zu einem stabilen Motor, während der Katalog die Ebene darstellt, an der sich das branchenspezifische Verhalten ändert.

Operative Vorteile des Katalogs

Ein externalisierter Katalog verbessert nicht nur die Flexibilität. Auch die täglichen Abläufe werden einfacher:

• Ein Änderung des Domänenprompts erzwingt keine Neuerrichtung der Service-Image,
• eine neue Ausgabeschema kann ohne Einfluss auf den Laufzeitumfeld eingeführt werden,
• Konfigurationen, die sich auf bestimmte Nutzer beziehen, können an einem Ort verwaltet werden,
• eine Rücksetzung ist dann nur eine Konfigurationsanpassung und nicht eine vollständige Neuverteilung,
• Auditor:innen können die Verhaltensdefinitionen direkt einsehen, und
• Plattformteams können auf kontrollierte Weise einen Selbstbedienungsansatz für Produkt- und Domänenteams bereitstellen.

Dies ist besonders wertvoll, wenn viele Anwendungsfälle dieselbe Struktur teilen. Wenn das System bereits Anfragen leiten, SQL-Tools aufrufen, Definitionen abrufen und Antworten formatieren kann, sollte der Bereitstellungsprozess nicht jedes Mal zum Engpass werden, wenn ein Team eine Variante wünscht.

Vergleich mit der Verbreitung von hardcodierten Agenten

Ohne eine Konfigurationsschicht geraten Unternehmens-Agentenprogramme in eine bekannte Falle, bei der jeder Anwendungsfall seine eigene Codebasis erhält – oder zumindest eine stark abgewandelte Implementierung. Schnell treten Probleme auf: doppelte Logik in verschiedenen Teams, inkonsistentes Sicherheitsverhalten, ständige Änderungen, die schwer nachvollzogen werden können, wiederholte Integrationsarbeiten, fragmentierte Überwachungsmöglichkeiten, steigende Wartungskosten sowie ein langsamerer Aufbau neuer Anwendungsfälle.

Ein konfigurationsgesteuerter Ansatz schafft eine kohärentere Plattform. Die Codebasis bleibt kleiner, Verbesserungen werden auf viele Agenten verteilt, die Verwaltung wird einfacher und das Testen systematischer. Dadurch entsteht Wiederverwendung statt unkontrollierter Ausdehnung. Das ist umso wichtiger in Programmen zur Datenverarbeitung und -analyse, wo die Anwendungsfälle meist ähnlich sind und das Einzelprogrammieren jedes Falls nur unnötige Kosten verursacht, die vermieden werden könnten.

Konfiguration als Produktinterface betrachten

Es lohnt sich, die Konfiguration als Teil der Produktoberfläche und nicht als Implementierungsdetail zu betrachten. Sie ist der Vertrag, der festlegt, wie neues Agentenverhalten sicher erstellt wird. Eine gute Konfiguration ist strukturiert und nicht ad hoc, wird vor der Laufzeit überprüft, versioniert, getestet und sowohl von Ingenieuren als auch von Fachleuten geprüft, lässt sich leicht zwischen verschiedenen Versionen vergleichen, bleibt außerhalb der Laufzeitdatei und kann über ein kontrolliertes Katalogsystem in verschiedenen Umgebungen eingesetzt werden.

Ein Insights-Agent für Betriebsabläufe könnte beispielsweise durch eine Rolle („Operations Performance Analyst“), erlaubte Fähigkeiten (sql_runner, doc_retriever, chart_formatter), ein Kernset an Anweisungen (ein Glossar zu Betriebsabläufen, Definitionen von KPIs sowie eine Checkliste für Ursachenforschung), einen Ausgabemodus (Zusammenfassung für Führungskräfte zusammen mit einer Tabelle mit Belegen) sowie Schutzmechanismen gegen Spekulationen bei unvollständiger Datenerfassung definiert werden. Das ist besser, als dieselben Entscheidungen in imperativen Code und verstreuten Anweisungssätzen zu verbergen – und noch besser, wenn die Definitionen in einem externen Katalog verwaltet werden und nicht im Deployment-Artifact enthalten sind.

Was der Katalog selbst bieten sollte

Falls die Konfiguration eine echte Bedienoberfläche sein soll, benötigt der Katalog eigene, produktreife Funktionen. Mindestens:

• Validierung der Agentendefinitionen gegen ein Schema,
• Versionskontrolle mit einem Änderungsprotokoll,
• Metadaten, die angeben, wer was besitzt,
• Abläufe für Überprüfung und Freigabe,
• Wege zur Einführung in die Entwicklungs-, Staging- und Produktionsumgebung,
• Verweise auf abhängige Fähigkeiten, Tools und Schemata,
• Differenzen zwischen Versionen,
• Rücksetzung auf früher genehmigte Konfigurationen und
• eine Prüfungschronik darüber, wer was geändert hat und warum.

Besser ausgereifte Kataloge können Vorlagen für gängige Agentenfamilien hinzufügen. Eine Standard-Vorlage für „Insight-Agenten“ könnte bereits genehmigte Routen, SQL-Spezialisten, Erzählmusterer und Standard-Verwaltungsrichtlinien enthalten, sodass neue Anwendungsfälle von einer bewährten Grundlage ausgehen und nicht von vorne beginnen müssen.

Die Rolle eines Fähigkeitsregisters

In Architekturen, bei denen konfigurationsgesteuerte Agenten zum Einsatz kommen, übernimmt oft ein Fähigkeitsregister die Rolle des Betriebssystems. Es handelt sich um ein strukturiertes Verzeichnis wiederverwendbarer Fähigkeiten, die der Basisagent laden kann, und jede Fähigkeit sollte mit entsprechenden Informationen ausgestattet sein.

Hier können Fachleute aus den jeweiligen Bereichen auf sinnvolle Weise beitragen. Finanzexperten können dabei helfen, Regeln sowie Erwartungen an die Formatierung von Finanzberichten festzulegen, Mitarbeiter aus den Betriebsabteilungen können Heuristiken zur Untersuchung von Anomalien definieren, und ein Governance-Team kann festlegen, wie ein konformes Antwortformat aussieht. Das Plattformteam muss den Agenten nicht jedes Mal neu erstellen. Es stellt vielmehr einen stabilen Mechanismus zum Laden und Kombinieren spezialisierter Fähigkeiten bereit, wobei das Katalogsystem entscheidet, welche davon für eine bestimmte Definition aktiv sind.

Der Orchestrierer ist wichtiger denn je

Manchen Menschen fällt beim Begriff „konfigurationsgesteuert“ sofort ein einfaches System mit einem einzigen Agenten ein, doch in der Regel ist das Gegenteil der Fall. Ein konfigurierbarer Basisagent ist am wirkungsvollsten, wenn er mit einem leistungsstarken Orchesterierer kombiniert wird, der als Entscheidungsträger während des Laufszeitenprozesses spezialisierte Verhaltensweisen je nach Aufgabe und aktueller Konfiguration auswählt.

Nehmen wir eine Unternehmensanfrage: Dabei kann es erforderlich sein, die Absicht der Anfrage zu klassifizieren, Definitionen von Metriken abzurufen, SQL-Abfragen für ein Lager zu erstellen, diese bei Fehlern zu korrigieren, das Ergebnis zusammenzufassen und es schließlich in eine Auskunft für Führungskräfte umzuformulieren. Der Orchesterierer steuert diese Abfolge, während die Konfiguration vorgibt, was zulässig, bevorzugt oder erforderlich ist sowie wie die endgültige Antwort aussehen soll. Dadurch wird sowohl Wiederverwendung als auch Kontrolle gewährleistet.

Die Steuerung verbessert sich, wenn das Verhalten explizit definiert ist

Unternehmensweite KI-Systeme werden nach ihrem Kontrollgrad sowie ihrer Nützlichkeit beurteilt, und ein konfigurationsgesteuertes Design hilft dabei, da es das Verhalten explizit macht. Niemand muss sich durch Code wühlen, um herauszufinden, was ein Agent tun kann. Teams können eine strukturierte Konfiguration öffnen und auf einen Blick die aktivierten Tools, die genehmigten Datensätze, das vorgeschriebene Ausgabeschema, das verwendete Modell, die Richtlinien für einen bestimmten Nutzer sowie den Punkt erkennen, an dem ein Mensch eingreifen muss.

Diese Klarheit unterstützt die Prüfbarkeit, die Konformitätsprüfung, das Release-Management, die Analyse von Vorfällen, den Umgebungswechsel sowie kontrollierte Experimente. Die Konfiguration ist somit sowohl ein Governance-Mechanismus als auch ein Beschleunigungsmechanismus, und ihre Erfassung in einem Katalog stärkt dies weiter, da die Definition des Verhaltens unabhängig überprüft, freigegeben und geprüft werden kann.

Strukturierte Variationen vereinfachen das Testen

Die Testbarkeit ist ein unterschätzter Vorteil. Wenn jeder Agent eine maßgeschneiderte Konstruktion ist, muss jeder wie ein eigenständiges Produkt getestet werden. Wenn die Variationen hauptsächlich aus Konfigurationseinstellungen auf einer gemeinsamen Laufzeitumgebung bestehen, ist das Testen systematischer:

• die Basislaufzeitumgebung wird einmalig hinsichtlich der Kernzuverlässigkeit getestet,
• jede Fähigkeit wird unabhängig hinsichtlich der Aufgabengüte getestet,
• jedes Konfigurationspaket wird auf Einhaltung der Richtlinien sowie Richtigkeit der Ausgabe überprüft, und
• jeder orchestrierte Ablauf wird von Anfang bis Ende getestet.

In der Praxis ergibt sich daraus eine Bewertungsstrategie aus Plattformtests für gemeinsamen Code, Fähigkeitstests für spezialisierte Verhaltensweisen, Konfigurations Tests für branchenspezifische Anforderungen sowie Workflow-Tests mit Goldstandard-Szenarien für vollständige Geschäftsprozesse. Dies ist weitaus nachhaltiger als die Behandlung jeder Agentenanfrage als einmaliger Anwendungsfall.

Wo LangGraph passt

LangGraph eignet sich für dieses Muster, da es ein Framework zur Orchestrierung auf niedriger Ebene ist und kein vorgefertigter Agentenbauer – genau deshalb funktioniert es für Unternehmensplattformen. Teams können die Anordnung des Graphen, den Zustandswechsel, Aufrufe von Tools, Checkpointing, Schritte zur menschlichen Freigabe sowie das, was zur Laufzeit konfiguriert werden kann, steuern. Es liefert kein fertiges, konfigurationsgesteuertes Agentenprodukt, bietet aber die notwendigen Grundelemente zum Aufbau eines solchen.

Spezifisch ermöglichen RunnableConfig sowie die configurable-Parameter es, Verhaltensweisen zur Laufzeit in einen kompilierten Graphen einzubringen, sodass ein Basisgraph einmal kompiliert werden kann und anschließend bei jeder Aufrufung Anweisungen, Modelle, Tools sowie Richtlinien variiert werden können. Auf konzeptioneller Ebene ist das genau das, was ein konfigurationsgesteuerter Basisagent benötigt.

Ein minimales Beispiel

Die zugrundeliegende Idee lässt sich leicht formulieren: Erstelle ein einziges Basisgraphen, halte die Knoten allgemein, übernimm das Verhalten aus der Laufzeitkonfiguration, suche Tools und Fähigkeiten in Registern auf und stelle Ausgabeverträge sicher, bevor Ergebnisse zurückgegeben werden. Eine minimale Veranschaulichung beginnt mit den Importen:

from typing import TypedDict, Annotated, Sequence
from langchain_core.messages import BaseMessage, SystemMessage
from langchain_core.runnables import RunnableConfig
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages

und setzt mit dem Zustand, einem allgemeinen Modellknoten sowie der Verkabelung des Graphen fort:

class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], add_messages]
def call_model(state: AgentState, config: RunnableConfig):
    configurable = config.get("configurable", {})
    persona_prompt = configurable.get(
        "system_prompt", "You are a helpful assistant."
    )
    model_name = configurable.get("model", "gpt-4o-mini")    model = ChatOpenAI(model=model_name, temperature=0)
    messages = [SystemMessage(content=persona_prompt)] + list(state["messages"])    response = model.invoke(messages)
    return {"messages": [response]}
builder = StateGraph(AgentState)
builder.add_node("agent", call_model)
builder.add_edge(START, "agent")
builder.add_edge("agent", END)base_agent = builder.compile()

Es ist absichtlich einfach gehalten, zeigt aber den Punkt auf: Der Graph bleibt konstant, während sich das Verhalten je nach Konfiguration ändert. Derselbe Graph kann anschließend mit unterschiedlichen Konfigurationen aufgerufen werden. So wird daraus ein SQL-Spezialist:

config_analyst = {
    "configurable": {
        "system_prompt": "You are a Senior SQL Expert. Return only raw query executions.",
        "model": "gpt-4o"
    }
}

events = base_agent.stream(
    {"messages": [("user", "How many users signed up today?")]},
    config=config_analyst
)

Ein anderer macht daraus einen Copywriter:

config_writer = {
    "configurable": {
        "system_prompt": "You are a witty Marketing Copywriter. Use punchy sentences.",
        "model": "gpt-4o-mini"
    }
}

events = base_agent.stream(
    {"messages": [("user", "Write a hook for a landing page.")]},
    config=config_writer
)

Der produktive Einsatz geht über das Überschreiben von Prompts und Modellen hinaus. Er beinhaltet eine strukturierte Laden der Funktionen: Abfragen im Fähigkeitsregister, Tool-Rechte, Schema-Validierung, Routing-Regeln sowie genehmigte Agentendefinitionen, die aus einem externen Katalog bezogen werden.

Die Unternehmenserweiterung

Eine realistische Konfiguration für einen Daten- und Erkenntnisagenten könnte im Prinzip wie folgt aussehen:

agent_id: operations_insight_agent
role: Operations Performance Analyst
system_prompt: |
  You are an enterprise operations analyst.
  Use only approved data and definitions.
  Distinguish clearly between observed facts, hypotheses, and recommendations.

skills:
  - metric_definition_lookup
  - sql_query_generator
  - sql_error_repair
  - executive_summary_formattertools:
  - warehouse_readonly
  - document_retrieveroutput:
  mode: executive_summary
  schema: ops_insight_response_v2
  include_citations: trueguardrails:
  no_speculation_without_evidence: true
  escalate_on_low_confidence: true

Die genaue Formatierung ist weniger wichtig als die Disziplin dahinter. Ein auf ein bestimmtes Gebiet spezialisierter Agent kann aus Konfigurationen zusammengestellt werden, anstatt von Grund auf neu implementiert zu werden – und in einer ausgereiften Plattform wird diese Konfiguration in der Regel aus dem Katalog geladen und nicht in das Service-Bild kopiert.

Wer ist für was verantwortlich?

Damit das Modell funktioniert, muss das Plattformteam die wiederverwendbare Basis kontrollieren. Dazu gehören der Orchestrierungs-Runtime, das Konfigurationschema sowie der Validator, der Katalog mit seiner Auflösungsschicht, das Fähigkeitsregister und der Lader, gemeinsam genutzte Connector sowie Tool-Wrapper, die Überwachungsfunktionen mit Traceing und Audit-Logging, Evaluierungswerkzeuge, Deployment-Arbeitsabläufe sowie die Durchsetzung von Richtlinien und Sicherheitsmaßnahmen. Die ingenieurtechnischen Anstrengungen zahlen sich hier in besonderem Maße aus und verstärken sich noch, da jede neue Agent-Konfiguration von derselben Infrastruktur profitiert.

Domain-Teams sollten nicht in die Framework-Entwicklung gedrängt werden. Sie liefern das Wissen, das aus einem Agenten etwas Nützliches für ein bestimmtes Unternehmen macht: Definitionen, zulässige Argumentationsweisen, Entscheidungsheuristiken, genehmigte Interpretationen der Daten, Randfälle, was echte Interessengruppen sehen möchten, sowie Beispiele zur Bewertung. Eine starke, konfigurationsgesteuerte Plattform macht diese Beiträge in der Praxis nutzbar – das ist einer der klarsten Wege, die Bereitstellung von KI zu skalieren, ohne das zentrale Engineering-Team zum Engpass werden zu lassen.

Entwurfsprinzipien, die die Funktionalität gewährleisten

Einige Prinzipien tragen dazu bei, solide, konfigurationsgesteuerte Systeme von brüchigen zu unterscheiden.

• Halten Sie den Basis-Agenten eng gefasst, aber leistungsstark. Er sollte gemeinsame Mechanismen handhaben und nicht jede domänenspezifische Ausnahme berücksichtigen. Geschäftslogik, die in der Konfiguration oder in spezialisierten Fähigkeiten untergebracht werden kann, sollte nicht im Laufzeitumfeld liegen.
• Halten Sie die spezialisierten Fähigkeiten fokussiert. Je enger der Umfang einer Fähigkeit ist, desto einfacher ist es, sie zu bewerten, zu verbessern und sicher wiederverwenden. Eine sql_error_repair-Fähigkeit ist besser als eine vage „Datenverarbeitungs-Fähigkeit“.
• Überprüfen Sie die Konfiguration streng. Konfiguration ist kein informeller Text. Verwenden Sie Schemata, erforderliche Felder, Standardwerte sowie Kompatibilitätsprüfungen, denn schlechte Konfigurationen können genauso gefährlich sein wie schlechter Code – besonders, wenn sie externalisiert und getrennt vom Laufzeitumfeld veröffentlicht werden.

Externalisieren Sie frühzeitig. Es ist in Ordnung, mit Konfigurationsdateien im Repository zu beginnen, doch wenn das Ziel eine Unternehmensplattform mit vielen Varianten ist, sollte die Externalisierung von Anfang an ein explizites Designziel sein. Andernfalls stellt die Organisation fest, dass sie einen Laufzeitumgebungen erstellt hat, der konfiguriert werden kann, aber kein Betriebsmodell, das dies ebenfalls ermöglicht.

Setzen Sie Kontrakte an den Grenzen durch. Wenn eine Funktion SQL zurückgeben muss, überprüfen Sie, ob tatsächlich SQL ausgegeben wird, und wenn ein Formatierer JSON gemäß einem Schema erzeugen muss, prüfen Sie dies vor der Auslieferung des Ergebnisses.

Trennen Sie Routing von Fachwissen. Der Orchestrierer entscheidet, wann eine Funktionalität verwendet werden soll, wodurch die jeweilige Funktionalität auf ihre eine Aufgabe fokussiert und dabei besonders effektiv bleibt.

Machen Sie das Verhalten beobachtbar. Bei jeder Aufrufung sollte es einfach sein, die verwendete Konfiguration, die geladenen Fähigkeiten, die aufgerufenen Tools sowie die Begründung für den gewählten Weg zu erkennen.

Häufige Fehlermuster

Das Muster ist mächtig, doch einige Fehler treten immer wieder auf.

• Überfüllte Konfiguration. Wenn die Konfiguration zu einem Auffangbecken für alle Randfälle wird, wird das System unleserlich und anfällig. Die Konfiguration sollte kontrollierte Variationen ausdrücken und nicht die Softwarearchitektur ersetzen.
• Schwache Grenzen zwischen Fähigkeiten. Wenn die Fähigkeiten stark überschneiden, kann der Orchestrierer keine klaren Entscheidungen treffen, wodurch die Bewertung unübersichtlich wird. Wiederverwendbare Fähigkeiten benötigen eine klare Aufgabe und eine eindeutige Schnittstelle.

Keine Schleife zur Überprüfung von Domains. Ein konfigurierbares System beschleunigt die Auslieferung nur dann, wenn Domain-Experten bei der Definition von Anfragen, Regeln, Beispielen und der Antwortqualität mitwirken. Andernfalls erstellen die Teams einfach einen schnelleren Weg zu generischen Ergebnissen.

Unkonsistente Ausgabeverträge. Viele Unternehmensfehler treten in der letzten Phase auf. Ein Agent, der nicht zuverlässig die erwartete Struktur erzeugen kann, untergräbt sowohl die Integration als auch das Vertrauen.

Versteckte Richtlinienlogik. Wenn Richtlinien und Zugriffsregeln auf Code, Anfragen und Bereitstellungs-Einstellungen aufgeteilt sind, wird die Steuerung schwierig. Halten Sie die Steuermechanismen klar und eindeutig.

Warum das strategisch wichtig ist

Der langfristige Wert konfigurationsgesteuerter Agenten liegt nicht nur in ihrer Eleganz. Sie unterstützen ein skalierbareres Unternehmensbetriebsmodell. Organisationen können ähnliche Anwendungsfälle für Agenten viel schneller umsetzen, bewährte Infrastrukturen wiederverwenden anstatt sie zu duplizieren, Fachleute aus dem jeweiligen Bereich einbinden, ohne jede Änderung in eine Programmieraufgabe umwandeln zu müssen, die Governance durch explizite Verhaltensdefinitionen verbessern, Varianten über ein externes Katalogsystem verwalten statt durch wiederholte Neuimplementierungen, systematisch in gemeinsamen Laufzeiten sowie spezialisierten Konfigurationen testen und schließlich eine interne Fähigkeitsbibliothek aufbauen anstelle eines „Gräberfelds“ aus einmaligen Bots.

Für Unternehmen, deren wichtigste KI-Möglichkeiten in Daten- und Analyseprozessen liegen, ist dies besonders verlockend, denn diese Anwendungsfälle teilen einen gemeinsamen Kern. Jeden davon unabhängig zu entwickeln, ist selten die richtige Strategie. Stattdessen lohnt es sich in der Regel, eine solide Grundlage zu schaffen, die richtigen Konfigurationsmöglichkeiten bereitzustellen und durch kontrollierte Kombinationen spezialisiertes Verhalten hervorzubringen.

Was bleibt von den Unternehmens-Agentenplattformen übrig?

Die effektivsten Unternehmens-Agentenplattformen werden wahrscheinlich nicht diejenigen sein, die die meisten maßgeschneiderten Agenten erzeugen. Vielmehr werden es jene sein, die gemeinsame Agentenmuster in eine Infrastruktur umwandeln, die man konfigurieren kann. Ein Basisagent, der seine Fähigkeiten, Tools, Anweisungen und Richtlinien aus Konfigurationen bezieht, ist kein Abkürzungsweg – es handelt sich dabei um eine ausgereifte architektonische Entscheidung, die noch effektiver wird, wenn diese Konfigurationen in einem externen Katalog gespeichert sind.

Dies ermöglicht es Ingenieurteams, schnell voranzukommen, ohne die Kontrolle zu verlieren, und gibt Fachleuten aus den jeweiligen Bereichen eine echte Rolle bei der Gestaltung des Systemverhaltens. Zudem passt es zur zugrundeliegenden Realität der meisten Unternehmens-AI-Portfolios, in denen viele Anwendungsfälle auf den ersten Blick unterschiedlich erscheinen, aber strukturell ähnlich sind.