What We've Learned Shipping Agentforce Agents to Production
What it actually takes to ship Agentforce agents to production.
Designing Agents Around Topics, Not Features
The fastest way to ship a brittle agent is to design it the way you'd scope a feature backlog. Agents don't behave like deterministic software, so the unit of design has to change. We start with topics, the bounded jobs an agent is trusted to handle, before we write a single action.
Scoping Topics That Actually Hold Up
A topic is a promise about what the agent will and will not attempt. When that promise is vague, the agent improvises, and improvisation is where trust breaks down. We keep topics narrow enough to reason about and explicit about their boundaries so the planner has somewhere clean to route every request.
Define each topic by the decision it owns, not the data it touches, so two topics never compete for the same request.
Write the out-of-scope cases first, because what an agent refuses to do is as important as what it handles.
Pressure-test topics against real transcripts, not invented prompts, so the boundaries reflect how people actually ask.
Grounding Agents in Trusted Data
An agent is only as credible as the data behind its answers. Hallucination in an enterprise setting is not a quirk, it is a liability, and the fix is almost always grounding rather than a better prompt. We connect agents to governed sources and design retrieval so the agent cites what it knows and stays quiet about what it doesn't.
Route knowledge through controlled sources with clear ownership so answers trace back to a system of record.
Use retrieval that returns passages with provenance, which lets the agent ground a claim instead of inventing one.
Build a graceful fallback for low-confidence cases, because a clean handoff beats a confident wrong answer every time.
The Shift from Clicks to Agent Script
For years, Salesforce work meant clicking through Setup. Agentforce changes that posture. With Agent Script now open and agents treated as buildable artifacts, the teams moving fastest are the ones who stopped configuring and started engineering.
Deterministic Control Where It Matters
The appeal of Agent Script is that it gives you deterministic control over behavior that used to be left to chance. Some steps in a workflow cannot be probabilistic. Approvals, eligibility checks, and anything touching money need to run the same way every time. We use scripted control for those paths and reserve model reasoning for the parts that genuinely benefit from it.
Script the steps that carry compliance or financial weight so they execute identically on every run.
Let the model handle interpretation and phrasing, where flexibility is an asset rather than a risk.
Keep the boundary between the two visible in the design, so future maintainers know which logic is fixed and which is fluid.
Treating Agents Like Software, Not Configuration
Once an agent is code, it inherits the discipline of code. That is a feature, not a burden. We version agents, review changes, and test them the way we would any production system, which is what lets us ship updates without holding our breath.
Put agent definitions under version control so every change has an author and a history.
Build a test suite of representative conversations and run it before any deployment.
Stage changes through environments rather than editing live, because a regression in an agent is a regression your customers feel.
Distribution Through AgentExchange
Building a great agent is half the work. Getting it in front of the people who need it, and not rebuilding the same thing twice, is the other half. AgentExchange has matured into a real distribution surface, and that changes how we decide what to build at all.
Why the Marketplace Changes the Build Decision
When the ecosystem already offers thousands of apps, agents, and connectors, the question shifts from "can we build this" to "should we." Salesforce has grown AgentExchange into a marketplace spanning its app catalog, Slack apps, and a deep library of agents, tools, and MCP servers. We treat it as the first place to look before committing engineering hours to something the ecosystem already solves.
Check the marketplace before building integrations that partners already maintain and support.
Favor connecting proven components over recreating them, so your team's effort goes to genuinely custom work.
Weigh the cost of owning a connector for years against the cost of adopting one that someone else keeps current.
Packaging Internal Wins as Reusable Assets
The flip side is that the work you do once can serve you many times. We learned this building InsightForce, our Slack-native Agentforce intelligence layer, which started as an internal solution and became a reusable product. The discipline of packaging an agent for reuse forces a level of clarity that one-off builds never demand.
Design internal agents as if a stranger will configure them, which makes them portable from day one.
Document the assumptions and dependencies, so the agent survives a handoff or a new environment.
Treat your best internal builds as candidates for the wider ecosystem, because a problem you solved is usually one others share.
