Die alte Welt: Embedded Agents
Vor kurzem haben wir im Customer Service auf Basis unserer FAQ wieder einen Chatbot entwickelt – technisch eine klassische RAG-Lösung: Die FAQs liegen als Markdown vor, werden in eine Vektor-Datenbank geladen und von dort durch einen Agent auf Basis von LangGraph gelesen, aufbereitet und beantwortet.
Der Agent ist in diesem Fall tief in die Lösung eingebettet – quasi beim Kompilieren oder beim Image-Build auf seine Aufgabe festgebrannt. Will man die FAQs erweitern, muss neu indexiert, das Image neu gebaut und neu deployed werden. Will man die Logik ändern, muss am LangGraph-Code geschraubt werden.
Bis vor kurzem war das der einzige Weg. Genau das verstehe ich unter einem Embedded Agent.
Die neue Option: Externe Agents wie Claude
Was aber, wenn man sich das ganze Setup spart?
Ich kann inzwischen Claude als dauerhaft laufenden Prozess starten und ihm einfach einen Ordner mit allen FAQ-Dateien geben. Keine Vektor-DB, kein RAG-Setup, kein Re-Indexing, kein Image-Build.
- FAQ ändert sich? → Markdown-Datei editieren. Fertig.
- Neue FAQ-Kategorie? → Neue Datei in den Ordner legen. Fertig.
- Logik soll angepasst werden? → Skill-Datei (Markdown) ändern. Fertig.
Was vorher Tage an Engineering-Arbeit war, ist plötzlich eine Frage von Minuten – und die Pflege übernimmt im Zweifel das Fachteam selbst, nicht mehr die Entwicklung.
Das spannende Zwischenmodell: Externe Agents an internen Systemen
Noch interessanter wird es, wenn man beide Welten kombiniert. Zwei reale Beispiele:
Beispiel 1: Buchhaltung – Steuerdatei als Schnittstelle
In unserer Buchhaltungssoftware existiert ein interner Agent als LangGraph-Implementierung, der Zahlungsflüsse automatisch den passenden Belegen zuordnet. Das ist die klassische Embedded-Variante.
Gleichzeitig bietet die Software die Möglichkeit, über eine Steuerdatei Belege manuell zu Zahlungsflüssen zuzuordnen. Diese Datei kann von zwei Akteuren befüllt werden:
- Ein Mensch im Buchhaltungsteam, der einen Sonderfall manuell erfasst.
- Ein externer Agent wie Claude, der die Datei programmatisch befüllt.
Beide nutzen dieselbe Schnittstelle. Der externe Agent ergänzt den internen Agent dort, wo dessen Logik nicht greift – etwa bei ungewöhnlichen Buchungsfällen, die in den LangGraph-Flow nicht eingebaut wurden.
Beispiel 2: Chatwoot – Dual-Agent über die REST-API
Ähnlich beim Customer-Service-System Chatwoot (siehe meine vorherigen Beiträge zur E-Commerce-Kundenservice-Optimierung). Auch hier ist intern ein LangGraph-Agent am Werk, der Standardanfragen automatisch beantwortet.
Über den Chatwoot-API-Token kann Claude jedoch zusätzlich von außen über die REST-API Support-Tickets beantworten – ohne dass am internen Agent etwas geändert werden muss. Beide Agenten arbeiten parallel an demselben Ticket-Bestand:
- Der interne Agent übernimmt das, wofür er trainiert wurde.
- Der externe Agent springt für alles ein, was der interne nicht abdeckt – oder erledigt einmalige Sonderaufgaben („beantworte alle Tickets der letzten Woche, in denen Versandverzögerungen erwähnt werden, mit folgender Information”).
Wann welcher Ansatz?
| Kriterium | Embedded Agent | Externer Agent |
|---|---|---|
| Setup-Aufwand | Hoch (RAG, Vektor-DB, LangGraph, Deployment) | Sehr niedrig (Ordner + Skill-Datei) |
| Änderungen am Wissen | Re-Indexing, Re-Deploy | Datei editieren |
| Latenz | Sehr niedrig | Höher (LLM-Call extern) |
| Kosten pro Anfrage | Niedrig nach Setup | Pro Anfrage Token-Kosten |
| Skalierung auf hohe Volumina | Stark | Eingeschränkt durch API-Limits |
| Flexibilität bei Sonderfällen | Gering – nur was eingebaut wurde | Hoch – jeder Prozess möglich |
| Wer pflegt es? | Entwicklung | Fachteam |
Die Faustregel:
- Hohes Volumen, eng definierter Anwendungsfall, niedrige Latenz gewünscht → Embedded Agent.
- Niedriges bis mittleres Volumen, breite oder wechselnde Anwendungsfälle, schnelle Iteration → externer Agent.
- Beste Ergebnisse oft in der Kombination: ein interner Agent für das Standardgeschäft, ein externer Agent als „Joker” für alles, was darüber hinausgeht.
Was bedeutet das strategisch?
Der wichtigste Punkt: Die Entscheidung „eigene Lösung bauen” wird seltener.
Vor zwei Jahren war ein RAG-System der Standardweg, um einer Domäne ein Sprachmodell verfügbar zu machen. Heute ist es in vielen Fällen Overkill. Ein dauerhafter Claude-Prozess mit Zugriff auf einen Ordner deckt 80 % der Anwendungsfälle ab – ohne Engineering-Aufwand und ohne laufende Wartung.
Das verschiebt die Frage von „Wie bauen wir den Agent?” zu „Welche Schnittstellen bieten wir dem Agent an?”. Steuerdateien, REST-APIs, geteilte Ordner – das sind die neuen Integrationspunkte. Und sie existieren in vielen Unternehmen längst, weil sie ursprünglich für menschliche Nutzer geschaffen wurden.
Genau hier liegt die elegante Symmetrie: Die Schnittstelle, die ein Mensch nutzt, ist dieselbe, die ein externer Agent nutzt. Embedded Agents bleiben dort relevant, wo Latenz, Kosten oder Volumen es verlangen – aber sie sind nicht mehr der Default.
Sie überlegen, ob für Ihren Anwendungsfall ein eingebauter oder ein externer Agent der bessere Weg ist? Wir bewerten das gerne mit Ihnen – jetzt Anfrage stellen.