Salesforce Headless Experience Layer: Ein Widget für jede KI-Agenten-Oberfläche

Wenn ein KI-Agent eine Frage zu Ihrem Unternehmen beantwortet, ist die Antwort oft ein Textblock. Karten, Bewertungen und Schaltflächen, die Nutzer aus Salesforce kennen, gehen verloren. Teams, die Agenten bauen, haben dann ein zweites Problem: Dieselbe Ansicht muss für jeden Ort neu gebaut werden, an dem ein Agent laufen kann.

Salesforce hat eine Entwickleranleitung zum Headless Experience Layer (HXL) veröffentlicht. Er ist in der Beta. Dieser Beitrag zeigt, was Salesforce über die Funktion sagt, was Sie vor dem Einsatz prüfen sollten und welche Regel unserer Meinung nach jedes Unternehmen zuerst festlegen sollte.

Was hat Salesforce veröffentlicht?

Der Beitrag im Salesforce Developers Blog vom 7. Oktober 2026 beschreibt HXL so.

• Ein Widget einmal definieren. Laut Salesforce definieren Sie ein Widget in deklarativem JSON. Es wird nativ in Agentforce und in jedem Model-Context-Protocol-Client (MCP) angezeigt, der MCP Apps unterstützt.
• Es ist keine LWC und keine React-App. Salesforce beschreibt ein Widget als deklarativen Baum aus Komponenten, den jede Oberfläche nativ darstellt.
• Drei Bausteine. Komponenten sind wiederverwendbare UI-Teile. Widgets kombinieren Komponenten für einen Anwendungsfall. Custom Lightning Types beschreiben die Form Ihrer Daten und legen fest, welches Widget sie darstellt.
• Die Daten kommen aus Ihrer Aktion. Im Beispiel liefert eine Apex-Invocable-Action die Daten. Ein Widget zeigt nur, was die Aktion zurückgibt.
• Zwei Anbindungswege. Für Agentforce wird ein Custom Lightning Type auf die Apex-Klasse typisiert. Für MCP-Clients fügen Sie laut Salesforce zwei verschachtelte Typen hinzu, weil ein MCP-Tool-Aufruf die Ausgabe in einen Umschlag packt.
• Interaktion ist in der Beta begrenzt. Widgets können zwei Client-Aktionen nutzen: sendMessage und openLink.

Was sagt Salesforce zur Sicherheit?

Salesforce nennt als Kernvorteil: Ein Widget zeigt nur, was Ihre Aktion zurückgibt. Wenn die Aktion Freigaberegeln und Sicherheit auf Feldebene durchsetzt, sieht laut Salesforce jeder Nutzer auf jeder Oberfläche nur das, was er sehen darf.

Dieser Satz legt die Sicherheitsarbeit in die Aktion, nicht in das Widget. Ein Widget kann eine Aktion nicht reparieren, die zu viel zurückgibt.

Was sollten Sie vor dem Einsatz prüfen?

Punkt	Was Salesforce sagt
Status	Der Headless Experience Layer ist eine Beta. Sie aktivieren ihn in Setup und akzeptieren die Beta-Bedingungen.
Version	Ihr Projekt sollte API-Version 67.0 oder höher verwenden.
Verlässlichkeit	Das Modell entscheidet weiterhin, wann die Karte gezeigt wird. In den Tests von Salesforce erscheint sie meist bei der ersten Frage in einem neuen Gespräch, Folgefragen kommen manchmal als Text zurück.
Vorschau	Vorschauen im HXL Playground können vom echten Erlebnis abweichen. Testen Sie auf jeder Zielfläche.
Clients	Für die Darstellung über MCP braucht es einen Client, der den MCP-Apps-Standard unterstützt. Salesforce nennt Claude und ChatGPT als Beispiele.

Warum sollten Fachteams das beachten?

Wenn Sie Salesforce betreiben oder einen Partner dafür Agenten bauen lassen, verschiebt sich die Frage von „Kann der Agent antworten?“ zu „Was zeigt der Agent, wem und wo?“

• Eine Definition lässt sich leichter steuern als fünf. Ein Widget und eine Aktion bedienen alle Kanäle, es gibt also nur eine Stelle zur Prüfung.
• Mehr Oberflächen bedeuten mehr Orte, an denen Daten erscheinen. Dieselbe Karte kann jetzt in Werkzeugen auftauchen, die Ihre Mitarbeitenden außerhalb von Salesforce nutzen. Jede davon braucht eine Entscheidung.
• Beta heißt Veränderung. Bedingungen, Grenzen und Verhalten können sich ändern. Ein Plan, der das ausschließt, ist ein Risiko.

Das ist kein Grund zu warten. Es ist ein Grund, festzulegen, wer verantwortet, was ein Agent zeigen darf.

Eine kurze Checkliste, bevor Agenten Ihre Daten zeigen

1. Prüfen Sie zuerst die Aktion. Stellen Sie sicher, dass sie Freigaberegeln und Sicherheit auf Feldebene durchsetzt, bevor ein Widget angehängt wird.
2. Listen Sie die Oberflächen auf. Notieren Sie jeden Agenten und jeden Client, in dem ein Widget erscheinen kann.
3. Legen Sie fest, was auf eine Karte darf. Nicht jedes Feld, das ein Nutzer sehen darf, gehört in ein Chatfenster.
4. Testen Sie auf jeder Zielfläche. Verlassen Sie sich nicht allein auf die Vorschau im Playground.
5. Planen Sie den Text-Fallback. Das Modell kann in reinem Text antworten. Auch diese Antwort muss sicher sein.
6. Benennen Sie einen Verantwortlichen. Eine Person sollte beantworten können: „Welche Widgets sind live, wo, und wer hat sie freigegeben?“

Regel zum Mitnehmen

Bevor ein Agent Salesforce-Daten auf irgendeiner Oberfläche zeigen darf, prüft ein benannter Verantwortlicher die Aktion dahinter und gibt jeden Ort frei, an dem sie erscheint.

Wie Incresco hilft

Incresco ist Claude-Partner. Wir entwickeln Web- und Mobile-Anwendungen, Cloud-Systeme, Salesforce-Lösungen, WhatsApp-Erlebnisse und KI-Agenten. Für Teams, die Agenten auf Salesforce aufsetzen, helfen wir, zuerst die Regeln festzulegen: was ein Agent zeigen darf, wem und wer freigibt. Siehe unsere Leistungen KI-Transformation, Salesforce-Beratung und Systemintegrationen.

Sie planen Agenten auf Basis von Salesforce? Sprechen Sie Incresco an und bitten Sie um eine Prüfung der Agenten-Oberflächen. Wir gehen durch, welche Aktionen Ihre Agenten aufrufen, was jede zurückgibt und wo sie erscheinen kann, und sagen Ihnen, welche Kontrollen zuerst gelten sollten.