Most Agentforce demos look great. Most Agentforce production rollouts look much worse, and the gap between the two is rarely the LLM. It’s the topic and action design, specifically, what context the agent is operating on when it makes decisions, and what guardrails sit between intent and side effect.
We’ve reviewed enough Agentforce engagements over the past year to see the same pattern: agents that work brilliantly on hand-curated demo data, then drift into confident hallucinations the moment they meet a real CRM with messy account hierarchies, soft-deleted contacts, and incomplete activity history.
Two failure modes
Mode one: ungrounded topics. A topic prompt that says “the agent should help with billing inquiries” and trusts the LLM to figure out what billing means in your system. Without an explicit grounding to real Data Cloud DMOs or Salesforce objects, the agent invents plausible-sounding entities. Your users see this as the agent making things up. Your engineers see it as a missing schema.
Mode two: unbounded actions. An action wired to “update the account” with no pre-conditions, no validation, no logging of why the agent decided to call it. The action works ninety percent of the time. The other ten percent silently corrupts your data, and the audit trail is “the agent did it.”
Both come from the same root cause: treating Agentforce like a chat layer instead of a production system that happens to use natural language at the edge.
How to design topics that survive
Topics are contracts. Treat them that way.
- Bind topics to schema, not vibes. Every topic should reference real DMOs or sObjects. The agent retrieves grounded context from named entities, not its training data.
- Constrain the universe. Topic-level filters tell the agent which slice of data is in scope. A “billing inquiries” topic should not see test accounts, archived records, or inactive entitlements unless you explicitly want that.
- Write topic eval cases. For every topic, write five concrete scenarios with expected behaviour and run them on every change. This isn’t testing in the unit-test sense; it’s the closest analogue Agentforce has to integration testing.
How to design actions that don’t lie
Actions are side-effects. Treat them like API endpoints, not natural-language conveniences.
- Pre-conditions. Every action checks the conditions that must be true before it can fire. If they’re not met, the action returns “I can’t do this” to the agent, not silently to the user.
- Post-conditions. Every action verifies the side effect actually landed. A successful return from
updateAccountdoesn’t mean the field changed; it means the API didn’t throw. Verify, then confirm. - Observability. Every invocation logs the topic, the inputs, the user identity, and the result. When something goes wrong (and it will), the audit trail tells you what the agent thought it was doing, and why.
The discipline this requires
None of this is exotic. It’s the same discipline you’d apply to any production service that mutates data on behalf of users. The novelty is that the natural-language interface makes it easy to not apply that discipline, easy to ship a topic that seems to work and find out two months later that it’s hallucinating account hierarchies on partial matches.
We design Agentforce engagements to fail loudly, not gracefully. An agent that confidently does the wrong thing is worse than an agent that says “I don’t know.” The hardest part of the work is making sure your agent says it.