Agentforce-Design ohne halluzinierten Kontext.

Die meisten Agentforce-Demos sehen großartig aus. Die meisten Agentforce-Produktiv-Rollouts sehen deutlich schlechter aus, und die Lücke zwischen beiden liegt selten am LLM. Sie liegt am Design der Topics und Actions, genauer: an dem Kontext, auf dem der Agent seine Entscheidungen trifft, und an den Schutzmechanismen zwischen Absicht und Nebenwirkung.

Wir haben im vergangenen Jahr genug Agentforce-Projekte gesehen, um dasselbe Muster wiederzuerkennen: Agenten, die auf handverlesenen Demo-Daten brillant arbeiten und in dem Moment in selbstbewusste Halluzinationen abdriften, in dem sie auf ein echtes CRM mit unsauberen Account-Hierarchien, soft-deleteten Kontakten und unvollständiger Aktivitäts-Historie treffen.

Zwei Fehlermuster

Muster eins: nicht geerdete Topics. Ein Topic-Prompt sagt „der Agent soll bei Abrechnungs-Anfragen helfen” und vertraut darauf, dass das LLM herausfindet, was Abrechnung in Ihrem System bedeutet. Ohne explizite Erdung an reale Data Cloud-DMOs oder Salesforce-Objekte erfindet der Agent plausibel klingende Entitäten. Ihre Nutzer sehen darin einen Agenten, der sich Dinge ausdenkt. Ihre Engineers sehen ein fehlendes Schema.

Muster zwei: ungebundene Actions. Eine Action, die auf „Account aktualisieren” verdrahtet ist, ohne Vorbedingungen, ohne Validierung, ohne Logging des Warum der Aufruf erfolgte. Die Action funktioniert in 90 Prozent der Fälle. Die übrigen 10 Prozent korrumpieren still Ihre Daten, und der Audit-Trail lautet: „der Agent hat es gemacht.”

Beide gehen auf dieselbe Wurzel zurück: Agentforce wie eine Chat-Schicht zu behandeln, statt wie ein produktives System, das natürliche Sprache zufällig an seinem Rand verwendet.

Wie man Topics gestaltet, die tragen

Topics sind Verträge. Behandeln Sie sie auch so.

• Bind Topics an das Schema, nicht an Bauchgefühl. Jedes Topic sollte reale DMOs oder sObjects referenzieren. Der Agent zieht den Kontext aus benannten Entitäten, nicht aus seinen Trainingsdaten.
• Begrenzen Sie das Universum. Filter auf Topic-Ebene sagen dem Agenten, welcher Datenausschnitt im Scope ist. Ein Topic „Abrechnungs-Anfragen” sollte keine Test-Accounts, archivierten Datensätze oder inaktiven Entitlements sehen, sofern Sie das nicht ausdrücklich wollen.
• Schreiben Sie Topic-Eval-Cases. Pro Topic fünf konkrete Szenarien mit erwartetem Verhalten, bei jeder Änderung neu durchgespielt. Das ist kein Unit-Testing; es ist die nächste Entsprechung zu Integrationstests, die Agentforce kennt.

Wie man Actions gestaltet, die nicht lügen

Actions sind Nebenwirkungen. Behandeln Sie sie wie API-Endpoints, nicht wie sprachliche Bequemlichkeiten.

• Vorbedingungen. Jede Action prüft die Bedingungen, die erfüllt sein müssen, bevor sie ausgelöst werden darf. Wenn nicht, gibt sie ein „Das kann ich nicht” zurück, an den Agenten, nicht still an den Nutzer.
• Nachbedingungen. Jede Action verifiziert, dass die Nebenwirkung tatsächlich angekommen ist. Eine erfolgreiche Antwort von updateAccount heißt nicht, dass das Feld geändert wurde; sie heißt, dass die API keinen Fehler geworfen hat. Erst verifizieren, dann bestätigen.
• Beobachtbarkeit. Jeder Aufruf protokolliert das Topic, die Eingaben, die Nutzer-Identität und das Ergebnis. Wenn etwas schiefgeht (und das wird es), zeigt der Audit-Trail, was der Agent zu tun glaubte und warum.

Welche Disziplin das verlangt

Nichts davon ist exotisch. Es ist dieselbe Disziplin, die Sie auf jeden produktiven Service anwenden würden, der Daten im Auftrag von Nutzern verändert. Das Neue ist, dass die natürliche Sprache an der Oberfläche es so leicht macht, diese Disziplin nicht anzuwenden, ein Topic auszuliefern, das funktionieren scheint, und zwei Monate später festzustellen, dass es Account-Hierarchien aus Teilübereinstimmungen halluziniert.

Wir gestalten Agentforce-Projekte so, dass sie laut versagen, nicht elegant. Ein Agent, der selbstbewusst das Falsche tut, ist schlimmer als einer, der „Ich weiß es nicht” sagt. Das Schwierigste an der Arbeit ist sicherzustellen, dass Ihr Agent es sagt.