Agent-Tools
Agent-Tools: bestehende Aktionen Ihrer Systeme sicher für KI-Agenten nutzbar machen.
Ihre Systeme können längst Aufträge anlegen, Sperren prüfen und Accounts aktualisieren. Nexus macht diese vorhandenen Aktionen für KI-Agenten nutzbar, mit festen Parametern, Version und Freigabe. Einmal angebunden, verwenden mehrere Agenten und Prozesse dasselbe Tool.
- SAP
- Salesforce
Kein SAP gleicht dem anderen.
In fast jedem Unternehmen steckt viel Arbeit in SAP und Salesforce: Custom Objects und Felder, Flows, Apex-Klassen, SAP-Customizing, eigene OData-Services und APIs. Genau dort liegt die Logik, nach der Ihre Aufträge, Preise und Sperren funktionieren.
Ein Agent, der nur Standardobjekte kennt, scheitert am ersten echten Auftrag. Nexus setzt deshalb auf Ihrer Landschaft auf, wie sie heute ist.
Vom Systembaustein zum kontrollierten Tool.
Metadaten lesen
Nexus liest Objekte, Felder, Flows und Apex Actions sowie OData Entity Sets, Actions, Function Imports und Custom APIs.
Tool vorschlagen
Daraus entstehen Tool-Entwürfe mit Name, Beschreibung und Parametern, z. B. erp.salesOrder.create.
Eingrenzen
Ihr Team legt fest, welche Felder und Werte erlaubt sind, ob das Tool liest oder schreibt und welche Policy greift.
Testen und freigeben
Das Tool wird gegen Ihre Testsysteme geprüft und erst nach Freigabe in PROD verfügbar.
Low-Code für den Standard, Code für den Rest.
Beide Wege enden im selben Tool-Modell, mit derselben Freigabe und demselben Audit Trail.
- Low-Code
Aus Metadaten erzeugen
Für Objekte, Flows und Services, die Ihre Systeme schon beschreiben. Nexus schlägt das Tool vor, Ihr Team grenzt Felder und Werte ein.
- Pro-Code
Eigene Tools entwickeln
Für Logik, die sich nicht aus Metadaten ableiten lässt: mehrere Aufrufe in einem Schritt, Umrechnungen, eigene Prüfungen. Grundlage sind OpenAPI, Code oder ein MCP-Server.
Was Nexus aus Ihren Systemen liest.
Die Tool-Namen sind Beispiele. Benennung und Zuschnitt richten sich nach Ihrem Prozess.
Salesforce
- Standard- und Custom Objects
- Felder
- Flows
- Apex Actions
- crm.opportunity.read
- crm.account.update
SAP
- OData Entity Sets
- Actions
- Function Imports
- Custom APIs
- erp.salesOrder.create
- erp.customer.check
- delivery_block.search
Weitere Systeme
- REST-APIs
- OpenAPI-Spezifikationen
- MCP-Server
- Webhooks
Ein Prozessmodell, unterschiedliche Systemlandschaften.
Process Packs arbeiten mit fachlichen Fähigkeiten statt mit festen APIs. Bei jedem Kunden werden diese Fähigkeiten im Projekt auf dessen Systeme abgebildet. Der Ablauf bleibt gleich, die Anbindung darunter ändert sich.
| Fachliche Fähigkeit | Landschaft A (Beispiel) | Landschaft B (Beispiel) |
|---|---|---|
| crm.customer.read | Salesforce Account mit Custom Object für Kundenklassen | Salesforce Account, ergänzt um Daten aus dem SAP-Geschäftspartner |
| erp.customer.check | Kredit- und Sperrprüfung in S/4HANA über Standard-OData | Eigener API-Service mit kundenspezifischer Sperrlogik |
| erp.salesOrder.create | S/4HANA-Kundenauftrag über Standard-OData-Service | SAP ECC über Integration Suite |
| crm.opportunity.update | Opportunity-Update, danach Salesforce Flow | Opportunity-Update über Apex Action |
Beispiel zur Veranschaulichung, keine Kundendaten.
Jedes Tool steht unter Kontrolle.
Versioniert
Änderungen am Tool ergeben eine neue Version. Agenten nutzen die Version, mit der sie getestet wurden.
Freigegeben
Ein Tool ist erst nach Freigabe in PROD nutzbar. Wer freigibt, legen Sie fest.
Policy-gebunden
Je Tool und Agent ist geregelt, ob gelesen, geschrieben oder nur mit Freigabe gehandelt wird.
Wiederverwendbar
Ein Tool dient mehreren Agenten und Process Packs. Änderungen und Audit laufen an einer Stelle zusammen.
Wo die Grenzen liegen.
Ein Tool kann nur, was die Schnittstelle darunter erlaubt. Gibt es für einen Schritt keinen Service und keine API, entsteht kein Tool, bis eine Schnittstelle geschaffen ist. Vorschläge aus Metadaten sind ein Startpunkt, kein fertiges Ergebnis: Zuschnitt, Werte und Tests gehören zur Projektarbeit.
Was Sie einplanen sollten
- Technische Benutzer mit eng zugeschnittenen Rechten in jedem Zielsystem
- Schreibzugriffe nur nach Test und ausdrücklicher Freigabe
- Kundenspezifisches Mapping je Systemlandschaft
- RPA nur als Ausnahme, wenn keine Schnittstelle möglich ist
Häufige Fragen zu Agent-Tools
Müssen wir unser SAP-Customizing oder unsere Salesforce-Org umbauen?
In der Regel nicht. Nexus nutzt Ihre bestehenden Objekte, Flows, Services und APIs. Fehlt für einen Schritt eine Schnittstelle, klären wir, ob ein vorhandener Service reicht oder ein neuer nötig ist.
Bekommt der Agent Vollzugriff auf das System?
Nein. Ein Agent sieht nur die Tools, die ihm zugewiesen sind, mit genau festgelegten Parametern. Zugangsdaten liegen nie im Kontext des KI-Modells.
Was passiert, wenn sich eine Schnittstelle ändert?
Dann wird das betroffene Tool angepasst, als neue Version getestet und freigegeben. Agenten arbeiten bis dahin mit der Version, mit der sie getestet wurden.
Funktioniert das auch mit SAP ECC?
Ja, sofern die nötigen Funktionen über Services, RFC-Bausteine oder Ihre Integrationsplattform erreichbar sind. Das prüfen wir für Ihren konkreten Prozess.
Weiterlesen
Integrationen
Was tief integriert ist und was per API, Events oder MCP dazukommt.
Freigaben & Regeln
Wann ein Tool ohne Freigabe genutzt werden darf.
Process Packs
Fachliche Lösungen, die auf Ihre Tools abgebildet werden.
- Insights
Wie KI-Agenten sicher in SAP schreiben
Identität, Policies, Freigaben und Idempotenz, wenn Agenten Aufträge in SAP anlegen.
Starten Sie mit einem Prozess.
30 Minuten · kostenlos · mit einem Senior Architect. Sie erhalten eine mündliche Ersteinschätzung und konkrete nächste Schritte.