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 hält. Bauen Sie einen eigenen Agenten, wenn nicht die Aktion, sondern das Denken der schwierige Teil ist, oder wenn die entscheidenden Daten außerhalb des CRM liegen. Ernsthafte Projekte landen meist bei beidem, mit einer bewusst gesetzten Naht dazwischen.

Was ist der tatsächliche Unterschied?

• Agentforce ist die Agentenschicht von Salesforce. Sie läuft auf der Atlas Reasoning Engine, wird konfiguriert statt programmiert und erbt Identität, Sharing-Modell, Audit-Trail und Limits der Plattform (Agentforce Developer Guide).
• Ein eigener KI-Agent ist Software, die Ihnen gehört: Ihre Modellwahl, Ihr Retrieval, Ihre Tools, Ihre Orchestrierung, ausgeführt wo Sie wollen und gegen die Systeme, die Sie haben.

Der Handel lautet nicht "einfach gegen mächtig", sondern begrenzt und governt gegen unbegrenzt und Ihres. Beides ist ungefähr in der Hälfte der Fälle 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, geführte Vertriebsaktionen.
• Die Aktionen sind aufzählbar. Sie können 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-Kapazität. Wer Flow, Permission Sets und das Datenmodell beherrscht, kommt schneller weiter als ein Engineering-Team ohne Plattformwissen.

Der oft übersehene Punkt: Ein Agent innerhalb der Plattform erbt deren Sicherheitsmodell. Das im eigenen Stack nachzubauen ist teuer und subtil fehleranfällig.

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 Geräteflotte. Muss der Agent darüber schließen, ist das CRM eine Quelle unter vielen.
• Das Denken ist das Produkt. Mehrstufige Analyse, Planung, begründete und gewichtete Empfehlungen, oder alles, wo die Antwort verteidigt und nicht nur ausgeführt 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 Fälle?

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 Oberfläche: Sie sitzt dort, wo Service und Vertrieb ohnehin arbeiten, mit der Governance der Plattform ringsum. Ein eigener Agent ist ein gutes Gehirn für alles, was systemübergreifend schließen 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 nächsten Generation des DevOps Center (Salesforce Help). Agent-zu-Agent-Übergaben 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 häufigsten. 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 systemübergreifend handeln. Auf der Geräteseite senkte unsere Arbeit für ASSA ABLOY die wöchentlichen Fälle von 3.000 auf 350, eine Reduktion um 93% über 11.000 Geräte und bis zu 2,5 Millionen Ereignisse pro Woche, in drei Märkten ohne zusätzliches Supportpersonal. So arbeiten wir.

Wie entscheiden Sie ohne halbjährigen 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. Zählen Sie, wie viele außerhalb von Salesforce liegen.
3. Fragen Sie, was bricht, wenn der Agent falsch liegt. Großer Wirkungsradius spricht für die governte Plattformschicht.
4. Pilotieren Sie zuerst die kleinere Hälfte. Welche Seite auch begrenzt ist, liefern Sie die aus und lassen Sie die Naht warten, bis der Nutzen bewiesen ist.

FAQ

Reicht Agentforce allein?

Für 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 übliche Muster. Agentforce hält die governte CRM-Oberfläche, eigene Agenten übernehmen das systemübergreifende Denken, und beide übergeben aneinander.

Gibt man mit einem Eigenbau die Salesforce-Governance auf?

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

Was ist der häufigste Fehler bei dieser Entscheidung?

Die Entscheidung nach Kosten. Beide Wege konvergieren bei den Gesamtkosten häufiger 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.