Agentforce oder eigener KI-Agent: konfigurieren oder bauen?

Kurze Antwort: Konfigurieren Sie Agentforce, wenn die Aufgabe eine begrenzte Menge von Aktionen auf Daten ist, die Salesforce ohnehin haelt. Bauen Sie einen eigenen Agenten, wenn nicht die Aktion, sondern das Denken der schwierige Teil ist, oder wenn die entscheidenden Daten ausserhalb des CRM liegen. Ernsthafte Projekte landen meist bei beidem, mit einer bewusst gesetzten Naht dazwischen.

Was ist der tatsaechliche Unterschied?

• Agentforce ist die Agentenschicht von Salesforce. Sie laeuft auf der Atlas Reasoning Engine, wird konfiguriert statt programmiert und erbt Identitaet, Sharing-Modell, Audit-Trail und Limits der Plattform (Agentforce Developer Guide).
• Ein eigener KI-Agent ist Software, die Ihnen gehoert: Ihre Modellwahl, Ihr Retrieval, Ihre Tools, Ihre Orchestrierung, ausgefuehrt wo Sie wollen und gegen die Systeme, die Sie haben.

Der Handel lautet nicht "einfach gegen maechtig", sondern begrenzt und governt gegen unbegrenzt und Ihres. Beides ist ungefaehr in der Haelfte der Faelle richtig.

Wann sollten Sie Agentforce konfigurieren?

Konfigurieren Sie, wenn das meiste davon zutrifft:

• Die entscheidenden Daten liegen bereits in Salesforce oder landen in Data 360.
• Die Arbeit hat CRM-Form: Fallabwehr und Routing, Serviceantworten, Opportunity-Hygiene, Terminplanung, gefuehrte Vertriebsaktionen.
• Die Aktionen sind aufzaehlbar. Sie koennen aufschreiben, was der Agent darf, und die Liste passt auf ein Whiteboard.
• Governance ist die harte Anforderung. Rechte, Sharing und Audit gibt es gratis, weil der Agent in der Plattform lebt.
• Sie haben Admin-Kapazitaet. Wer Flow, Permission Sets und das Datenmodell beherrscht, kommt schneller weiter als ein Engineering-Team ohne Plattformwissen.

Der oft uebersehene Punkt: Ein Agent innerhalb der Plattform erbt deren Sicherheitsmodell. Das im eigenen Stack nachzubauen ist teuer und subtil fehleranfaellig.

Wann sollten Sie einen eigenen Agenten bauen?

Bauen Sie, sobald einer dieser Punkte zutrifft, denn jeder einzelne disqualifiziert einen reinen Konfigurationsansatz:

• Die entscheidenden Daten liegen nicht im CRM. Telemetrie, ERP, Dokumente, Ticketing, ein Data Warehouse, eine Geraeteflotte. Muss der Agent darueber schliessen, ist das CRM eine Quelle unter vielen.
• Das Denken ist das Produkt. Mehrstufige Analyse, Planung, begruendete und gewichtete Empfehlungen, oder alles, wo die Antwort verteidigt und nicht nur ausgefuehrt werden muss.
• Der Prozess ist kein CRM-Prozess. Betrieb, Engineering, Lieferkette, Felddiagnose.
• Sie brauchen Modellwahl. Verschiedene Aufgaben wollen verschiedene Modelle, und diese Entscheidung geben Sie ungern ab.
• Der Agent muss dort laufen, wo die Nutzer sind, und die Nutzer sind nicht in Salesforce.

Welcher eine Test entscheidet die meisten Faelle?

Schreiben Sie die Aufgabe des Agenten als Liste von Aktionen. Gelingt das, und liest oder schreibt jede Aktion etwas, das Salesforce ohnehin kennt, dann konfigurieren Sie. Liegt das Schwere darin, welche Aktion es sein soll, auf Basis von Hinweisen aus mehreren Systemen, dann bauen Sie.

Dieser Test ist schneller als ein Vergleichsprojekt und ehrlich zu den Fehlermodi. Reine Konfigurationsprojekte scheitern, wenn eine begrenzte Aktionsliste doch unbegrenztes Urteil verlangt. Reine Bauprojekte scheitern, wenn ein Team ein Quartal damit verbringt, Sharing Rules, Audit-Trails und Fallmanagement nachzubauen, die es schon gab.

Warum lautet die Antwort meist beides?

Weil die beiden Schichten verschiedene Rollen wollen. Agentforce ist eine gute Oberflaeche: Sie sitzt dort, wo Service und Vertrieb ohnehin arbeiten, mit der Governance der Plattform ringsum. Ein eigener Agent ist ein gutes Gehirn fuer alles, was systemuebergreifend schliessen muss. Verbinden Sie beide, und jeder tut, was er kann.

Diese Naht ist inzwischen ein echtes Plattformthema und kein Behelf mehr. Salesforce liefert Model-Context-Protocol-Schnittstellen im eigenen Werkzeugkasten, darunter einen Salesforce DX MCP Server hinter der naechsten Generation des DevOps Center (Salesforce Help). Agent-zu-Agent-Uebergaben und MCP-Action-Hubs sind der Weg, auf dem ein governter CRM-Agent Spezialagenten aufruft, ohne dass eine Seite die andere schluckt.

Genau diese Architektur bauen wir bei Tekunda am haeufigsten. Wir sind zertifizierter Salesforce SI, ISV und PDO sowie Anthropic-Partner, wir haben als Erste Agentforce Agent-zu-Agent-Orchestrierung und SWARM-Architektur in Produktion gebracht, und wir bauen Headless CRM und MCP-Action-Hubs, damit Agenten von einer Stelle aus systemuebergreifend handeln. Auf der Geraeteseite senkte unsere Arbeit fuer ASSA ABLOY die woechentlichen Faelle von 3.000 auf 350, eine Reduktion um 93% ueber 11.000 Geraete und bis zu 2,5 Millionen Ereignisse pro Woche, in drei Maerkten ohne zusaetzliches Supportpersonal. So arbeiten wir.

Wie entscheiden Sie ohne halbjaehrigen Vergleich?

1. Schreiben Sie die Aktionsliste. Zehn Minuten am Whiteboard, mit den Leuten, die die Arbeit heute machen.
2. Notieren Sie die Datenquelle neben jede Aktion. Zaehlen Sie, wie viele ausserhalb von Salesforce liegen.
3. Fragen Sie, was bricht, wenn der Agent falsch liegt. Grosser Wirkungsradius spricht fuer die governte Plattformschicht.
4. Pilotieren Sie zuerst die kleinere Haelfte. Welche Seite auch begrenzt ist, liefern Sie die aus und lassen Sie die Naht warten, bis der Nutzen bewiesen ist.

FAQ

Reicht Agentforce allein?

Fuer CRM-begrenzte Arbeit auf Salesforce-Daten meist ja. Es reicht nicht mehr, sobald die entscheidenden Belege in Systemen liegen, die Salesforce nicht besitzt.

Kann ein eigener KI-Agent mit Agentforce zusammenarbeiten statt es zu ersetzen?

Ja, und das ist das uebliche Muster. Agentforce haelt die governte CRM-Oberflaeche, eigene Agenten uebernehmen das systemuebergreifende Denken, und beide uebergeben aneinander.

Gibt man mit einem Eigenbau die Salesforce-Governance auf?

Nur wenn man es so baut. Laufen CRM-Schreibzugriffe ueber Plattformaktionen, bleiben Sharing-Modell und Audit-Trail erhalten.

Was ist der haeufigste Fehler bei dieser Entscheidung?

Die Entscheidung nach Kosten. Beide Wege konvergieren bei den Gesamtkosten haeufiger als erwartet; der bleibende Unterschied ist, ob die Arbeit begrenzt ist.

Womit sollte ein erstes Projekt starten?

Mit einem Prozess, der einen klaren Verantwortlichen und eine messbare Ausgangszahl hat. Agentenprojekte, die als Plattformstrategie beginnen, werden selten fertig.