Salesforce Headless 360: Wer rahmt den Aktionsraum des Agenten?

Sales­force hat auf der Trail­blaz­erDX 2026 eine Architek­turentschei­dung angekündigt, die über Pro­duk­t­poli­tik weit hin­aus­ge­ht: Mit „Head­less 360″ wird die gesamte Sales­force-Plat­tform – CRM, Agent­force, Slack – als reine API‑, MCP- und CLI-Infra­struk­tur für AI-Agen­ten zugänglich gemacht. Kein Brows­er mehr, kein grafis­ches Inter­face als primäre Inter­ak­tion­ss­chicht. Marc Benioffs Formel lautet: „Our API is the UI.”

Das ist keine tech­nol­o­gis­che Inno­va­tion. Es ist eine insti­tu­tionelle Weichen­stel­lung – und als solche ver­di­ent sie eine andere Analyse als die üblichen Pro­duk­tankündi­gun­gen.

Von der Benutzeroberfläche zur Agenteninfrastruktur

Was Sales­force vol­lzieht, lässt sich struk­turell als Repo­si­tion­ierung ent­lang der Sys­te­mebene beschreiben: weg vom Sys­tem of Record (Daten­hal­tung) und Sys­tem of Engage­ment (UI-gestützte Men­sch-Mas­chine-Inter­ak­tion), hin zu einem selb­st deklar­i­erten Sys­tem of Exe­cu­tion. Agen­ten sollen nicht mehr nur Dat­en lesen, son­dern Work­flows aus­lösen, Entschei­dun­gen imple­men­tieren, Geschäft­sprozesse autonom weit­er­führen.

Das ist ein Über­gang, der in der Luh­mannschen Sys­temthe­o­rie präzise benan­nt wer­den kann: von Kon­di­tion­al­pro­gram­men zu Zweck­pro­gram­men. Kon­di­tion­al­pro­gramme definieren Wenn-dann-Rela­tio­nen – sie sind regel­ge­bun­den, trans­par­ent, ex ante prüf­bar. Zweck­pro­gramme ori­en­tieren sich an Ziel­er­re­ichung und lassen die Mit­tel­wahl offen. Je mehr ein Agent autonom Work­flows „aus­führt”, desto weit­er bewegt er sich aus der Kon­di­tion­al­pro­gramm-Logik her­aus – und desto dringlich­er wird die Frage, wer die Gren­zen dieser Zielo­ri­en­tierung zieht.

Die ISA-Perspektive: Drei Ebenen, eine Machtfrage

Das Konzept des Insti­tu­tionell Situ­ierten Agen­ten (ISA) unter­schei­det drei oper­a­tive Ebe­nen:

Regel­ge­bun­dene Agen­ten han­deln inner­halb expliz­it definiert­er Para­me­ter. Sie führen aus, was vorgeschrieben ist. Ihr Aktion­sraum ist eng, ihre Legit­i­ma­tion­s­grund­lage klar.

Regelin­tel­li­gente Agen­ten inter­pretieren Regeln kon­textab­hängig, wählen zwis­chen vorgegebe­nen Optio­nen, opti­mieren inner­halb eines definierten Lösungsraums. Ihr Han­deln ist flex­i­bel, aber nicht regelschöpfend.

Rege­len­twer­fende Agen­ten verän­dern die Regeln selb­st – sie passen insti­tu­tionelle Rah­menbe­din­gun­gen an, schaf­fen neue Hand­lungsmuster, gener­ieren Präze­den­zfälle. Hier begin­nt die eigentliche Legit­i­ma­tions­frage.

Sales­force Head­less 360 posi­tion­iert seine Agen­ten expliz­it auf der regelin­tel­li­gen­ten Ebene: 60+ MCP-Tools, 30+ vorkon­fig­uri­erte Cod­ing-Skills, eine Expe­ri­ence Lay­er für die Aus­gabe in Slack oder Teams. Der Aktion­sraum ist reich bestückt – aber voll­ständig von Sales­force definiert. Die rege­len­twer­fende Ebene bleibt insti­tu­tionell ver­schlossen. Kein Nutzerun­ternehmen, kein Drit­tan­bi­eter-Agent, kein reg­u­la­torisch­er Akteur gestal­tet diesen Rah­men mit. Er gehört dem Plat­tform­be­treiber.

Das ist kein Verse­hen. Es ist das Geschäftsmod­ell.

MCP als Standardisierungshebel – und seine doppelte Logik

Das Mod­el Con­text Pro­to­col (MCP) ist ein von Anthrop­ic entwick­el­ter offen­er Stan­dard für die Kom­mu­nika­tion zwis­chen AI-Agen­ten und Werkzeu­gen. Sales­force adop­tiert diesen Stan­dard und baut darüber 60+ pro­pri­etäre Tools. Das Muster ist aus der Plat­tfor­mökonomie ver­traut: offe­nen Stan­dard übernehmen, pro­pri­etär ein­hegen, Net­zw­erk­ef­fek­te nutzen.

Die insti­tu­tionelle Wirkung ist sub­til, aber weitre­ichend. MCP schafft Inter­op­er­abil­ität auf der Pro­tokollebene – Agen­ten ver­schieden­er Herkun­ft kön­nen mit Sales­force-Tools kom­mu­nizieren. Gle­ichzeit­ig definiert Sales­force, welche Tools existieren, welche Aktio­nen möglich sind, welche Dat­en fließen. Der Stan­dard öffnet die Tür; Sales­force entschei­det, was dahin­ter liegt.

Für den ISA-Rah­men bedeutet das: Die Pro­tokoll­stan­dar­d­isierung erzeugt den Anschein insti­tu­tioneller Offen­heit, während die eigentliche insti­tu­tionelle Grenzziehung – was darf ein Agent in diesem Ökosys­tem tun? – weit­er­hin ein­seit­ig fest­gelegt wird. Das ist keine Kri­tik an MCP als Stan­dard, son­dern ein Befund über die Dif­ferenz zwis­chen Pro­tokoll-Inter­op­er­abil­ität und insti­tu­tioneller Gov­er­nance.

Testing Center, Session Tracing, Custom Scoring: Governance als Kontrollarchitektur

Head­less 360 enthält explizite Mon­i­tor­ing-Funk­tio­nen: Test­ing Cen­ter, Ses­sion Trac­ing, Cus­tom Scor­ing für Agent-Mon­i­tor­ing. Diese Fea­tures sind auf­schlussre­ich­er als die Kern­funk­tion­al­ität, denn sie spiegeln eine insti­tu­tionelle Selb­st­di­ag­nose: Sales­force weiß, dass der Shift von regel­ge­bun­den­er zu regelin­tel­li­gen­ter Agen­ten­op­er­a­tion Kon­trol­lver­luste riskiert.

Aus ISA-Per­spek­tive sind diese Tools eine Antwort auf ein Gov­er­nance-Prob­lem, das die Plat­tform selb­st erzeugt. Je mehr Agen­ten autonom in Geschäft­sprozesse ein­greifen, desto weniger reicht Ex-ante-Regel­ge­bun­den­heit als Legit­i­ma­tion­s­grund­lage. Ses­sion Trac­ing ist der Ver­such, Ex-post-Nachvol­lziehbarkeit als Sub­sti­tut zu etablieren. Ob das reg­u­la­torisch aus­re­icht – ins­beson­dere unter DSGVO, KI-Verord­nung und sek­tor­spez­i­fis­chen Com­pli­ance-Anforderun­gen –, ist eine offene Frage, die Sales­force bewusst offen­lässt.

Vendor Lock-in der zweiten Ordnung

Ana­lysten war­nen vor Ven­dor Lock-in und empfehlen mod­erne Data-Stacks als Alter­na­tive. Diese War­nung greift zu kurz. Was Head­less 360 erzeugt, ist kein klas­sis­ch­er Lock-in auf der Datenebene, son­dern ein kog­ni­tiv­er Lock-in auf der Prozess­logik-Ebene.

Wenn Agen­ten-Work­flows tief in Sales­force-MCP-Tools codiert sind – wenn die Hand­lungs­gram­matik des Agen­ten in Sales­force-Kat­e­gorien, Sales­force-Objek­t­mod­ellen, Sales­force-Aktion­sräu­men denkt –, entste­hen Abhängigkeit­en, die nicht durch Daten­mi­gra­tion auflös­bar sind. Die insti­tu­tionellen Muster, die Agen­ten einüben, sind Sales­force-Muster. Das ist Lock-in auf der Ebene der organ­i­sa­tionalen Kog­ni­tion, nicht der Daten­hal­tung.

Dieser Befund ist für Unternehmen rel­e­vant, die AI-Agen­ten nicht als tak­tis­che Tools, son­dern als strate­gis­che Infra­struk­tur betra­cht­en.

Was das für die ISA-Gouvernanzfrage bedeutet

Sales­force Head­less 360 ist ein Lehrbeispiel für eine grundle­gende Span­nung im Enter­prise-AI-Zeital­ter: Die Plat­tfor­men, die Agen­ten-Infra­struk­tur bere­it­stellen, definieren gle­ichzeit­ig die insti­tu­tionellen Gren­zen des Agen­ten­han­delns. Das geschieht nicht durch explizite Reg­ulierung, son­dern durch Architek­tur.

Für eine The­o­rie des Insti­tu­tionell Situ­ierten Agen­ten fol­gt daraus: Die Frage, auf welch­er Ebene (regel­ge­bun­den / regelin­tel­li­gent / rege­len­twer­fend) ein Agent operiert, ist nicht allein eine tech­nis­che Frage. Sie ist eine insti­tu­tionelle Frage – und die Antwort darauf wird zunehmend von kom­merziellen Plat­tfor­man­bi­etern gegeben, nicht von Nutzerun­ternehmen, nicht von Reg­u­la­toren, nicht von ein­er delib­er­a­tiv­en Gov­er­nance-Infra­struk­tur.

Das ist der eigentliche Shift, den Trail­blaz­erDX 2026 markiert. Nicht „agent-first work­flows” als Fea­ture. Son­dern die stille Insti­tu­tion­al­isierung des Agen­ten-Aktion­sraums durch Plat­tfor­mar­chitek­tur.

Ralf Keu­per

Quelle:

Sales­force launch­es Head­less 360 to turn its entire plat­form into infra­struc­ture for AI agents https://venturebeat.com/technology/salesforce-launches-headless-360-to-turn-its-entire-platform-into-infrastructure-for-ai-agents