SOLUTIONS.agent
KI-Agenten für Unternehmen
Aufträge in Worten beschreiben, an einen Auslöser hängen und im Hintergrund arbeiten lassen. Mit den Rechten, die Sie vergeben, und einem Protokoll jedes Schritts.
Jeden Montag fasst jemand die Neuerungen der Woche zusammen. Nach jedem Release prüft jemand, ob die Dokumentation noch stimmt. Nach jedem fehlgeschlagenen Import sucht jemand die Ursache und schreibt ein Ticket. Ein KI-Assistent könnte das alles, wenn ihn nur jemand fragen würde.
Ein Assistent wartet, ein Agent arbeitet
Die meisten KI-Werkzeuge in Unternehmen sind Gesprächspartner. Sie antworten gut, aber nur, solange ein Mensch vor dem Bildschirm sitzt und die richtige Frage stellt. Die wiederkehrende Arbeit, das Prüfen, Zusammenfassen und Nachfassen, bleibt damit beim Menschen liegen.
Wer diese Arbeit automatisieren will, landet meist bei einem Skript. Es läuft nachts auf irgendeinem Server, benutzt einen Sammelzugang mit weitreichenden Rechten, und was es getan hat, steht bestenfalls in einer Logdatei. Ändert sich der Ablauf, muss jemand den Code anpassen.
Mit SOLUTIONS.agent beschreiben Sie die Aufgabe in Worten und hängen sie an einen Auslöser. Der Agent arbeitet dann im Hintergrund, mit den Werkzeugen Ihrer Anwendungen, in festen Grenzen und so, dass jeder Schritt nachzulesen ist.
Was einen Auftrag ausmacht
Ein Agent ist bei uns ein Auftrag. Er besteht aus wenigen Angaben, und alle sind fachlich.
Anweisung
Was der Agent tun soll, in ganzen Sätzen. So, wie Sie es einer neuen Kollegin erklären würden.
Lernziel
Optional: was er sich über die Läufe hinweg merken soll, etwa welche Änderungen nie eine Anpassung der Dokumentation brauchen.
Sprachmodell
Je Auftrag wählbar. Ein kleines, schnelles Modell für Routine, ein großes für Aufgaben, die mehr Abwägung verlangen.
Verbindungen
Die MCP-Verbindungen, über die er in Ihren Anwendungen liest und handelt. Je Verbindung lässt sich festlegen, welche Werkzeuge er überhaupt angeboten bekommt.
Auslöser
Wann er startet: nach Zeitplan, wenn sich ein Datensatz ändert, oder auf ein benanntes Ereignis aus einer Anwendung.
Grenzen
Budget, Werkzeugaufrufe und Zeit je Lauf, dazu eine Höchstzahl an Läufen je Stunde.
Wann ein Agent startet
Ein Agent wird nicht aufgerufen, er wird ausgelöst. Welche Anwendung was meldet, richten Sie einmal ein. Danach sucht sich SOLUTIONS.agent zu jeder Meldung die passenden Aufträge selbst.
Zeitplan
Zu festen Zeiten, beschrieben als Cron-Ausdruck mit Zeitzone. Etwa jeden Montag um sieben Uhr, für eine Zusammenfassung der vergangenen Woche.
regelmäßig
Datensatz
Wenn in einer Anwendung ein Datensatz angelegt, geändert oder gelöscht wird. Eine Bedingung grenzt ein, welche Datensätze zählen, und die Anwendung prüft sie, bevor sie überhaupt etwas meldet.
anlegen, ändern, löschen
Ereignis
Ein benanntes Ereignis, das eine Anwendung meldet: ein Knopf in der Oberfläche, ein Knoten im Datenfluss von SOLUTIONS.transformer oder ein gemergter Pull Request.
auf Zuruf
Wer einen Lauf ausgelöst hat, steht im Protokoll, und der Agent sieht es in seinen Eingangsdaten. Auf seine Rechte hat das keinen Einfluss. Drückt eine Administratorin den Knopf, arbeitet der Agent trotzdem nur mit dem Zugang, den sein Auftrag mitbringt.
Zwei Beispiele aus unserem eigenen Betrieb
Dokumentation nach dem Merge
Wird in Forge, unserer Projektverwaltung, ein Pull Request gemergt, prüft ein Agent, ob das Entwickler-Wiki dazu noch stimmt. Findet er eine Lücke, legt er einen Änderungsvorschlag an. Ob der übernommen wird, entscheidet ein Mensch.
Fehlgeschlagene Importe
Im Datenfluss von SOLUTIONS.transformer reicht ein Agentenknoten Datensätze an einen Agenten weiter. Der sieht sich etwa fehlgeschlagene Importe an, sucht nach dem gemeinsamen Muster und öffnet ein Ticket mit seiner Einschätzung.
Mit welchen Rechten ein Agent arbeitet
Das ist die wichtigste Frage an jeden Agenten, und die Antwort ist bei uns einfach: Seine Rechte kommen immer aus der Anmeldung seiner Verbindungen, nie von dem, der ihn auslöst.
Agenten von Benutzern laufen mit dem Zugang ihres Besitzers. Er gibt ihn einmalig frei, indem er sich über SOLUTIONS.user anmeldet. Der Agent bekommt damit kein Recht dazu. Was der Besitzer in einer Anwendung nicht sehen oder ändern darf, sieht und ändert auch sein Agent nicht.
Agenten für den Betrieb, die keinem einzelnen Menschen gehören, laufen mit einem technischen Benutzer. Den legen Administratoren an und geben ihm nur die Rechte, die der Auftrag braucht. Der Agent für das Wiki darf Vorschläge anlegen, das Wiki selbst aber nicht ändern.
Ob ein Agent etwas direkt ändert oder nur vorschlägt, entscheidet damit die Anwendung über ihre Rechteprüfung, und zwar dieselbe, die auch für Menschen gilt.
heute üblich
Automatisierung per Skript
- läuft mit einem Sammelzugang, der mehr sieht als jeder Mensch
- Zugangsdaten liegen in einer Datei auf dem Server
- was passiert ist, steht bestenfalls in einer Logdatei
- jede Änderung am Ablauf ist eine Änderung am Code
- Kosten und Laufzeit fallen erst auf, wenn es zu spät ist
mit SOLUTIONS.agent
Agent mit Auftrag
- läuft mit dem Zugang seines Besitzers oder eines eng gefassten technischen Benutzers
- Zugangsdaten liegen verschlüsselt und erscheinen in keinem Protokoll
- jeder Schritt ist gespeichert und live mitzulesen
- der Ablauf ist eine Anweisung in Worten
- feste Grenzen je Lauf, je Stunde und je Monat
Wer was einrichtet und wer was sieht
SOLUTIONS.agent kennt zwei Rollen. Administratoren pflegen die Grundlagen: die Verbindungen zu den Anwendungen, den Zugang zum Sprachmodell, die Budgets und die Freigaben, welche Rolle welche Verbindung an einen Auftrag hängen darf. Sie legen auch die Höchstwerte fest, über die kein Auftrag hinausgeht.
Benutzer richten ihre Agenten mit ihrem eigenen Sprachmodell ein, etwa mit Claude Desktop über SOLUTIONS.mcp. In der Oberfläche sehen sie nur ihre eigenen Aufträge und deren Läufe, und zwar lesend. Was ein Lauf gekostet hat, sehen nur Administratoren.
Zugangsdaten der Verbindungen werden verschlüsselt gespeichert und nur beim Aufbau der Verbindung entschlüsselt. In der Oberfläche lassen sie sich setzen, aber nicht wieder auslesen, und bevor ein Schritt gespeichert wird, ersetzt der Dienst sie durch Sternchen. Das gleiche Prinzip kennen Sie von SOLUTIONS.vault.
Erst probieren, dann laufen lassen
Jeder Auftrag hat einen Probelauf. Er arbeitet mit echten Daten: Lesende Werkzeuge laufen wirklich, damit der Agent dieselben Informationen sieht wie später im Betrieb. Jeder schreibende Aufruf wird dagegen abgefangen. Im Protokoll steht dann mit allen Eingaben, was der Agent angelegt oder geändert hätte, und das Modell bekommt eine Antwort, mit der es weiterarbeiten kann.
So sehen Sie vor dem ersten echten Lauf, ob die Anweisung verstanden wurde, welche Daten der Agent liest und was er daraus machen würde. Sein Gedächtnis verändert ein Probelauf nicht.
Jeder Lauf ist nachvollziehbar
Ein Lauf ist bei uns ein Protokoll. Darin steht, wann und warum er gestartet ist, welche Nachrichten das Modell geschrieben hat, welche Werkzeuge es mit welchen Eingaben aufgerufen hat und was zurückkam. Dazu Dauer, Verbrauch und das Ergebnis.
Die Lauf-Ansicht zeigt das Schritt für Schritt, auch während der Agent noch arbeitet. Endet ein Lauf mit einem Fehler oder bricht er an einer Grenze ab, geht eine Mail an die Personen, die am Auftrag hinterlegt sind. Verschickt wird sie über SOLUTIONS.email, wie jede andere Mail aus Ihren Anwendungen.
Grenzen, die ein Lauf einhält
Budget je Lauf
Ist der Betrag erreicht, bricht der Lauf ab.
je Lauf
Werkzeugaufrufe
Eine Höchstzahl an Aufrufen, damit sich ein Agent nicht im Kreis dreht.
je Lauf
Zeitlimit
Was länger dauert als vorgesehen, wird beendet.
je Lauf
Läufe je Stunde
Schützt vor Ketten, in denen Agenten sich gegenseitig immer wieder auslösen. Änderungen eines Agenten lösen seinen eigenen Auftrag ohnehin nicht erneut aus.
je Auftrag
Monatsbudget
Je Zugang zum Sprachmodell. Ab einer Schwelle kommt eine Warnung per Mail, ist das Budget aufgebraucht, starten keine neuen Läufe.
je Provider
Ein Gedächtnis, das Sie lesen können
Ein Agent, der bei jedem Lauf von vorn anfängt, durchsucht jedes Mal alles neu. Deshalb führt SOLUTIONS.agent je Anwendung ein Gedächtnis, das wir Brain nennen. Es ist aufgebaut wie ein gut geführtes Notizbuch: ein Überblick über die Anwendung mit ihren Themen, darunter Notizen zu einzelnen Datenmodellen, und alle Notizen sind untereinander verlinkt.
Darin stehen nicht nur Zusammenhänge, sondern auch Erfahrungen. Etwa, dass reine Updates von Abhängigkeiten nie eine Änderung der Dokumentation brauchen, oder welches Feld bei einem Vorschlag Pflicht ist. Was ein Auftrag lernen soll, legt sein Lernziel fest. Alle Aufträge derselben Anwendung teilen sich deren Brain, und kein Agent liest das Brain einer anderen Anwendung.
Jede Änderung ist eine eigene Version mit Verweis auf den Lauf, der sie geschrieben hat. Administratoren sehen damit, was der Agent gelernt hat und aus welchem Anlass. Sie können eine Notiz korrigieren oder eine frühere Version wiederherstellen. Weil darin auch Betriebswissen stehen kann, bleibt das Brain den Administratoren vorbehalten.
Eine Instanz je Installation
SOLUTIONS.agent ist ein eigener Dienst der SOLUTIONS Familie und läuft je Installation einmal, neben Ihren Anwendungen. Jede Instanz hat ihren eigenen Zugang zum Sprachmodell, ihr eigenes Budget und ihre eigenen Verbindungen. Angebunden werden die Anwendungen über das offene Model Context Protocol, also dieselbe Schnittstelle, die auch SOLUTIONS.mcp für KI-Assistenten bereitstellt.
Wo die Grenzen liegen
Ein Agent ist so gut wie seine Anweisung und die Werkzeuge, die er bekommt. Ein paar Dinge gehören deshalb vorher gesagt.
Ein Lauf ist kein Gespräch. Während der Agent arbeitet, stellt er keine Rückfragen. Ein Lauf endet erfolgreich, mit einem Fehler oder an einer Grenze, und was unklar war, steht danach im Protokoll.
Das Protokoll enthält, was der Agent gelesen hat. Liefert eine angebundene Anwendung sensible Daten zurück, stehen sie im Protokoll wie jedes andere Ergebnis. Dagegen hilft vor allem, die Rechte des Zugangs eng zu halten.
Agenten kosten im Betrieb. Jeder Lauf verbraucht Leistung des Sprachmodells, abgerechnet über Ihren eigenen Zugang. Deshalb sind Grenzen Pflicht und nicht Zierde, und deshalb empfehlen wir für Routineaufgaben das kleinere Modell.
Weiterlesen
Häufige Fragen
Muss ich für einen Agenten programmieren?
Nein. Ein Auftrag ist eine Anweisung in Worten, dazu ein Auslöser, ein Sprachmodell, die Verbindungen zu den Anwendungen und seine Grenzen. Eingerichtet wird er in der Oberfläche oder über Ihr eigenes Sprachmodell, etwa Claude Desktop über SOLUTIONS.mcp.
Darf ein Agent mehr als der Mensch, der ihn eingerichtet hat?
Nein. Ein Agent, den ein Benutzer anlegt, läuft mit dem Zugang dieses Benutzers, den er einmalig über die Anmeldung an der Benutzerverwaltung freigibt. Was er selbst nicht darf, darf sein Agent auch nicht. Agenten für den Betrieb laufen mit einem technischen Benutzer, den Administratoren mit eng gefassten Rechten anlegen.
Kann ich einen Auftrag testen, ohne dass er etwas verändert?
Ja, mit dem Probelauf. Er liest echte Daten, fängt aber jeden schreibenden Aufruf ab und protokolliert, was der Agent getan hätte. Werkzeuge, deren Art unbekannt ist, gelten dabei als schreibend.
Was verhindert, dass ein Agent unbemerkt Geld ausgibt?
Jeder Lauf hat ein Budget, eine Höchstzahl an Werkzeugaufrufen und ein Zeitlimit. Dazu kommen eine Höchstzahl an Läufen je Stunde und ein Monatsbudget je Provider mit Warnung per Mail. Wird eine Grenze erreicht, bricht der Lauf ab und der Grund steht im Protokoll.
Was merkt sich der Agent, und wer sieht das?
Der Agent führt je Anwendung ein Gedächtnis aus verlinkten Notizen: Themen, Zusammenhänge und Erfahrungen aus früheren Läufen. Jede Änderung ist eine Version mit Verweis auf den Lauf. Administratoren lesen und korrigieren es und können eine frühere Version wiederherstellen.
Laufen die Agenten bei Ihnen oder bei uns?
Je Installation gibt es eine eigene Instanz mit eigenem Zugang zum Sprachmodell und eigenem Budget. Sie läuft dort, wo auch Ihre übrigen Anwendungen laufen.
Sprechen Sie mit uns.