Die Demo endet immer bei der Erkenntnis. Der agent liest Bestelldaten, identifiziert eine Anomalie und liefert eine Empfehlung. Der Raum nickt. Dann fragt jemand: “Und dann? Aktualisiert er den Datensatz?” Der Raum wird still. Das ist der Moment, in dem das eigentliche Projekt beginnt.
Write-back ist der Punkt, an dem Enterprise-Agent-Projekte scheitern oder gelingen. Es ist der Punkt, an dem die architektonischen Entscheidungen, die in der Prototyp-Phase übersprungen wurden, unvermeidbar werden.
Das Write-Back-Problem, das niemand in der Demo löst
Agent-Demos sind um die sichere Hälfte des Loops aufgebaut: ERP-Daten lesen, Erkenntnis generieren, in einem lesbaren Format zusammenfassen. Das Modell leistet das gut. Die Leseoperationen sind idempotent. Fehler sind sichtbar und korrigierbar. Niemandes Gehaltsabrechnung ist betroffen.
Die Produktion ist anders. Der agent muss zurückschreiben: einen Bestellstatus aktualisieren, ein Ticket schließen, eine Transaktion neu klassifizieren, einen Genehmigungsworkflow auslösen, einen Lieferantendatensatz anlegen. Diese Operationen sind nicht idempotent. Falsche Entitätsauflösung erstellt Duplikatdatensätze. Unvollständige Transaktionen hinterlassen das ERP in einem inkonsistenten Zustand. Doppelte Schreibvorgänge korrumpieren Daten, von denen Downstream-Systeme abhängen. Und im Gegensatz zu einer halluzinierten RAG-Antwort, die ein Benutzer verwerfen kann, erfordert ein schlechter ERP-Schreibvorgang, dass ein Mensch ihn findet, versteht und manuell korrigiert.
Drei Fehler-Modi machen den Großteil der Write-Back-Vorfälle aus:
Falsche Entitätsauflösung. Der agent erhält “Bestellung für Carlos Lima aktualisieren” und findet zwei Datensätze, die dem Namen entsprechen, einer für einen Mitarbeiter und einer für einen externen Kontakt. Ohne einen Disambiguierungsschritt wählt er einen aus. Er wählt 40 % der Zeit den falschen aus, was 40 % der Zeit zu oft ist, wenn die Operation irreversibel ist.
Unvollständige Transaktion. Der ERP-Workflow erfordert drei Schritte: Datensatz anlegen, Dokument anhängen, Genehmigungsrouting auslösen. Der agent schließt Schritte eins und zwei ab. Ein API-Timeout unterbricht Schritt drei. Das ERP befindet sich nun in einem inkonsistenten Zustand: Ein Datensatz existiert, ein Dokument ist angehängt, aber der Genehmigungsworkflow wurde nie ausgelöst. Die nächste Person, die sich den Datensatz ansieht, kann nicht erkennen, ob der Prozess abgeschlossen oder abgebrochen wurde.
Kein Rollback-Plan. Der agent initiiert einen mehrstufigen Workflow. Schritt vier schlägt fehl. Es gibt kein definiertes Rollback-Verfahren für Schritte eins bis drei. Die manuelle Korrektur dauert vier Stunden. Das Agent-Projekt wird bis zur Governance-Überprüfung pausiert.
Das sind keine LLM-Probleme. Es sind Software-Architektur-Probleme. Sie haben Software-Architektur-Lösungen.
Entitätsauflösung vor Write-Back
Die Kardinalregel des ERP-Write-Backs: Nie in einen Datensatz mit einem Namens-String schreiben. Immer zuerst zu einem kanonischen Identifikator auflösen.
Entitätsauflösung ist eine dedizierte Lookup-Schicht zwischen dem agent und dem ERP. Sie empfängt Natural-Language-Input, fragt das Identitätsmodell des ERPs ab, gibt den kanonischen Identifikator für den Zieldatensatz zurück und bietet einen Konfidenz-Score und Disambiguierungsinformationen.
Die Architektur: Der agent produziert ein strukturiertes Intent-Objekt (“Bestellung für Lieferant X aktualisieren, Status auf genehmigt ändern, Betrag Y”). Die Entitätsauflösungsschicht empfängt das Objekt, fragt das ERP nach Datensätzen ab, die Lieferant X entsprechen, und gibt null oder mehr Kandidaten mit Konfidenz-Scores zurück. Wenn ein Kandidat den Konfidenz-Schwellenwert überschreitet, wird der Identifikator an die Write-Back-Schicht übergeben. Wenn kein Kandidat den Schwellenwert überschreitet, stoppt der agent und stellt die Ambiguität für die menschliche Auflösung dar.
Der Konfidenz-Schwellenwert ist nicht willkürlich. Er wird gegen Ihre spezifische ERP-Datenqualität kalibriert. ERPs mit sauberen Stammdaten tolerieren einen höheren Schwellenwert. ERPs mit jahrelangen Legacy-Daten, Duplikatdatensätzen und inkonsistenten Benennungskonventionen erfordern einen niedrigeren Schwellenwert und häufigere menschliche Auflösungs-Gates. Die Entitätsauflösungsschicht offenbart Ihre ERP-Datenqualität, bevor sie den Produktionsbetrieb betrifft.
Für TOTVS Protheus, SAP oder Oracle: Entitätsauflösung muss das eigene Identitätsmodell des ERPs respektieren. Protheus verwendet sein eigenes Entitätsidentifikator-Schema. Das Aufzwingen eines externen Identitätsmodells darüber einzuführen führt eine Mapping-Schicht ein, die zur Wartungslast wird. Die eigenen Entitätsidentifikatoren des ERPs über seine eigene API abfragen.
Die Human-in-the-Loop-Architektur für ERP-Aktionen
Jede ERP-Aktion, die ein agent ausführen kann, sollte vor dem Lauf des agent klassifiziert werden, nicht nachdem er gescheitert ist.
Das Klassifizierungs-Framework:
| Aktionstyp | Reversibilität | Genehmigungsanforderung |
|---|---|---|
| Lesen | N/A | Keine |
| Risikoarmes Schreiben | Reversibel, geringer Geschäftsimpact | Protokollieren und ausführen |
| Hochriskantes Schreiben | Reversibel, signifikanter Geschäftsimpact | Menschliche Genehmigung vor Ausführung |
| Irreversibel | Kann nicht rückgängig gemacht werden | Doppelte Genehmigung mit vollständigem Audit-Log |
Diese Klassifizierung ist eine Software-Konfiguration, keine Modellanweisung. Der agent entscheidet nicht zur Laufzeit, in welche Kategorie eine Aktion fällt. Die Kategorien werden zum Designzeitpunkt definiert, Aktionstypen zugeordnet und durch die Orchestrierungsschicht durchgesetzt.
Genehmigungskanäle, die in der Praxis funktionieren: eine Slack-Nachricht mit Genehmigen- und Ablehnen-Buttons, eine E-Mail mit einem signierten Genehmigungstoken oder eine interne Portal-Warteschlange mit Benachrichtigung. Die Genehmigungsschnittstelle sollte dem Genehmiger genau zeigen, was der agent zu tun beabsichtigt, in einfacher Sprache, mit dem Geschäftskontext, der die Aktion motivierte. “Genehmigen Sie das Schließen von PO-2891 (Lieferant: ABC Manufacturing, Betrag: CHF 45.000, Grund: Lieferung vom Lagersystem am 2026-04-12 bestätigt)” ist genehmigungsfähig. “Agent schlägt Schreiboperation auf ERP-Datensatz ID 2891 vor” ist es nicht.
Ein Designprinzip aus dem 12-Factor-Agents-Framework: Menschliche Genehmigung ist eine System-Komponente, kein Ausnahme-Pfad. Den Genehmigungsworkflow aufbauen, bevor die erste agent Aktion Produktionsdaten berührt. Wenn der Genehmigungsworkflow nicht existiert, wenn der agent eine hochriskante Aktion erreicht, wird er entweder die Genehmigung überspringen (was den Vorfall produziert) oder ohne Eskalationspfad stoppen (was das Support-Ticket produziert).
ERP-Transaktionen sind oft nicht-atomar. Wenn ein agent einen mehrstufigen Workflow initiiert, muss der Rollback-Plan definiert und vor dem ersten Schritt getestet werden. Nicht “Wir werden Rollback herausfinden, wenn etwas schiefläuft.” Definierte Rollback-Verfahren, auf jeden Aktionstyp abgebildet, gegen eine Staging-Umgebung getestet. Das erste Mal, dass das Rollback-Verfahren benötigt wird, ist nicht der richtige Zeitpunkt, es zu schreiben.
Das MCP-Server-Muster für ERP-Integration
ERP-Fähigkeiten als MCP-Server zu exponieren verwandelt jede Fähigkeit in eine governte Schnittstelle: typisiertes Input-Schema, authentifizierter Zugang, Rate-Limiting und ein Audit-Log für jeden Aufruf.
Das Muster: Jede ERP-Fähigkeit, “Bestellung anlegen”, “Lieferantendatensatz aktualisieren”, “Ticket schließen”, wird zu einem separaten MCP-Tool mit einem definierten Input-Schema, definierten Berechtigungen und definiertem Audit-Verhalten. Agents greifen auf ERP-Fähigkeiten durch diese Tools zu. Direkte Datenbankaufrufe, direkte REST-API-Aufrufe ohne Governance und Ad-hoc-Integrationen, die die Berechtigungsschicht umgehen, sind nicht gestattet.
Vorteile auf der Governance-Ebene: Berechtigungen für ERP-Schreiboperationen werden einmal auf der MCP-Schicht konfiguriert und von jedem agent geerbt, der diese Tools nutzt. Neue Fähigkeiten werden dem MCP-Server hinzugefügt und werden allen autorisierten agents gleichzeitig verfügbar. Veraltete Fähigkeiten werden einmal entfernt und verschwinden überall.
Für TOTVS Protheus speziell: Kein offizieller MCP-Server von TOTVS existiert zum Zeitpunkt der jüngsten Recherche [aktuellen Status vor dem Deployment verifizieren]. Benutzerdefinierte Implementierung mit Protheus-REST-APIs ist erforderlich. Das ist Engineering-Arbeit, keine Konfigurationsaufgabe.
Eine Sicherheitsüberlegung, die nicht verschoben werden kann: Eine 2026 entdeckte RCE-Schwachstellenklasse im MCP-Protokolldesign bestätigte, dass MCP-Server Software sind und dieselben Sicherheitspraktiken erfordern wie jede andere Produktionskomponente. Whitelisting, aktuelle Patches und Audit-Logging auf Gateway-Ebene. Ein MCP-Server, der eine Verbindung zu einem Produktions-ERP herstellt, ist eine hochwertige Angriffsfläche.
Der stufenweise Rollout, der Desaster verhindert
Kein Enterprise-Agent-Projekt sollte in einem einzigen Schritt von einem Pilot zu vollständiger Write-Back-Autonomie gehen. Der stufenweise Rollout existiert, weil jede Stufe Probleme aufdeckt, bevor die Konsequenzen produktionsskaliert sind.
Phase 1: Nur-Lese-Betrieb. Der agent liest ERP-Daten, gibt Empfehlungen aus und stoppt. Keine Write-Fähigkeit. Vier bis acht Wochen laufen lassen. Entitätsauflösungsgenauigkeit validieren, Datenqualitätsprobleme in Stammdaten aufdecken, Empfehlungen als richtungsweisend korrekt bestätigen. Die Datenqualitätsbefunde aus Phase 1 ordnen typischerweise die Arbeit der Phasen 2 bis 4 neu.
Phase 2: Überwachtes Schreiben. Der agent schlägt Aktionen vor. Ein Mensch überprüft und genehmigt jede, bevor sie ausgeführt wird. Laufen bis die Genehmigungsrate sich stabilisiert, typischerweise über 95 Prozent ohne Modifikation. Abgelehnte Vorschläge sind diagnostisches Material zur Verbesserung der Entitätsauflösung.
Phase 3: Autonomes Schreiben mit Monitoring. Vorab genehmigte Aktionstypen werden ohne menschliche Überprüfung ausgeführt. Alle Ausführungen protokolliert. Anomalieerkennung kennzeichnet Abweichungen für menschliche Überprüfung.
Phase 4: Hochvolumen-Automatisierung. Nur für Aktionstypen mit bewährter Genauigkeit und geringem Reversibilitätsrisiko über die Phasen 1 bis 3.
Eine Phase überspringen, auf den Datenkorrumpierungs-Vorfall zusteuern, der das Programm für zwei Quartale pausiert.
Das Geschäftsargument, das richtig zu machen
ERP-Anbieter liefern ihre eigenen AI-Schichten: TOTVS LYNN (im Februar 2026 angekündigt), SAP Joule, Oracles integrierte Assistenten. Das sind generische Lösungen. Sie sind nicht um Ihre spezifischen Prozesse, Ihre Datenqualitätseigenschaften oder Ihre regulatorischen Einschränkungen herum gebaut.
Benutzerdefinierte agents mit tiefem Prozesswissen und einer governten Integrationsschicht übertreffen Anbieter-Copiloten für spezialisierte Workflows. Die Integrationsinfrastruktur, der Entitätsauflösungs-Service und der Aktions-Audit-Trail sind für jedes nachfolgende Agent-Projekt wiederverwendbar. Das zweite Projekt kostet einen Bruchteil des ersten.
Die Teams, die bei der ERP-Agent-Integration am schnellsten voranschreiten, sind diejenigen, die früh genug in Governance investiert haben, um eine stabile Grundlage zu haben, wenn das Unternehmen Skalierung fordert.
Für Enterprise-Teams, die agent Integration mit Kerngeschäftssystemen bewerten, kartiert der AI Opportunity Sprint die Integrationsarchitektur, bevor Code geschrieben wird.