Agentforce oder Copilot Studio: Wann eine offene Self-Hosted-Runtime passt

Kurz gesagt: Geschlossene Suiten gewinnen innerhalb ihres eigenen Ökosystems – wenn Ihre gesamte Welt hinter den Mauern eines einzigen Anbieters liegt. Wenn Daten über mehrere Systeme verstreut sind, in Ihrer Hand bleiben müssen und Sie sich die Modellwahl bewahren wollen, ist eine offene, self-hosted Runtime (oder beides zugleich) die Antwort.

Ein Unternehmen trifft eine Auswahlentscheidung für KI-Agents, die Shortlist ergibt sich ganz natürlich: Agentforce, Copilot Studio, ServiceNow AI Agents. Alle drei stark, alle empfohlen.

Sie hätten fast Agentforce unterschrieben – im CRM-Szenario demonstrierte es am schönsten. Kurz vor Toresschluss stellte ein Architekt eine Frage: „Von den Kundenanliegen, die der Agent für uns bearbeiten soll, muss er die eine Hälfte gegen die Opportunities in Salesforce abfragen, die andere Hälfte gegen Lieferung und Serviceaufträge in unseren Eigenbausystemen. Wie kommt Agentforce an die Hälfte jenseits der Mauer?”

Die Antwort des Vertriebs lautete „dafür gibt es Integration”. Also investierten sie sechs Wochen in einen Integrations-PoC. Das Ergebnis war eindeutig: Es lässt sich anbinden, aber jedes weitere System jenseits der Mauer erfordert das Neuschreiben einer Synchronisation, eine Definitionsausrichtung und die Pflege einer Pipeline, die abreißen wird – und sie hatten sieben, acht Systeme jenseits der Mauer. In diesem Moment erst begriff das Team: Das Problem liegt nicht daran, dass Agentforce nicht gut genug wäre, sondern daran, dass es wie die anderen beiden eine Voraussetzung annimmt, die für dieses Unternehmen nicht gilt.

Die Kosten von sechs Wochen und einem PoC erkauften eine Lehre, die man sich von Anfang an hätte klarmachen können.

Die unausgesprochene Voraussetzung: Ihre ganze Welt liegt hinter einer Mauer

Die Stärke dieser Suiten ist im Kern „optimal innerhalb des Ökosystems”. Agentforce nimmt an, dass Ihre Kunden, Prozesse und Objekte schon in Salesforce liegen; Copilot Studio nimmt an, dass Ihre Zusammenarbeit, Dokumente und Identität in 365 liegen; ServiceNow nimmt an, dass Ihre Prozesse darauf laufen. Gilt die Voraussetzung, sind sie tatsächlich entspannt – Daten vorhanden, Berechtigungen vorhanden, Integration vorhanden, der Agent dockt fast nebenbei an.

Aber diese Voraussetzung gilt für die meisten Unternehmen nicht. Ein reales Unternehmen sieht so aus: CRM von einem Anbieter, ERP von einem anderen, Tickets vom dritten, dazu ein Haufen Eigenbausysteme und Tabellenkalkulationen; sie wollen sich die Modellwahl bewahren, weil Modelle jedes Jahr anders sind; sie unterliegen regulatorischen Auflagen, die Daten dürfen nicht beliebig den Geltungsbereich verlassen. Für ein solches Unternehmen wird „optimal innerhalb des Ökosystems” im Gegenteil zur Beschränkung – weil Ihre Welt schlicht hinter keiner einzigen Mauer liegt. Dass jedes angebundene System jenseits der Mauer eine Pipeline neu zu schreiben verlangt, ist genau die Mauer, gegen die jenes Unternehmen im PoC gerannt ist.

Nebeneinandergelegt: nicht wer besser ist, sondern wer zu wem passt

Dimension	Geschlossene Suite (Agentforce / Copilot / ServiceNow)	Offene self-hosted Runtime (ObjectStack / ObjectOS)
Am besten geeignet für	Geschäft schon stark in diesem Ökosystem konzentriert	Daten über mehrere Systeme verstreut, stackübergreifend, selbst zu halten
Datenort	Anbieter-Cloud	Ihre eigene Infrastruktur
Modellwahl	Tendenz zum eigenen oder gebundenen Modell	Frei wechselbar, Modell außen, Runtime innen
Zugehörigkeit der Geschäftsdefinition	Wächst in der Plattform	Offene-Protokoll-Metadaten in Ihrem Repository (Apache 2.0)
Abrechnung	Pro Aktion / pro Sitzplatz	Nach Runtime und Infrastruktur, vom Volumen entkoppelt
Starthaltung	Erst das Geschäft ins Ökosystem verlagern	Bestandssysteme erweitern, keine Migration vorab nötig

Diese Tabelle hat keine durchweg „richtige” Spalte.

Erst zwei kalte Duschen: Oft sollten Sie die Suite wählen

Sagen wir es gleich vorweg, damit dieser Artikel nicht zur einseitigen Anpreisung wird. Offenes Self-Hosting ist nicht die edlere Wahl, es ist die Wahl für eine bestimmte Situation – und die Situation vieler Unternehmen passt gerade zur Suite.

Erstens: wenn Ihre Welt wirklich im Wesentlichen hinter einer Mauer liegt. Liegen 90 % Ihres Geschäfts in Salesforce, ist Ihnen der Datenabfluss egal und planen Sie keinen Modellwechsel – dann ist Agentforce höchstwahrscheinlich die optimale Lösung. Wegen des noch gar nicht eingetretenen Risikos „nicht eingesperrt zu werden” die ganz reale, gegenwärtige Migrations- und Betriebslast auf sich zu nehmen, lohnt sich nicht.

Zweitens: wenn Sie kein Plattformteam haben. Das ist das klassische „Build vs. Buy”. Offen und self-hosted heißt, Sie müssen es selbst betreiben – patchen, Verfügbarkeit sicherstellen, Upgrades verwalten. Das „out of the box, jemand hebt im Ernstfall ab, durch SLA abgesichert” der Suiten ist für ein Unternehmen ohne dediziertes Plattformteam oft wertvoller und entspannter als „vollständige Kontrolle”. Kontrolle hat Betriebskosten, und Kontrolle, die niemand auffangen kann, ist eine Last.

Aber „die Suite kaufen” erspart weniger Arbeit, als Sie denken

Auf der „Kaufen”-Seite gibt es jedoch eine Rechnung, die oft übersehen wird: die Integrationssteuer.

Auf dem Angebot der Suite steht das Geld für Sitzplätze oder Aktionen, nicht aber – dass jedes Ihrer sieben, acht Systeme jenseits der Mauer eine eigene Integrationspipeline braucht: Beim Bau muss die Definition ausgerichtet werden, nach dem Bau muss sie mit den Upgrades beider Seiten fortlaufend gepflegt werden, und ändert eine Seite ein Feld, reißt die Pipeline womöglich stillschweigend ab. Der sechswöchige PoC jenes Unternehmens am Anfang hat genau die Anzahlung dieser Steuer gemessen. „Die Suite kaufen + ein Haufen zerbrechlicher Integrationen” ist also oberflächlich Buy, im Kern bauen Sie weiterhin – und Sie bauen den wertlosesten, zerbrechlichsten Teil.

Rechnet man diese Integrationssteuer in die TCO ein, hält der Schluss „die Suite kaufen ist entspannter” nur dann, wenn Sie sehr wenige Systeme jenseits der Mauer haben oder diese ohnehin nicht vom Agent erreicht werden müssen. Je verstreuter die Systeme, desto schwerer diese Steuer, desto mehr wird der „Entspanntheits”-Vorteil der Suite abgenagt.

Eigentlich können Sie beides nutzen: Hybrid ist kein Lavieren

Daraus ergibt sich eine Option, die in Auswahldiskussionen lange übersehen wurde: Das muss keine Entweder-oder-Frage sein.

Die pragmatischste Architektur ist oft hybrid: In dem Ökosystem, das Sie wirklich intensiv nutzen, nutzen Sie weiterhin dessen Suite – den Vertriebs-Agent in Salesforce lassen Sie Agentforce machen, das, was es am besten kann; aber auf jener Schicht, die systemübergreifend ist, eine einheitliche Definition braucht und die Daten selbst halten soll, nutzen Sie eine offene, self-hosted Runtime als Bindegewebe. Letztere ersetzt die Suite nicht, sie tut das, was die Suite strukturell nicht gut kann: das über mehrere Mauern verstreute Geschäft zu einer einzigen, von Ihnen selbst gehaltenen, mit Berechtigungen und Audit versehenen, einheitlichen Definition zusammenzuführen.

Anders gesagt: Die offene Runtime kann das Bindegewebe über Ihren mehreren Systemen (einschließlich jener Suiten) sein, statt noch einer Mauer, in die Sie umziehen sollen. Erkennt man das an, wird aus der Auswahl von „auf welchen Anbieter setze ich” ein „welcher Teil per Suite, welcher Teil offen” – und genau so sieht es bei den meisten realen Unternehmen am Ende in der Umsetzung aus.

Was offenes Self-Hosting konkret einbringt

Wenn Sie zur rechten Spalte gehören oder genau jene systemübergreifende Verbindungsschicht bauen müssen, dann bringt „offen + self-hosted” kein Pathos ein, sondern konkrete Fähigkeiten. Am aussagekräftigsten ist seine Haltung gegenüber Bestandssystemen – genau die Stelle, an der jenes Unternehmen am Anfang feststeckte.

Die Suite will, dass Ihre Welt in ihre Mauer einzieht; die offene Runtime nimmt an, dass Ihre Welt von Natur aus verstreut ist, und ihre Aufgabe ist, bestehende Systeme nativ KI-fähig zu machen, statt erst zu migrieren. Die Kundendaten jenes Unternehmens lagen zur einen Hälfte in Salesforce, zur anderen in Eigenbausystemen. Auf ObjectOS kann es beide Seiten als Datenquellen anbinden, jeweils als Objekte modellieren und sie über einen gemeinsamen Schlüssel – die USt-IdNr. – zu einem einzigen, mit Berechtigungen und Audit versehenen „Kunden” zur Deckung bringen:

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: 'Kunde',
  fields: {
    name: Field.text({ label: 'Kundenname', required: true }),
    tax_id: Field.text({ label: 'USt-IdNr.' }), // gemeinsamer Schlüssel, um systemübergreifend „denselben Kunden" zur Deckung zu bringen
  },
});

Der Unterschied lässt sich an einer einzigen Frage festmachen. „Lohnt es sich, in diesen Kunden Ressourcen zu stecken, um ihn zu halten?” –

• Vorher: Der Agent ist an Salesforce angebunden, sieht aktive Opportunities und antwortet „lohnt sich”; er weiß überhaupt nicht, dass die Lieferung an diesen Kunden im Eigenbausystem ständig verzögert ist und die Serviceaufträge sich stauen.
• Nachher: Der Agent steht einem vereinheitlichten Kunden gegenüber, sieht Opportunity, Lieferung und Serviceaufträge zusammen und antwortet „die Opportunity ist gut, aber das Lieferrisiko ist hoch, lösen Sie erst die Erfüllung, bevor Sie über Upselling reden”.

Dasselbe Modell, dieselbe Frage; allein weil der „Kunde” unter seinen Füßen nicht mehr von einer Mauer zerschnitten ist, wird aus einem einseitigen Schluss ein globaler. Und das alles, ohne für jedes System jenseits der Mauer eine Synchronisationspipeline neu zu schreiben – die Geschäftsdefinition sind diffbare, migrierbare Metadaten in Ihrem Repository; die Runtime läuft auf Ihrer eigenen Infrastruktur, erzwingt Berechtigungen, zeichnet Audits auf; das Modell kann von außen, von jedem beliebigen Anbieter kommen. Sie haben „die Definition Ihres eigenen Geschäfts” keinem einzigen Anbieter zur Verwahrung übergeben.

Eine ehrliche Auswahlfrage

Das ist also kein „wer soll aussortiert werden”, sondern ein „welcher Teil wird wem übergeben”. Stellen Sie sich drei Fragen:

1. Liegt mein Geschäft im Wesentlichen in einem einzigen Ökosystem, oder ist es über mehrere Systeme verstreut?
2. Kann ich akzeptieren, dass Daten fortlaufend in die Anbieter-Cloud fließen? Kann ich das in puncto Compliance unterschreiben?
3. Habe ich ein Team, das eine self-hosted Runtime betreiben kann?

Tendieren die ersten beiden Antworten zu „verstreut, kann nicht” und die dritte zu „habe ich” – dann suchen Sie von vornherein keine weitere, stärkere geschlossene Suite, zumindest nicht auf jener systemübergreifenden Schicht. Tendieren alle drei Antworten zur anderen Seite, dann nutzen Sie ruhig die Suite, die sind wirklich brauchbar. Sich ehrlich einzuordnen oder sie gar großzügig zu mischen, ist weit wichtiger, als hinterherzujagen, wessen Funktionsliste neuer ist – und weit billiger, als es erst nach sechs Wochen PoC zu begreifen.

Schlusswort

Die geschlossene Suite gewinnt mit „optimal innerhalb des Ökosystems”, ein Vorteil, der sehr real ist, solange seine Voraussetzung gilt, und der nicht geleugnet werden sollte. Die offene self-hosted Runtime gewinnt mit „gilt auch dann noch, wenn die Voraussetzung nicht gilt” – wenn Ihre Welt verstreut ist, die Daten selbst zu halten sind, das Modell frei sein soll, die Definition in Ihrer eigenen Hand bleiben soll, und Sie die Verantwortung tragen können, sie selbst zu betreiben.

Zu wissen, welcher Teil per Suite, welcher Teil offen laufen sollte – und welchen Preis man jeweils dafür zahlt – ist wichtiger als die Funktionsliste irgendeines Anbieters. Hätte jenes Unternehmen am Anfang jene drei Fragen früher gestellt, hätte es sechs Wochen und einen PoC gespart.

npm i -g @objectstack/cli && os start

Ohne Migration, ohne in jemandes Mauer einzuziehen, bringen Sie in fünf Minuten in Ihrer eigenen Umgebung ein einheitliches Objekt zum Laufen, das zwei Systeme überspannt, und beurteilen Sie dann, ob dieser Weg eher dem ähnelt, was Sie suchen.