Salesforce Agentforce: Lessons Learned for Developers

Agentforce, Salesforce's own AI product, has been through two solid years of iteration. The launch hype seems to be cooling, which is usually when a product gets interesting, because you can finally see what the team got wrong and what they changed in response. If you build or implement AI on the platform, that record is worth more than the keynote was.

What follows comes out of Salesforce's own trial and error, and it sticks to the technical and operational problems they ran into.

The iterative journey of Agentforce

Agentforce has shipped in a lot of versions, each one adding features, agents, and architectural changes. Where it stands now: Agentforce 360, announced at Dreamforce 2025, covers the Agentforce 360 platform, Data 360, the Customer 360 apps, and the Slack integration. Headless 360, announced at TrailblazerDX 2026, then exposed that AI through MCP so agents can reach it across the rest of the functionality.

Slackbot, Claude Tag, and Agentforce Coworker arrived in quick succession, and pricing recently moved to a pay-per-resolution model. Salesforce is still working out what Agentforce is worth and how to deliver it. That is progress, but it is also a reminder that getting this class of AI to market is hard even for the vendor that owns the platform.

Key challenges and Salesforce's learnings

Paul O'Sullivan, SVP of Solution Engineering at Salesforce, talked about the development journey. The problem he keeps returning to is the pace of change in AI, and whether internal teams and customers can absorb it.

Mistake 1: Underestimating the human and operational impact

Salesforce took a while to accept that AI transformation is a technology problem, a people problem, and an operating model problem at the same time. Early on the weight sat on the technology, and the adoption strategy was weaker for it.

For developers and architects, that means budgeting for change management alongside the build: training, redesigned workflows, and users who actually want the thing. The technology has to fit the human processes already in place rather than tear them up.

Mistake 2: Rushing ahead without grounding in business context

There was a pull toward pushing advanced frontier models out without grounding them properly in a specific business context and a specific objective. That gets you something technically impressive that nobody downstream can use.

Build for the customer's business instead. Deep data integration, a real understanding of the problem being solved, and responses and actions tuned to concrete goals. A generic model where a context-aware one is needed wastes everyone's time.

Mistake 3: The "hallucination" pitfall and accuracy drop

Internal agents, Salesforce's own Help Agent among them, tested well on accuracy early on. Once they went generally available, accuracy dropped noticeably. Two things sit behind that: LLMs still hallucinate, and a controlled test environment looks nothing like the spread of data real users throw at an agent.

Know what you are trading when you pick a model. Flexible LLMs are unpredictable, while more deterministic models give you control and reliability where a task cannot afford to be wrong. Salesforce has moved toward deterministic models for certain functions, which tells you which way that trade-off went for them.

Test the way production behaves: varied data sets, edge cases, different operational loads. Accuracy metrics need to keep being measured after deployment, not signed off before it.

Then build the guardrails and the error handling. Hallucinations need something to push against, and for an agent that faces customers, you cannot skip that work.

The role of Forward Deployed Engineers (FDEs)

Salesforce's Forward Deployed Engineer team sits between the new AI technology and what customers actually deploy. FDEs work across product and services, get a customer's first agents live, and carry feedback back into the product. The team has grown fast, which says plenty about how much specialist help AI integration currently needs.

For technical architects, the FDE model is a hint: complex technology tends to need a dedicated role or team before it gets adopted. Worth deciding early where that expertise comes from on your side, whether you hire it or borrow it.