„KI-Agenten automatisieren dein Business." Den Satz liest du gerade überall. In LinkedIn-Posts, in Sales-Decks, in Analyst-Reports. Meistens verpackt in Demos die beeindruckend aussehen und in Produktion selten so funktionieren wie auf der Folie.
Ich baue seit 2011 E-Commerce-Projekte und seit 2025 haben wir die ersten KI-Agenten produktiv bei Kunden laufen. Kein Pilot, kein Proof-of-Concept mit Exit-Roadmap. Echte Systeme, die Bestellungen anfassen, Tickets bearbeiten, Daten anreichern. Die Erfahrung daraus ist klar: Agenten tragen heute, aber nur in bestimmten Szenarien. Und der Unterschied zwischen „das läuft" und „das ist eine teure Spielerei" liegt nicht im LLM, sondern in der Engineering-Arbeit drumherum.
Dieser Artikel ist für Geschäftsführer und CTOs im Mittelstand die gerade entscheiden müssen, wo sie KI-Agenten einsetzen, wann sie selbst bauen und wann sie besser abwarten. Kein Ultimate Guide. Keine 10-Punkte-Liste mit Stockfotos. Was heute funktioniert, was scheitert und was du vorher klären musst.
Inhalt
- Was ist ein KI-Agent, technisch betrachtet
- Wo Agenten in Unternehmen heute wirklich tragen
- Grenzen und Risiken, die niemand auf Folie 3 zeigt
- Make-or-Buy: selbst bauen, kaufen oder pilotieren?
- Wie du in 90 Tagen ehrlich startest
- FAQ zu KI-Agenten in Unternehmen
- Fazit: Agenten sind kein Produkt, sie sind eine Engineering-Disziplin
Was ist ein KI-Agent, technisch betrachtet
Ein KI-Agent ist nicht „eine intelligente Version von ChatGPT". Ein Agent ist ein System aus vier Komponenten die zusammenarbeiten:
- LLM als Entscheidungs-Kern (Claude, GPT, Llama, egal)
- Tool-Use, also die Fähigkeit APIs aufzurufen, in Datenbanken zu schreiben, Code auszuführen
- Memory, damit der Agent weiß was er in Schritt 3 gemacht hat wenn er in Schritt 7 ist
- Autonomie, also ein Loop der entscheidet ob das Ziel erreicht ist oder noch ein Schritt nötig ist
Das klingt trivial. Ist es nicht. Die Abgrenzung zu dem was vorher schon da war macht den Unterschied.
Ein Chatbot (auch ein guter, mit Claude oder GPT-4o dahinter) antwortet auf Fragen. Er hat keinen Loop. Du fragst, er antwortet, fertig. Wenn der Bot etwas „tut", hat meistens ein Entwickler einen Workflow vorgebaut den der Bot nur triggert. Das ist eine Schablone mit LLM-Deko.
RAG (Retrieval Augmented Generation) ist ein Chatbot der vor der Antwort noch in deiner Wissensdatenbank nachschlägt. Nützlich für Support-Assistenten, Handbücher, Produktkataloge. Aber er tut nichts. Er zitiert.
Klassische Automatisierung mit Zapier, Make oder n8n folgt festen If-This-Then-That-Regeln. Vorhersagbar, robust, aber stumm. Eine Änderung am Input-Format und der Flow kippt.
Ein Agent dagegen hat ein Ziel („bearbeite dieses Support-Ticket", „reichere diese 500 Produkte an", „erstelle ein Angebot für diese Anfrage") und entscheidet selbst welche Werkzeuge er in welcher Reihenfolge nutzt. Er kann mitten im Prozess feststellen „mir fehlt Info X", diese über einen Tool-Call nachladen, und weitermachen. Wenn er scheitert, merkt er es im besten Fall und eskaliert.
Damit das nicht in Halluzinationen kippt, braucht jeder ernsthafte Agent drei Dinge: ein enges Set an erlaubten Tools, Guardrails (was darf er nicht tun), und einen Kill-Switch. Ohne das ist ein Agent ein teurer Zufallsgenerator mit Schreibzugriff auf deine Datenbank.
Die Entwickler in deinem Team müssen diese Definition mitgehen können. Wenn ihr euch intern nicht einig seid ob euer „KI-Agent" ein Agent oder ein Chatbot mit Plugins ist, ist das der erste Punkt den ihr klärt, bevor ihr irgendwas einkauft.
Wo Agenten in Unternehmen heute wirklich tragen
Ich zeige dir vier Szenarien, die wir bei dasistweb und bei Kunden aus E-Commerce und B2B produktiv sehen. Keine Demo-Fantasie. Stand heute.
Datenklassifikation und Produktanreicherung (PIM-Kontext)
Ein Händler mit 80.000 Artikeln bekommt neue Lieferantenfeeds mit inkonsistenten Kategorien, leeren Attributen und mäßigen Beschreibungen. Früher waren das zwei Stellen im Produktmanagement, Excel, Wochen.
Ein Agent bekommt den Feed, vergleicht mit dem PIM-Schema, klassifiziert in die interne Kategoriestruktur, füllt fehlende Attribute aus den Produkttexten, schreibt SEO-taugliche Beschreibungen und legt Stichproben für das Team zur Freigabe hin. Jeden Tag, für jeden neuen Batch.
Was funktioniert: Kategorie-Mapping, Attribut-Extraktion aus Fließtext, Text-Normalisierung. Hybrid-Workflow mit Mensch-im-Loop für Stichproben.
Was nicht funktioniert: bei schlechter Datengrundlage halluziniert auch der beste Agent. Wenn dein Lieferanten-Feed 40% Müll ist, schiebst du diesen Müll nur schneller ins PIM.
Was du vorab lösen musst: sauberes PIM-Schema, Freigabe-Workflow für Stichproben, Versionierung der Prompts. Und: wer bekommt Bescheid wenn der Agent sich zu unsicher ist?
Customer-Service First-Level mit echter Eskalation
Nicht der klassische „Chatbot" den jeder auf seiner Website hat. Ein Agent, der in deinem Ticketsystem sitzt, das Ticket liest, in der Bestellhistorie nachschaut, im PIM Produktinfos zieht, in der Wissensdatenbank Policies prüft und dann entweder direkt antwortet, den Status ändert, ein Retoure-Label anstößt oder an den richtigen Menschen eskaliert.
Was funktioniert: Standard-Anfragen zu Versand, Rechnungen, Retouren, Produktinfos. In stabilen Setups fliegen 40 bis 60% der Level-1-Tickets durch ohne dass ein Mensch sie anfasst. Die Zahl schwankt je nach Branche und Ticket-Qualität.
Was nicht funktioniert: alles mit Emotion, Kulanz-Entscheidung oder juristischem Einschlag. Und: Agenten die ohne klare Eskalations-Kriterien laufen, sind in drei Wochen ein PR-Problem.
Was du vorab lösen musst: sauberes Ticketsystem, klare Policies („ab welchem Bestellwert wird eskaliert"), Monitoring jeder einzelnen Agent-Antwort in den ersten Wochen, und die Bereitschaft im Team, Policy-Regeln wirklich schriftlich zu haben. Implizites Wissen wird vom Agenten nicht erraten.
Interne Workflow-Orchestrierung mit n8n und Claude
Das ist der Sweet Spot für die meisten Mittelständler. Nicht ein monolithischer Super-Agent, sondern n8n als Prozess-Skelett mit einem LLM als Decision-Node an den Stellen wo Regeln nicht reichen.
Beispiel aus einem unserer Setups: eingehende Lieferanten-Rechnung als PDF. OCR extrahiert Daten, n8n prüft Formalien, ein Claude-Node entscheidet ob die Rechnung zu einer bestehenden Bestellung passt, füllt Verdachts-Felder für Buchhaltung, routet bei Abweichungen an den richtigen Einkäufer. Kein Agent im strengen Sinn, aber agentisches Verhalten an genau den Stellen wo es trägt.
Was funktioniert: Strukturerkennung, Anomalie-Erkennung, Vorausfüllen mit expliziter Human-Freigabe.
Was nicht funktioniert: komplette Autonomie ohne Freigabe. Freigabe-Schwellen solltest du als Unternehmen selbst setzen, nicht der Agent.
Was du vorab lösen musst: sauberes API-Zugriffsrecht auf ERP, Warenwirtschaft und Mail-System. Ohne Zugänge ist jede Agent-Diskussion Theorie.
B2B-Angebotskonfiguration mit Freigaberouten
B2B-Shops mit Kundenspezifika, Staffelpreisen und Freigabeprozessen sind eigentlich Legacy-Use-Cases für Agenten, weil die Regeln komplex sind, sich oft ändern und der Vertrieb jeden Sonderfall anders behandelt.
Ein Agent kann eine Anfrage lesen, aus CRM und ERP die Kundenkonditionen ziehen, ein Konfigurations-Setup vorschlagen, Preise kalkulieren, Rabattlogik anwenden und das Angebot mit Freigabe-Route und Kommentar zurück an den Vertrieb spielen. Der Vertrieb prüft, klickt, verschickt. Aus vier Stunden werden zwanzig Minuten.
Was funktioniert: Vorbereitung, Konfiguration, Preislogik auf Basis dokumentierter Regeln.
Was nicht funktioniert: politische Entscheidungen (der Kunde ist strategisch, Rabatt ist „drin"), Kulanzfälle, Sonderkonditionen die nur im Kopf von Kollege X existieren.
Was du vorab lösen musst: dokumentierte Preislogik. Wenn die Regeln nirgendwo stehen, kann auch ein Agent sie nicht anwenden. Und das ist oft der Moment in dem Unternehmen merken: der Agent ist gar nicht das Problem. Die fehlende Dokumentation ist es.
Das Muster siehst du in allen vier Cases: der Agent ist selten der Engpass. Daten, Rechte, Dokumentation, Monitoring sind es. Wer das vorher nicht sortiert, baut teure Demos.
Grenzen und Risiken, die niemand auf Folie 3 zeigt
Nur damit wir ehrlich bleiben: die Agenten die heute in Produktion gehen, haben echte Grenzen. Wer die ignoriert, zahlt später.
Halluzinationen in autonomen Loops. Ein Chatbot halluziniert einen Satz. Ein Agent halluziniert in Schritt 4, trifft darauf Entscheidung 5, ruft darauf Tool 6 auf und korrumpiert dir eine Datenbank. Fehler pflanzen sich fort. Ohne Grounding (Tool-Use statt Wissen-aus-Gewichten), ohne Validierung nach jedem Schritt und ohne klare Exit-Kriterien baust du eine Fehlerkette.
Kostenexplosion. Ein Agent der ein Ticket bearbeitet macht zwischen drei und vierzig LLM-Calls. Bei einem hohen Ticket-Volumen werden aus niedrigen API-Kosten pro Call schnell Budgets die man vorher besprechen will. Rate-Limits, Caching, kleinere Modelle für einfachere Schritte und ein hartes Monthly-Cap gehören in jedes ernsthafte Setup. Wir selbst kombinieren Claude für Qualitätsentscheidungen mit eigenen GPU-Servern für kosteneffiziente Embeddings und Klassifikation. Nicht aus Prinzip, sondern weil der Unit-Cost sonst nicht rechnet.
Audit-Trail und Nachvollziehbarkeit. Wenn ein Agent eine Entscheidung getroffen hat die später falsch war (Kulanz wurde nicht gewährt, Rechnung wurde fehlgebucht), musst du rekonstruieren können warum. Welcher Prompt, welche Tool-Calls, welche Antworten. Wer das nicht loggt, wird bei der ersten Eskalation ratlos dastehen.
DSGVO bei Cloud-LLMs. Wenn du personenbezogene Daten an OpenAI oder Anthropic schickst, brauchst du AV-Vertrag, dokumentierten Zweck und eine saubere Bewertung. Anthropic und OpenAI haben inzwischen EU-Datenresidenz-Optionen, aber das ist kein Selbstläufer. Bei sensiblen Daten (Gesundheit, Finanzen, Gehälter) prüft man on-premise oder EU-Hosting über Modellanbieter. Wir setzen bei bestimmten Use-Cases eigene GPU-Server ein, nicht aus Kostengründen, sondern aus Compliance-Gründen.
Kein Kill-Switch, kein Agent. Jeder Agent der live geht, muss per Knopfdruck deaktivierbar sein. Auf Feature-Ebene („stopp Retouren-Automatik"), auf Prozess-Ebene („stopp alle Agent-Entscheidungen") und im Extremfall global. Wenn das nicht von Tag 1 definiert ist, geht es vor die Wand.
Kein Agenten-Projekt geht in Produktion ohne die fünf Punkte. Nicht als Bremse, sondern als Voraussetzung.
Make-or-Buy: selbst bauen, kaufen oder pilotieren?
Die Frage wird mir in jedem CTO-Gespräch gestellt und die ehrliche Antwort ist: kommt drauf an. Aber anders als beim Plattform-Vergleich gibt es hier ein paar recht klare Muster.
Selbst bauen lohnt sich, wenn …
- der Use-Case in deinen eigenen Daten wohnt (PIM, ERP, Kundenhistorie) und sich nicht sauber von außen abbilden lässt
- die Regeln business-kritisch und hochspezifisch sind (Shopware-B2B mit eigener Preislogik, Konfiguratoren, individuelle Freigabe-Prozesse)
- du bereits ein Engineering-Team hast das APIs, Deployments und Observability kann, und das Thema strategisch ins Haus will
- Datenhoheit aus Compliance-Gründen Pflicht ist
Bei uns sind das die meisten Agenten die wir bauen, weil im E-Commerce-Mittelstand die spannende Logik immer im Datenmodell steckt und nicht in einem SaaS-Template.
Kaufen lohnt sich, wenn …
- du einen Standard-Use-Case hast (Service-Assistent, E-Mail-Triage, Meeting-Notizen)
- die Anbieter-Tools schon 80% deines Bedarfs abdecken
- du nicht planst aus dem Agent ein eigenes Produkt zu machen
Niemand sollte einen generischen Service-Chatbot from scratch bauen. Dafür gibt es taugliche Lösungen. Aber: jedes SaaS-Agent-Tool bleibt an der Oberfläche deiner Daten. Wenn du tiefe Integration willst, wirst du trotzdem selber Hand anlegen.
Pilotierung mit einer Agentur lohnt sich, wenn …
- du das Thema ernsthaft bewerten willst, aber noch keinen klaren Use-Case hast
- dein internes Team heute mit anderen Themen ausgebucht ist und ein schneller Lern-Zyklus wichtiger ist als Team-Aufbau
- du eine belastbare Make-or-Buy-Entscheidung erst nach einem echten MVP treffen kannst
Unsere Perspektive als dasistweb ist dabei klar: Engineering-Tiefe vor Demo-Eleganz. Wir sind Shopware-Partner seit 2012, Co-Entwickler von Shopware 6, dockware kommt aus unserem Haus, und wir setzen Claude für Qualitäts-Entscheidungen und eigene GPU-Infrastruktur für Cost-Control und Compliance ein. Das ist keine Positionierung gegen die Big-Tech-Agent-Plattformen. Das ist Arbeitsteilung. Microsoft, Salesforce und IBM machen horizontale Plattformen für Konzerne. Wir bauen vertikale Agenten-Lösungen für E-Commerce- und B2B-Mittelstand, weil dort jeder Use-Case eng an die eigenen Daten angelehnt ist.
Ein interner Team-Aufbau macht Sinn, wenn du Agenten als Teil deiner Kern-IT verstehst und sie über Jahre pflegen willst. Dann brauchst du Senior-Engineers mit LLM-Erfahrung, einen Observability-Stack und eine Roadmap. Das dauert. Und während du das aufbaust, passiert am Markt nichts Gutes. Pilotierung mit externer Agentur ist oft der schnellere Pfad zum ersten Ergebnis, das du dann intern skalieren kannst.
Was auch immer du wählst: entscheide nach Use-Case, nicht nach LinkedIn-Post. Kein Agent der für Logistik gebaut wurde passt automatisch auf B2B-Vertrieb. Kein generisches Agent-Framework ersetzt das Domänenwissen im Prozess.
Wie du in 90 Tagen ehrlich startest
Wenn du jetzt sagst „ok, wir probieren das", dann nicht mit einem Moonshot, sondern mit einem sauberen Lern-Zyklus. So laufen die Projekte bei uns:
Woche 1 bis 2: Discovery. Nicht „welchen Agent kaufen wir?", sondern: welche drei Prozesse fressen am meisten Zeit, haben klare Datenquellen und sind reversibel wenn der Agent Mist baut? Gespräche mit Fachbereich, Sichtung der Tickets, Logs, Prozesse. Am Ende steht ein einziger Use-Case, nicht drei.
Woche 3 bis 4: Daten und Zugänge. APIs aufräumen, Rechte-Konzept, Testdaten, Logging. Dieser Schritt wird oft unterschätzt und ist meistens der eigentliche Engpass. Ein Agent kann nur so gut sein wie die Daten die er sieht. Wenn du hier Wochen sparen willst, sparst du sie am falschen Ende.
Woche 5 bis 8: MVP mit Human-in-the-Loop. Der Agent läuft, aber jede Entscheidung geht noch an einen Menschen zur Freigabe. Du sammelst Fälle, trainierst Prompts, definierst Eskalations-Regeln. Niemand geht in diesem Schritt live. Das ist Lern-Phase.
Woche 9 bis 10: Shadow-Mode. Der Agent läuft parallel zum bestehenden Prozess, macht seine Empfehlungen, aber wirkt nicht. Du vergleichst mit den menschlichen Entscheidungen. Hier entscheidet sich ob der Agent wirklich tragfähig ist, oder ob er nur in kuratierten Demos gut war.
Woche 11 bis 12: Schrittweise Autonomie. Freigabe pro Fall-Typ. Erst die klaren Standard-Fälle (Lieferfrage, Retoure nach Schema), dann die komplizierteren. Monitoring bleibt eng. Kill-Switch bleibt drin. Kein Schritt ist irreversibel.
Nach 90 Tagen hast du entweder einen produktiven Agenten für einen Use-Case, oder eine sehr belastbare Entscheidung gegen diesen Use-Case. Beides ist mehr wert als sechs Monate Workshop-Theater.
Unser Tipp: Du brauchst im Projekt von Tag 1 einen Fachbereichs-Lead der Entscheidungen treffen darf. Nicht jemand der Rücksprache hält. Sonst dauert jeder Klärungsschritt drei Wochen und der 90-Tage-Plan wird zu neun Monaten.
Fazit: Agenten sind kein Produkt, sie sind eine Engineering-Disziplin
KI-Agenten sind kein Tool das du einkaufst und einschaltest. Sie sind ein System aus Prompts, Tool-Integrationen, Guardrails, Monitoring und Prozess-Design. Die LLM-Komponente ist austauschbar. Der Rest ist Engineering-Arbeit. Wer das ernst nimmt, bekommt Systeme die tragen. Wer es unterschätzt, bekommt ein Demo-Projekt mit Restlaufzeit.
Für den Commerce- und B2B-Mittelstand heißt das: nicht auf den nächsten Big-Tech-Launch warten. Klein anfangen, richtig anfangen, und einen Use-Case produktiv machen bevor du die Plattform-Entscheidung triffst. Die Unternehmen die 2026 wirklich Vorsprung haben, sind nicht die mit den schönsten KI-Slides. Es sind die, die in sechs Monaten gelernt haben wie sich ein Agent in ihrem Prozess verhält, was er darf und was nicht.
Und wenn du Vergleich und Kontext brauchst: Claude im E-Commerce zeigt wie wir Anthropic-Modelle konkret einsetzen, Agentic Commerce beschreibt was auf deinen Shop zukommt wenn Agenten auf Käufer-Seite einkaufen, und unsere Leistung KI-Implementierung ist der Rahmen in dem wir solche Projekte umsetzen. Alle weiteren Cluster-Artikel findest du in der Themenwelt KI.